I wanted to offer up my perspective on this Quora question about when hands-on management makes sense for engineering leadership. Does it ever make sense for engineering leaders to be hands-on with coding? While there is no universal answer to this question, I will offer some insights based on my personal experience.
I’ve observed this hands-on management where leaders were writing code generally at smaller companies, or on smaller teams even within larger organizations. In these early stages of growth, it can be useful to have hands-on management for engineering who can help set the technical direction and guide the team’s architecture.
I have lived this approach at a startup where I worked for roughly eight years. As a technical engineering manager, I wrote software for small teams while also overseeing the career growth of the engineers. This allowed me to influence the technical direction and help build up my engineers’ skills. Omit, some of the larger teams at the company had managers who were not hands-on coding at all. Of course, this is not a dig at those managers! Their teams were too big to allow for dedicated coding time, and the technical areas within the team were better understood and supported by their engineers.
So, when should we have hands-on management for engineers compared to going hands-off? Let’s dive deeper.
Early-Stage Companies and Teams
At smaller companies or on smaller teams within larger organizations, there may be more of a need for hands-on management and engineering leadership. This is especially true in the early stages of growth when the team is starting off the code base, making first iterations in a product space, and otherwise completely new to the technical problems.
In these situations, hands-on management where the engineering leader is participating in writing code can help set the tone for the team’s work. Being entrenched in the team means that they can help provide guidance on technical decisions for the scope of work. By writing code, the leader can also help to build up the team’s technical skills and identify areas where they may need additional training or support.
Yet, as the team grows and becomes more established, it may no longer be workable for the leader to continue writing code. At this point, it’s important for the leader to focus more on guiding the team’s technical direction and supporting their work, rather than participating in it.
Established Companies and Teams
For larger, more established companies and teams, hands-on management and engineering leadership may not be as necessary. In fact, it might not even be feasible given the actual direct support the engineers need from their manager. In these situations, the team may be too large for the leader to dedicate significant time to coding, and their expertise may be better utilized in guiding the team’s overall direction.
Engineering Management Scenario
Consider this scenario. An engineering manager has a team of roughly 7 people, consisting of one very tenured engineer, several senior engineers, and several junior engineers. The team works in a product or service domain where the more senior folks on the team have multiple years of working experience.
From a day-to-day perspective, does it make sense to:
- Have a hands-on approach for the manager where they are writing code?
- Or is it likely more effective for the manager to focus on getting growth opportunities for the senior engineers, and helping level up the junior engineers?
Not always, but it’s likely the latter.
Technical Competence
However, even in these situations, it’s still important for engineering leaders to be technically competent and able to relate to their engineers. This allows them to understand the team’s strengths and weaknesses and provide effective guidance on technical decisions. While it isn’t necessary for the manager to have as much technical depth, it’s still very valuable to have technical expertise.
Overall, the decision of whether or not to have hands-on management will depend on a variety of factors, including the size and stage of the team, the company’s goals, and the leader’s individual strengths and weaknesses.
The Benefits of Hands-On Management
While hands-on management may not be necessary for every team, there are certainly benefits to this approach in certain situations. Some of the key benefits include:
- Setting the tone for the team’s work and technical direction
- Providing guidance and support for the team’s technical decisions
- Building up the team’s technical skills and expertise by sharing knowledge, best practices, and providing hands-on mentorship
- Helping to establish a culture of continuous learning and improvement by demonstrating the importance of staying up-to-date with new technologies and methodologies
- Acting as a bridge between the technical and non-technical sides of the business, by being able to communicate complex technical concepts in a way that is understandable to those outside of the engineering team
- Being able to identify potential technical issues or roadblocks early on and proactively addressing them before they become larger problems
- Maintaining a deep understanding of the technical details of the product, which can be valuable when making important technical decisions or working with other teams that may have different technical requirements.
It’s important to note that while there are certainly benefits to hands-on management, it may not be a sustainable approach in all cases. For example, if a team is rapidly scaling or if the engineering manager is responsible for multiple teams, it may not be feasible for them to dedicate a significant amount of time to hands-on coding. There is often a point where the more senior engineers on the team can lead in all of the points listed above without requiring hands-on management and the engineering leader writing code.
Hands-On Management: Yay or Nay?
Ultimately, the decision to be hands-on as an engineering leader should be based on the needs of the team and the business as a whole. If the team is small and there is a need for technical expertise and guidance, being hands-on may be the most effective approach. However, as the team grows and more resources become available, it may make more sense to shift towards a more managerial role in order to focus on other important aspects of leadership, such as team building, mentoring, and strategic planning.
In conclusion, the question of when engineering leadership should be hands-on and coding is not something that has a simple universal answer. It depends on the needs and circumstances of each team and organization. However, there are certainly benefits to being hands-on in certain situations, particularly when it comes to setting the tone for the team’s work, building up technical skills and expertise, and establishing a culture of continuous learning and improvement. As with any leadership approach, it’s important to regularly evaluate its effectiveness and adjust as necessary to ensure that the team is set up for success.
Do you have questions for me? Feel free to ask your questions on my Dev Leader Quora space!