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

Thrashing

exple.tive.org

Post reply on HN
Print view View original

11–20 of 21 posts

Re: Thrashing

#11

Post by jmaker »

mrkeen wrote: post #10

Managers only have one phrase in their vocabulary: "Get this one feature out as quickly as possible." Everything else is just making devs 'heard' (so they can get back to feature). There have been a few variations over the years: "Just focus on the happy path" and "Build the feature now, and we'll work on stabilisation later". This week I heard twice: "The sooner we get the feature out to the customers, the sooner we…

But the manager gets to report a new feature, a boon to their career, at the cost of the devs’ careers and satisfaction. The manager might be glossing over or just muting any product satisfaction issues, particularly if no one in their line of report directly puts a KPI on that. That’s about company culture.

> "The sooner we get the feature out to the customers, the sooner we can gather feedback and change our product"

Maybe analyze the target audience before shipping? Also an org issue, where a the PO should put their business analyst hat on. I mean, to me it’s a question of competence if the team is supposed to ship something that must be changed (not fine-tuned or improved) - it’s about how much.

Re: Thrashing

#12

Post by codeduck »

kstrauser wrote: post #3

That was exquisitely well put. Nicely done. I don't envy project managers who are responsible for tracking all our engineering shenanigans and trying to communicate trends to upper management. They have a hard, thankless job that probably needs to be done. But the tooling they so often inflict upon teams (I'm looking at you, Jira), is soul-deadening. Bug trackers are great. As soon as they involve a workflow with sta…

I've maintained for a long time that Jira (and similar tools) are where work goes to die.

Re: Thrashing

#13

Post by ozgrakkurt »

roxolotl wrote: post #2

As a manager I strongly agree with this post. I’m currently responsible for taking a team whose old manager wanted to go back to being an ic. The team has a reputation for being slow, not being the best at architecture. So far I don’t really care about that. The problem is that no one at any level can even agree on what their priorities should be. When every standup you’re told to do something different of course you…

There is also something about confidence in there. If the manager is not confident, then they will be perpetually unsure about if person x should be doing y or if it is a waste of time.

And they project this by constantly questioning if x “really” is being productive on y or they maybe should do z.

Re: Thrashing

#14

Post by charles_f »

Superb piece!

> People multitask because they’ve been assigned multiple unprioritized tasks. People are distracted and unfocused because day to day their managers and leaders value responding to distractions and interruptions over consistency and focus

This in particular rings so true, makes me think of a meeting not so long ago where, within a 15m bracket, one of the tied-up VPs was telling us "leaders" we needed to pay more attention to side-projects because devs were working on things that weren't mandated by the hierarchy. That was introducing too much distraction, and slowing down delivery. We need to foster innovation and make sure devs ideas are listened to. And also we need to make sure we don't leave any stone unturned and leave time in the schedule so that explorations requested by PMs are addressed faster.

It's terrifying. Sometimes I tell myself "they're just untrained, they don't know", but when you get higher ups requesting more focus, then immediately asking for breadth as well, it tells me they know, but they also don't care. They just don't want to give any priority, they shove every contradictory requirement down the line, set expectations that everything should be promptly worked on, and proceed to blame devs for their shortcomings.

Then set their LinkedIn tagline to "humane leader with high expectations for excellence".

Re: Thrashing

#15

Post by Nextgrid »

jmaker wrote: post #11
mrkeen wrote: post #10

Managers only have one phrase in their vocabulary: "Get this one feature out as quickly as possible." Everything else is just making devs 'heard' (so they can get back to feature). There have been a few variations over the years: "Just focus on the happy path" and "Build the feature now, and we'll work on stabilisation later". This week I heard twice: "The sooner we get the feature out to the customers, the sooner we…

But the manager gets to report a new feature, a boon to their career, at the cost of the devs’ careers and satisfaction. The manager might be glossing over or just muting any product satisfaction issues, particularly if no one in their line of report directly puts a KPI on that. That’s about company culture. > "The sooner we get the feature out to the customers, the sooner we can gather feedback and change our produc…

