The burden of Tech Managers
"Tragedy of the commons" but played by a multilevel marketing corporate hierarchy
Prep talk
There is an aphorism that probably only works in Brazilian Portuguese: “A dog with two owners will starve" (Um cachorro com dois donos morrerá de fome”). The closest thing I could find to that is The Tragedy of Commons. Both describe a situation with finite resources, ownership drama and (lack of) care for results.
We are in a wave of VCs and executives learning to manage their money and care for outcomes. That naturally reflect on companies and teams. Metrics that were seen valuable in excess as number of engineers, layers of managers, number of tribes became red flags.
Companies over hired not to make teams healthier, but to avoid hard discussions among executives. Not even the fallacy of hiring more people to increase velocity played a role there. It was easier to double the team so John and Paul could have their way than figuring out an agreement.
The effect is that the role that should be accountable for success where work happens, leading the team got of weakening and lost its meaning. New layers and positions were created because a big team with ambiguous prioritization requires a lot of work to … work ! Meaning that "the amount” of ownership and accountability present in this role is diluted as new positions are created to ease the way of hard conversations and of managing outcomes.
We should not over hire but grow as needed, never hiring before needed but never counting on a stretched team.
Names matter
After more than a decade of mixing Agile methodologies with The Spotify Model, along with a host of vendor-based alternatives as SAFe we ended up with the weirdest structures for making software. Imagine being hired for a job named “Tribe Leader” and not being allowed to ride a horse into the office !
Companies got stuck at different degrees of adopting of these models, incorporating roles as “Tribe Manager”, “Squad Lead”, “Tech Leads”, “Tech Managers” and all permutations among them as jobs without a clear line of ownership.
Everyone seeks Autonomy, Mastery and Purpose , but we still live the dichotomy of individual contributors not knowing how to make impact, and high executives complaining that investment in tech is not yielding the expected velocity.
The role of a team leader
The role names I've mentioned before are tied to auxiliary structure as QA, process teams, project offices, agile coaches, mentors and layers of indirection that takes out the meaning of leading a team. The meaning of a team leader makes the difference in the outcome of teams.
A team that is close to work should not be subject of a negotiation heavy structure and should be able to make most of their local decisions with acceptable velocity and quality following any decision model (I recommend a tree-based decision model).
If an Engineering Manager manage other managers, the next logical level of managers is a team leader. There is a progressive mix of skills required for leading a team, that comes with an increased burden as you are responsible for individuals. Let's name this role “Tech Manager”.
(I wrote about the expectations of an Engineering Manager before. The same structure and questioning applies for a Tech Manager)
What's on the table for a Tech Manager
A Tech Manager should manage the team. So no coaching or agile masters to take over as glue for inter-function tension as product/engineering or stakeholders/technology.
A Tech Manager has to help create and follow up PDI (professional development plans) and its success should be part of their own development.
A Tech Manager is not required to be the best programmer in the team but they have to collaborate on technical guidance and review, specially for quality. Past experience in the role helps understanding how to ask for help, how difficult or easy a job is and how to give technical feedback.
A Tech Manager is the hand of HR work and projects: company values, diversity programs, development training, performance evaluation, hard conversations, hiring and firing.
A Tech Manager owns production with the team and is usually in the second escalation level. They also train and onboard new team members, aiming for autonomy - You build You run !
A Tech Manager is a quality gate. Having an external QA team strips leader and team of an important learning tool which is to own your mistakes.
A Tech Manager does not overstep and make decisions that the team should make. They decentralize command, provide safe guard rails, talk to and bring stakeholders close to the team but understands that at each level a team member should be coached to make better calls in a safe environment. But they don't let decisions that need to be made loose.
A Tech Manager minds about span of control and growth. The healthy way to groom a tech manager to be an Engineering Manager is to keep their span under control. When the team grows, add a new tech manager under them if they are performing a level above, to help manage part of the team. The split the team, reduce the span. Splitting and growing teams that are stable will carry the culture and what made them successful.
How to burn out as a Tech Manager
Companies where management is split between “People Manager” and a “Tech Lead” but that's a local power fallacy as it dilutes accountability and feed bureaucracy. That sucks when you are growing in the role because under the guise of being responsible for technical guidance you will find a task backlog that you can barely influence.
A team with poor leadership lacks accountability, autonomy and partnership. The strongest and most basic work unity is a team, but a Tech Manager is also part of a team. If this team doesn't works well, there won't be proper support.
Increasing span of control: it may be acceptable for a short while but a team smaller than 5 and bigger than 8 people is not a manageable team. Anything above that is a time drag. Split it.
A big span of control usually comes with unusual context stretch - what I like to call “meta” teams. The same team context-switch depending on the time of the day or day of the week, feeding back the lack of ownership and quality cycle. Teams that are seen as a different team depending on the stakeholder are in danger.
How to succeed managing Tech Managers
Look to your organization from line managers and teams up. You shouldn't have need more managers (summing all levels) than developers, you don't need more levels than the minimal span of a team.
Drop the weird tribe lead manager squad magician scrum master names. If you can't find accountability of a team, fix the leadership. Don't add up funny roles where difficult conversations should happen.
Pay fairly, develop people, look for diversity and be nice to each other
If you liked this post please consider buying my new book, The CTO Field Guide which expands on team organizations and their impact in their result.