The vast majority of engineers I have worked with are somewhat control-freaks. It’s something that’s hard to avoid when your job basically revolves around just two things: shipping features and preventing things from crashing. In the process of doing these two things well, we create best practices like code review, code conventions, performance practices, test-driven development, etc. The problem is that after you do these things long enough, the idea of following “best practices” starts to creep into everything you do, not just code.
All these practices come from the right place. Coding is complicated, and you are trying to avoid chaos. We come up with these rules to prepare for when the codebase grows or when the team grows.
- You can’t merge code into master without a PR review.
- You can’t deploy without waiting for the CI to finish.
- You can’t deploy without QA approval.
- You can’t work on this task before the PM approves.
- You can’t work on that before the Sprint Planning (it will affect Velocity)
- You can’t fix that now; it’s not an OKR.
- You can’t deploy on Fridays.
These are all mechanisms to avoid mistakes, and it’s all very mature. The problem is that trying to avoid every mistake will also affect agility. Most teams curtail (employee) freedom as they get bigger to prevent errors, it’s almost an inevitable trade-off.
The problem is that things quickly escalate from day-to-day programming processes to the high-level organizational process as engineers become managers. Eventually, almost every company turns into a slow-moving bureaucratic place, and it’s a hard-to-avoid boiling frog situation. Things start to slow down, but you can’t tell when and how it began. Bureaucracy creeps in little by little before people can notice. Someone makes a mistake here, the team has a retrospective meeting, then the team (or just the manager) comes up with a way to avoid it, and a new rule is born.
Here’s the step by how it goes: Desire for our output increases -> the team grows -> team get more things built -> complexity increases -> chaos emerge -> mistakes happen -> people get pissed -> people leave -> process emerge to stop chaos = It’s time to grow up, and process feels good compared to chaos.
Give enough time, and most nimble startups will eventually devolve into a slow, tedious enterprise that can’t put out software anymore.
Process has nice short term benefits:
- Minimal thinking required
- Easier to onboard people
- Few mistakes made – very efficient
- Easier to predict and easier to estimate outcomes
But also come with side-effects:
- Efficiency trumps flexibility.
- Lack of flexibility frustrates innovators.
- Adherence to process reduces personal responsibility.
- Very optimized for the existing team and market.
- Experienced people get frustrated/bored with low impact and leave.
- Beginners join at a much higher ratio (minimal think required and clear step-by-step rules make them somewhat efficient).
Over time, the market will shift, and the company won’t be able to adapt quickly anymore because the employees are great at following the process. You feel like things are moving much slower than they should be.
On very few occasions, I’ve had the pleasure of experiencing the total opposite. Working at a small team where everyone trusts each other’s skills and is so aligned in the overall direction that they end up outperforming much larger organizations.
In my experience, the reason smaller teams could outperform much larger ones was always that the % of high-performance employees grew faster than the complexity of the problem/business. The problem is that you can only attract really high-performance employees and keep them for a long time at a startup if you can:
- Provide freedom.
- Provide a chance for big impact.
- Provide a challenging environment.
- Provide top of market compensation.
With the right ratio of high-performance employees, you can optimize for freedom by drastically reducing process simply because high-performance employees commit fewer mistakes.
Bad process vs. good process
But not all process is a bad process. Bad process is designed to distribute responsibility, keep track of people, and _try_ to prevent recoverable errors. Here are some examples:
- Multi-level approval for projects.
- Get ten people to interview a candidate.
- Not allow deploying the smallest changes without QA review.
- Not allowing merges on master branch without another programmer approval.
- Not allow an employee to deploy on Friday even if the person is willing to be on-call to cover any issues.
- Daily standup at 9 AM every day because you can’t trust people to get stuff done if they are not in the office from 9 to 5.
- Or daily stand-ups to catch problems, even though the vast majority of time problems don’t get raised during the meeting.
- Two-week sprints to tell people what to do.
A good process, on the other hand, is designed to maximize freedom by creating alignment and sharing context. Example:
- Regularly high-level strategy meetings to keep everyone aligned.
- Regularly sharing context on what you are currently working on (but in a way that doesn’t interrupt everyone’s workflow and with only relevant people).
- Letting others know when you are updating code that might overlap with someone else.
- A minimum overlap of certain # of hours when working remotely.
- Regular 1-on-1s to think through things to be improved and share context.
The case for rigidity and process:
Not all mistakes are created equal. Some things are disastrous, and you can’t recover from (ex: ethical issues, security, data loss). For those, you should have a ton of process around, but in creative environments, the vast majority of problems are recoverable as long as you can be fast at fixing them. It takes much more effort to try to prevent all issues, then fixing the few mistakes made (especially when you have a more senior team).
Long story short
You can move quite fast if you:
- 1st – don’t try to prevent recoverable mistakes
- 2nd – reduce the number of errors by having mostly high-performance employees (especially helpful for early-stage products or tough times)
- 3rd – maximize for freedom, responsibility, and creativity instead of control.
- 4th – trust that high-performance employees will do their work well.
⚡️ Our software, Know Your Team, helps you nail the fundamentals of business and leadership: We help you run effective one-on-one meetings, get honest feedback, share team progress, and build team rapport. Try Know Your Team for free, yourself, today.