The vast majority of engineers I have worked with are somewhat control-freaks. It\u2019s something that\u2019s 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.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
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\u2019s almost an inevitable trade-off. <\/p>\n\n\n\n
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\u2019s 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.<\/p>\n\n\n\n
Here\u2019s 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\u2019s time to grow up, and process feels good compared to chaos.<\/p>\n\n\n\n
Give enough time, and most nimble startups will eventually devolve into a slow, tedious enterprise that can’t put out software anymore.<\/p>\n\n\n\n
But also come with side-effects:<\/p>\n\n\n\n
Over time, the market will shift, and the company won\u2019t 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.<\/p>\n\n\n\n
On very few occasions, I\u2019ve had the pleasure of experiencing the total opposite. Working at a small team where everyone trusts each other\u2019s skills and is so aligned in the overall direction that they end up outperforming much larger organizations.<\/p>\n\n\n\n
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:<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
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:<\/p>\n\n\n\n
A good process, on the other hand, is designed to maximize freedom by creating alignment and sharing context. Example:<\/p>\n\n\n\n
Not all mistakes are created equal. Some things are disastrous, and you can\u2019t 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).<\/p>\n\n\n\n
You can move quite fast if you:<\/p>\n\n\n\n
\u26a1\ufe0f Our software, <\/em>Know Your Team<\/em><\/a>, <\/em>helps you nail the fundamentals of business and leadership:<\/em><\/strong> We help you <\/em>run <\/em><\/strong>effective one-on-one meetings<\/em><\/strong><\/a>, get <\/em><\/strong>honest feedback<\/em><\/strong><\/a>, share <\/em><\/strong>team progress<\/em><\/strong><\/a>, and <\/em><\/strong>build team rapport<\/em><\/strong><\/a>.<\/em><\/strong> Try <\/em>Know Your Team<\/em><\/a> for free, yourself, today.<\/em><\/p>\n","protected":false},"excerpt":{"rendered":" The vast majority of engineers I have worked with are somewhat control-freaks. It\u2019s something that\u2019s 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… <\/p>\n