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

If you think you can never tell your boss no because you'll be fired, you're not going to have a good employment story.

Work _with_ your boss, not against them. You have more agency than you realize.

My stance is that you cannot pretend the power dynamic does not exist. Boss can fire worker, worker cannot fire boss. Consquences of getting fired range from irritating to life-threatening, depending on worker's resources. Consequences of having to fire someone... not such a problem. You ignore that reality at your peril.

If the boss wants workers who can say "no", the boss has to create an environment where people don't have to fear the consequences of doing so.

Power dynamics can't be ignored, but just because someone has the upper hand in that dynamic means you always have to be subservient and do everything they ask you to do. Always saying yes to a boss is probably a faster way to get fired than being a partner and pushing back when needed.

If you give it away for free, theyre not going to voluntarily pay you.

More likely, you finish up fighting the latest fire and someone will suddenly remember the thing that is now ‘very late and behind schedule’.

The gold standard for a military briefing is that it includes a high level overview of the global, regional and local situation before getting into specific orders and this was adopted because small unit doctrine depends on unit commanders having enough context to make informed independent actions in lieu of direct chains of command being available.

Everytime I've watched a ticket languish in any organisation, it's always because people don't feel a need to give context. They think they understand what they're asking for, it doesn't match reality and then the back and forth culminating in a bunch of calls and finally someone explaining the goal happens.

I agree for the need of context. Because only then can the operative understand why it is important what they are doing and in case of decisions to be made on the ground either decide or clarify with the org structure.

I know that unit commanders are being (ideally) briefed like you described. But how does this context trickle down to their people? Does the military have a means to ensure the passing down of relevant and qualitativ information?

Because that is what I personally see as a problem more often than not. The information is lost at the lower rungs of the ladder.

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.

Everything is a trade off. Most developers probably shouldn’t write their own database engine. But at the same time adding another dependency to handle padding a number with zeroes is overkill.

In practice after 2 decades doing this, I’m much more likely to run into an over reliance on libraries these days than the other way around.

Yarn's zero install and the like could probably have stopped that from ever being an issue. Many lodash/underscore/whatever utilities have that feature, and with dead code removal I don't know why people still use micro libraries.

There's of course malware concerns, but that's why you don't use things that aren't popular with a million eyes on them unless you want to check it yourself.

That’s certainly not what the JavaScript community as a whole does. If anything that’s closer to the way many other languages do it with large standard libraries.

> There's of course malware concerns, but that's why you don't use things that aren't popular with a million eyes on them unless you want to check it yourself.

Those popular libraries often have hundreds to thousands of dependencies and sub dependencies themselves, many of which almost certainly don’t have a million eyes on them.

“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?”

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

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.

> Sales wins because they can claim "Feature X" being sold and get their commission

That’s true even if the product is high quality from the get-go, isn’t it?

> 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

I‘ve seen contractors, big and small, fired for providing complain-worthy software, multiple times. Some (most?) customers have enough on their plate and just want working software. Take Apple as an example. Their software quality seems to have worsened considerably in the last decade, but I don’t feel this has made myself more inclined towards buying their products. Infact, I‘m frustrated and have considered switching to other tech more than once.

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

I agree, support staff actually needs bugs to occur or else they will be scaled down. What’s the business case for having a huge support team though, if shipping high quality software is an option?

> 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

Why not, instead of working on authority and under-pressure skills, let PMs grow as leaders insider their team who can inspire hard work when the rubber really needs to hit the road?

> Software Development wins because they can now work on the secondary features, fixes, "skunk works" tech debt, etc. since this is now more important.

As an engineer I‘ve found it more satisfying to deliver great code instead of having old hacks thrown back at me, maybe with added time pressure because there’s data loss involved.

I think the point was that claim can be staked at an earlier time if you shovel out some “mostly works for happy path” code than if you wait and ship high-quality code as the initial (but later) delivery.

> when you slam the happy paths out there for the customer as fast as you can…

z’) If we deliver 20% of the wrong feature, the customers are going to say it and we can reorient before we make the other 50%. #Agile

I’m not very satisfied either but the history of programming is riddled with us building overengineered solution to the wrong problem.

* Customers signed off on requirements; they may not have liked them, but they knew what was coming. And when.

* The dev org got to have the (IMO important) psychological journey of discovery, creation, testing, "oh shit", last minute fixing, last second covering up, and the final human release of... releasing. Big celebration. Yay, we did it. My last couple positions have been SAAS stuff where we "release" tiny little things multiple times a week; sometimes multiple times a day. Honestly, it's a grind. There's no "big win". It's akin to "death by 1000 cuts". You don't have the big wins or the big losses, but you get ground down by the never ending stream of small stuff. Writing an app is like putting yet another pat of snow on the snowball.

I get where agile is coming from, but a lot of times it fails to recognize that sometimes, people actually DO want to be surprised with big things, even if they're not 100% positive. And sometimes, customers DO want to have the vendor "Just deal with it and leave me alone - I can't be bothered multiple times a month (or week!) to look at your teeny little new thing. SHOW ME THE FEATURE WHEN IT'S DONE." They WANT that ability to gripe all at once in the end, and not be part of the "steering committee - what am I paying you for if I have to dictate everything?"

I'm being hyperbolic here of course, but I've seen versions of this play out numerous times.

One good example is Linear. The product improves day by day, but they also publish a regular (weekly) summary of the changes. And for me as a user it's a delight to read through them. https://linear.app/changelog

Calling it a cultural issue seems off. Perhaps in some cases it is. But if the process truly is a grind, then the only target left to celebrate might be a proxy metric that the devs don't relate to. (Congrats on staying within 0.5 sigma of our mean time to deliver this week, let's have a pizza.)

Even though you are shipping piece by piece, don't you still have a "big win" that those small pieces make up to be to celebrate? For example, my old team had to deliver MFA. This was broken up and was "released" continuously. We celebrated when the whole feature was "done".

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.

People who say, "No." are being hard to work with. People who engage honestly with the CTO who is trying to change priorities is someone who you actually want on your team, the only kicker here is that the conversation ends with, "Okay so what gets shelved for this new thing we've been talking about, or should we finish out what we're currently doing before jumping on this?"

There is a lot of advice out there that says, "Say no!" but you can't take it at face value; no reasonable person is suggesting you respond to a request from leadership with a single word answer. You need to have a higher EQ than that, but what you can do is find ways of explaining the cost of what they're asking in a way that is effectively no, without actually just saying one word and then refusing to elaborate.

What's good about that is that your superior may want to actually eat the costs because he may have information that he has not shared yet with you.

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.