Scaling an Engineering Team from Zero to Infinity
Here’s my thoughts on designing products with sizeable engineering teams
To use an engineering analogy, verbal communication (the graph) doesn’t scale linearly with the number of nodes (people). When communicating 1-on-1, there is 1 edge in the network of two nodes, meaning you only need to say something once (edge) before both people (nodes) have full information.
This is the dream.
Not only that, but both people have confirmation (ack) that the message hasn’t been misinterpreted. Ok, (ack) was overkill but the interpretation concept is important.
Let’s see how this scales.
Just 1 Developer
When we first started Try.com in 2011, we were an engineering team of 1. Well, actually 0.5 because I was also the designer. I could easily jump straight into coding what was in my head. There was no need to build out design documentation, I would simply design in development.
Team of 2 Developers
Designing in development scaled for another few years when it was just 2 of us coding as we were in constant communication with each other. This is that dream scenario I was talking about.
Team of 3 Developers
When we hired our third engineer, we were lucky because we hired one of our customers who knew exactly what we needed to build. But we needed to introduce some process.
This is where instead of changing my role to full time designer, I decided to perfect my bad habit of designing in development by introducing a lame excuse for process: developers would send PRs with the new work and as part of my code review I would re-do all their work, except with a nice beautiful UI before merging master. Yes, you read that correctly.
Team of 4 Developers
Our “process” breaks overnight because developer 4 doesn’t know what to build. This is where we realize that this kind of team doesn’t exist.
Team of 4 Developers and a PM
Now things are getting dicey. We need to “project manage”. Hello JIRA.
Sidebar — Hating, then forever loving JIRA
Oh my god, JIRA. What a steaming pile… this can’t be real life. Yes, we all had the same brain explosions as you. But I can say with confidence:
Moving to JIRA from all the other pretenders was a great decision. Good decisions are the ones that stick, and it’s a topic for another time but JIRA just gets better and better the more you scale and there is nothing like it.
Its sooo bad but it’s sooo good. It’s craigslist.
But in the beginning you don’t need to be a JIRA power user, and at this stage simply ticket tracking is enough.
Team of 5+ Developers, 1 PM and 1+ Designer
No matter how product minded your engineers are, no engineer enjoys not having clarity of what they’re building. Really solid teams of 3 or maybe 4 developers might be able to get by without a PM but that’s really the limit. Ideally you need to hire a dedicated PM and designer right around 4 developers.
People often say PM stands for Product Manager where in fact it should mean Project Manager. Ben Horowitz’s definition of a Product Manager is the CEO of the product and even if it is old school I agree with it. PMs are not leading the product direction but they are managing the product development process. There is no shame in this and someone should put an end to this madness. I’ll just say PM and you can interpret it however you like.
Hiring our first PM was another great power move because he taught us how to use JIRA to increase the team’s output. His name is Derek Ward and he is one of the best people I’ve ever worked with.
Now is a good time to talk about epics. Epics are the real reason why JIRA is so great. An epic is a standalone marketable feature. Its a unit of the product that has enough isolated value that it’s worth mentioning in an update.
Top tip on writing epics
When I begin writing epics I actually begin by writing the feature release announcement so I can visualize what value we’re creating for the user or the business. I will always include measurement criteria for the feature to be successful or be deleted. More on this later.
The great thing about epics in JIRA is the customer service team, the ops team, the eng team, customers, basically all stakeholders in the business can read and understand the epic from day 1 which goes a considerable way to reaching the dream state.
Design is 1 or 2 sprints ahead of engineering
Some considerable effort must be put into design documentation for engineering teams to really fire on all cylinders.
I always start with a UX flow. Miro has been an invaluable tool for us here. This is one of the best product development products I’ve used. Here’s a real flow I created for our post checkout customer experience.
Notice how nice-to-haves are dotted into v2 boxes. Each step that requires a UI design is numbered in red if incomplete and green if already complete. We’ll discuss this as a team and various epics and then stories will fall out of it.
Now the designer (also me at this point) will label their UIs with the corresponding circle code. Here’s a flow of screens that would fall out of a flow diagram, complete with motion blur for animations.
We will often map out the screens onto the original flow diagram right inside MIRO, basically putting the screens where those red circles were in the original flow.
Leveling up with Lottie
If we’re feeling really fancy, we’ll build an entire animated flow of the product in After Effects and export the animations to Lottie for direct use in the web and iOS, like this one:
The more design documentation you have, the better decisions engineers can make story pointing and sprint planning. The amount of effort this takes cannot be underestimated and is the reason you need at least one dedicated full-time designer. For a really accelerated timeline we needed to backfill with 2x FTE designers from UENO plus me. Then we scaled down to just me and 2 part timers.
“Do what you’re not told” — This is the dream but for large teams
Let’s look at some of the ways we’ve leveled up by this point.
- With epics, engineers will understand how their stories fit into the bigger picture, and they will automatically make good decisions based on good context. Smart engineers will even predict what should come next and even build things that would have required another round of design and story planning. We called this “do what you’re not told” and it was one of our core values. This is how we reach a dream scenario even with so many levels of comms.
- For support staff, the epic appears in Confluence so they know how to communicate to customers about feature questions or things coming down the pipe. These staff have the direct line with customers and experience the customer pain every day. This gets really old fast and can lead to frustration and employee churn if they feel like the engineering team isn’t listening. When your staff have confidence that engineers are working on a clearly articulated epic that fits into a larger roadmap, this is also a dream scenario. Now they can communicate with customers the same way the Product lead would. Now they can do what they’re not told.
- A good PM will ensure new epics are never released without instrumentation to measure the intended impact of the epic. And by the way, a properly defined epic will have the expected measurement defined at inception. A proper product roadmap will map a business’s entire funnel. And I mean your entire business can be mapped as a funnel, every product and every business process. It is normal for this funnel to take up an entire whiteboard. We had ours up in the office permanently. Each of piece of the funnel will be red/orange/green indicating its performance which allows your PMs to self manage. Now the PMs know where to focus the engineering team. This is another do what you’re not told situation but will likely require input from founders.
This part is really important. Do not skip.
For a while we were executing on epics and successively increasing revenue but our support team were extremely unhappy with their tools and our engineers were ignoring much needed chores. It took us a while to figure out that this was a huge problem. We were only optimizing for dollars. We found that epic impact can be measured in at least 1 of 3 ways:
- Profit. Some epics will literally turn up on the P&L as increased profit. This is why Ben Horowitz says a good Product Manager owns his/her P&L.
- Customer happiness. This is self explanatory.
- Employee happiness. As your startup grows you will find that your employee tooling will degrade and cause incredible frustration with engineers, ops, customer service, all of the above. Some epics should be dedicated to keeping your people happy.
That means a piece of your business funnel can be red even if it is making customers super happy because it might be crippling for employees. This is really important.
Shards = Workstreams
7 people to a team is the one-pizza rule so when you need to scale beyond this you will probably start thinking about workstreams.
Workstreams were introduced to me by Ethan Batraski one late evening in our office when we needed help hiring engineers. I have fond memories of this moment when he drew a grid on the whiteboard with engineers as the rows and workstreams as the columns, showing how to deal with dependencies across timezones and across resources. You’ll want to design your workstreams so they aren’t blocked by work happening in different timezones. Sometimes you can take advantage of the timezone difference within a workstream.
A workstream is a full-stack team that can generally deliver product without being blocked by work required from others outside the team. Depending on the capabilities of your engineers you can usually carve out workstreams by sub-product, lets say a particular cross-platform internal tool. This will include the mobile engineers, backend, frontend, pipeline, PM, designer etc…
In larger organizations the lead engineer is the Director of Engineering and they will report to the VP Engineering. The key is that the workstream contains engineers that work on the full stack and be responsible for the same feature across all platforms.
Now you have a model to scale from zero to infinity.
