Life Lessons in Engineering Leadership
Trust is the foundation of good leadership. In my fifteen years as a software engineer and seven years as an engineering manager, I have seen leaders who failed to inspire trust, and I have failed in many of the same ways. Only recently have I really focused my practice toward emphasizing trust as the core of my relationship with my reports, and I’ve built stronger relationships with my team as a result. I hope that you too can learn from my observations and find some inspiration for your own leadership practices.
Transitioning from Engineer to Manager
Early on in my career as a software engineer, I struggled to understand the role managers should play. I expected them to be more involved in technology, and I often felt disappointed by their lack of current knowledge and mentorship. Later, I encountered managers who were too involved in technical decisions, causing them to fail as leaders. In my own practice, I too have found myself leaning too far towards one extreme or the other without explaining my intentions to my teams.
In my first role managing engineers, I spent too much time in code and troubleshooting and not enough time focused on my team. This felt natural because it was how I had always wanted my managers to behave. After a year on the job, however, I realized that my choices had left my team without the leadership that they needed to advance their careers. Recognizing this, I started to rebalance my workload to focus on creating meaningful growth opportunities for my team.
I gradually stopped writing code and reviewing every pull request and started focusing on one-on-ones with my engineers, strengthening my feedback loops and creating a dedicated space for career growth. I took over handling site reliability requests to keep my team focused on product feature work, and I included them earlier in the problem solving process for particularly complex requests. Throughout the year, I evolved my view of my role from focusing on what I contributed to caring about how I supported my engineers.
A crucial learning from this transition was that I had to be transparent about my intentions with my direct reports. On teams where I was most effective, everyone knew my limitations and understood the role that I intended to play. On teams where I failed to properly communicate how I viewed my role, my engineers grew frustrated as they looked to me to be an expert in our core technologies. Looking back, I believe I would have been more successful if we had a shared understanding of my role and accountabilities.
In my most recent incarnation, I have felt most effective when I share my limitations and intentions with my teams. Knowing why I choose to be involved only at the abstract level helps them understand how they can best utilize my knowledge. Limiting my time spent on engineering work in this way gives me the flexibility to maintain a balance between my responsibilities as a manager and as an engineering mentor. This is very much a learning process though, and I rely heavily on feedback from my engineers to understand how my efforts impact them.
Soliciting this kind of constructive criticism from anyone is a challenge, but without trust I can’t imagine it would even be possible. I often struggle to give folks confidence that I hear their concerns and that I am accountable to them. To demonstrate this accountability, I refer to notes that I take during retros, performance reviews, and one-on-one conversations about my commitments. More often than I like to admit, I discover that I am falling behind on these commitments. But acknowledging these lapses and being open about my flaws helps my team understand my limitations.
Building Trust
All of my frustrations with former managers and many of the grievances that my own teams have had with me stemmed from a lack of trust. It is the foundation upon which my most successful teams have been built and something I try very hard to establish and maintain as I lead my teams today.
I encourage you to look for the humanity in your engineers so that you can understand what motivates them and keeps them engaged with their work. I spent my time as a software engineer frustrated by bosses who thought that managing engineers was impossible because we were too difficult to understand. In my own practice, I have learned to accept that my engineers have hopes, fears, ambitions, and insecurities just like everyone else.
To identify these characteristics, I rely heavily on the pyramid of needs to understand how to build on the foundations that my teammates already have in place. Sometimes motivation comes from simply encouraging their physical well being through comfortable working conditions, nutritious snack options, and healthy work life balance. If that’s already been addressed, I look to ensure they feel safe in their work environment. In the case of engineers, safety is often more about emotional security. I try to make sure my engineers feel safe sharing their ideas with me and with their peers.
Encouraging this kind of safety translates well into helping my team members establish strong relationships with their peers. This is an area often overlooked by engineering managers who don’t realize that their more introverted teammates still want opportunities to socialize with their peers but might feel intimidated by large gatherings. Creating opportunities for all personality types and being transparent about your intentions helps folks understand your efforts and give you feedback. In turn, this feedback can help you tailor your efforts to better serve your whole team instead of just the extroverts.
These events can also be useful for helping your engineers feel appreciated and gain insight into what kinds of encouragement their peers need to thrive on the team. I also try to focus my feedback on recognizing how my engineers’ efforts are impacting the business and how I see their progress unlocking future opportunities. My intention is to build their self esteem and also show them a path forward at all times.
Once I understand what motivates my engineers, I try to demonstrate my trust by encouraging them to share in the ownership of decisions. I have often felt frustrated by managers who believed that decision making was a function of their role and not something that could be delegated. My frustration came from being asked to build solutions without sufficient context or input behind the decision making process. To overcome this, I try to encourage my engineers to connect with the problems they’re solving by giving them a seat at the table where decisions are made. As a manager, I expect to be held accountable for my decisions, and I trust that when my team is involved in the process, they will stand behind me and support me in a deeper, more meaningful way.
As my engineers take ownership of their work, I try to stay connected with them by participating in team story grooming sessions and code reviews. My intention here is to give my team insight into my level of understanding and to have more opportunities to celebrate their efforts and offer pointed guidance. As an engineer, I often felt disconnected from my managers when I was creating systems because they didn’t have time for me to explain what I was building. This left me lacking trust that they were good stewards of my career. As a leader, I encourage my engineers to share their struggles and accomplishments with me. This gives me a deeper understanding of the problems they’re facing and how they’ve overcome them. I then use these insights to encourage their growth and better understand where they might be best deployed on future assignments.
My hope is that forming a mutual understanding with my team will help us collaborate about the nature of their work and what enhances or reduces their productivity. I’ve had many managers who felt it was their role to dictate processes to the team, but I always struggled to trust someone to make these decisions when they didn’t have to live with their impact. I ask my teams to help me define the processes that will work best for them. I start by sharing why I think the status quo is broken so that they know what I hope to accomplish. I also encourage them to discuss their goals and how a new process could impact their work. This builds a sense of shared ownership and empathy toward my needs as well as those of their peers.
Sharing Leadership Roles
Sharing the burden of leadership with your team can demonstrate your trust in them and ensures the team is getting the best guidance available. I break leadership into three roles: Coach, Captain, and Cheerleader. The Coach is responsible for strategic decisions and long term skill growth. The Captain is responsible for leading the team through tactical decisions and technical skill development. The Cheerleader is responsible for recognizing accomplishments, offering encouragement and reinforcing learning.
An example of delegating the Coach role is when I ask my lead engineer to mentor junior engineers on a technology. It’s important to me that I make sure the team knows that this takes time away from my lead engineer and also that I feel the less experienced engineers will benefit from more current and deeper technical knowledge that I expect my leads to possess.
For the Captain role, I look for both technical and non-technical opportunities for folks to take the lead. An example of delegating a technical leadership role is when I ask my senior engineer to design a system and explain their design to the rest of the team. My expectation is that the engineer will lead the implementation effort as well. As the project progresses, I focus on helping them delegate and dedicating time to help folks level up.
When I delegate the Cheerleader role, I try to find someone who is willing to hold their peers accountable in a constructive and encouraging manner. Within a Scrum Agile team, this can be as simple as delegating the scrum or retro leader role to an engineer. Sharing this role develops empathy amongst the engineers for their peers’ contributions. It also fosters awareness of the effort required to keep projects on track.
My goal in delegating these roles is to help my team understand how I view leadership. This gives my team a strong foundation to assess my leadership and help me understand where I’m falling short. I don’t expect my engineers to take the reins at every opportunity but I want them to know that I trust them when they do.
Key Takeaways
I leave you with a few hard-earned lessons. Build up your people by investing in their growth, empowering them to make decisions, personally connecting with their wins and struggles, and giving them ownership of the processes that define their work life. Advocate for intentional leadership and model it for your team so that they can help you carry the burden as Coaches, Captains, and Cheerleaders for their peers. Be mindful of the role you intend to fill on the team, and share that with your engineers. Knowing your intentions helps them shape their expectations for technical mentorship and career guidance. Finally, encourage your engineers to give you feedback. Only by hearing their perspectives can you gauge how well you’ve communicated your intentions and how your efforts are being received.
