This resource first appeared in issue #116 on 02 Apr 2022 and has tags Strategy: Prioritization, Working With A Research Community: Other
How To Do Less - Alex Turek
Four Steps to Organizational Change Without the Drama - Deiwin Sarjas
Turek walks through the steps of digging yourself and your team out of a hole via absolutely ruthless prioritization - picking exactly one priority and only advancing that goal. That means advancing it either directly through work on the priority, or through making work more effective by changing how and what work is being done.
The hardest part of doing this is the communications with others, and not letting yourself be sidetracked or buffeted by external requests to dillute your efforts. He helpfully gives useful lines to use, both for management and stakeholders:
This isn’t
MAIN_PRIORITY
, so we aren’t going to do it until at leastESTIMATED_DONE_DATE
. Right now our priority isMAIN_PRIORITY
because ofONE_SENTENCE_JUSTIFICATION
, and this is 100% our shipping focus. I agree this sounds like a really useful feature - once we finishMAIN_PRIORITY
, should we consider droppingSECOND_PRIORITY
and do it?
and to the team, after you’ve discussed the new approach with them:
This isn’t
MAIN_PRIORITY
, that we all said we’re going to work on. What if we don’t do this? What can we do without it? Is this a requirement or a nice to have? Will it speed upMAIN_PRIORITY
? Can we put this onto our (New Feature/Maintenance) Roadmap after our current priority finishes? I think we can finishMAIN_PRIORITY
without this.
Turek also closes out his article with, almost in passing, an observation I don’t see made often enough. Small teams are often doing “iterate” work, making small changes rapidly to get feedback, and/or “invest” work, where there’s a big push needed to get a single something done. Standing up a system or creating an initial MVP is “invest” work, as is paying off a tranche of technical debt. New features/services or bug fixes/service improvements are “iterate” work. Turek says that at any given moment a small team should be in one or the other - trying to do both simultaneously squanders effort and confuses communications.
Sarjas also emphasizes the importance of communications when making a change (echoing Lara Hogan’s “Don’t YOLO the Comms”). He recommends an outline and process - Situation, Task, Intent, Concerns, Calibrate, or STICC - to organize the communications, and a roll-out plan with the example of promoting a team member to be a manager. You want communication of a change to result in people saying “Makes sense” and not “Wait, What!?”. Being thoughtful in your communications, keeping that goal in focus, can reduce unnecessary drama around big changes. Some drama may happen, and may even be necessary! But you don’t want to contribute to it needlessly through poor communications. As covered way back in #34, good leaders reduce chaos, they don’t add to it.