[HN Gopher] Ego killed the empowered product team
___________________________________________________________________
Ego killed the empowered product team
Author : mooreds
Score : 63 points
Date : 2023-12-11 16:01 UTC (6 hours ago)
(HTM) web link (jeffgothelf.com)
(TXT) w3m dump (jeffgothelf.com)
| najork wrote:
| I agree with the author's sentiment that product teams fail
| because of a lack of trust, but don't think it's necessarily ego-
| driven.
|
| It's challenging to build a company with a high-trust culture.
| While many companies say it's one of their values, I'd bet it
| only holds true for a small minority of them in practice,
| especially when things aren't going according to plan.
|
| When an organization is failing to execute against its goals,
| regardless of the root cause, the natural tendency is to
| introduce more process and exert more top-down control.
| Ironically, this drives away the most capable, creative problem
| solvers, who'll look elsewhere for fulfillment.
| gtirloni wrote:
| _> especially when things aren't going according to plan._
|
| Exactly my experience. The first misstep and it reverts back to
| top-down micromanagement and the actual product roadmap is the
| last priority... then it's downhill from there.
| codemac wrote:
| > [top down control] drives away the most capable, creative
| problem solvers [..]
|
| Eh, I think it's the lack of execution that drives them away,
| in fact if you're not executing many times it's because they're
| not even there.
| LargeTomato wrote:
| Interesting article but in my company the shifting priorities
| aren't ego driven, it's driven by the rapidly changing technical
| requirements of the company. Maybe at Google it was ego but at
| the startup I work at it's just pivoting to capture market share.
|
| A lot of my peers have trouble with this constant shift and I
| think that's ego. They are wrapped up in their own work and are
| ignorant of the company's priorities.
| janejeon wrote:
| I mean also just adapting to rapidly changing environment and
| requirement _is_ hard. It 's a skill, just like anything else.
| Best not assign reason to why others have trouble doing a thing
| (not just this) based on our own experiences (referring to
| "that's ego" bit).
| CharlieDigital wrote:
| > A lot of my peers have trouble with this constant shift and I
| think that's ego. They are wrapped up in their own work and are
| ignorant of the company's priorities.
|
| I'd say that it's not necessarily ego but perhaps one part
| coherency and one part skepticism. And it can often be
| exacerbated by lack of communication of those priorities and
| why they are shifting.
|
| If the previous strategy was validated, then why is the
| strategy shifting? Is the product design process fundamentally
| broken in the org? "If I dump my in progress work now, how long
| before my next effort gets short circuited?" Rapidly shifting
| priorities without clear reasoning raises questions on whether
| the leadership team knows what they are doing.
|
| In both cases, my own experience is that open dialog and
| communication from the leadership team on how the decision was
| made and sharing the data points can reduce the friction. From
| the technical leadership, communicating the right mindset also
| helps -- especially with more senior resources.
| happymellon wrote:
| > Rapidly shifting priorities without clear reasoning raises
| questions on whether the leadership team knows what they are
| doing.
|
| It also leads to wasted work. What was the point of of
| working hard when it gets thrown away?
|
| If alternative views were expressed earlier then perhaps the
| work could have been made generic to handle both use cases in
| case of a pivot.
| pavel_lishin wrote:
| Not just wasted work, but a general understanding that
| there's no _point_ to working hard, when the work gets
| thrown away _every time_.
| happymellon wrote:
| That's a good rephrasing.
| datadrivenangel wrote:
| If priorities will change again before you get to ship the
| new project, you're better off not doing anything and getting
| ready for the next thing.
| pavel_lishin wrote:
| Unless, of course, that thing will _also_ be deprioritized,
| in which case you 're better off not doing anything at all.
| bjornsing wrote:
| An early stage startup is an empowered product team, I would say.
| I would never found a company, take on the CEO role, and then
| hand off responsibility for customer value and business viability
| to a newly hired "empowered product manager". That makes no sense
| to me.
|
| For a later stage company I fully agree with this model though. I
| tend to think of these "empowered product teams" as sort of
| internal startups, each with a "mini-CEO" and a "mini-CTO".
| karaterobot wrote:
| In my experience, it's fear over ego. At the last company I
| worked for, the CEO discovered Marty Cagan and immediately
| switched the entire company over to following his
| recommendations. I was on a product team, and we came up with our
| own strategy to meet our OKRs. The CEO didn't like our approach,
| and decided that, actually, he was going to both set the
| objectives, and results, and tell us how to achieve them. We were
| basically a feature team.
|
| But it wasn't ego, it was fear. The company was running out of
| runway, we just hadnt been told yet. The CEO adopted the product
| team strategy as a Hail Mary, out of sheer panic, and he
| sabotaged it for the exact same reason: he was terrified of not
| trying it, and then terrified of it not working.
|
| Not only because of this anecdote, but because of several other
| important ones, I view leadership as being generally fear-driven
| in their decision making. Ducklike, they appear calm and even
| confident on the surface, while desperately thrashing and failing
| below the surface. Or, like someone falling down a hill and
| reaching out for anything to hold on to.
| AnimalMuppet wrote:
| "We're running out of runway; let's change our development
| approach"? Talk about counterproductive...
| WJW wrote:
| Fear/panic is not known for inducing rational decisions.
| foobarian wrote:
| Well look at all the unicorns that pivoted their way into
| success. Clearly you're supposed to pivot! /s
| kabouseng wrote:
| Not to pick a fight, but there is this misconception from
| salaried employees that the running of a company is mostly calm
| and relaxed, and there are certainty where next months salary
| is going to come from. Or at least that good management
| achieves this.
|
| But in reality, leadership of a company is constant chaos, the
| image of the dog with room on fire saying everything is fine
| comes to mind.
|
| Who knows what the right decisions is, everybody has feet of
| clay.
| ska wrote:
| There is some truth in this. In the startup world, we often
| tend to avoid this framing because it isn't positive - but
| every startup begins in the process of failing (running out
| of resources and ceasing to be a going concern, one way or
| another).
|
| The term "runway" is often interpreted to mean: "We need to
| get this plane going fast enough to lift off before the end
| of the road". Reality is more complex, because there isn't a
| plane yet. You have to design and build that as you go, and
| if you get it wrong, you crash.
|
| Management is in this position: without action, the company
| will die. With the wrong actions, the company will die. Many
| decisions close doors, and it's not exactly clear from the
| start what sequence of doors will lead to the company not
| dying.
|
| If you involve the team too much in the sausage-making
| aspects of this, they will invariably become distracted, lose
| focus, and the company will die. If you leave them too much
| in the dark, they will lose trust, and the company will die.
|
| It's not easy, and all of this leads to the duck nature: calm
| up top, under the water feet are paddling like crazy.
| kabouseng wrote:
| "If you involve the team too much in the sausage-making
| aspects of this, they will invariably become distracted,
| lose focus, and the company will die. If you leave them too
| much in the dark, they will lose trust, and the company
| will die."
|
| Incredible truth in this statement!
| happytiger wrote:
| When I was much younger I spent two years trying to run
| an open company only to be "openly told" that several of
| my employees didn't want to know and that it was too
| stressful for them to go through all of the tribulations.
|
| Some people honestly don't want to know what's happening.
| They just want to do their jobs and get paid. And I came
| to the conclusion that it's perfectly acceptable.
|
| Still love the open company concept. But if you love and
| respect the people you work with you have to think pretty
| deeply about it and whether it's _actually_ of service to
| your employees, investors and team.
| anonacct37 wrote:
| It's the old "you are not the customer" but applied to
| management. I really really want to be told what the high
| level goals are and come up with a solution. So of course
| when I started managing people I worked really hard to
| communicate those high level goals and let them decide
| the how. They told me no thanks please just let me know
| what tickets to work on.
|
| People are different and motivated by different things
| and that's ok.
|
| The dictator who listens really seems to be what the
| majority prefer because they don't actually want to be
| accountable for those decisions they just want a seat at
| the table.
| salty_biscuits wrote:
| I was also incredibly optimistic about this approach in
| the past but life experience has shifted me away from it.
| I personally can't understand people not wanting to know.
| It is weird dynamic. I changed jobs a few years ago and
| went from management to an IC role for a while. It was
| nice to focus on technical problems but it also did my
| head in. I felt incredibly neurotic knowing that stuff
| was going on but I was in my little bubble of productive
| calm.
| Jare wrote:
| What a fantastic and succinct description. Developing
| something new, whether you're a startup or an established
| company, feels like that. In a large company, dying may
| mean something less dramatic, but it may still lead to a
| team or division sacked.
| brightball wrote:
| Yep. This is why getting people talking about priorities and
| focus is job one on the product side of things. The
| conversation will look different depending on size, but it's
| still there.
| golergka wrote:
| Starting and running a company is very scary, so it's not
| surprising that many people who are not cut out for the
| emotional work involved end up like this.
|
| > The company was running out of runway, we just hadnt been
| told yet.
|
| At least your CEO didn't dump all the bad news and resulting
| anxiety directly on the team. Good job, it's exactly what he's
| paid for.
| karaterobot wrote:
| Well, instead he waited until we were almost out of money,
| then laid off a very large percentage of the company one
| morning.
| golergka wrote:
| That sounds like the right thing to do. If you have to do
| layoffs, it's better to do them all at once and then tell
| everyone how much runway you have left. Doing several
| smaller once, making everybody unsure of the future and
| afraid for their jobs is much worse.
| al_borland wrote:
| I've worked for and with many people who's stress response is
| to try and control everything, especially the flow of
| information (read as hoarding information and giving people the
| bare minimum, and often less than that).
|
| It inevitably leads to more stress, not just for them, but for
| the whole organization. I've never seen it play out well long
| term and wish I had a good way to call it out and correct it.
| At least I can more clearly see the pattern now that I've run
| into it a few times.
| hangonhn wrote:
| > he was terrified of not trying it, and then terrified of it
| not working
|
| What a great piece of insight and observation. That really sums
| up so many situations where we seemingly shoot ourselves in the
| foot. It's the dilemma of being afraid of not going down a path
| but also fearing what we may find at the end of that path.
| nostrademons wrote:
| This is very true, and is also why we have things like
| corporations, founder cash-outs, outlandish executive
| compensation packages, finance, golden parachutes, etc. The
| whole idea is to make failure _somebody else 's problem_, so
| that you're set for life regardless of what you do. This takes
| fear out of the equation, so that (supposedly at least) you can
| make rational decisions and it becomes a simple dollar-
| maximization exercise.
|
| It'd be an interesting experiment to see if we could take
| _executives_ out of the decision-making loop and just have AI
| (or aggregated intelligence) make the decisions, since
| computers are generally better at it than humans and certainly
| don 't have pesky emotions _or_ egos to get in the way.
| Aperocky wrote:
| > The short summary of Cagan's definitions is that feature teams
| are told what to do and are measured on delivering output.
| They're incentivized to ship products, have low levels of
| collaboration and almost no autonomy. Product teams, on the other
| hand, are empowered to solve problems.
|
| Seems like author's product team has quite an ego of itself,
| having feature team only ship products and not solve or point out
| problems is a recipe for tech debt and disaster.
| apineda wrote:
| The feature team is as a comparison, not in addition to the
| product team.
| DyslexicAtheist wrote:
| all the digital and agile transformations I've seen had 1 thing
| in common: they missed to get buy in from middle management.
| Instead there are agile coaches preaching[1] to the choir while
| the rest of the org is betting against their success.
|
| [1] Art imitating life in that regard:
| https://www.youtube.com/watch?v=bB340S0tGf8
| sumtechguy wrote:
| You can also have the whole org go all in on agile. I am not
| sure which way is worse now. But we sure have tons of forms to
| make sure our rituals are properly done.
| j4yav wrote:
| Middle management and agile almost seems like a contradiction
| in terms in the first place. Although I guess that's what SAFe
| is for.
| orochimaaru wrote:
| I would also add buy in from rank and file engineering team
| members. Also, not being sensitive to concerns of those teams.
| If you make life hard for folks implementing, they will find
| loopholes that will eventually crater your plan.
| al_borland wrote:
| I've also seen where upper management dictates those below them
| to use it, but they want to be exempt from all of it, forcing
| teams to do double (or worse) work to handle the paperwork
| around agile, while also preparing bespoke reports to feed up
| the chain in each leader's preferred format.
| j4yav wrote:
| I think some people are talking about startups here and some
| people are talking about enterprises and it's confusing the issue
| a bit. Apart from that, I think there's an element of "skin in
| the game" that benefits startups - there's a natural tendency for
| people at companies big or small to lose track of the big picture
| and start working on pet projects. At a startup at least you have
| a chance of things being aligned, everyone has equity and things
| are (relatively) simple enough that everyone can sort of tell
| what needs to be done. But at a big enterprise company, an entire
| department can spend millions on some pet project before anyone
| even realizes what's happening, and things are so complex that
| you can make a reasonable case for anything being a valid bet.
| And to the people in the department, it will appear that some
| egocentric executive showed up out of nowhere and disrupted their
| idea.
|
| In the end, though, I don't think it's really mostly executive
| ego being inflicted on a group of people, although I am sure that
| sometimes happens. And I especially don't believe that
| demonstrating small incremental value will protect you from
| anything.
|
| I think if you really want to be on an empowered product team,
| for real, work at startups. But that comes with its own
| downsides.
___________________________________________________________________
(page generated 2023-12-11 23:01 UTC)