Development team: Managing multiple competing priorities

Apart from the ideas and work generated from within the Product Development Team, there are always plenty of stakeholders needing engineering support. When I first joined Decision Tech in 2013, the number of requests I would get for the Dev Team to ‘just help out’ or to ‘take a quick look at this’ was bewildering. And every request was, of course, ‘needed ASAP’.

So how can you better manage all of these competing priorities?

There need to be processes in place that manage the flow of these requests onto the development team. A nice way of starting to add some structure is to understand your work flows.

Ask yourself the following three questions:

1.What are all the different sources of work? For example:

• Internal teams, such as marketing
• External teams
• Regulatory

2.What workflow is the item channelled through? e.g.

• A project steering group?
• Change requests?
• Live support?

3.What is the estimated duration of the piece of work? e.g.

• Small change <1 week
• Feature <3 months
• Project >3 months

At Decision Tech we knew we needed to make some changes, so we applied the above questions to our own workflow:

What are all of our different sources of work?

• Partners – using our technology
• Mobile comparison product
• Home comms comparison product
• Product development ideas
• Tech debt/health
• Ofcom accreditation support

What workflow should each item be channelled through?

• Urgent Things (unplanned work)
• Projects/Growth Hacks (planned internally owned project work)
• M&A platform integration projects (taking businesses we have built, integrating and enhancing their products)
• Tech debt/health (planned internal maintenance)

What is the estimated duration of the piece of work?

• Urgent things = less than a day
• Projects/growth hacks = several weeks of development, usually accompanied by A/B Testing
• Tech debt/health = a few days of development

The challenge for us, was switching categorisation of tasks and applying our new priority work while simultaneously freeing our Dev teams to work on project/growth hack work. We needed to manage work originating outside the department to create focus and quality. It’s essential that the Dev team is focused on big-ticket projects that improve the experience for our customers and clients, rather than implementing minor changes to the website.

We set those workflows in place with their own processes. Mainly centred on a single list with a sequential priority. We have pushed for priority calls to be made earlier, and helped educate our stakeholders a.k.a. those people generating internal work, to understand that Development is – unfortunately – not a bottomless pit of people and time. We limit the amount of work being pushed onto the team within these workflows, and we give stakeholders full control in deciding the priority of their own lists.

How did we tackle the inefficiencies of stakeholder work?

There will always be stakeholder work, and at Decision Tech we found that this could rapidly grow to such an extent that it prevented any other development work from taking place. So, the team made a conscious effort to be involved at the inception of ideas and improvements, applying a LEAN methodology to measure and learn from every piece of work. By working more closely with the problems identified at an earlier stage we could release ‘minimum viable products’ – or MVPs – which means to build and release the smallest viable component of a product, and then add additional elements to it subsequently, rather than waiting for the entire product to be built. This approach allows us to learn quickly, limit our spend, and maximise the ROI.

Employing new techniques

My boss recommended that I read a book called; ‘Notes To A Software Team Lead’ by Roy Osherove. It’s excellent if for no other reason than the two paragraphs below which talk about dealing with someone who’s trying to change the prioritisation of tasks. It’s an awesome technique, and has proven so effective that I find myself using it pretty much every week:

Learning how to say no by saying yes

One way to refuse stakeholder requests is by letting the requesting party realize for themselves that there are better ways to spend the team’s time. One of the best ways I know to accomplish that is by having the walled task board with Post-it notes with what’s currently in progress and what’s coming up, sorted by priority (most important tasks are closer to the top).

If your stakeholder wants feature X, bring them up to the wall and say: “Ok, which feature do you want to move down in order to build this?” Ask them to take down a feature from the in-progress column or the to-do column. This usually leads to an interesting conversation with the stakeholder about what each task means and how much time it was estimated for. By the end of the conversation, either the stakeholder realizes where the task fits in, or you will. Either way, what wins is the value generated for the company.

Defining URGENT

In any workplace, jobs are often submitted under the general heading of “it’s urgent”, but it’s crucial that there is agreement about what counts as a truly urgent piece of work. It has to be important enough that you would instantly roll people off of other work to help out.

To better understand what should fit into this category, I went round the business to discuss with every department what is truly urgent for them, and why. The context they were able to give me on this was invaluable, and I was able to share that with the wider Development team.

As a result of this discussion, we were able to settle on an agreed list of ‘Urgent Things’ which we sent to everyone in the business accompanied by a guide on what to do if one of these events happened.

Overall, we were slowly able to define what qualifies as an Urgent Thing and therefore how the dev team should deal with each job.

This approach of establishing distinct workflows with tailored processes remains key to managing our wide-ranging, and competing priorities. These changes have revolutionised the way we stream dev work through the business, our work efficiency, and how effectively we work with our stakeholders both within, and outside of, Decision Tech.

Vix Leyton