Run A Sprint Where Engineers Prioritise Their Own Tasks
Engineering teams’ work ends up being prioritised by the product manager, eng manager or someone in a similar role. This relegates individual engineers to order takers. Like a waiter in a restaurant, they have to cook whatever is ordered. This effectively assumes that engineers can make no decisions on their own, and don’t know what’s important. Any management structure should give some weightage to the views of the people who are actually doing the work and have a first-hand feel of it. We can debate what this weightage should be, but zero is not the right answer.
Engineers took up engineering as a career because they’re excited about building things. Nobody took it up to do what managers or designers tell them to do. But when they’re reduced to a mere implementor, they’re dissatisfied. They may not be able to pin it down and articulate it, “I’m unhappy because I have too little autonomy.” They’re just dissatisfied, which manifests in general grumpiness, doing just enough not to get fired, emotionally disconnecting from work, jumping whenever someone offers a higher salary, and so on.
To give more autonomy, companies should experiment with running one sprint where each engineers prioritise and pick their own tasks. They can work on scalability, reliability, privacy, security, fix bugs that annoy them, improve UX or whatever they like. They can prototype new features, or modifications to existing features.
The UX designer, PM and others will be available during this sprint to help with whatever engineers want. This is a reversal of the usual role where these people tell the engineers what to do and how to do it.
Engineers should be able to pick tasks only within the existing scope of work. They can’t build something like a game that’s unrelated to the company’s business. Or a new product even within the company’s business. They can’t do anything that effectively commits the company to future work, like launching a new feature. They can’t learn a technology that may not be relevant to the company, like Haskell 1.
It’s not an open-ended “do whatever you want” 20% time, which isn’t affordable for many startups. Rather, the idea is to work within the existing scope, but to have a free hand at prioritising within that scope.
If you haven’t tried this idea, do so for one sprint.
This proposal should result in useful things being developed that wouldn’t otherwise be developed, and increased morale for engineers.
Before the sprint, engineers plan what they want to do, and share a plan with the (product) manager, to ensure that it’s aligned with the above goals.