Discover more from Dev Interrupted
3 Cures For Imposter Syndrome (From 20+ Years Of Leading Wildly Different Teams)
If you're diving into new waters, learn from someone who has swam there before.
About the author: Mike Krohn is a 20+ year engineering leader, who has led teams across multiple segments at Philips, including R&D, operations and digital solutions.
You're doing a great job at what you're supposed to be doing. Your manager thinks highly of you and you have a few bonus checks to prove it. Things are going great! As a reward for this outstanding performance, you've been asked to "help" in a completely random, what-am-I-doing-here kind of space. It turns out your manager thought that it would be a good assignment for you because… of course they did. Neat.
Has this happened to you? I’ve been caught off guard many times in my career and while this kind of thing doesn’t bother me anymore, it certainly did in the beginning. I used to get excited about doing something new, working with new people, and getting a chance to stretch my skills a bit. A few hours later a tiny crack of doubt starts to appear. The doubt grows and suddenly, I’m out of my depth. Fortunately, there’s something you can do about it. You can take this feeling of being an imposter and turn it into rocket fuel. Let’s dig in.
1. Learn a team’s day-to-day responsibilities & show them how they’re viewed in the big picture
The first time I was given this opportunity was through being assigned leadership of a Tiger Team. The concept is straightforward: successfully lead a highly technical team to overcome a serious issue or significant technical debt, usually in a matter of a few weeks. No problem, right?
I figured that if I was going to fail, that it wouldn’t be for lack of trying. My manager wanted me here for a reason, and I needed to get started. I learned very quickly that to build trust on this new team, I was going to have to show that I was willing to sit in the pocket with each developer to really understand what we were solving for. It was weird at first. I invited the team to the report-outs so that they could hear first-hand what questions were being asked and how I was representing the team. After a few days of awkward conversations, the team knew I was on their side.
Over the next few weeks my exchanges turned into mapping and coding sessions. I learned the finest-grain details about our check-in and code-review process, how the team comes together to solve a big problem, and I learned that I truly love coding in Python. We were able to dig out of our hole with two days to spare.
2. Let data dispel internal doubts & subjective differences
The next opportunity came in the form of a hardware project. My leadership team needed someone to restart a shelved project from two years prior to make a pitch to the executive team about how to spend $12 million. No big deal, right? Honestly, even though I had a few successes along the way, I was still surprised to find my old friend Imposter Syndrome was right there waiting for me again. I didn’t know exactly what I was going to do, but I knew that taking the first step was critical.
The first thing I did was reach out to the lead designer. I was able to watch what decisions were made and why, and I (as delicately as possible) helped to air out tradeoffs and assumptions with this person and the rest of the team. The hardware projects we worked on come with very long lead times and we needed a way to fail faster. With the help of our simulation tools and the common goal of getting a massive project off the ground, the team and I were able to develop a rapid prototyping process that gave us guard rails in terms of performance. In a matter of weeks we were able to make critical decisions based on data.
The time came to make that all-important pitch to the executive team. We knew the hardware would work, but to make the kind of business-altering impact we needed to make, it was going to require significant investment in another part of our system. We were the first team to show with data that this was the best solution possible under the given design conditions. Ultimately the project failed due to funding concerns about the rest of the system.
I gained first-hand experience with the hardware development process. I was part of a high-functioning team that shared a common “fail fast” mentality, and ultimately, we were able to produce the results we wanted. I learned so much about antenna design, microelectronics, the magic of RF engineering, and designing hardware for scalability. It’s too bad the project did not move forward, but it was one of the best experiences I’ve ever had working on a team.
3. Get advice from people who’ve built what you want to build | They love it
The last example is a fun one. I was given the task of pitching my organization on the need for a design group that we (at the time) staffed with enterprising software engineers and a few experts. This amounted to starting a brand new team in an organization that prides itself on its grind mentality.
Cue the angst.
By now I had some experience reaching out and making new friends. This objective put me into a new position – cold calling people. In order to make a thorough case to the management team, I needed to know how other companies were structured. Companies similar to mine and companies different from mine. With no connections to these companies, it meant that my last resort was to cold-call or email people and ask for help.
I was amazed by how generous most of the responses I received were. A few of the companies similar to mine were skeptical, but we weren’t talking about the proprietary process of splitting atoms. We were talking about structure. What works, what doesn’t, and what we would all do differently. I had the best response from companies that looked nothing like mine – I received offers to tour offices, to talk to design groups, and to interview leaders for their thoughts.
In the end, we provided two scenarios to choose from and one of them was selected. Because of the first-hand knowledge we gained, we were able to make informed decisions and a great proposal.
Imposter syndrome is the norm. It’s learning ways to defeat it that’s unusual.
The real point of these quick stories is to tell the reader that you are not alone. Imposter Syndrome looks different from person to person, and the good news is there is something you can do about it when it starts to show. You’re sure to learn something about yourself, and new skills are often only a conversation away.
Ready to build a new skill? Learn how to start your engineering metrics program
While sales and marketing have clear, well-understood dashboards, engineering insight often feels just out of reach.
Structuring and correlating engineering data with a metrics program provides holistic visibility into engineering health, fosters delivery predictability, improves dev experience, and helps you communicate with the rest of the business in a common language.
Use this free guide to start your metrics program–inside you’ll learn to:
Identify leading and lagging indicators of engineering health
Benchmark metrics and define “good” for your team
Surface risk indicators and improvement opportunities
Build an improvement strategy with automation and goal setting