How not to overwhelm your team with meaningless work.

Oh, the old tactical work versus strategic work dilemma. How much do you want to impact your short-term value in favour of the long-term?

Your organisation should set this at the top level. Your mission statement could answer most questions in theory – if it's good enough.

"MAKE ALL THE MONEY YAAHHH"

is not a good mission statement.

At a high level, you should know what is essential to your organisation. The strategy will, in turn, bubble down (like Guinness) to your goals and should explain the thinking behind some decisions.

In a more sales-led company, with the above mission statement, the goals may distil down to increasing the conversion rate on your main website. Other plans may reduce legacy tools and assets so people can focus on more things that directly influence the mission.

Legacy tools are what I'm going to home in on.

In general, software teams like to work on Greenfield applications. They get to use new technologies, and creating something from scratch is exciting. You can change the world with new tech. You cannot change the world by writing a tool which allows users to bulk import records into an ageing application.

End-of-life software is more complicated and far less common. Stuff is tightly coupled everywhere. There are often monolith applications central to an entire ecosystem of peripheral systems.

These slowly need to be unpicked and replaced one system at a time to not completely take down the underpinnings of an entire company.

You can be working on these systems, trying to ensure that they are still stable, bugs are fixed, upgrades and patches are done etc. But, there are still people using these systems day in and day out. Good users will want to make changes. Good user teams will look at updating processes and trying to streamline their work. Even though the systems shouldn't evolve, the departments using them will want them to. (well, they should want to, certainly not always the case)

To summarise the very long intro, you've got an old system that needs to be deleted, but people still want to update it. How do you say no?

Some of these techniques can, of course, be used for applications that are not only end-of-end life. They're directly transferable. It's just that your reason for saying no will be different.

Artificial Constraints

The first way to say no is to add artificial constraints. One of these is reducing the team size or increasing the number of applications they have to support. A group of people can only do so much work, so it will naturally be throttled as the team won't be able to take on too much extra work. With an increasing amount of systems, the cognitive load will be high. The team will be more than happy to reduce this; to make their lives much more manageable.

This approach is kind of summed (ish) up by Conway's Law, which I've touched on here:

Some caution, though, if you work for a company that pays no attention to a team's capacity and demands weird non-strategic enhancements by tomorrow. Then, your team will burn out and – quite rightly – leave.

Throttle the work

One of the jobs of a Product Owner is to throttle the work for a team. So it could fall on them mostly to do the nay-saying.

Communication is vital; not every user will know the overall strategy. They may have just joined the company or felt particularly productive one day. Change is a good thing.

In this instance, a gentle reminder of why you're saying no and outlining the strategy should be enough to dissuade the casual requester of work.

The strategy drum is one that you'll find you'll keep banging repeatedly. "This system is set to be decommissioned.."

Impossible Requests

Sometimes, it's impossible to do the requested in the required time. You'll get calls to reconfigure your roadmap, drop what you're doing and get something done.

If a stakeholder wants to do x in a month, but it's a year's work for the team. They have no choice but to look at other options and solutions. Being transparent with the work required and why it takes so long can help here. Don't be afraid to get slightly technical if needed. Teams often work on complicated systems, and people don't always understand why everything isn't just the click of a button.

This is the Way

The most successful way of saying no to things is to try and understand what the user is trying to achieve. Quite often, you'll be presented with a solution, but when you truly understand the problem in their shoes, you'll be able to help and come up with an alternative solution.

Often, these solutions can be quicker to implement and may not even require development effort. Or your team may not be the right team to deliver the solution. It's okay to get other people involved as needed.

There is a warning here: you shouldn't become slopey-shouldered and defer the work to others, coming up with technically inelegant weird solutions that you can palm off onto other people.

The goal here is to be as helpful as possible and come up with the right solution that has the nice side effect of reducing the toil on your team.

See The Trick for some examples of how you can do this.

The oxymoron here is that you can work very hard trying to avoid doing work.

Other projects

Keep your ear to the ground and know what is happening in your organisation. Know which projects are happening and when. See how they impact your software estate.

These projects may solve a stakeholder's problem or make their lives considerably more straightforward. Just pointing out that life will be better after some time will be enough.

Or, it may be that after other projects are completed, their requirement would be more suited to these projects and far quicker to implement.

Reducing Scope

The tried and tested method is to reduce the scope of the work required. Maybe, a simple report can solve the problem instead of software development. Does that feature request solve a need and add value? Or perhaps it's nice to have. It would be best if you could tell the difference between what is critical and what is on someone's wish list. Again, you can only really do this by fully understanding the problem being solved.

I've seen the MoSCoW prioritisation used for quite a few projects. Typically most items are listed as Must Have, and the remaining Should Have's were non-negotiable. Some of these projects should never have started in the first place ;)

The Dark Side

Not quite as honourable is to ask too many questions. Send your requester to a few IT Surgeries, and you may find that the requirement fritters away.

Asking too many questions isn't a bad thing. It helps to understand the requirements truly, and more importantly, it helps the requester to consolidate their thoughts.

If someone can't be bothered to go through the work to flesh out the detail of what they need, then clearly, the request isn't too important to them.

When the team doesn't have enough information to look at the work properly, things should be a non-starter.

Here, you can see that I'm straying away from being an empowered Agile team and more toward a service-style team. Bleerrgghh.

Neo, you know that road

If you've been on a project or team long enough, you'll garner an understanding of what works and, more importantly, what doesn't. New stakeholders may bring up tired old past requests that didn't work.

Having some experience of what has and hasn't worked in the past can undoubtedly aid in saying no. You may be able to get straight to the complex problem that caused everything to grind to a halt. You may be able to shape the requirement in a better way to reduce toil on the team.

Or, more likely, you'll have a good conversation with the stakeholder about why things haven't worked previously. They'll gain more insight into your realm, which could shape their thoughts for future work.

Escalation

You've said no lots, so people will decide to escalate to their line managers in the hope that it will bubble up the organisation and back down again so that you get grief from your boss.

Negating the toxicity of operating like this, escalations aren't always a bad thing. It can help remind the more senior stakeholders of what their strategy is in the first place.

Causing people some pain – not too much, hopefully ;) - will again enforce why there is a need to change and the strategy chosen is the correct one. People will be annoyed, but the trick is to have them upset with the situation, not you or your team.

To Wrap Up

As a Product Owner or team, you'll constantly make priority calls.

Some requirements, such as legal or security patches, must be met, even if the system is on its last legs.

Remember that these tactics are bred explicitly from the need to decommission software. If you do this to every feature that comes your way in a greenfield application, you won't last very long.

But, there are productivity gains from saying no to work and only focusing on what is truly important.

It's far more challenging to say no, rather than just getting on and doing the work.

Finally, I'll leave you with an exchange that I had once

"I hate to create work for you, but we might have lit a little spark under something here."

"That's fine; happy to fight the fire."

Thank you for reading this article! Please leave a comment below if you have any questions or feedback.

If you enjoyed this article then please consider buying me a coffee:

Chris Sheldon is a Project Manager for DataArt Ltd. DataArt are a global software engineering firm that takes a uniquely human approach to solving problems.

In his career Chris Sheldon has been a Software Developer, Scrum Master, Development Manager and more. He’s decided that people are harder than process, so this is where his attention is now targeted!

Chris graduated in the UK from Reading University with a degree in Electronic Engineering and Cybernetics.

A bit of an Agile enthusiast, productivity nerd and Wantrepreneur Chris really needs to decide what he wants to do in life and focus.

You can connect with him on LinkedIn, Twitter, Facebook, or by visiting his website, ITsChrisSheldon