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

21–30 of 74 posts

Re: How To Do Less

#21

Post by fartcannon »

malfist wrote: post #18
fartcannon wrote: post #11

Earlier quoted context omitted.

I think its the power dynamic. Not everyone can just leave jobs. If people don't trust their CTOs, bosses, CEOs, that is mostly the bosses fault and on them to fix. Requiring the person who can be at-will fired to also manage upwards is pretty much a fail state.

Not managing upwards is how you wind up in a fail state. Business, teamwork and employment isn't a zero sum game. Everyone is working together to achieve something. Helping your boss understand why something shouldn't be done/prioritized/cancelled is paramount to being efficient. 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.

Its about how _much_ information you give your boss. And when. When the power balance is even, the flow of information can be, too. But given the relationship of employment, it can never be. So its still on the employers/the powerful.

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

Re: How To Do Less

#22

Post by afarrell »

jimbob45 wrote: post #12
sdoering wrote: post #4

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

Why would you ever give a developer a task without ensuring they understand your strategic long-term goals? That sounds like a sure-fire way to end up with a product that doesn’t match your vision.

By believing that the goals are already clear.

By believing you don’t need to repeat yourself about what the goals are.

Re: How To Do Less

#23

Post by marssaxman »

malfist wrote: post #18
fartcannon wrote: post #11

Earlier quoted context omitted.

I think its the power dynamic. Not everyone can just leave jobs. If people don't trust their CTOs, bosses, CEOs, that is mostly the bosses fault and on them to fix. Requiring the person who can be at-will fired to also manage upwards is pretty much a fail state.

Not managing upwards is how you wind up in a fail state. Business, teamwork and employment isn't a zero sum game. Everyone is working together to achieve something. Helping your boss understand why something shouldn't be done/prioritized/cancelled is paramount to being efficient. 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.

It's the boss' responsibility to make it safe to say "no". You can't expect the more vulnerable party in the relationship to take the initial risk when there is a power imbalance.

Re: How To Do Less

#24

Post by sarchertech »

eternityforest wrote: post #19

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…

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

Oh man. We have worked on some very different JS applications.

Re: How To Do Less

#25

Post by jll29 »

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.

Re: How To Do Less

#26

Post by sokoloff »

jimbob45 wrote: post #12
sdoering wrote: post #4

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

Why would you ever give a developer a task without ensuring they understand your strategic long-term goals? That sounds like a sure-fire way to end up with a product that doesn’t match your vision.

There’s plenty of work (possibly a majority of it) in the industry that can be of the form “take a ticket, do the ticket, close the ticket”. Someone in the cascade has to understand the strategy and product vision to ensure you get a good overall outcome, but it doesn’t have to be the 22 year old SWE-1.

Re: How To Do Less

#27

Post by sokoloff »

manmal wrote: post #20
michaelcampbell wrote: post #8

Earlier quoted context omitted.

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…

I don’t mean to attack by going through these points, but would like to share a different perspective. > 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 s…

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

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…

Re: How To Do Less

#28

Post by underwater »

sdoering wrote: post #4

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

Explaining and communicating the strategic goals is the job of the CTO. They're adults, they can deal with being told "no". And changing priorities due to strategic shifts shouldn't be happening frequently.

Re: How To Do Less

#29

Post by underwater »

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.

Being a team player at every company is different too. That makes it hard to give general advice. But I think that "learn to prioritise, communicate priorities and default to no" is most useful advice than "don't say no to your CTO."

Re: How To Do Less

#30

Post by Aeolun »

Negitivefrags wrote: post #7
sdoering wrote: post #4

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

This is the result of the "Us vs Them" mentality that so many developers have these days and boils down to a lack of trust. 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…

There’s very few situations in which dropping a feature that was previously ‘highest priority’ midway through makes sense.

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

Post reply on HN