April 08, 2020
At Jellyfish, we have the rare opportunity to work with hundreds of engineering teams and their leaders every day. We see these organizations grow and change, and we’re able to talk to their leaders about the fun and not-so-fun challenges of managing an engineering organization through its journey and at different scales. This too, is one of the most common questions we field from Directors to CTOs, especially when they’re in a new role: what should we expect and plan for at the different stages and sizes of the engineering team; what are some of the common challenges that you see at our stage?
A Note Upfront About Distributed Teams
The trend toward, and now a necessity for distributed and remote work is having a significant impact on the dynamics of engineering management. At Jellyfish, 84% of our customers had engineering teams that were distributed to some extent even before working remotely was non-optional, as we’re all working from home now, so everyone is distributed. More impressively, almost 40% of these engineering teams were over 50% distributed. At companies with distributed and remote engineering organizations, engineering leaders don’t have access to the lunch conversations and hallway flybys that we’ll talk about below. They cannot “walk the floor” because there is no floor!
Our customers tell us that as distributed teams, they actually hit the wall where they need to change the way they gather data for decisions one stage earlier than they would have because they simply miss out on all the flyby signals of colocation. They need more rigor and rules about everything: strictness of meeting times, never missing 1:1s, more consistent data collection, and review. More generally they need to over-communicate on all fronts. One of our customers leaves a Zoom room open all day for folks to “drop by” her office.
Let’s explore these engineering stages in more detail.
Stage One: Up to about 20 engineers
At some point in your career, you probably managed an engineering organization of fewer than 10 people. At this scale, engineering leaders naturally have a strong sense of what’s happening on the team. You are the glue that holds the team together. You’re the DBA, the janitor, the bartender, the test writer. The flow of information is almost by osmosis – from working in close proximity. With a team of 10 or 20, you can walk the floor and talk to your direct reports, and you can have casual lunch conversations or hallway flybys to gather quick bits of information that help you make decisions and guide the team.
Engineering leaders at this stage know what the team is doing almost from memory. A 3-minute readout that walks through even anecdotal progress on strategic projects may be sufficient. Generally, though, VPEs and CTOs at this stage spend most of their time participating in the actual work of building along with their teams.
Stage Two: 20 to 50 engineers
When a team grows beyond 20 people, the leaders we work with tell us things start to change. At this stage, it no longer makes sense to have regular 1:1’s with everyone, and relying on information through “pulse-feel,” walking the floor, or the messages popping up in your inbox or slack is starting to falter. Engineering leaders of teams this size can be still technical so they can try to keep up by reading pull requests, manually eyeballing the progress of different projects, and chatting with direct reports and engineers here and there to fill in knowledge gaps and add context. This is the stage where you’re likely to really start relying on lieutenants.
At stage two, executive meetings are starting to get real and your presentations probably should as well. Ensuring alignment with sales and marketing leaders is getting tough, so it’s important to agree on some standard ways to communicate what the team is working on – measure progress, productivity, quality, SLAs, etc. – and demonstrate an understanding of how those engineering dollars are being spent (the payroll is now significant). This is the point where most of the VPEs and CTOs we work with a start thinking about how they’ll generate these KPIs and reports. Many will do some combination of combing through JIRA and GitHub and working with direct reports in order to pull together all the data they need. A surprising number of you will try to pull in the data programmatically into spreadsheets or build simple applications that hook into various engineering tool APIs.
Stage Three: 50 plus
At 50 plus, the processes you could rely on for smaller teams no longer work. You’re two or more layers away from the line. Too many initiatives are in flight. You can’t read through everyone’s code and scour through JIRA to check in on progress. Flyby hallway conversations don’t provide nearly the context you’ll need to make any informed decisions. And the most important email and slack messages you’re getting are probably more related to business issues than technical ones. At the same time, with so many initiatives in flight, it becomes critical that you know where the important ones stand.
For many engineering leaders, when they reach the point at which there is a third layer of management, they can no longer pick up any of these “flyby signals.” That’s the point where they need to make more data-driven decisions. They shift to the signals they can measure – engineering signals. And in a related manner, this is the point where most of our customers start working with an Engineering Management Platform.
Bigger Teams Need Better Signals
The takeaway from all the conversations with our customers is really that as engineering organizations grow and change, both in headcount and geographic diversity, their leaders need new and better ways to keep a pulse on what is being worked on, how these projects are going, and whether they’re aligned to the direction of the business. One way to do that is by measuring the signals engineers create by using development tools. An Engineering Management Platform can help you there. Better yet if your EMP can contextualize those engineering signals with business data for the most informed decision-making. In the end, visibility will be your friend as you scale your engineering team to the next level.
