* Finishing work is more important than starting it
* Teams working together on a single priority ("swarming") seem to be more successful than teams where each person is doing 1-2 things on their own
A few subtle points in this article that made me think:
* Keeping existing features working as well as customers expect is a great zeroth priority but it can be hard to know what customers actually expect. Absolutely the worst is when you carefully maintain a very reliable, feature-rich thing that no one particularly wants or uses. In an org without a dedicated PM, I'm never quite sure how to account for time spent on the product-management work of "listen to my customers about what they want from my service".
* The article talks about engineers and stakeholders caring about "project X" and "feature Y". A bunch of literature suggests that anyone who is thinking this way is probably a bit lost -- they have lost sight of the business outcome that the team's work is supposed to be getting (more sales, quantifiably happier customers, fewer pager alerts interrupting engineers, whatever). If you can tie particular features/projects to outcomes maybe you can make it easier to explain why you've prioritized other work first (it makes bigger outcomes sooner).
It's an interesting one, same as e.g. pair programming; people (and I'm speaking for myself but I'm sure others will agree) prefer to work alone, because software engineering is difficult, brainy work, whereas swarming and pair programming are social activities. If you're like me - introverted, probably on the spectrum, etc - it's something that is well out of your comfort zone.
I wonder if there is a reference supporting that statement. I believe it, but it would be nice to have a reference.
To back that up, I’d like to acknowledge that almost all significant contributions I’ve witnessed weren’t the top priority item (instead, they’re some weird experiment). I am generally suspicious of the human ability to form a hierarchy of needs/opportunities, so I try to favor qualities like experimentalism, curiosity.
Of course, this is all circumstantial. I’m sure some teams have hard deliverables where there is little value in exploring or doing things with no known measurable impact.
Sometimes the business priorities and your chain of command priorities don’t mesh. That’s a good reason to be able to focus on multiple things.
This probably sounds insane but it's working for me. I think part of the reason is that I often don't have the mental bandwidth (or discipline) to recognize at the moment of task creation whether something is a good idea or not. I'm simply moving too fast, multitasking too much, to make those calls. So I batch every new idea into the inbox and review it later. And even if I discover good ideas in there later, if they aren't essential to my work or life they go in the brain vomit folder. So I get all the satisfaction of stream of consciousness "ubiquitous capture" (a la GTD) without the emotional burden of having to actually do all that non-critical stuff.
Over the past few years I've used a similar convention, first called Journal, then Stream, then finally Archive. Everything goes in there, added to the bottom of the file: snippets, ideas, links, both personal and work-related stuff. I have a shell alias to append one-liners from the terminal, which I use throughout the day (and night). I review it regularly to move the important parts, especially plans and actions:
- Archive
- Do
- Doing
- Done
From my experience people "on the ground" often miss out on the strategic long term goals.
Neither my take on it, nor the author's approach will be the silver bullet. Both are too extreme. And might appeal to different audiences on paper but not survive reality imho.
If your CTO lacks context about your reality on the ground, then tell them the context. How else can they readjust what the priorities are? If you tell them and they refuse to adjust your priority then it's probably you that lacks context about what the goals actually are.
If you still disagree with that, then it's because you don't trust your CTO. If you don't trust your CTO then you should leave and find a better one.
If you have worked in a few places and have never trusted the CTO anywhere you have worked, perhaps you need to sit down and take a hard look at your yourself rather than others.
More likely, you finish up fighting the latest fire and someone will suddenly remember the thing that is now ‘very late and behind schedule’.
By believing you don’t need to repeat yourself about what the goals are.
This has been my experience too, having been an engineer for the past 3 decades and to this day.
And even if the CTO does a great job of communicating strategy, we on the ground tend to get lost in the weeds just because of the nature of our work.
I think outright saying “no” because we don’t think it’s hight priority is a dangerous move that makes the team a target for future performance reviews.
We should, instead, find a common ground and sell our priorities rather than impose them.
1. Say no a lot, up front
2. As early as you hear anybody else’s plans that involve your team doing something new, interject with a clear No
3. Everything your team already owns (that actually matters to your customers) needs to approach 0 maintenance costs
4. Ask your team what the biggest maintenance costs are
5. Write a Maintenance Roadmap to reduce your team’s costs
6. List all the new things you’re currently doing or planning to do, and put them in the New Features roadmap doc
7. Dig into your data, figure out where the drag on your team comes from, and drive it down
8. Drop everything except the top item on the list
Anything that makes me think of the words "Bespoke" or "Artisinal" or worst of all "A perfect fit to the project needs" is where I look first for problems. I also look at anything that provides multiple ways to do the same thing.
The JS community understands it better than anyone. At the application level, any program, be it amateur or professional, is almost always readable and maintainable. Because there's no interesting algorithms, no abstractions you haven't already seen in a design patterns list, and just generally nothing special about the code at all. They use libraries for everything.
When you stop trying to write interesting and beautiful code, and stop trying to innovate at any level below the application, stuff gets a lot easier.
Of course some projects really do have interesting technical challenges... but so many projects don't.
Oh man. We have worked on some very different JS applications.
“Here are some concrete ways to tell management or stakeholders no.
This isn’t MAIN_PRIORITY, so we aren’t going to do it until at least ESTIMATED_DONE_DATE.
Right now our priority is MAIN_PRIORITY because of ONE_SENTENCE_JUSTIFICATION, and this is 100% our shipping focus.
I agree this sounds like a really useful feature - once we finish MAIN_PRIORITY, should we consider dropping SECOND_PRIORITY and do it?”
Seen it happen.
A project manager inadvertently laid this out for me when I was new in my career; he didn't mean to put it like this, but this is what came out. (Note that I'm a software developer, and at the time the software I wrote was not "shelfware", but rather installed into big enterprises' data centers. Pre cloud)
NO ONE wants software done right the first time. Because, when you slam the happy paths out there for the customer as fast as you can:
* Sales wins because they can claim "Feature X" being sold and get their commission
* The customer wins because they get to complain about x or y being bad, incomplete, or whatever they want to whinge about and feel like they're part of the solution
* Customer Support/Sales Engineering/etc wins because they get to appear to be "responsive" to the customer by quickly reorganizing ongoing work to take care of the "urgent need"
* The Project Manager wins (2x!) because they can now a) do the same "response" dance for the C-levels, and b) berate the software development staff and show their authority and working under pressure skills
* Software Development wins because they can now work on the secondary features, fixes, "skunk works" tech debt, etc. since this is now more important.
I just know enough from my brief stint in management that always saying "No" is a great way to get people to say you're "difficult to work with" or "aren't a team player".
That was a hard lesson to learn: "team player" means different things at different org levels.
Instead, foster change where you can say "Yes, and" or "Yes, but", where there is a common understanding that sure we can work on it, eventually, as it's going into the backlog, that will need to be prioritised, or it goes at the bottom of the queue as any new thing should - as what is already in the queue, should already be prioritised.
Obviously what is already in the stack can be shifted around as the business needs may necessitate the change in priority...but popping shit at the top of the stack constantly...that's not where you need to learn to say "No"...that's where you need to learn to say "Bye".
I've found convincing everyone else an engineering team needs to focus doesn't take too long. Managers are not shocked or confused to hear that a team drowning needs to do less.
The individual engineers though, those can be the hardest. How does management split credit for group effort? Will the leader of the project get promoted, even though their contribution may in total be less than others on the project? What happens to my ongoing work, will I get skewered in "calibrations" when other teams talk about how I dropped everything to work on something to important to them?
Delivering one feature at a time may neither synch up with org roadmaps or go down well with mgt. expectations, but that depends where you work; I can see your approach might work in a smaller organization with overloaded team, where it may be a tool to create laser focus.
The third how to say no copy/paste example is poor compared to the first two.
assuming you have the luxury to do that.