[HN Gopher] How to Do Less
___________________________________________________________________
How to Do Less
Author : ggoodale
Score : 188 points
Date : 2022-03-11 17:06 UTC (2 days ago)
(HTM) web link (alexturek.com)
(TXT) w3m dump (alexturek.com)
| jll29 wrote:
| 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.
| sdoering wrote:
| > 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.
| jimbob45 wrote:
| 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.
| afarrell wrote:
| By believing that the goals are already clear.
|
| By believing you don't need to repeat yourself about what the
| goals are.
| sokoloff wrote:
| 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.
| warlog wrote:
| Tell my manager (the CTO) that.
| Negitivefrags wrote:
| 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 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.
| Aeolun wrote:
| 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'.
| fartcannon wrote:
| 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.
| malfist wrote:
| 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.
| fartcannon wrote:
| 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.
| marssaxman wrote:
| 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.
| underwater wrote:
| 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.
| cushychicken wrote:
| This could be a guide of "How to quickly get on the wrong side of
| a CTO".
|
| Seen it happen.
| btrettel wrote:
| What should someone do differently to have a more realistic
| workload?
| michaelcampbell wrote:
| 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 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.
| manmal wrote:
| 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 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.
| sokoloff wrote:
| > 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...
| laurent92 wrote:
| z) Customers are gonna complain anyway and ask for more, so
| better make 80% of the feature and see what they focus on.
|
| 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.
| michaelcampbell wrote:
| 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 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.
| wereHamster wrote:
| 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
| cushychicken wrote:
| 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.
| underwater wrote:
| 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."
| jaqalopes wrote:
| 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.
| arthurofbabylon wrote:
| 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.
| eternityforest wrote:
| 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.
| sarchertech wrote:
| > 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.
| bghfm wrote:
| 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.
| 9wzYQbTYsAIc wrote:
| This is the authors take on that:
|
| "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?"
___________________________________________________________________
(page generated 2022-03-13 23:00 UTC)