The Ignorant Engineering Leader
How being open about your knowledge gaps can make your a better engineering leader, with practical examples.
Welcome to the Captain’s Codebook newsletter. I'm Ilija Eftimov, an engineering manager at Stripe. Each week (or so) I write a newsletter article on tech industry careers, practical leadership advice and management how-tos.
Jim Whitehurst, CEO of open-source software maker Red Hat, has said, "I found that being very open about the things I did not know had the opposite effect than I would have thought. It helped me build credibility." Asking for help is effective because it taps into the natural human impulse to cooperate with others.
What Jim is getting at here is that, as a leader, not knowing something is not a problem. It can even be transforming. It isn't good to pretend that you know something when you truly do not.
So, how do you show your ignorance in different forums as a (budding) engineering leader? I've put this writeup together with practical examples, covering:
Openly admitting mistakes and knowledge gaps
Asking for help in public
Sharing your struggles
Reacting well to feedback
Sharing learnings
Transparently sharing uncertainties or insecurities, and
Borrowing Authority
Let's dive in.
Admit mistakes openly
Born in Eastern Europe, I grew up with the idea that elders or leaders must always be right—no questions asked. In that culture age, experience, or status allowed one never to be questioned about their choices or knowledge. If you haven't, watch the BBC's Chernobyl mini-series—you'll get the idea very quickly.
The top-down culture doesn't translate in the tech world. The all-knowing leader persona might work for a bit, but in the long term, it breeds insecurity in the people on the team and creates a toxic environment. Not being afraid to admit and embrace mistakes is the better way to lead. Benjamin Laker, in his article on the MIT Sloan Management Review website, argues that "responding without blame creates an environment of learning and growth in which employees recognize that mistakes are part of the process and that their efforts are appreciated — a blameless culture".
So how can we, as engineering leaders, admit our mistakes and show engineers that it's OK to make mistakes and learn from them? Share instances where you made errors in judgment or decision-making and how you learned from those experiences.
In team meetings, actively encourage discussions about setbacks or challenges faced during projects. Lead by example:
Share a personal story where a misjudgment on your part led to a project delay, then
Explain how acknowledging your mistake allowed the team to pivot and find a solution and finally
Reinforce the lessons that openness allowed for fast recovery.
At some point, we all ended up choosing a technology that did not fit the project requirements. If this has happened to you, share the decision-making process, the signs you missed, and the technical shortcomings later discovered. Sharing this will signal your team that it's OK to make mistakes when they are acknowledged and serve as lessons.
The bottom line is that leaders should lead by example, share their mistakes openly, and build an environment of psychological safety in which mistakes are valuable lessons and not anomalies.
Publicly ask for help
It's impossible to know everything. So, another way of being vulnerable as a leader is to ask for help transparently. Asking for help signals to the team that not knowing is OK and encourages the team members to lean on each other. So, how can you, as a leader, practically do this?
Begin by making seeking help a non-event—in other words, normalizing it. For example, during team meetings, openly discuss areas where a project needs specific expertise that you do not have. Say something like, "[Person] asked me about our team's vision of evolving our service within the broader architecture. I realized this is an area where I have limited knowledge. Who can help out here?"
While broadcasting requests for help is good, another way is to call for help from individuals on the team directly. For example, if you're grappling with a new technology stack crucial for your project, ask a proficient team member for a brief tutorial or resources. You might say, "I've noticed your extensive experience with Rust. I'm trying to get up to speed on our upcoming project. I want to understand the technology we will use to support the team. Could we schedule some time for you to walk me through the basics and best practices?"
As a bonus point, always acknowledge the expertise of others publicly. For example, if someone helped you understand the basics of Rust, record the session and praise them publicly. Say something like: "Jane gave me a tour of Rust, which I found extremely useful. We recorded the session—watch the recording HERE. Thank you, Jane, for the wonderful tour of Rust!"
Share your struggles
Managers face challenges, just like any other individual. Curve balls, escalations, complications, projects going sideways—the apparent drama never seems to stop. Good managers shield their teams from needless information or drama to keep their teams focused on the projects. But still, as a manager, it's good to show vulnerability and share some of the struggles you're experiencing.
In team meetings, you can incorporate stories from lessons you've learned the hard way. Team meetings are an opportunity to talk about past projects where you had difficulties or failures. Discuss the context, your reaction, and the outcome. For example, if you once led a project over budget due to poor planning, share how you took responsibility, what measures you implemented to mitigate the situation, and how it changed your approach to budgeting and planning in future projects.
You can also share your struggles in one-on-one meetings. Share a personal story of a time when you faced a significant challenge, such as when you struggled to meet expectations. Explain your feelings, your actions to address the situation, and what you learned from the experience. Sharing your struggles will build a deeper, more trusting relationship with your team members.
React well to feedback
Another way to show vulnerability as a leader is feedback. You must welcome it, take it well, and act upon it. Begin by regularly asking for feedback. Ask for feedback during one-on-one meetings with team members. Don't ask for general feedback - be explicit. Ask about your particular skill or how well you do something. For example, say, "I'm working on improving my leadership skills. Could you provide specific examples of what I've been doing well and areas where I could improve?"
Once you get the feedback, be appreciative. Thank the person for their input. For instance, if a team member suggests a better approach to managing project timelines, respond with, "Thank you for sharing your thoughts. Your input is invaluable to me, and I'll look into how we can incorporate this approach moving forward."
Then, take the feedback and do something about it. For example, if you've made changes based on feedback, check back with the person or team who provided it to see if they've noticed the improvements. If not, you may have more work to do. Say something like, "A few weeks ago, you mentioned that my emails were unclear, and I've been trying to make them more concise. Have you found them easier to understand?"
Lastly, share improvements in public! During team meetings, share how specific feedback has led to personal or process improvements. It could involve discussing how feedback about your communication style led you to seek out a coach or a course to improve your skills, showing that you take feedback seriously and are committed to personal development.
Admit ignorance
You might not like vulnerability, but admitting you don't know something is the best way to show integrity. Saying "I don't know" is liberating. It signals the team that not knowing is OK. It also encourages learning. Use any "I don't know" as an opportunity to brainstorm, research, and learn together.
First, be transparent about your knowledge gaps during discussions. For example, if a particular product behavior comes up that you're not familiar with, openly admit it. Say something like, "I'm not as familiar with the details of that part of the product. Could someone quickly bring me up to speed so I can participate in the discussion?" Such behavior creates a team culture where it's safe to admit gaps in knowledge and is an expected part of growing.
Next, ask insightful questions. For example, when someone brings up a concept or strategy you don't know about, ask detailed and thoughtful questions. "Can you explain how that would work in our current environment? What are the potential challenges we should anticipate?" Asking questions demonstrates that you value the information and are engaged in learning, even if the topic is new.
After admitting your knowledge gap, take time to research the topic. At the next opportunity, share what you've learned and thank those who provided insights or resources. "Thanks to your recommendations, I explored the X product further. Here are some ideas from it that we can apply to our project…".
Share learnings
Talk about recent things you've learned. Emphasize that learning is an ongoing process for everyone, regardless of their position.
Learning must be part of regular team meetings. For example, introduce a short "Lessons Learned" segment where you share something new you've learned. It can be a recent discovery or challenge you've overcome. It doesn't need to be fancy: a simple new coding shortcut you found can be enough.
For a broader influence, write about what you have learned. Lots of companies have internal blogs or newsletters that you can leverage. For instance, after attending a workshop or conference, write a summary of key takeaways and how they might apply to your team's work. Publicly sharing lessons documents your learning journey and provides a resource for others.
Always model a growth mindset. When facing setbacks, share the lessons constructively learned with your team. For instance, do a retro if a project didn't meet its objectives. Analyze what happened, gain new insights, and leverage the team to decide how these lessons will influence future projects. Then, broadcast the insights and decisions widely.
Transparently share uncertainties
Similar to knowledge gaps, trying to under-communicate uncertainties is a bad idea. It's OK to say, "I don't know how we will do that," or "I haven't thought of that before". For example, when facing a significant decision with multiple unknowns, openly discuss the options, the knowns and unknowns, and your reasoning. Say, "We're at a crossroads between technology A and B. Here are the potential benefits and risks as I see them. I'm leaning towards A because of X, but I'm concerned about Y. What are your thoughts?"
Also, involve your team in risk assessment. When dealing with incomplete information, involve your team. Use a (virtual) whiteboard to list potential risks, their impact, and mitigation strategies. Say, "Given the unknowns about this market, let's do a pre-mortem and decide how we might mitigate the risks."
Lastly, regularly schedule Q&A sessions with your team to address uncertainties and concerns. Underscore that _all_ questions are OK to be asked. This provides a safe space for open dialogue and lets you share your thoughts about risks, decisions, and strategies. As a bonus, allow the team to ask questions beforehand to ensure you address all concerns anonymously.
Borrow authority
You don't have to do everything around projects, especially when you're not the right person. Instead, delegate responsibilities to your team. Delegation signals that you value their expertise and judgment, just like they value your leadership. Assign a team member the responsibility of making critical decisions for a project component. For instance, you could say, "I trust your judgment on the architecture for this module. Let's review your decision framework, and you can take the lead on finalizing it."
But delegating is not enough—people need to feel empowered. In project or client meetings, explicitly designate a team member as the expert on a specific topic. Prepare them beforehand and make it clear to others that this person has the authority in that area. For example, "Alex will lead our discussion on the integration design, as he's spearheaded that effort."
For a longer-term delegation, give a team member full ownership over a project or a (sub)domain. They should own the topic, including the authority to make decisions and manage resources. Ensure they have access to you for guidance, but make it clear to the team and stakeholders that this person is the go-to authority in this area.
And that’s it for this week! If you liked this, consider doing any of these:
1) ❤️ Share it — Captain’s Codebook lives thanks to word of mouth. Share the article with your team or with someone to whom it might be useful!
2) ✉️ Subscribe — if you aren’t already, consider becoming a subscriber. Seeing folks read the newsletter energizes me and gives me ideas to write.
3) 🧠 Let’s chat — I am always on the lookout for questions to answer, to help out with challenges, or topic ideas to cover. Hit me up on LinkedIn, Twitter or send me an email to blog@ieftimov.com.
Until next time,
Ilija