How To Do Less

I'm currently reading through Johanna Rothman's "Manage Your Project Portfolio" and related literature and a bunch of this resonates:

* 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).

In my experience/opinion (disclaimer: small teams only) this single-item paradigm misses a lot of opportunities. I prefer the 60-30-10 approach (see https://minimal.app/603010) as it is more experimental/open while still capturing great focus.

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.

As a self-employed person, this is essential. I'm constantly using Things3 to take down notes on ideas for things I want to do, or could do. But there's only so much I can do in my waking hours. So when it comes time to "prioritize" and make my plan for the week, I throw everything that's not on fire in a secondary list called "brain vomit" that I simply never look at, while filtering out the important and urgent stuff to the main actual list of things I'm actually going to do.

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.

> unless you work at a 10 person company, the CTO has less context than you about reality “on the ground.”

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.

Here are my key takeaways:

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

My priority is always decustomization.

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.

Great article and thanks for sharing; great applications in one’s personal life too. The author is very focused on hows of managing expectations of the technology team, and would love to hear his/her thoughts on how to manage expectations with the business.

The prioritization tip reminded me of "Final Version" productivity system that I personally like. It's just one big-ass list of everything and you pick and do stuff at random (more or less). Yes, it sounds silly, but I found out that it works better than constantly re-ordering goals. :-)

http://markforster.squarespace.com/final-version-faqs/

This could be a guide of "How to quickly get on the wrong side of a CTO".

Seen it happen.

It sounds like this is just an exercise in, not learning, but being forced to say "No" (a lot) out of a need for mental survival...in a work culture where priorities are constantly shifted (and this is the key).

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".

But what about Engineer FAANG: Who will get promoted based on individual impact?

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?

Thanks for sharing. I like how you provide text snippets for potential responses, as communications & stakeholder mgt. is something junior people often struggle with (not taught much at uni).

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.

This is one of the best articles i can recall reading in a while. What a great piece.

The third how to say no copy/paste example is poor compared to the first two.

"So now, you’ve committed to a big, one-time effort of saying No to everybody. "

assuming you have the luxury to do that.

One interesting thing I learned from the book "essentialism" is that the word priority used not to have a plural. It described the single most important thing to do.