The Road to Engineering Bureaucracy is Paved with Good Intentions

Raise your hand (metaphorically) if you’ve heard the following:

It’s just a 15-min daily standup so everyone knows exactly what they should be doing everyday…

How can we align different teams together if we don’t meet…

We need to streamline the project management process between product, front-end, and backend…

When an engineer wants to introduce a new service or tool, one of the required exercises is to do a cost benefit analysis. Based upon our current and expected use cases, how much is this new thing going to cost in $ or time. When a product manager wants to prioritize work, they often go through a budgeting exercise to assign dollar amounts to issues to emphasize the fact that a team’s time is a limited resource.

Yet when technical program management is separated out, there’s often no consideration to the cost of process. Somehow meetings are considered free. For a team of 10, a 15-min daily standup costs about 600 hours a year. And of course, it’s never just a 15-min interruption. Most research shows that workplace interruptions takes 20min+ to recover from. Congratulations, this one standup just cost your company a headcount.

Of course, not having any process is just as dangerous. You need to know whether everyone is working on the right thing at the right time in the right way. But our goal should be to improve current processes, not just to add more. For that to happen, you need to first understand how your team works currently and not just attend an extreme agile training session and suddenly feel you’ve discovered the magic bullet to all teamwork/collaboration issues.

But perhaps the most insidious is the accumulation of necessary processes over time. You need a daily standup right? You need a company all hands right? You need an engineering team sync right? You need a product-engineering sync right? Taken in isolation, each of these meeting don’t take up much time and may even be critical. But after a while, you reach a point where your engineers know how to “align themselves with higher company goals”, but they don’t have any time to code. Or that in order to do any project, you need 4 managers to meet for 6 months to reach “alignment” before 1 engineer starts working on it. The 15-min standup computed alone costs 600 hours a year. But if the team already has a virtual standup in Slack and a weekly sync-up, the marginal cost should be even higher.

Once meeting/process overhead goes above 20% (~ an hour a day), new process must compete with old processes for time. This means that some new processes must be rejected, or at the very least combined with existing processes in some refactored form. A good team lead or manager MUST think from the perspective of their ICs and be vigilant for opportunities to make their team processes more and more effective. As an engineering manager, this type of refactoring will pay-off immense dividends in the long-run.

99.9% of the time, process is not being proposed out of malice or some kind of power trip. Instead it’s usually a combination of cargo-cult’ing and/or lack of a developer-focused perspective. But the road to engineering morass is paved with mission critical sync-ups. Whether you’re an engineering or a product leader, if you want to have useful processes and an efficient engineering team, these are the 3 rules to remember:

  1. Processes aren’t free
  2. Processes have increasing marginal cost
  3. Don’t propose new processes unless you understand the existing issues

Twitter: @changhiskhan

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store