> Maybe analyze the target audience before shipping?

The problem is that there’s a risk the analysis finds out that “the product adequately fits our target market’s needs, there’s no easy way to adapt to another market, so most pragmatic approach is to stay put, cut costs and reallocate resources to marketing or other projects”.

No product/project manager and very few devs want to hear they’re not needed, so it’s better for everyone is busywork is continuously being made up, regardless of whether it’s actually beneficial for the business.

I’ve been at dysfunctional places where the winning strategy would’ve been to just give the whole team a 3-month paid holiday while higher level management figures out an actual direction for the product, rather than desperately thrashing around and causing damage/tech debt that would continuously slow down further development (I originally wrote “that would need to be fixed later”, but who am I kidding, that will never happen).

Re: Thrashing

#17

Post by pch00 »

YZF wrote: post #9
kazinator wrote: post #6

Earlier quoted context omitted.

Yes, the manager knows what tasks you're assigned and what priority they are. So how does that work then, if you can't be interrupted? Boss has a new task for you which is higher priority than your current highest one. How do you learn about this? OK, you are not interrupt-driven, so you must poll. The boss puts the task into some task tracking system, which you check every hour. 1. Isn't the hourly check an interrup…

Constant interrupts is a sign something is wrong. Look at construction sites. Do you see the manager telling the dude on the crane lifting some beam up that he has to stop mid-way and go do something else? Never. If you plan and execute well this should not be a problem to start with. If it's not a problem then polling or interrupts doesn't matter. Plans can change but they don't change every hour. The customers behi…

> In the days before Slack and being constantly plugged in people were a lot more conscious about interrupting others and we had less interrupts. The reason we have more interrupts today is that it's just too easy to interrupt people.

So much this. Our org moved pretty quickly into organising and communicating via Teams when the lockdowns hit and people starting working from home. Moving that quickly meant that many basic things like messaging etiquette never really got thought about. Even now I'll still receive messages when my status is set to DND or receive complete junk openers like "You there?".

Re: Thrashing

#18

Post by mr_toad »

kstrauser wrote: post #3

That was exquisitely well put. Nicely done. I don't envy project managers who are responsible for tracking all our engineering shenanigans and trying to communicate trends to upper management. They have a hard, thankless job that probably needs to be done. But the tooling they so often inflict upon teams (I'm looking at you, Jira), is soul-deadening. Bug trackers are great. As soon as they involve a workflow with sta…

> I've worked in shops that optimized for getting work done, and I've worked for shops that optimized for tracking how much work is getting done, and the former outdelivers the latter every single time.

In the past I’ve attributed this to the people in those organisations. Some people like to get things done. Others just like to be doing things (and they don’t understand the difference).

Re: Thrashing

#19

Post by [deleted] »

roxolotl wrote: post #2

As a manager I strongly agree with this post. I’m currently responsible for taking a team whose old manager wanted to go back to being an ic. The team has a reputation for being slow, not being the best at architecture. So far I don’t really care about that. The problem is that no one at any level can even agree on what their priorities should be. When every standup you’re told to do something different of course you…

[deleted]

Re: Thrashing

#20

Post by Xss3 »

codeduck wrote: post #12
kstrauser wrote: post #3

That was exquisitely well put. Nicely done. I don't envy project managers who are responsible for tracking all our engineering shenanigans and trying to communicate trends to upper management. They have a hard, thankless job that probably needs to be done. But the tooling they so often inflict upon teams (I'm looking at you, Jira), is soul-deadening. Bug trackers are great. As soon as they involve a workflow with sta…

I've maintained for a long time that Jira (and similar tools) are where work goes to die.

It really depends how you use it.

My interaction with JIRA is read ticket, assign myself, add estimate, create branch, check out, do thing, put pr up, merge pr, next day after builds have run overnight i move the ticket to 'ready for test' and add the build number so QA can look at it.

Overall its less than 5mins per day in general. For big tickets i wont touch it for many days, sometimes even a couple of weeks.

Its better than qa messaging me to ask which build has the new feature they need to test.

Post reply on HN