Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How To Do Less

alexturek.com

Post reply on HN
Print view View original

41–50 of 74 posts

Re: How To Do Less

#41

Post by mherdeg »

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

Re: How To Do Less

#42

Post by Spooky23 »

arthurofbabylon wrote: post #17

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…

It depends on how well the organization understands priorities, whether it does so consistently and how it is organized.

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.

Re: How To Do Less

#43

Post by gmfawcett »

wereHamster wrote: post #15
michaelcampbell wrote: post #13

Earlier quoted context omitted.

My background (and experience) might be different than many here, but I've worked in dev orgs that specifically did the every-6-months big-bang release to a customer, with the BigDesignUpFront, waterfall, and all that. There were some wins here: * 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 jou…

Not celebrating is a cultural issue. Even if you ship a thousand new things a week, you can still take time to celebrate those. It's your (or your team's) choice not to. 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

I don't think a client-facing changelog tells us much at all about how the dev-team celebrates.

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

Re: How To Do Less

#44

Post by jrochkind1 »

lioeters wrote: post #36
jaqalopes wrote: post #16

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 stu…

That's interesting to hear about the inbox for quickly capturing thoughts, including brain vomit. 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…

That reminds me of a "kanban board" with: Backlog, Ready, In Progress, Complete.

Re: How To Do Less

#45

Post by jrochkind1 »

michaelcampbell wrote: post #8
btrettel wrote: post #6

Earlier quoted context omitted.

What should someone do differently to have a more realistic workload?

If history is any guide, commit to X, deliver X/5, then start Y. There's always time to fix stuff, never time to do it right. 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 center…

How depressing. This would seem to suggest that this is not a good industry if you like producing quality work, but is a good industry if you prioritize being able to blame other people for something over getting it right.

Re: How To Do Less

#46

Post by nevir »

mherdeg wrote: post #41

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 wo…

It's also worth noting that another way to reduce the cost to maintain your existing functionality (priority 0) is to actively _remove_ rarely-used or less valuable functionality

Re: How To Do Less

#48

Post by CraigJPerry »

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.

Re: How To Do Less

#49

Post by redisman »

cushychicken wrote: post #9
btrettel wrote: post #6

Earlier quoted context omitted.

What should someone do differently to have a more realistic workload?

I'm not sure. The business unit is always demanding more. I don't have a solution for that. 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.

Every IC and manager needs to just learn to say: “yes we can do that, the sprint/quarter/whatever is already planned full, what would you like to remove to fit the new priority in?”

Re: How To Do Less

#50

Post by TameAntelope »

cushychicken wrote: post #9
btrettel wrote: post #6

Earlier quoted context omitted.

What should someone do differently to have a more realistic workload?

I'm not sure. The business unit is always demanding more. I don't have a solution for that. 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.

You aren't saying "No", you're saying, "What drops?"

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.

Post reply on HN