If you want to build a ship, don't drum up the men to gather wood, divide the work and give orders. Instead, teach them to yearn for the vast and endless sea.
Imagine your startup with one tiny adaptation: engineering builds anything instantly.
Visualize the details. How will it affect other teams? How fast will you iterate? What would be achieved in a single day? You’ve become a startup god capable of anything.
This thought experiment is not practical, but it illustrates how engineering is the engine of a tech company. The better the engine, the faster the car goes.
Fast engineering teams are not created by accident. They are the result of intentionally designing and maintaining them for speed, just like a nice race car.
How does one design an ultra fast engineering team? I’m glad I asked.
Warning before going over the speed limit:
Some companies (say healthcare or hardware) should be mindful of the costs of speed and may want to optimize for speed within some strict constraint (say patient security, hardware reliability)
To apply these principles to multiple teams you’ll want to apply them to each team individually while designing the organization to have minimal cross-team dependency (also known as Squad model)
Don’t mindlessly copy paste these principles. Understand why they work and adapt to your case
Hire fast engineers
The foundations of an ultra fast engineering team are fast engineers.
Three points are often misunderstood:
The term “10x engineer” exists because some engineers are literally 10 times faster than others. This is why hiring for speed is so critical and why you need to get a sense for the speed spectrum that is available
Speed is a behavior, not a skill. That’s why you must hire for it and not hope to cultivate it (doesn’t work). This also implies firing engineers who are below your speed bar
The measure of speed is shipping, not coding. Don’t judge speed based on coding speed alone. Look for engineers with demonstrated ability to quickly navigate to full shipping process
There’s a lot more to engineering hiring but these points should help you optimize any hiring process to output fast engineers.
Embrace the cost of speed
Move fast and break things was one of Facebook’s core values back when it was a cool company.
It is a fantastic value because it acknowledges the benefit and the cost - that moving fast means that things will inevitably break. New engineers at Facebook use to ship on their first week and often break something shortly after.
You need to embrace the fact that moving fast means that sometimes things will break, quality will suffer, and cringe inducing shortcuts will be taken. Accepting means not getting mad, not punishing for it, and being vocal that these costs are acceptable.
Explain why speed matters
Your engineers (hopefully) want your company to succeed and are analytical thinkers. If you explain why shipping speed is more important than making a feature 10% more polished they will adapt accordingly.
Explain why faster iteration gets you to product-market fit faster
Explain why linear improvements to speed have non-linear effect on results
Explain how engineering drives the whole company forward
Explain that every slow startup in history failed
Broadly speaking, you want your engineers to value creating value and not creating code.
There is no engineering team
As an engineer I am allowed to say that engineers working in isolation are terrible. It is in our nature to allow scope to grow and try to fix every potential future problem, and this happens when engineers work in isolation.
Instead of engineering teams, build tech teams (or Squads) that include product and design. Make sure the team has full autonomy to ship within their scope and help them create a steady (but not strict) fast shipping pulse.
Optimize your tech stack for speed (and simplicity)
This should be the #1 parameter of your tech stack.
How?
Map out where engineers will spend most of their time
For every tech choice do this:
Start with the option that is the fastest (in context of the mapping above)
Choose this option
Make it as easy as possible to write tests
Do not optimize for the stack for how fast it will take to spin it up or some distant future benefit. It is more important to make the ongoing work move as fast as possible
Project autonomy
Every time you make a decision for someone you take a swing at their motivation.
You should invest in your team's motivation for humane reasons, while enjoying the side benefit that motivated engineers are faster engineers.
Particular areas to watch for:
Which projects they work on. Create enough slack so that you don’t prescribe every single project they work on. Some ways to do this are to maintain a good backlog, have built-in time for different types of work (product, debt, fun), and loosening your grip
Scope and sequencing. Repeatedly encourage scoping small and breaking things down, but never force it
Technical choices. Pick your battles carefully when reversing or forcing down technical decisions. It is quite demotivating to implement your manager’s solution
Team comes first
A bunch of fast executing engineers don’t add up to a fast executing team. Individuals must optimize for the team’s speed first and theirs second.
To optimize for team speed engineers need to unblock others before doing their own work and as well as be mindful of others’ time.
Here are a few good habits to start with:
Review code before writing code
Write small single purpose PRs
Practice pair programming
Standardized communication structure in PRs, tickets, and code reviews
Just enough planning
Planning saves time and pain. Before engineers start executing they should write a light project plan. The goal of the project plan is to
Align on the technical approach
Clarify what’s in scope (and what is not)
Raise open questions and get them answered
Uncover risks and complexities
This plan should take no more than a few hours to write. It should be critically reviewed by at least one engineer and both design and product. I have yet to see a project plan of this form that wasn’t a good use of time.
Just enough means that you don’t do more than this and don’t write a plan for small 0-2 day projects.
Needful to say that proper planning and attention to detail by design and product impacts engineering speed even more than engineering planning itself.
Quality matters?
Of course maybe.
My personal philosophy is that speed is more fundamental than quality. Here’s why:
Speed is behavioral and deeply ingrained. It is much harder to influence a mature team’s speed than improve work quality
Speed is more important for business
The pursuit of speed leads to a healthy mindset towards quality
That being said, quality is not inherently detrimental to speed, quite the contrary. What is detrimental to speed is obsession over quality.
To avoid this common obsession you want engineers to think critically and flexibly about quality. This begins with the understanding that quality heavily depends on context and that it is a rich topic (we’ve got code quality, testing quality, UI quality, architecture quality, and so on).
When embarking on a new project, ask these questions::
Are we building a proof of concept or a long lasting feature?
Is this a core part of our system that will be extended and built upon? Or maybe it’s a peripheral piece?
How might this project impact our speed?
What about this project can go horribly wrong?
Including this in project plans will encourage your team to think critically and flexibly about quality.
Let engineers own their launch and lunch schedule
Here’s what one of my engineers said when asked how we’re moving fast:
We have a flexible schedule. We know the task and we can do it whenever we want. We don't push ourselves to work, it's more like an inspiration process. When you are inspired your speed is three times faster.
Flexible schedule is not only inspiring, it allows engineers to work when they are most productive, avoid context switching, and optimize their time like engineers.
Flexibility also refers to meetings. Engineers should be able to block long periods of time for heads down work without any friction. Fragmented days are productivity killers.
Two-way collaboration
Following design and product decisions with 100% precision is an enormous timesuck. This is because many small differences are meaningless to users but will greatly impact implementation complexity.
To avoid the timesuck make sure that:
Product and design spend time explaining the why instead of the what
Engineers understand your users, their problems, and your value
Engineers are encouraged to push back and suggest changes. And even have autonomy to make small changes on their own (but start small with this one)
The more engineers are building towards value rather than specifications the better.
Forget about tech debt and focus on engineering health
Like the US national debt, tech debt can be massive and meaningless at the same time. Tech debt is only meaningful in the context of the health of your engineering team.
The framework that helped me the most is the 4 states of an engineering team by Will Larson. Here’s a good summary of it and a useful screenshot. Your goal is to always move up to reach state 4.
Note that I’m not suggesting that you ignore debt. On the contrary, you should be diligent about tracking and organizing your debt to be able to understand it. But your goal is state 4, not minimal debt.
Implied pitfalls
In case you weren’t reading carefully and at the risk of repeating myself, here are the implied things you don’t want to be doing.
Strict deadlines - Not fun, burns out engineers, causes re-work, and inhibits innovation. Use flexible deadlines instead and strict ones only when necessary
Measuring and compensating based on speed - This can only lead to fake sense of speed with underlying reduction in quality and spammy engineering practices
Forgetting how engineering works - Forgetting that engineering timelines are volatile and that a lot of the work is hidden can lead to disappointment and anger. Just trust your team and go do some meditation feeling angry
Being “hands on” - Being too involved pisses people off, being too out of touch is also a problem. Your goal is to be informed, helpful, and motivating. How you do this needs to be tailored for each individual engineer
Quality standards and technical debt - Obsessing about these makes them the goal. Obsess about delivering value fast and engineering health instead
Making speed stressful - Don’t create competition amongst your engineers. Engineering speed is a team sport and the goal is for the whole team to be ultra fast together
Conclusion
Here’s the blueprint for an ultra fast engineering team.
Hire fast engineers
Embrace the cost of speed
Explain why speed matters
There is no engineering team
Optimize your tech stack for speed (and simplicity)
Project autonomy
Team comes first
Just enough planning
Quality matters?
Let engineering own their launch and lunch schedule
Two-way collaboration
Forget about tech debt and focus on engineering health
Oh and remember this: your team will move only as fast as you do.