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

211–220 of 309 posts

Re: Egoless Engineering

#211

Post by locallost »

It makes sense, but I wonder if it's something most people feel it should be like, but the reason it's not is that it's not possible. I switched jobs recently looking for something like this, but still haven't found it. Now I know the argument of the article is that it worked in one place, but maybe this was just lightning in a bottle of same minded people coming together. So maybe the answer to the problem is that it doesn't take a large number of extremely ego driven people to mess everything up. I say extremely because I think to an extent everyone has one.

But it made my heart warm that someone used Amdahl's law and applied it to people. It's how I've felt for a long time, and why I value communication but kept at a minimum.

Re: Egoless Engineering

#212

Post by safety1st »

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…

If you were the benevolent dictator of a small engineering with no stakeholders to answer to how would you fix this? How would you make ownership all the way to prod a reality and who would the owner be?

Re: Egoless Engineering

#213

Post by wkrsz »

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…

> Resist the urge to build walls between people/teams/departments

Do you often have to deal with support staff reaching out directly to developers on Slack to investigate some problem – without going through "normal" process of creating a ticket that gets assigned? Or even asking for features.

Developers generally want to be helpful, but also small requests often turn out to be rabbit holes. And even in best case it distracts from work that was explicitly assigned and scheduled.

I noticed I experience a bit of anxiety every time I'm doing some work that came through backchannels. The way I try to alleviate is create the ticket myself, mention its source and assign it to myself. This way switching context is visible and I can tell myself that "if manager doesn't want me to spend time debugging this now, they can react".

Re: Egoless Engineering

#214

Post by red_admiral »

There's an old rachelbythebay post that's relevant here: https://rachelbythebay.com/w/2018/03/21/next/

I think it was about the blue company that's tried to pivot to the metaverse?

The gist of the post is that managers started to actively discourage looking outside of their little walled garden, to the point of people getting bad performance reviews for building bridges to elsewhere.

Re: Egoless Engineering

#215

Post by motorest »

khafra wrote: post #175
motorest wrote: post #169

Earlier quoted context omitted.

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

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

You don't get the luxury of not making decisions. You always have to make decisions.

Re: Egoless Engineering

#216

Post by kunley »

Oversimplifying warning:

Must of the problems described here come from a cultural setup that you can't tell or even suggest your managers that they are stupid and/or someone above them is even more stupid.

I noticed that this is especially painful in the US companies, we in Europe seem to be much more lucky with telling people that they do stupid sh*t and not lose the job after telling that. But YMMV

Re: Egoless Engineering

#217

Post by Lanolderen »

kookamamie wrote: post #182
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…

> Require ownership all the way to prod and beyond Ideally this sounds great, practically it rarely happens in modern organizations. Companies, and corporations especially, do not like the idea of engineers having personal ownership over things, as that makes them harder to replace, i.e. reduces the redundancy of the organization.

Redundancy is honestly a good thing. Some smaller companies not in IT have their entire software/hardware infrastucture dependant on a single person who's been there for 20 years and it's objectively dangerous.

Is ownership incompatible with redundancy though? The way I understand it ownership is more so about keeping the app in the specific teams hands to avoid having secretaries running from team to team trying to keep teams from unintentionally sabotaging each other and handling suggestions in a constructive way so everyone is involved in the architecture and general direction of the product and they don't feel like code monkeys. You can still have 20 people on a single project each owning it to an extent. You probably even get more redundancy that way since people are incentivized to look at the bigger picture if they can impact it.

PS: Stupid question but is there an actual definition for ownership? I think I might be talking out of my ass here.

Re: Egoless Engineering

#218

Post by julik »

This is incredibly good, and reflects most of the things I have bumped into that made me miserable. One of the takeaways for me (which transpired where I am now) is "to do devops properly, do not have, hire or designate dedicated ops people". It works exactly like it should.

Re: Egoless Engineering

#219

Post by julik »

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 is what makes creating these performing structures so hard - once the incentives to "show ownership to demonstrate performance and get promoted" is permitted in the organization, people have to "play to stay at the table" and the actual necessary work ethic gets displaced. There should be a clear realisation that creating a moral maze is a taboo, and it is very hard for leaders to stick to that throughout the growth of an org.

Re: Egoless Engineering

#220

Post by julik »

safety1st wrote: post #212
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…

If you were the benevolent dictator of a small engineering with no stakeholders to answer to how would you fix this? How would you make ownership all the way to prod a reality and who would the owner be?

There should not necessarily be an owner, but a responsible individual - which would then be "you", the benevolent dictator. Ownership "in and of itself" creates incentives to gatekeep.
Post reply on HN