How to keep engineering teams effective through prioritization

How much work you have in progress, how often teams are shipping code, and how your team deals with technical debt can all affect how efficient your reports are.

Everyone is familiar with the theory of keeping teams effective as they work to deliver bug fixes, features, and products to your users, but when work feels like it’s piling up and you’re being pulled in multiple directions, it can be hard to apply that theory and ensure your team is focused and prioritizing correctly. 

A product team is responsible for feature work, bug fixes, and technical debt. Some of these responsibilities will come with strict deadlines that the business expects to be met. This can be difficult for some teams, especially if processes are chaotic and efficiency is lagging. To help performance in this area, consider making informed trade-offs on which incoming work is truly urgent, which is impactful, and which is unfortunately headed to the bottom of the list.

Minimizing work in progress

Work in progress (WIP) refers to the amount of work that your team is in the middle of working on. This can be a bug fix that is waiting on review, a feature that needs input from user experience (UX), or some technical debt that is partially refactored. It is important to keep this set of work down to a minimum to avoid overwhelming and overloading your team. We know that humans are not great multitaskers and struggle to context switch, and the more work any team has on their plate at one time the more times during the day a colleague will need to context switch.

In a perfect world, every team would have one piece of WIP per person (or potentially less if people are working together). Once that piece of work is complete, that team member would pick up another piece and get started. Unfortunately, we don’t live in that perfect world, often things can go wrong elsewhere or urgent requests can come in that pull an engineer away from the WIP. 

It’s important to have a strategy for when these instances occur. Some ideas you might try are:

• Hold back on pausing WIP items unless absolutely necessary. If something “urgent” lands on your lap, gently push back by asking if it would be a problem to get started on the task the next week. It is surprising how often (or not) that “urgent” has been oversold.
• Communicate clearly what work will now be deprioritized as a result. “We can get X done now, but at the expense of Y being delayed.” Often people requesting work do not realize that it will have a knock-on effect. Communicate that effect and explicitly ask if that is OK. Not only does this highlight the impact, but it also gives you sign-off should anyone then ask why some work has been delayed.
• Reduce the scope of the current work in order to complete it sooner. If you can find a way to reduce the current work in order to get into a state where you can pause and push the rest of the scope onto your backlog. That will allow your team to move on without the work lingering over them. No one likes loading up their worklist in the tracking tool and seeing five items with their name on it. By changing the scope you can get that initial work off the tracker and prioritize the rest after dealing with the urgent problem.

Shipping little and often

An easy way to keep the amount of WIP down is to keep each item small. 

It is important to set a culture on the team of shipping often because it has many benefits outside of minimizing work in progress:

• Code reviews are easier if there are fewer changes in each review.
• The risk of breaking functionality is reduced as each release contains fewer changed lines of code.
• It builds a habit of shipping on the team and maintains a nice momentum through the team.
• You can ask users to test features that you have partially shipped and gather feedback.

Some of these might not be possible depending on the products you work on and how their releases are managed, but even then there are ways to enable this workflow. We have had a lot of success with feature flags, where features are gated behind a setting that can be toggled on or off. This setting can be managed at whatever level you prefer:

• Allow your users to turn settings on and off to get early previews of features.
• Turn settings on early for your internal users to get their feedback whilst avoiding releasing incomplete features to the public.
• Ship to a percentage of your users and gather feedback incrementally, or run A/B tests on the impact of the feature.

Should the feature cause a bug in your software, it can easily be disabled via the toggling of a setting. This is either a change that can be done without code modifications (you might have an admin dashboard where you can change these settings) or it will require a one-line change to set the flag back to “off.”

By shipping incrementally and keeping risk down, we also decrease the chance of bugs occurring and interrupting work. If there is a bug in a feature that is flagged, you are able to quickly disable the feature via the flag, and then prioritize fixing that bug in the future without derailing the current item you are working on.

Approaches to technical debt

Every team I have ever worked on or with has been negatively affected by technical debt. This debt can have accrued over time in a myriad of ways and is not necessarily the fault of any individual or the team. Long-running software products, or start-ups who have needed to move nimbly to secure funding, will inevitably build up code that cuts corners or has been forced to handle new scenarios that it wasn’t designed for. Knowing how to tackle this to avoid ineffectual teams but also without the drastic step of requiring multiple weeks of pure technical debt work to clean things up is a challenge.

Assigning specific weeks or months solely to technical debt work is bound to fail. It will either act as a band aid, barely keeping the team unburdened for a period of time until tech debt mounts up again, or it will be voted out by other stakeholders who are frustrated by a slowdown and lack of feature work. Instead, you must create a process that allows you to incrementally reduce technical debt, so that your engineers can work on it without additional overhead.

The best approaches consider the option of technical debt early in the development process of a new feature, but they also quantify the impact that the technical debt will have on the implementation and timeframe of this work. 

There is nothing achieved by tackling technical debt in isolation. The best and most relevant time to tackle technical debt is just before you are about to do work that would be negatively impacted by it. If an area of your codebase is hard to work on due to technical debt, but you never have to work on that area of the codebase, that debt is not worth improving. 

On the other hand, technical debt in an area of the codebase you are frequently changing is going to have an impact on your output. Trust your team to highlight areas that will impact upcoming work and discuss the trade-offs of tackling debt with them. This approach does not mean that your team gets total freedom to free up all technical debt – that might be too much of an undertaking – but you might agree that an extra day spent on sorting the issue will pay dividends in the medium term and therefore is very worth it.

Final thoughts

Keeping product teams effective is a challenge, but if you can use the techniques above you will be able to free them from feeling overwhelmed and give them space to advise you as the lead on how best to deal with any problem areas of the codebase. 

An effective team is usually a happier team, and a happy, productive team ships more features and is generally more pleasant to work with.