Just Say No
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.."
?????You can read the rest of the article on?Just Say No.
This link????is a???Friend Link??.?So, you?don’t need a?Medium Premium Membership????to read the article.
More From the Author
and even?more...
Love this... ?? however, is this not a very Germanic and direct approach???. Having lived in Britain for 22 years I would say instead: what assumptions have been made? Do we have a full set of requirements? Are there any open questions? Start any decisions with as few assumptions as possible and make sure all questions have been answered before commencing with 'wasteful' activities? Ultimately it boils often down to the same result but is just a bit more of a fun British way to accomplish excellence even though the principle obviously was most developed by Plato in Greece who never said no directly, but instead always replied with a question (?).