Should you be "hands-on" as an Engineering Leader?
The case for and against coding as a Senior Engineering Leader
During my interviews for Director-level positions, I can get a glimpse into many different engineering organizations and their values. One very obvious differentiator seems to be how the concept of “being technical” is considered.
To get this out of the way: I’m 100% convinced every engineering leader should have a background in software development. It helps understand the process steps, the importance of tooling and collaboration as well as the occasional lack of visible progress (to avoid: “You spent 3 days on these 5 lines???”). It helps them understand the long-term effects of decisions and gives them nuance in technical discussions.
The “hands-on” spectrum
However, I’ve discovered there are vastly different interpretations of how this technical background should be applied while holding a leadership position.
On the one end of the spectrum, you have a leader who doesn’t have any practical software development done in recent years and only vaguely remembers the syntax of the language, esp. not any recent language constructs.
The other end of the spectrum shows a leader who is an active engineer on the team, both picking up tasks, often working as architect as well as giving feedback on their colleague’s code contributions, in pairing or via code review.
Most of us will fall somewhere in the middle of this. But what should your organization aim and hire for? Is there an optimal point on the scale? Let’s explore.
The Power of Staying Hands-On
Credibility and Trust
Let's face it, keeping tabs on coding best practices and new technologies feels like a constant chase. But it's not just about mastering the latest lingo or frameworks. It's about solidifying our credibility and building trust within our teams.
Picture this: our team is neck-deep in a complex architecture quandary, frustration radiating like heat waves. This is where staying hands-on becomes our secret weapon. By not only grasping the problem at hand but also suggesting solutions informed by recent coding experience, we earn instant respect. This technical dexterity translates directly into trust, the cornerstone of effective leadership.
Remember, it's not just about solving problems reactively. Staying involved allows us to offer guidance grounded in real-world experience. We've navigated the trenches, know the pitfalls, and can anticipate potential roadblocks. This informed perspective empowers our team to make smarter decisions, tackle challenges with confidence, and ultimately, achieve greatness.
Think of it this way: it's not about micromanaging or becoming a coding roadblock. It's about harnessing our unique skillset to guide, support, and inspire our teams. It's about speaking their language, earning their trust, and ultimately, building a stronger, more effective unit together.
Mentorship and Growth
By rolling up our sleeves and participating in tasks, code reviews, or hackathons, we demonstrate best practices, identify areas for individual growth, and foster a learning-by-doing culture. Remember, leading by example shows the team we're not just talking, but also "in the trenches" with them.
Problem-Solving and Innovation
Our direct involvement translates to tackling technical challenges and bringing unique perspectives to the table. Imagine sharing our knowledge of a new cloud platform to unlock innovative solutions for an existing problem. This hands-on approach can spark creativity and propel the team forward.
Pitfalls of being too “hands-on”
While the benefits are clear, remember that leadership extends beyond code. Overly frequent coding can:
Distract from Broader Responsibilities
Crafting strategy, setting vision, and nurturing talent are crucial aspects of our role. Neglecting these due to constant hands-on involvement can hinder the team's long-term success. Additionally, setting unrealistic expectations by implying everyone should handle both coding and leadership simultaneously can create unnecessary pressure.
Sustainability and Scalability
Maintaining high-quality code contributions alongside leadership duties becomes increasingly difficult as the team expands and projects become more complex. Setting a precedent that future leaders require similar coding skills can restrict the talent pool and neglect the importance of delegation and empowerment.
Micromanagement and Demotivation
Offering guidance is essential, but overzealous involvement can veer into micromanagement. Taking on tasks others can handle undermines team trust and autonomy, potentially stifling growth and motivation. Moreover, if the perception arises that we value our technical skills over individual development, it can create a demotivating environment.
Finding the Golden Mean
As engineering leaders, we constantly dance between the "hands-on" and "big picture" realms. While staying technically engaged offers undeniable benefits, diving too deep can pull us away from crucial leadership duties. So, how do we find the sweet spot?
From Code Warriors to Strategic Guides
Instead of constantly wielding our keyboards, let's empower our team by delegating tasks and fostering ownership. Trust their expertise, offer guidance instead of micromanaging, and focus on high-level technical decisions. Our deep understanding should inform choices about architecture, technology selection, and long-term plans. Remember, investing in team development through mentorship, training, and knowledge sharing creates a self-sufficient force.
Informed, not Inundated
We don't need to rewrite every line of code to stay sharp. Participating in code reviews allows us to share valuable insights on quality, design, and best practices. Engaging in technical discussions keeps us on top of trends and challenges, and experimenting with new technologies fuels our curiosity without sacrificing leadership duties. Let's find the right balance to stay informed without getting lost in the code jungle.
Catalysts, not Bottlenecks
Imagine our team as a finely tuned engine. We shouldn't become the single point of failure by holding onto code ownership. Empowering individuals to take responsibility fosters accountability and a sense of accomplishment. Setting clear expectations ensures everyone understands when to seek our guidance and when to lead independently. Finally, celebrating team achievements reminds everyone that success is a collective effort, not a solo performance.
By embracing these strategies, we can achieve the optimal balance between technical engagement and leadership. Remember, our goal is to leverage our expertise strategically, not get bogged down in the details. By empowering our team and staying informed, we can create a collaborative environment where everyone thrives.
Let's lead the way, not hold the team back, and witness the magic unfold!