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

Egoless Engineering

egoless.engineering

Post reply on HN
Print view View original

171–180 of 309 posts

Re: Egoless Engineering

#171

Post by motorest »

dakiol wrote: post #9
spuds wrote: post #3

Really resonated with this, reminded me of the journey I went on over the course of my dev career. By the end, my advice for every manager was roughly: * Don't add process just for the sake of it. Only add it if seriously needed. * Require ownership all the way to prod and beyond, no matter the role. (Turns out people tend to really like that.) * Stop making reactive decisions. If something bad happened on a total, e…

With modern team structures it’s difficult to have ownership all the way to prod. My team consists of: one product manager, one staff engineer, one or more lead engineers, one or more senior engineers, one engineering manager. The PM wants his share of the cake, so any big feature needs to go through his approval (“does this feature delivers value?”, “how many users will use the feature?”, etc.) The staff engineer ne…

> The PM wants his share of the cake, so any big feature needs to go through his approval (“does this feature delivers value?”, “how many users will use the feature?”, etc.)

That's literally the Product Manager's job. That's why your employer felt the need to pay a hefty salary to have that role played by a single person whose man responsibility is being held accountable for features being delivered.

I mean, do you expect on releasing features in a product without the Product Manager's say?

That makes as much sense as the PM expecting to single-handedly pushing software architecture changes without consulting with staff and senior engineers.

> So there you are in the middle of all those people wanting their share. If you don’t manage to own a good chunk of that work, you won’t be able to show it in your perf. review. Owning is hard.

Isn't this concern shared by everyone in your example?

Re: Egoless Engineering

#172

Post by motorest »

bibabaloo wrote: post #12
dakiol wrote: post #9

Earlier quoted context omitted.

With modern team structures it’s difficult to have ownership all the way to prod. My team consists of: one product manager, one staff engineer, one or more lead engineers, one or more senior engineers, one engineering manager. The PM wants his share of the cake, so any big feature needs to go through his approval (“does this feature delivers value?”, “how many users will use the feature?”, etc.) The staff engineer ne…

I feel this so much. I feel like most of my job is playing politics to make sure people are happy and let them feel like they're adding value. Rather than shipping things to users to improve the product. It's honestly so depressing. Strongly considering going back to work at a small startup, to avoid having to work with these layers of middlemen that really add little to no value.

> I feel this so much. I feel like most of my job is playing politics to make sure people are happy and let them feel like they're adding value. Rather than shipping things to users to improve the product.

Why do you feel your way of shipping things to users to improve the product is something that makes your team members unhappy and not able to add value?

Re: Egoless Engineering

#173

Post by motorest »

worksonmymach wrote: post #102
dakiol wrote: post #9

Earlier quoted context omitted.

With modern team structures it’s difficult to have ownership all the way to prod. My team consists of: one product manager, one staff engineer, one or more lead engineers, one or more senior engineers, one engineering manager. The PM wants his share of the cake, so any big feature needs to go through his approval (“does this feature delivers value?”, “how many users will use the feature?”, etc.) The staff engineer ne…

It needs a culture change. The magic words: "Our customers prefer the product works over getting a new feature, so let's ensure that at any cost" Number of features is a dial. You turn that down. You turn the operations (devops) dial up. There is nothing modern about releasing half arsed shit... we been doing it since the dawn of civilization.

> "Our customers prefer the product works over getting a new feature, so let's ensure that at any cost"

Do they, though? If a competitor launches a feature that all your customers want and start to switch to benefit from it, what are you going to do? Show burn-down charts of your bug backlog?

Re: Egoless Engineering

#174

Post by didibus »

throwaway2037 wrote: post #168
didibus wrote: post #158

One thing I've realized is that people in different roles have different levers to solve problems, and they naturally skew to using that lever to try and solve all problems, even if that lever can't solve the problem and could make it worse. A manager, to which directors, CEOs, and so on are all included in, have this lever which is that they can hire more people and create new roles/re-organize teams. And they skew…

> hire more engineers I was listening to a podcast with Joel Spolsky recently. He told a story that when he went to Microsoft, they had done internal research (and experiments) to debunk some of the theories from Fred Brooks' "Mythical Man Month". At the time, he generally believed in the "rules" from "Mythical Man Month", and was pleasantly surprised to learn about this further research. In short: Adding more develo…

> Adding more developers does help, up to a certain point

Did it mention any insight on what that point is? And did it contrast against any other approach in the studies? Like look at opportunity cost of this versus other ways to deliver faster?

P.S.: And I didn't mean that those levers are always wrong, more that I've noticed this bias towards the main levers each person has at their disposal. If there's no check on that bias, you, for example, end up in a company that keeps hiring at a furious pace and keeps rewriting all their services all the time in new languages or alternate designs to no end, because everyone just uses their obvious lever as much as possible with the good intent of trying to solve all the problems in the way they can.

