Earlier quoted context omitted.
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?
Egoless Engineering
221–230 of 309 posts
Re: Egoless Engineering
#222Earlier quoted context omitted.
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.
The actual point stands, either way: Whether you do not make a decision, or you decide not to act, the outcome is the same--and it is often a better outcome than the result of reactive or proactive decision-making.
Re: Egoless Engineering
#223Earlier quoted context omitted.
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
#224Really 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…
Our approach was unique. We engaged directly with the people who did the work, learning from their insights and challenges, and built tools specifically for them. It wasn’t an Agile team or a Waterfall approach, or any other rigid corporate framework. It was an ad hoc team that came together organically to solve problems—and solved them faster than large corporations, consultants, or armies of workers ever could.
With just four people, we scaled applications, built automation systems, and tackled complex problems that delivered multi-million-dollar savings across the board. The process was simple: no micromanagement, no unnecessary oversight. Everyone contributed based on what made sense, and we all collaborated freely to solve problems as they arose, moving seamlessly from one challenge to the next. It was innovation through cohesion—a kind of synergy that can’t be forced or replicated through standard processes. It’s the magic of the right people, in the right place, at the right time.
Over the years, the tools we developed have grown into critical applications used by professional organizations, with over 3,000 users relying on them daily to make their work hundreds of percent faster. Yet, when these tools are handed over to large organizations for "modernization" or "corporatization," they often end up spending exorbitant amounts of money, adding no meaningful features, and making the tools less effective. Teams of 30 people fail to replicate what our small team accomplished. It’s a strange and frustrating reality.
I’ve tried to find ways to replicate this success, but I think it comes down to that intangible element—a “ragtag team” dynamic where the right people come together with a shared drive and passion. It’s rare, and perhaps it doesn’t exist as it once did. Maybe it’s out there, but we need to find ways to enable and foster it.
Re: Egoless Engineering
#225Sorry -- you lost me in the first sentence.
Re: Egoless Engineering
#226"Like many of you, I was raised in the background radiation of Calivinist thought" Sorry -- you lost me in the first sentence.
Re: Egoless Engineering
#227"Like many of you, I was raised in the background radiation of Calivinist thought" Sorry -- you lost me in the first sentence.
I've read H&P and a bunch of PG's essays. Unsure what conflict exists btw Graham's writings and the content of this guy's powerpoint essay.
Re: Egoless Engineering
#228Really 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…
Re: Egoless Engineering
#229Kiva's engineering drew quite a few lessons from Etsy, though we never got so big. I think Dan is missing mentioning one ingredient: Security. Not code security, the human feeling of personal security. Most especially, of being secure in one's role. And that drives so much of this. If everyone is secure in themselves, or able to transcend worrying about their personal security, then magic happens. Without it, things…
I think there's so much in that (although how to scale it out is clearly a tricky question). The best places I've worked, have all had the ability to make changes when there's a clear benefit. The worst places I've worked have had the opposite, where it's so hard to touch anything beyond the remit of a ticket or feature item, nobody changes things that are obviously flawed and easily fixable.
Re: Egoless Engineering
#230Ok, but how do you deal with people that submit broken CSS, break the site, and are unapologetic? Especially when you are in no position to fire them (because laws, or organisation)? All these “if you do it this way it works” posts seem to assume everyone has the best of intentions (or at least want to do the best job possible), and especially in corporate settings I just don’t think that’s always the case. People ar…
If so, then it's already pretty messed up.