This is a short excerpt from an online book I’m currently writing called CTO Patterns. The book-to-be is full of advice for building and managing engineering teams at startups. Some of it is my own; some has been borrowed from much wiser people. Let me know if you have any feedback!
I remember vividly the feeling I got when I was put in charge of my first real team of engineers. I got pulled into an unscheduled meeting with our CEO and COO on a Wednesday afternoon. They told me that my boss - our company’s Head of Engineering - was leaving in two weeks and that they wanted me to take over his role.
I had managed small teams of writers in college and just afterward, and I started this job managing a couple contractors overseas, but leading and building our engineering team of five at a quickly growing startup felt like a big leap. How would I get the team to respect me? I was younger than most of them, and hadn’t really been a developer that long. Would I have the courage to stand up for their interest in company meetings? How would the new engineers feel about getting a new boss just after they started work?
The company’s makeup had dramatically changed over my first year and a half there, and now, just as things were starting to stabilize and our engineering team was picking up steam, our leader was moving on and I was going to have to step up.
I’m an ambitious individual, so you might think I was excited - and maybe part of me was - but the only feeling I vividly remember was fear.
I walked out of the meeting with the founders a bit shaky and tried to focus on getting some work done for the rest of the day. I went home and kept my girlfriend up late talking about what I should do and how I was going to deal with this new role. I felt completely unprepared and uncertain.
I’ve talked to countless CTOs and engineering managers since then, and I now realize that this feeling of inadequacy is far from exceptional. In fact, most people will have this feeling at some point in their career, which is why we have a name for it: imposter syndrome.
I’m not going to try to give you a cure-all for this feeling. If it’s your first time managing a team, you’re probably going to get it at some point, and hopefully you have a supportive network of mentors within and outside your company to help you out.
That said, here’s what has helped me keep imposter syndrome from paralyzing me:
1. Talk through the feelings
Having people around you who you trust and can go to when you feel overwhelmed or unworthy is the biggest career asset you can have. I have a few close mentors who are years ahead of me on the leadership journey, a wonderful fiancee who also holds a position of leadership in her profession, and have had great coworkers at various places along the way.
It’s hard to admit that you don’t feel adequate for your job, but it’s okay. Remember 70% of people have felt this way, so chances are that your support network has been in your shoes.
2. Keep the big picture in mind
Going back to my point in chapter 2, most of the little decisions you make during a typical week are not actually as big a deal as you think they are when you visualize the big picture. Your company may succeed or fail, but it’s unlikely that you will be the sole root cause of either of those. If you feel like you are, ask your leadership team how they feel about it. If they feel like you’re the right person for your job there’s probably a reason for it.
3. Be honest with your team
Finally, I am honest with my teammates in one-on-ones and group settings. When I don’t know the best decision to make, I tell them. This is a sign of humanity, not weakness, and it increases their empathy for you as a leader. It also gives them a chance to step up and help you out if they know you feel a bit overwhelmed.
Leaders often must make decisions with incomplete information. When I joined The Graide Network in 2016, I spent a lot of time talking with the founders about the requirements of their platform. The first version was unreliable and had fundamental flaws in the way data was stored, so like many companies dealing with a legacy software stack, we faced a choice between rebuilding or refactoring.
Rebuilding meant we could throw the mess out and restart the project based on the features we knew it had to have. We could eliminate inefficiencies, unit test everything, and in three to six months, probably be back where we started.
Refactoring would be a longer, but likely safer road. Every project has the spec that engineers know about and the spec that is locked away in the business team’s mind. What I mean is that even if we attempted to catalog all the features of The Graide Network’s platform, we’d constantly be discovering or remembering new ones.
This system was over a year old and had undergone many upgrades, so things were patched on top of each other in a way that made relying on the code for spec nearly impossible. Rebuilding from the ground up would likely take longer than we thought, and making reasonable estimates was impossible. Plus, we’d have to maintain the older system while the new one came online, and that would only slow things down more.
I did not have a template for dealing with this kind of problem yet, and the rest of my team was not technical, so they really didn’t know where to start. This wasn’t my first time dealing with uncertainty though, so I had an idea of where to start with making this decision.
1. Gather details
Details of a problem come in two flavors: technical and non-technical. Gathering them can mean talking to team members or customers, reading articles or books, or even trying one or two things out. Pulling together information is a great first step in conquering uncertainty, but here’s the catch: you have to set a limit for yourself.
“Analysis paralysis” is a term used for being unable to act because you’re so focused on gathering or analyzing data that you can’t commit to a path. The reason you don’t want the detail gathering phase of your decision making to take too long is that at a certain point, you really can’t absorb and weigh any more information than you already have. Set yourself a time limit, go learn all you can about your problem, then move on.
2. Talk to your mentors
While a great mentor might not have a solution to your particular problem, they’ll usually help you put it into perspective or help you remember your priorities.
A while back I was weighing letting an employee go. He was hired to do a very specific job and was mostly self-managing his priorities and timeline (that hire itself was a mistake on my part, but that’s another story). He had made some progress, but he was constantly overbuilding things, and it was a huge drain on our velocity. We were a startup, so perfection wasn’t the goal; pragmatism was.
Anyway, I met with a couple of my mentors about it, and one of them immediately pointed out my flaw in hiring him. “You hired someone to do X? And you’ve only got 6 engineers? No, no, no. Quit that now.”
The employee’s performance was my concern, but in reality, the biggest problem was that I had hired someone for a job that wasn’t necessary yet. Stepping back and hearing this from someone who had more experience and wisdom than me was of huge value.
3. Balance reasoning with your gut
In Richard Wiseman’s The Luck Factor, one of the things that he found in common among lucky people was that they knew when to listen to their “gut” rather than reasoning through every problem completely. Like any common muscle action - typing on a keyboard, turning a page in a book, or putting on your clothes - your brain has learned to put these tasks on auto-pilot. You don’t really think about them. At a certain point, your brain relies on this same auto-pilot to help it make decisions based on past experiences you’ve had that you don’t even consciously remember.
I know that as a first-time engineering manager or CTO, you might not think your gut is the best decision-maker, but you might also be surprised. Many of the same problems you faced as a software engineer or team lead have prepared you for making good gut decisions.
Most importantly, remember that fear, uncertainty, and imposter syndrome or normal reactions to taking on a new role. Your brain is telling you to back off and go back to something comfortable. Don’t let this hold you back. Learn to face struggles with action and keep moving forward. It only gets easier.
To read more and follow the rest of the book’s development, check out the Github repository: CTO Patterns.