Glorified Plumbing

Do you ever get involved in a project and find its scope, and your role starts expanding rapidly? That’s where I am today on so many levels. I was at a career junction, and I opted for “a bit of a break.” I wanted to work on a personal project, related to my profession, and then spend some time getting the right job for me. Those plans have gone sideways, as I got involved in some side work for a friend’s new venture, which slowed down the need for a full-time job. Concurrent with this came an opportunity to work with a career coach who has been helping me polish my résumé and LinkedIn profile alongside getting me updated on job search and interview techniques.

I’m not sure how to identify what I’m doing right now. Am I having a “gap year”? Is this a year-long sabbatical? Am I being an entrepreneur, or am I a co-founder of a new company? If this is taking a break, I’ll be happy to get back to work for a bit of a rest.

Taking a Sabbatical

The initial focus of what I can clearly state was “my sabbatical” was a three-month writing exercise. The three months were a solo effort in which I built the structure for and populated 1/3 of a book about embedded debugging. Maybe I should have had someone help review and edit the book on a weekly basis, but I elected to build a prototype and get feedback on that version. As I was working on it, I realized how much pre-requisite knowledge was needed, and I started to see feature creep in the book’s scope. I’d time-boxed the project to three months, which seemed reasonable for a career break and aligned with the severance pay. It was a good, healthy reset, and I was ready for the job search when that milestone was reached.

That’s when the other runaway project happened. I had talked with my friend about their project for about six months. I’d seen the white paper and patent application. I’d read around on the industry and saw the idea as not too crazy; it might just work. As I was ready for work, they had just made the first hardware prototypes and wanted firmware. Well, guess who is a firmware whiz? We negotiated terms, and I started work. This meant board bring-up followed by driver selection and preparing a software platform for the hardware evaluation. I did some extended trials to see if we got credible data and the overall system concept would work. Nothing was unreasonable about the project or scope of work to this point. I took on this challenge for fun, knowing if I got any payment, it would be down the road. A practical project would round out my sabbatical period nicely, even if it meant extending it by six weeks.

Falling Into a Startup

The next step was for me to design the next iteration of the system. I wouldn’t have to CAD the board, but I would select any replacement or additional components. I was ready for that phase, but then we started looking at adjacent problems our system could solve. Around this time, I was asked if I wanted to join the company, looking after all the technology. Great, stepping up from just a jobbing embedded engineer to the embedded systems lead role was just what I was looking for. Sure, I was still the one doing all the coding, but I was also now in the position to do all the strategic planning for the development roadmap and take on the system architecture. It’s not a big step for me; I’ve done this before.

As we court funding, we need another level of planning. Not only do we need to know what our technology and product roadmaps will look like, with a gross estimate of how long it will take, but now they want to have a team roadmap. What talent will we need, and when? What dollar budget do we need? Now, we are reaching beyond what I’ve done before.

The (Re-)Learning Curve

For the planning, I need more precise requirements, so I don my systems analyst hat and start on that. I can write good requirements documentation if you want a very 1990s style. I have been handed requirements in the form of user stories in the past. As an engineer, at first, they felt nebulous and artsy-fartsy, but I really came to appreciate them. They justify the need and a metric for success. Reading a user story and implementing it is a very different skill from composing one. So, I have to learn some skills. Of course, user stories are not complete requirements; there are hard numbers involved, so we need to build up our specifications; therefore, some traditional analysis is still required.

Writing style and current methodologies are not the only things I have to learn. I’m returning to an industry (ITS/IVHS) after a 25-year gap, so I must re-learn the vocabulary. We are also pitching to an adjacent industry (railroads) with its own lexicon. You can imagine how many industry articles I’m reading to ensure we align our solution to needs. Each time an engineer changes industry, they have this learning curve; this time, for me, it’s on top of taking on the new role of lead engineer/technologist, too.

I started planning the roadmaps and architecture, and I found that MS Word and Excel only go so far to support my needs. Sure, if they are your bread and butter, you can use them, but I come from a world of Jira and Confluence. I can work better at requirements capture and task planning with those tools, but I’ve typically been in places where we had IT and Project Management teams to support those tools and a paid account with access to premium features. I’m now IT and PM for the team, and we are using the free versions, so I have to learn how to administer these tools and train any users in our small team who are not familiar with them. Maybe I should have stayed with Word and Excel, but they were slowing me more than expanding my role did. I am using Jira Epics and Tasks, using this work planning tools to do the gross level functional decomposition of the system. I’d be doing that breakdown as part of the design effort; doing it in Jira naturally provides the tasks to assign and can also directly feed the Gantt chart tool for stakeholders to see what is ahead of us.