Re: Egoless Engineering

#175

Post by khafra »

motorest wrote: post #169
spuds wrote: post #3

Really resonated with this, reminded me of the journey I went on over the course of my dev career. By the end, my advice for every manager was roughly: * Don't add process just for the sake of it. Only add it if seriously needed. * Require ownership all the way to prod and beyond, no matter the role. (Turns out people tend to really like that.) * Stop making reactive decisions. If something bad happened on a total, e…

> * Stop making reactive decisions. If something bad happened on a total, extremely unlikely lark, don't act like it's going to happen again next week. I don't think this item was well thought through. Taking proactive decisions means allocating work for tasks that do not solve a concrete problem but bear the risk of introducing regressions. On the absolute best scenario, things continue to work as always. On the abs…

The context of "stop making reactive decisions" isn't "start making proactive decisions." It's to just make fewer decisions.

The specific example is of a rare event which, while regrettable, does not justify the cost of policy changes to prevent it.

Re: Egoless Engineering

#176

Post by lll-o-lll »

throwaway2037 wrote: post #168
didibus wrote: post #158

One thing I've realized is that people in different roles have different levers to solve problems, and they naturally skew to using that lever to try and solve all problems, even if that lever can't solve the problem and could make it worse. A manager, to which directors, CEOs, and so on are all included in, have this lever which is that they can hire more people and create new roles/re-organize teams. And they skew…

> hire more engineers I was listening to a podcast with Joel Spolsky recently. He told a story that when he went to Microsoft, they had done internal research (and experiments) to debunk some of the theories from Fred Brooks' "Mythical Man Month". At the time, he generally believed in the "rules" from "Mythical Man Month", and was pleasantly surprised to learn about this further research. In short: Adding more develo…

It’s been a while since I read it, but I thought the “actual” rule as articulated was. “Adding people increases communication overhead. At a certain point, more people cannot increase speed but actually makes things slower”.

Hence the more pithy “Adding people to a late project will make it later”. The assumption being that you’ve already maximised the number of people that could work on the thing (trying to get it out the door on time).

Re: Egoless Engineering

#177

Post by sublinear »

didibus wrote: post #158

One thing I've realized is that people in different roles have different levers to solve problems, and they naturally skew to using that lever to try and solve all problems, even if that lever can't solve the problem and could make it worse. A manager, to which directors, CEOs, and so on are all included in, have this lever which is that they can hire more people and create new roles/re-organize teams. And they skew…

That these levers are the tool instead of mentoring and validating plans is an extremely strong signal these people should not be managing engineers.

> Engineers have this lever of "technical ingenuity".

LMAO this is not merely a lever. This is why you hired engineers.

Re: Egoless Engineering

#178

Post by miki123211 »

spuds wrote: post #3

Really resonated with this, reminded me of the journey I went on over the course of my dev career. By the end, my advice for every manager was roughly: * Don't add process just for the sake of it. Only add it if seriously needed. * Require ownership all the way to prod and beyond, no matter the role. (Turns out people tend to really like that.) * Stop making reactive decisions. If something bad happened on a total, e…

> * Stop making reactive decisions. If something bad happened on a total, extremely unlikely lark, don't act like it's going to happen again next week.

I feel like everybody needs to internalize this one (and that notably includes governments and politicians), but it's a really hard problem to solve.

If something bad happened, people (whether that be higher-ups, journalists, lawyers or your constituents) expect you to do something about it. "yeah, a child just got raped on our property but we don't have to do anything about it, it probably won't happen again" is not an acceptable answer in most circumstances, even if it's the right answer.

Re: Egoless Engineering

#179

Post by Kinrany »

dakiol wrote: post #9
spuds wrote: post #3

Really resonated with this, reminded me of the journey I went on over the course of my dev career. By the end, my advice for every manager was roughly: * Don't add process just for the sake of it. Only add it if seriously needed. * Require ownership all the way to prod and beyond, no matter the role. (Turns out people tend to really like that.) * Stop making reactive decisions. If something bad happened on a total, e…

With modern team structures it’s difficult to have ownership all the way to prod. My team consists of: one product manager, one staff engineer, one or more lead engineers, one or more senior engineers, one engineering manager. The PM wants his share of the cake, so any big feature needs to go through his approval (“does this feature delivers value?”, “how many users will use the feature?”, etc.) The staff engineer ne…

This sounds like the team is straightforwardly too big for the task. Especially the EM and the staff, lead and senior engineers all wanting the same one thing of a certain scope when they should be working at two different levels at a minimum
Post reply on HN