Are Player Coaches Beneficial for Engineering Orgs?
What is the right role for engineering management after the year of efficiency?
Part two of a series focusing on the future of the engineering org.
With access to cheap money during the pandemic, it seemed prudent to hire aggressively for engineering management. Even if they didn’t have a full complement of direct reports immediately, your new leaders could start to create the organizational structure and processes required to responsibly scale the engineering org as you continued to hire Individual Contributors (ICs). It also provided the capacity for them to handle the planned interviewing and onboarding of a substantial number of new developers and managers as you continued to scale.
But now the music has stopped, and the debate has moved from growth at all costs to maximizing ROI. What should the management structure look like in an engineering organization going forwards?
Some companies certainly need to trim the number of layers between ICs and the CTO, and Engineering Managers with 3 reports or Directors with 1-2 seldom make much sense. But recently there has been a lot of talk about “player coaches” and it’s important to think through the planning required to successfully have Engineering Managers and Directors working as individual contributors as well as managers.
The Costs of the Coding Manager
1. Cycle time
The first cost can be cycle time. In most companies, there are “lumpy” management activities. These can be scheduled (like quarterly planning and performance management) or ad-hoc (planning a re-org or changing processes in response to an incident). In each of these cases, it’s important that the relevant manager not be on the critical path for delivering a feature as they’re likely to push back the timeline by weeks or months as they dig through their other responsibilities. (How many early-stage CTOs have been that person during a raise before they stopped coding critical features?!).
If you have managers coding, it’s important to assume you might need to pull them off the project any day and to have someone ready and available to take over their tickets. One good pattern is to have them pairing with full time IC’s. That way they’re providing mentorship, have access to someone who typically has more fluency in the language and frameworks they’re leveraging, it increases the bus number and makes it easy to roll off if they get busy.
2. Resolution time
The second potential cost is resolution time. There’s a reason we talk about manager vs maker schedules, so an engineering manager needs to optimize for one or the other. They either switch off slack, stop checking emails, get into the zone and code for 3-4 hours at a time, maximizing their productivity as an IC, or they keep on checking on their team, losing context on the code every time something pops up in slack that might be relevant to their part of the org.
There is a middle ground where the manager gives out a cell number and tells their team to “text me if it’s urgent – otherwise I’m coding in the mornings and managing in the afternoons”, but it’s going to take some experimentation and discipline to find a way for engineering managers to consistently find big blocks of maker time while still being free for meetings and for unblocking their teams.
3. Team support
The third cost is what they’re not doing. No question they’ll have more time if they’re not consistently interviewing to scale their org and only need to backfill positions (especially given the current climate where attrition is down for most companies due to the uncertain hiring market for engineers and managers). One of the big decisions most companies will need to make is how well to treat engineers, and how much time to invest in aligning them with the org.
Even with 7 direct reports, if you do a weekly 1:1 lasting an hour, that’s a chunk of your week gone. Maybe you could do shorter meetings or reduce the frequency to every other week, but it’s important to keep a level of connection so when someone on your team is unhappy or has an issue, you can help them to problem solve or re-align. Personally, as a leader I found weekly, half hour 1:1’s to be the right balance, but that often meant that if there was an issue, we’d have to schedule additional time to discuss it further.
The more we ask Engineering Managers to code, the less available they’ll be to ensure that their team is excited and growing in their roles. While that might not drive excessive attrition in the short term, it will reduce good will, and potentially impact the value you're getting from your ICs. There’s no point adding 10% to team velocity via a coding EM if your ICs are delivering 15% less value due to misalignment or poor motivation.
4. Organizational alignment
The final potential cost is organizational alignment. While this might not be as much of an issue at a series B startup with 30-40 engineers, many engineering managers I know at larger tech companies spend 30+ hours/week in meetings. Hopefully some of those are wasteful and can be trimmed without much harm, but alignment across a large org is crucial for managing competing priorities and keeping everyone moving in the same direction. Self-organizing teams with clearly defined cultural principles for decision making can help, but there is a level of alignment below which your speed might increase, but at the cost of your velocity (you’ll be doing more, but ultimately delivering less value).
The reduction of hiring and onboarding is going to provide more capacity for engineering leaders to do other work, but leveraging that as ICs is going to be a challenging balancing act for most companies.
If you’d like to be kept in the loop, sign up for our regular newsletter exploring “the future of the engineering org” here!