Starting Up a Start Up, or Two

This is when I got the real shock of how things were rolling. In the quest for finance, we need executive officers. As the only engineer on the project, my function is to actualize our aspirations as a working system. I assumed that meant I was the lead engineer, the architect, or maybe the chief engineer. As discussions unfolded, I started hearing that I needed a loftier title; I feared Director or VP, but no, I was told that the company required a CTO, and I was the best pick.

Oh, but there is more. As the project concepts firmed up, we saw how each played into its own space. As the company structure was evolving, looking at exit strategies, we saw that separating the IP into different entities would be best. This means I have a part-time position concurrently in two start-up projects. Thankfully, I’m splitting my time between them in the granularity of months, not hours, and the learning is shared between the two, with overlapping skill sets and technical needs.

I was looking for a nudge up the ladder, but this acting/accidental CTO thing is a bit overwhelming. They are both small companies, where guys like me become the de facto CTO until we get some funding, at which point we step back into the shadows as project leads as layers are added above and below us. There’s even more learning associated with the role, especially in business skills.

An Accidental CTO

I know the role is just lead engineer, but with slightly broader responsibilities, the title is a formality. That doesn’t stop me from having worries. Accidental CTOs apparently suffer imposter syndrome. I actually started feeling a bit out of my depth, so searched online for “Accidental CTO”; turns out that’s a real phrase used by others, and some, like CTO Acamademy, have made a business of it, to help folks like me.

I am happy to deal with all the technical side of the role. I can even write job descriptions for who we must add to the team as we grow. I can help with white papers for our marketing team. When I get a team, I know I can mentor them, I can share the workload, I’ll know who to trust with which task. But, like many engineers, I’m not sure about managing people. But, there are no people yet. I’m just doing strategies;

• What products do we make to solve the problem we are tackling?
• Which should we develop first for a sensible growing ecosystem?
• What technologies and specific components will we be using?
• Who should be on the team?
• What tools do we need?
• What software do we write?
• How do we model our system?
• How do we validate and QA?
• How long will this take?

Can someone else do the hiring, firing, and wrangling of clashing personalities for me, please? And when we get this thing rolling, I’d like the structure to evolve around me, not below me.

Personal Branding and Current Position

I’m feeling very entrepreneurial right now. So, am I still on a sabbatical, or am I really working? It’s hard to tell the difference; both fill my days fully; both give me a feeling of autonomy and fulfillment, neither is relaxing though.

But how do I sell 2024 to the outside world? Right now, I think I’m still in my gap year, working on projects I enjoy rather than projects that pay the bills. I might still be on sabbatical, taking time for personal growth by “playing at” a senior role and learning new tech and skills. But I’m also working; I am contributing to two entities. These positions both feel like technical advisors since we are still in the definition phase rather than the execution of implementation.

Wrapping Up

I made every step of this journey with my eyes wide open. It is, though, a journey on a snaking mountain road, where you occasionally see peaks in every direction, but mostly, all you see is the next curve or crest. It’s not a straight road across the plains, with a distant city skyline clearly 20 miles ahead. I’m enjoying the voyage. I am sometimes left breathless, literally by a steep ascent or metaphorically by a broad vista.

If you have taken this path before me, I’d love to know what potential perils, pitfalls, pleasures, and rewards are potentially ahead. If you are at the trailhead, about to start out, I wish you every success.

---

About The Photographs

I personally shot all three photographs featured in this piece.

• The typewriter was captured inside Old Parliament House in Canberra during a whirlwind tour of NSW, ACT, and Victoria in 2018. Although I use a PC for writing, I don’t have any cool photos of my laptop—it’s just a boring old thing.
• The model trains are actually two pairs of chopsticks that I picked up at a railway museum just outside Tokyo. I squeezed in this cultural side trip during a business journey. I first fell in love with “bullet trains” as a child of about five, poring over them in a railway book, so seeing them at the museum was a dream come true. As compact souvenirs, I chose chopsticks representing both the classic and the contemporary versions of these iconic trains.
• Hetch Hetchy Reservoir, captured in the backdrop of a mountain trail, perfectly symbolizes the ups and downs, the twists and turns of my narrative. The path, with its kinks and meanders, sometimes fording streams or crossing bridges misted by waterfalls, seemed an apt metaphor for the journey I describe.