1. A continuous flow of work is essential
“It’s important for Engineering to quickly detect bottlenecks. When work can’t be pulled through the system despite available downstream capacity we are operating inefficiently.”
Engineering should always have more features and products ready to be built than available resources and money to build them. Such a pipeline ensures the engineering team can be fully utilized while providing some flexibility for shifting priorities and requirements.
Fluctuating between too much work and nothing to do carries a huge opportunity cost. It can also be demoralizing for your developers and almost always nets out to low engineering efficiency, not to mention it makes estimation and planning that much more difficult (too much variability).
If your team uses Scrum, David recommends having the equivalent of at least 2 sprints capacity of ready-for-development (aka groomed) work lined up.
2. Don’t add head count until your team is running efficiently
“Aim to keep each engineering team as small as possible, while focusing on improving efficiency.”
Whenever an engineering team adds headcount, there are also non-trivial increases in complexity, communication, and overhead. Before adding more people to increase output, an effective manager first ensures the current team is operating close to their full potential.
Suppose an engineering team is running at a low efficiency rate, and operating at around 40% of its ideal capability (however measured) because of process overhead, poor specs, or other inefficiencies. Adding four engineers to a team that’s this inefficient means the new engineers are really only making an impact at the level of two well-deployed engineers.
Throwing more bodies at the problem doesn’t solve the problem. In fact, it compounds it.
The right play here is to focus on changing processes and lowering ‘non-work’ overhead first, before adding more team members. This is why managers that operate with this mode of thinking are so effective—achieving a 20 percent efficiency bump across a team of 15 by solving operational problems is the functional equivalent of adding three more engineers to the team, without any of the cost or snowballing complexity that comes from ‘throwing bodies at the problem.’
3. Prevent ‘building the wrong things’ before they enter the pipe
“It’s the role of the engineering manager to work with the product team to ensure everything being delivered is providing the value the business expects.”
Once a team is operating more or less efficiently, building things right, another critical area for improvement comes from building the right things. There’s a surprising amount of engineering waste that does not come from being unproductive, but from successfully building things that don’t provide business value.
This is still a form of waste, and it can take many forms. This is why it is so important to understand the ‘why’ in user stories.
One example of this is building features without a clear user in mind. The classic example is feature bloat in Microsoft Word, where something like 80% of the features are barely used.
The flip side of this is building to exact user requests. Users aren’t always excellent at communicating their underlying needs, so lack of inspection in interpreting feature requests is another kind of risk.
“The customer invents nothing. New products and services come from the producer.”
— W. Edwards Deming
f the customer always knew what they wanted, we would never have broad-scale disruption.
Through his experience at Vyze, David can attest that engineering management is all about creating this kind of balance: being responsive to users and stakeholders requests, while also trying to understand the real underlying needs.
By ensuring that every piece of work is weighed in before it enters the pipeline, the engineering manager serves as a critical sanity check for the business.
4. Make sure that each task has clear requirements
“The last thing an engineer wants to do is sit through more meetings, chase people and navigate the political game of gathering requirements. It’s at odds with the core skill set of most engineers.”
It’s important that the team has stated policies in place before work is accepted, so that everything requested can actually be built. For example, for work to be committed to by engineering, it must:
- Have Acceptance Criteria
- Be a properly formulated user story (who, what and why)
- Have been previously reviewed and groomed by the team
Vague or incomplete requirements are open to interpretation and scope-creep and often lead to misunderstandings, which negatively impact team morale and productivity. Instead, setting the right expectations up-front means that engineers get to do more of what they love: coding.
The ideal set of requirements provides the minimum amount of detail needed by the team to implement it and this is accomplished by having clearly understood requirements.
5. Communicate clearly — most problems arise from poor communication
“Many engineering inefficiencies take root long before a single line of code is ever written. A lot of problems are actually caused by a communication breakdown between people.”
If we could visualize a new feature moving through the pipeline—from the time a customer requests it to the time it’s delivered—a disproportionate amount of time is spent outside of engineering. Moreover, once a feature is queued up, there is a greater surface area for ‘engineering delays’ on the part of outside actors than on the part of people inside engineering!
What’s fascinating is that for the majority of the time, a feature request is actually in a ‘wait’ state—it’s not actively being worked on. Something that’s been waiting to be implemented in a backlog for most of a year, may be actively built in only a few weeks.
A feature request may come in through customer support, spend time in R&D, then product development, and finally to engineering. Where there are ‘handoffs’ between these ‘systems’ and poor communication, problems often arise. They’re not anyone’s fault per se, as each may have done their part, but there’s still a breakdown of the overall system and that’s exactly the point.
It all comes down to openly communicating progress and improving the flow of work throughout the entire organization. This can have a far greater impact to overall delivery times than simply focusing on optimizing the work of engineering—while the latter is important, the first is essential.
Ultimately, an effective engineering manager understands that business success is a team sport.