hckrnws

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, extremely unlikely lark, don't act like it's going to happen again next week.

* Resist the urge to build walls between people/teams/departments. Instead, build a culture of collaboration (Hard and squishy and difficult to scale? Yup. Worth it? Absolutely.)

* Never forget your team is full of actual humans.

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 needs to validate any design (that’s his job), and provide feedback if he thinks your design “sucks”. So if the feature ends up being successful, he gets points.

The senior and lead engineers need to own the design and implementation details. The leads would probably want to cover a good chunk of the solution so that it appears in their performance review. It’s gonna be though for senior engineers to get a good share if the leads are already one step ahead.

The engineering manager will own the timeline. He will ask you about estimates, but most likely you’ll feel the pressure of whatever imaginary deadline is set.

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.

I have to say, though, that I only have experienced this in tech companies that are around 5-7 years (old enough to have well established processes, young enough to still hire like there’s no tomorrow) and that are obsessed with FAANGs: they will hire faang engineers only if they could. This mix ends up badly, because suddenly every team needs to be a high performing team, everyone is raising the bar and speed is number one prio. When working with companies that hire no faang engineers, everything feels better.

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 remember in a prior job that I had just joined when I was still new to the field, they had a bug board where they collected all the most common bugs users were experiencing.

I decided to, in the middle of the sprint when I was done with the sprint work and had some small downtime, take care of some of the smaller bugs that were easy to fixup in a day's notice. My PM at the time immediately questioned why I'm working on "irrelevant" tickets and not focusing on the wider project we were working on, the senior I was working under had the same stance, and the PR never ended up being merged. It was like 20 lines of very easy to comprehend code that was fixing one of the most reported bugs our users had, like 6 figure number of reports since the bug card was created.

When I left that company a year and a half later, that bug card was still open, with my now-rotting PR sitting there with a "closed" status.

It really jaded me on all of these bullshit processes, sprints, AGILE, whatever you want to call it. It was obvious that nobody gave a shit about what we were building and how, it's all just a game to pad yourself up and to look good to the higher ups who control if you get a raise or not. If someone above you can't somehow gain a lot by boasting about the work done, then you might as well not do it. I fucking despise the mindset and how prevalent it is in the industry.

Healthy orgs must have slack in the system and allow teams and individuals to do a little chasing of fun or meaningful things that give them intrinsic pride and motivation.

Teams must advocate for projects, but, for individuals, one solution that I've seen help is that the week long oncall developer handles sprint interruptions, slack questions, and bugs. No sprint commitments. If something is not on fire, they get to work on whatever they think will add value at their discretion. New tooling, proof of concepts, pet-peeve bugs that can't get prioritized, etc.

After lots of stabilization work, devs looked forward to oncall.

> Healthy orgs must have slack in the system and allow teams and individuals to do a little chasing of fun or meaningful things that give them intrinsic pride and motivation.

As an Engineering leader, I try my hardest to make sure this Slack exists for the exact reasons you listed.

I feel this. The zero-sum pendulum of time is a bitch.

I wonder, are you under 35? This story reminds me of my experience. When I was younger, all the problems could be solved - all at once. I'd throw time at just about everything - cleaner code, fewer bugs, features delivered.

Later, the scope of what I was working on grew. No amount of time could be thrown at all the problems - it was zero sum. I had mentors try to guide me, to focus on solving what you need to, to focus on areas of impact and let the other things slide. If you don't, then the areas of impact never get done.

On the other side of the coin, the really frustrating part - is the bullshit processes you speak of. Time is zero sum. Yet, here was the team wasting time on another status meeting and time estimation; not getting the things done. Small quick wins, which do have impact, are not small quick wins because - did you fill out the TPS report regarding user impact? Did that get approval and story pointing? Is it a strategic initiative? No, then why are you working on it? Those are unhealthy orgs. Places like that I think are filled with folks that can't do the job and ride the coat tails of those that get shit done. These are also places where people want to go, clock in, and just not think that hard about their job - just do it and get home to their families.

Though, I've come to also appreciate that mentality too. I've never been a true owner at any place I've worked at. I've cared, I've been tricked into caring - but the long hours only went to enriching the person that had 1M shares, while I had just 2000. They were an owner, I was pawn.

I've worked in mid-sized companies where my job wasn't just one thing, and where I was not owned by a project manager. Other concerns existed. Even back at the ancient bank I worked at, our implementation of ITIL recognised this, and put incident and problem managers on equal footing with project managers. If a frequent issue is caused by some underlying problem, that problem needs to be fixed. Working on it was absolutely legitimate. During sprint planning a team could take work from the new features like or the bugs pile without interference from a project manager. If they complained that you worked on a bug, you could lean on the problem manager to talk to the project manager. If the project manager's timelines drift, part of their job is to deal with that, inform stakeholders and extend the deadlines. If they continually fail to factor in the possibility of conflicting work then they suck at their job. If their boss gives them shit for a slipping deadline that was out of their control, then they also suck. In your example the company allocate 100% of your time to working on new features and none of it to maintaining the product or keeping customers happy. There's no point in putting a brand new engine into a rusty car with bald tyres. This a bad organisation.

> 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?

[dead]

the one who solves this problem will flood the world with a neverending wave of light..

every day I wonder how come I do so few now that I'm paid compared to when I was jobless and hacking prototypes for $0

finding the recipe for creating goal driven, high speed, high quality, frictionless teams is a difficult quest

> every day I wonder how come I do so few now that I'm paid compared to when I was jobless and hacking prototypes for $0

Salary is inversely proportional to how much you actually (need to) do.

Lobby your government to tax management hours. That’ll fix things.

I often wonder how some open source projects manage to be so successful/productive with so little of what looks like corporate management.

How would you implement this though? Wouldn't things just be renamed?

A difficult quest indeed, but not impossible. Sometimes teams like this do exist.

You know the ones. They founded the trillion-dollar companies you hear about and became billionaires themselves

Nah, it's usually luck and robbing someone else work, windows apple Facebook etc

I'm going to say it is efficiency and the ability to implement ideas well, even if they are stolen ideas, that account for more of the success for anything else.

I also bet they did come up with some small things here and there themselves, in the process of implementing stolen ideas, because often things become apparent at the moment of implementation.

yeah there's always something a bit special in success, even if they took the idea, you can't just copy paste or you just produce shallow shiny stuff

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.

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

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.

Quality can also become it's own trap as the entire org chases metrics aimed at quality. Soon you have loads of brittle tests that likely aren't adding great assertions but you have code coverage.

Because that doesn't work soon you keep adding layers upon layers to reduce the risk and your time to delivery suffers.

All knobs have consequences and long term they can really compound. The balance of picking quality over features isn't something I've seen done amazing. I'd like to work somewhere that could pull it off.

You are right and the biggest asset here are executives and management that can:

1. Think

2. Know what is going on.

3. Effectively get the best from their people.

You want the whole org to engineer the right solution

Any metric that gets abused needs to be found and replaced. Companies should use metrics and be very respectful, curious and also suspicious of them. Even revenue!

I know companies that leave revenue on the table for strategy.

Finally quality is about probabilities. That test you wrote that takes 12s to run and flakes 0.1% adding 10 hours of build time a year ... what is the probability of it detecting a bug and what would the cost of that bug be. You need every engineer to think of that stuff. It is hard stuff to get right or even good.

I worked at places where a religion almost builds. People are hired to maintain those slow expensive unreliable tests! You want to improve that you now have politics!

How do you build 1 and 2? It seems so simple: talk relentlessly about what you’re trying to do as a company, and then figure out how to assign your people most effectively to do that. I’ve seen a number of leaders figure out the messaging and then flat out fail on execution. Once they’ve worked out the vision, they fail to give middle management enough latitude to accomplish it, and the lack of trust flows downhill.

I agree. First step I think is to start measuring what’s important at the top of the organization. When you have weekly progress meetings with the CTO and CPO and only look at lists of new features, then new features will be what people think about. “What gets measured gets done”, as they say.

I have never seen positive impact from turning the devops dial up. Most of the times, we just keep on adding checklist items for quality and engineering practices. Devops keeps pushing things like observability and standardization through complex things like service mesh which creates all of its own problems.

> "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?

> 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?

I would say this is not that common in SaaS. In that features are important but PMF is key. A feature that drags people over is really a new product. I can't think of an example of the bolt-on killer feature. And by the time you are big enough to run multiple distinct products youd better have good uptime. If you are a startup of course you need features but again finding PMF so you ain't worried about competitors. As a startup you are choosing boring tech and maybe a PaaS to help you do less productioning.

Notice the popularity of k8s, splunk, CI/CD, testing, multi region and so on? Yeah there is big money in being available.

> A feature that drags people over is really a new product.

But isn't that a post-facto observation? I mean, any project can work on a complex feature that's a flop, but sometimes a simple feature can go a long way and just tilt the scale. That's not a new product.

False dichotomy. The point of the quote is to worry about not breaking the product. It's still possible to deliver features while keeping it working.

> False dichotomy.

Not really. This is the fact of real world software development: your resources are limited, and either you invest them creating value for customers so that they choose your product over your competitor's or they choose your competitor's instead.

If you spend your resources on technical debt and clearing bug backlogs even of obscure nonblocking bugs, you're just spending your resources to offer your users more of the same. If you instead use your resources to deliver new features that might have a nonblocking bug here or there, you're improving your position over the competitor's.

Time to market matters. A lot. There is no such thing as time to empty backlog.

> If you instead use your resources to deliver new features that might have a nonblocking bug here or there, you're improving your position over the competitor's.

In the short term. Features can attract new customers but software that is frustrating to use due to a lot of low level bugs will repel existing customers towards competitors over the long term. If you've simultaneously decided tech debt isn't worth addressing then your competitor can easily overtake you. Furthermore adding feature after feature eventually leads to a kitchen sink product where potential customers are put off by the learning curve. This is really just a variation on the quantitative fallacy that ignores qualitative aspects.

> one staff engineer, one or more lead engineers

An engineer isn't really a "lead" if there are multiple, or if they are outranked by a "staff engineer".

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?

We have this. It's a culture thing. It's not actually possible to force someone to own something till production, but we encourage it and most people follow that.

One of the keys though, is a very easy process from development to code being in production. The more obstacles you put in the way, the less inspired a developer is to own the whole thing.

Not everyone is great at this, and people get frustrated when others don't own their stuff, but typically things are cordial and encouraging, rather than aggressive. But we're still a relatively small place (150 staff, about 40 developers), and inevitably, and sadly, this will change.

> t's not actually possible to force someone to own something till production

Only in the same way that it's not possible to force someone to complete their work?

Put their name on the ticket and clearly communicate what it means to "own" a ticket (an oft-missed step). It's just another task, like writing the ticket, testing the ticket, doing security review, etc.

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.

Why did I hire these people if I cannot delegate responsibility to them?

Interesting how you described the scenario quite accurately that is currently playing out and the current tech company of 5-8 years I am at.

Yeah I completely agree that a lot of structures work actively against this. Lot easier for me to write a bullet point about it than actually implement it at a company with an existing way of doing things. And I think it's almost impossible to implement from the bottom up, as it often requires some real process (and culture) changes.

this really must be common. I myself could have written a similar (less well put) summary of my last two jobs.

> 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?

> 'modern team structures'

This kind of argumentation somehow never settles with me and blocks me from reading on. 'modern', 'new', 'trendy', 'state of the art', 'industry practice' and alike all resonate with 'I do not know so I mimic how others do' in my mind. Weird, but do.

Are 'modern' team structures a desirable reference?

How about saying 'today's problematic team formations'? I'll try to understand so and read on.

---

Edit: it turns out we are on the same page, I jumped at ghost.

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

Yea Germany quitting all nuclear comes to mind…

Bad example in my honest opinion: Merkel made me believe it's the "worst case scenario" kind of thing - same reason there shouldn't be capital punishment. If you can't afford to pay the price in the worst case scenario you shouldn't take the risk.

That being said, I believe failures and mistakes are simply part of our lives. I would turn the other way and run when someone says that he found the perfect system, in which there are no losses failures and problems. You are always limited by what you don't know you don't know.

> If you can't afford to pay the price in the worst case scenario you shouldn't take the risk.

Which probably precludes leaving your house (or staying in it, for that matter).

I thought of that too, but also the US banning Kinder Surprise eggs.

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

In fairness, it seems the problem in your case is that the "manager" has built up walls between people, trying to own the work, and in that not allowing you the full context that would allow you to make informed decisions around such asks. "The manager not wanting you to spend time debugging this now" should be a false premise. Knock down the walls and you will know yourself that you shouldn't spend time debugging it now.

That makes sense. Either knock down the walls all the way and empower developers to make decisions, or keep the walls and let all requests go through the pipeline.

Recently, I was thinking plenty about trust within organizations, and it resonated with me too.

I've worked at a few startups and have seen high-trust environments lead to a lot of productivity, comfort and success— and the opposite for low-trust startups. In general, I think startups tend to lean towards high-trust, especially when they're small and early, but I was part of a 15-person one that was quite the opposite, and it was terrible.

The hiring process wasn't great. Long take-home task, and that was the only technical interview. A lot of talking, but not much noteworthy signal on the rest. Very long wait times. Now I know this is a red flag for low-trust companies. If they're not building trust at the hiring-stage, it means even after joining the organization it'll take time to acutally "be part of the team".

Once at the company, I had no permission to poke around— everything was hidden by default. There was no space for discussion, I was expected to learn, not to comment. There was plenty of micro-management; after all, if they don't trust you, they need to keep an eye on you at all times. You're probably doing something wrong.

The chasms were deep too; the company was building a web team to spin a contractor's project into a full web product, and I was supposed to lead it. We were disjointed from the rest of the company though, and would only hear about requirements through the founders. The team had interest on being more involved with the main product, but management just wasn't interested in making it happen, and just had us loiter around for a few months until they gathered requirements, and then implement some rather disjoint features.

The project failed. I'm working somewhere else now.

tldr; low-trust environments kill projects

Yeah, I think there's almost always a point where a company decides they need to stop generally trusting their employees. Then all the trustworthy ones start getting more and more frustrated, or just start checking out. Agreed that most startups lean towards trust. Need to keep that going as long as possible, and stay away from hiring managers who think their primary job is "protecting" the company from anyone who might make a mistake.

Yes, and at the same time, companies start hiring employees that shouldn’t be trusted.

Neither one causes the other, both occur as companies mature. I’ve seen this as startups mature. One very vivid recollection: we had a very strong and tiny dev team. Each dev owned a huge piece of the product. Definitely not egoless. We brought in trusted junior devs to grow. That was fine.

Then the very talented VP Eng. wanted a promotion and brought in a hack to replace him, who hadn’t coded in years, and was obviously more concerned with his career than our product. A real mediocrity. But the VP wanted to move on, so this mediocrity was hired, over vigorous objections.

That was the end. This new VP brought in mediocre devs, rewarding loyalty and “being a team player” more than productivity, or competence. He brought in employees who couldn’t be trusted.

As this was happening, we were acquired, and our new bosses from the parent company were used to employees who couldn’t be trusted, and acted that way.

HR knew that to keep the good engineers they had to do something, so they showered us with bonuses. That worked for a while. I finally got so bored and fed up that I left (for another startup).

> Need to keep that going as long as possible, and stay away from hiring managers who think their primary job is "protecting" the company from anyone who might make a mistake.

On that note, a quick shot-out because I've been lucky enough to see the opposite happen at a big company too. Performance cycles at the company very much disincentivized big bets. Some engineers really thought project "X" was important, but it was risky— if it didn't pay off by the end of the cycle, per the way the bureaucracy worked, it wouldn't be great.

The manager very much tried his best to protect them against this. In fact I don't think it paid that cycle, but the project remained active until it did eventually pay off. Shoutout to managers like this. The easy route is to act like a messenger for higher-ups, and never put your own skin in the game— but there's some out there that want to do what's best, not what's easy.

This. This is what ‘higher’ ups should be aiming for. I try and do it with all my attention. The good fight.

> there's almost always a point where a company decides they need to stop generally trusting their employees

I recall exactly when this happened at Facebook.

> Yeah, I think there's almost always a point where a company decides they need to stop generally trusting their employees. Then all the trustworthy ones start getting more and more frustrated, or just start checking out.

$employer has formal separation of duties between development and build/release for some things, which deal with other people's money. I'm pretty sure it's mandated by customer contracts.

I completely agree. I’ve had the privilege of working with a very small team of engineers—a team with diverse life experiences and unique areas of expertise but a shared work ethic: the willingness to try. We always said that most of our time was spent failing, and that’s what made the moments of success so rewarding. When we finally succeeded, it wasn’t just about the victory; it was the culmination of relentless effort that allowed us to push forward, improve our product, and refine our ideas.

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.

I think there are ways of philosophy not process. And the philosophy has to be agile to those in it.

> * 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 absolute worst scenario, you introduce a critical regression that brings down the service. There is literally no upside and all downsides.

There are many reasons why "if it ain't broke don't fix it" is tried and true.

> * Resist the urge to build walls between people/teams/departments. Instead, build a culture of collaboration (Hard and squishy and difficult to scale? Yup. Worth it? Absolutely.)

That really depends on what you mean by "walls". The reason Conway's law is a thing is that in order to have functioning teams you also need functional independence. If you need to book a meeting with anyone to justify pushing a change to a service you do not own, that's already a wall. No matter how easy it is to get through that wall, it's still easier to not have to go through it.

I can tell you an example of how independence always beats collaboration. Once I worked on a project where QAs were a separate team entirely, and made it their point to be the sole owners and maintainers of all automated test suites beyond unit and integration tests. We experienced a major regression that the regression test suite wasn't caught. I went right to the head of QAs and asked if I could push a commit to add a couple of regression tests. He politely declined by saying that they were already working on it and I wouldn't need to bother with that. Great, a victory for not building walls I guess? Except that his "we are working on it" ended up being "we added a ticket to our backlog and we might pick it up two months from now". Literally. And they never did, by the way, and the same regression was eventually introduced without anyone noticing.

In case you wonder how I solved that problem, I created my own regression test suite. Conway's law always wins.

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.

If you do not consider the problem at all, you have not made a decision on it; any more than you have to make a decision about, say, the most aesthetically pleasing perspective of Olympus Mons for prospective Martian colonists.

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.

What if the decision is to not do anything because the event is so unlikely to happen again that it isn't worth the cost to fix.

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

> 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 hate this, like when there's an outage and the outcome is 100 half baked ideas that must be implemented, that just make things worse to work with

Yeah. And all the time spent on those 100 half baked ideas take away from time that could be spent working on the most likely cause of the next outage. (Real forward-looking risk reduction work.)

I really believe in the ownership model, which is why I hate the Jira ticket-based development model so much.

There was a time in my company where a single developer, who owned the product, would ship an entire app in a year. Now we have a "cross-team" where you have to constantly manage all feedback and try to shut down stupid ideas from getting into the product. I really hate design by committee: all talk and no ownership.

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

This is a central theme in Bruce Schneier's 2003 book Beyond Fear, which I continue to recommend 20 years after I first read it.

> Require ownership all the way to prod and beyond, no matter the role. (Turns out people tend to really like that.)

Depends on what you mean.

Individual ownership over code/feature/module/etc would seem to run counter to the article - it's just another fiefdom.

Collective ownership? Sure.

I think the right balance here is to have ownership of the outcome rather than the thing. E.g. you have ownership of making sure the feature you’re working on makes it to production and works properly

With that ownership comes there responsibility and accountability of making sure it happens. The level of responsibility and autonomy that comes with that is what I’ve found people react positively to

Ownership to ‘make sure it happens’ is entirely different from being able to ‘make’ it happen. The first is absolutely toxic.

* Separate bullet points by blank lines on HN. ;)

Yeah, I'm facepalming on that one. Thanks!

The Process Person who wants to build a Mature software organization will say, process is seriously needed.

That dork can only become factory manager when there are factory workers, see? "Process" is just a word for a production line of some kind - narrower or broader, but still a life-sucking endeavor.

talking about ownership, I ran into some git repo with a "declaration of non ownership"

an economy of giving in a way

In my humble opinion, this is excellent advice. Honestly, so on point.

Excellent points!

I wonder why these almost never considered.

[flagged]

I've worked at FAANG. Actual humans too.

Can you unpack your comment?

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 towards it for many problems...

We want to deliver features faster, what can I do, me, a manager?

    - I could hire more engineers!
    - I could reorganize my engineers so each one works on a specific type of issue

I'm picking at managers, but every role has this issue. Engineers have this lever of "technical ingenuity". And they skew to it as the solution to all problems.

We want to deliver features faster, what can I do, me, a software engineer?

    - I could rewrite this in a more productive language/framework
    - I could redesign this to make it simpler and easier to work on

    > hire more engineers

Fred Brooks never said that adding more developers does not help -- he was stating that solving the single problem of being late will only be exacerbated by adding more people.

To use the infamous analogy that "nine women can't make a child in one month": it is still true, but if your goal is to have more children (as opposed to having one child be born sooner), adding more women would certainly help.

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

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

I heard this phrase in college and it stuck: "when all you have in your toolbox is a hammer, every problem looks like a nail".

The main thing a good manager can do is act as a wall between the engineers and everyone above them, which is hard to do politically because it exposes a whole subtree of the org chart as useless.

I think that's a little myopic because that subtree is providing the comfortable fiction that you can just go into work, do engineering, go home, and get a paycheck. I'm not saying I don't want to blow my brains out dealing with them but it's comparably a small amount of pain in return from being completely insulated from all of the realities of operating a business and the messiness that entails.

And sometime you really can't do anything except but waiting and letting the potatoes to grow, so to speak ("We plant potatoes in the spring, and harvest them in the autumn" — "Well, we plant potatoes in the morning and harvest them in the evening" — "Wow, do they really grow that fast at yours?" — "No, we just become really hungry by the evening").

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.

I believe that the GP's point was that different roles have different tools in the box that are more efficient in their particular areas, and tend to rely on these rules even when solving problems in other areas.

It is very common to see engineers trying to solve non-engineering problems using the "technical ingenuity" to attempt resolving social issues; sometimes it works well enough (e.g. timezones), and sometimes it fails pretty miserably (e.g. OLPC).

Exactly, and I'd claim this is even true in their area as well. "Technical Ingenuity" is the obvious arsenal in an engineer's bag, and that's why it will bias engineers as the solution to all problems, even engineering problems.

For example, on a previous team we had an issue where configuration was littered in too many places. It was confusing, and people didn't know where to change what in order to onboard a new client, and they'd always forget something.

Well, most engineers went directly to re-architecting/refactoring as the solution. We should centralize all config in some new central config store, and have all systems pull their configuration from there. Once it's all in one place, it'll be clear what to change and we can't forget to change any.

One engineer though said, we just need a good wiki that clearly describes all the steps. Well, that took about 2 days, and it solved the problem. No technical ingenuity needed.

You know... if you had managers that didn't suck ass this wouldn't be a problem and you could reign it in. Point proven exactly.

An ageless idea...

  "There once was the first software engineering best-selling book. It was called The Psychology of Computer Programming (Weinberg 1971). There was a peculiar idea contained among the many excellent ideas of that book. It was the idea that the task of programming should be egoless. Programmers, the author said, should not invest their ego in the product they were building. 
  ...

  What’s the alternative to an ego-invested programmer? A team-player programmer. 
  The team player sees the software product as a team effort and a team achievement. Error reports and reviews and questions become team inputs to help improve the product, not threatening attacks to derail progress.
  ...
  But after further thought, this notion begins to unravel. It is all well and good to advocate egoless programming, but the fact of the matter is that human ego is a very natural thing, and it is difficult to find people who can—or even should—divorce their ego from their work.
  ...
  A system that works will have to acknowledge fundamental human traits and work within the bounds they create. And ego is one of those traits.
  "
 - 'Facts and Fallacies of Software Engineering', Robert Glass, 2002

People may bring ego into programming because of some kind of pathology (eg the need to always be right or in control) but I think in many cases it's because they truly care about the work. And the problem is not that they truly care, but that there is a mismatch between the amount of influence/control/autonomy they wish to exert on their work and the amount they are actually able to exert on it.

I wasn't there, but my understanding is that essentially all programming in 1971 was done in large corporate settings or universities/research institutions. Those are environments where it's rare for any individual (even someone nominally in charge of a project) to have full creative and technical control over something, and even when they do, it only lasts as long as the project/grant or until their employer puts them on something else.

Compared to the 70s there are effectively no barriers to a passionate engineer starting their own software project as either an open source project or in their own startup, and I'd argue that those are settings where it's actually highly beneficial to bring ego into programming. It's pretty much the same notion as "founder mode" or why BDFL is one of the most popular forms of governance for FOSS.

Personally I'd recommend anybody who "brings ego" to their dayjob to take a stab at FOSS or a startup rather than trying to fit a square peg (caring a lot about their work) into a round hole (the realities of working on large projects).

Sometimes a person's dedication and care expresses itself to others as ego. Sometimes it is just ego.

I think we've all implemented some clever trick in our code that we started to feel proud of. It's hard not to do. Even if you just contribute to a small piece of the project, you still might have those instances of pride. We're all human, and it's fine to take a little motivation from your accomplishment. But hold on loosely. Be critical of your baby and be willing to throw it out if it isn't the best approach.

I used to really like driver/embedded programming because it seemed like there was a 'best approach' or idiomatic solution for most problems that eliminated ego. It felt more like electrical engineering. I often felt programmers working on higher level software treated their work like a personal art project and that turned me off from it.

How very well put.

The problem with "ego" as a concept IMO is that it carries negative connotations with most people and isn't exactly well-defined - some people might see it as always a bad thing (I think you might fall into this camp given that your phrasing "dedication and care expresses itself to others as ego" rather than saying it merely is ego). Personally I think that that is ego, but that ego is not necessarily a bad thing.

There is nothing wrong with taking pride in your work, nor in recognizing that you might actually be more knowledgable/skilled/correct in some particular matter than someone else and communicating that to them - as long as that sense of knowledge/skill/correctness is not misplaced, not expressed cruelly, and the actual reasoning is explained. To me, that is "good ego". But if someone thinks they always know better than someone else in all cases or isn't even willing to open discourse/explain why that's "bad ego".

I guess to me, the sentiment expressed in this article is one that I feel strays too far into the realm of toxic positivity or crabs-in-a-bucket where merely being opinionated or passionate about your work is a bad thing because sometimes other people get their feelings hurt when you explain why their approach won't work well. I just don't think being egoless is necessarily good. I certainly wouldn't sit there smiling while something I worked on for years got destroyed by other people, because it'd be impolite or egotistical to point out that they're destroying something. But of course, there is a difference between something actually getting ruined, and having a meltdown because someone started naming variable in snake_case instead of camelCase.

I would argue that in fact you do need a critical mass of ego throughout the ranks of engineers in a large organization. An engineering culture where engineers don't care inevitably leads to abdicating responsibility for overall system health and even data/workflow correctness as PMs attempt to steer the ship without understanding the implications of what they are asking for. Once this has gone on for a while, the system will be so intractably broken, and the dead sea effect will have caused such a brain drain of all those capable of fixing the problems, that at some point there's no economical path to restoring the software systems to a healthy and maintainable state. At that point you might as well just call in the private equity guys and figure out how to extract maximum cash out of the business as it stands, because any code change becomes more likely to break more things than it improves.

So yeah you need ego. That said, it must also be tempered with the reality of needing to compromise enough to satisfice all stakeholders (including both technical and business stakeholders of all the different flavors). The beautiful thing about software engineering though, is there is a reasonable amount of objective facts, metrics and tradeoffs, that given a critical mass of sufficiently skilled and mature engineers, common ground tends not to be too hard to align on. Or at least, far easier than to get a non-technical stakeholder to understand the long-term implications of a bad decision.

Agreed.

To make the best work you have to take pride in it. This work has my name on it, customers will use it, I want to improve their lives not make them worse.

The developers who come after me will need to assimilate this work. They'll need to build on it. I want to make their work a joy, not a burden.

Do I take pride in what I do. It's not enough that the code just compiles.

Pride is balanced by humility. I'm prepared to defend my choices (with well informed, well experienced) answers. But the choices I make are always a balance of upside and downside. And over my career things have changed which reweights some of those decisions. I'm open to external input from others because I want the result to be good not me to be right.

I want to be proud of my work. But I'm humble enough to let others help me to improve it.

[The above is my goal, sometimes I fall short]

The ego is, indeed, referred to in a negative sense because most people do not sublimate it to serve the group. It's natural state -- and, therefore, our natural state -- is to be selfish to oneself and one's in-group.

There are 19 pairs of vice/virtue pairs in the ego. We can only decrease our ego's vice-eous tendencies by increasing our consciously manifesting compassion to everyone we encounter. It also helps to contact our Creator and ask for guidance. It awaits us in Its Unfathomable Lonliness to beseech it for help to begin and then see out the complete transformation of our ego into a selfless, servant of the happiness of others and the societies/cultures we inhabit.

That Path of Loving Service is the key to happiness, and is the opposite of narcissistic attitudes and bahaviors.

There is nothing mysterious about the ego; it's just that willful ignorance is one of our heart's vices, and its purpose is to deny that each person's ego transformation is not only possible, but the source of joy and community uplift, and is our free will to choose love or any of its many selfish opposites.

Huh. I thought it was thought of negatively because people confuse the word ego (self) with egotism/conceit (exaggerated sense of self-importance).

The same sadly has happened with confusion of the word selfless (having no concern with self) with unselfish (concerned with others before oneself) and altruistic (unselfish concern for others' well being).

Personally, I don't see any incompatibility between having a sense of self and healthy self-esteem and having compassion.

Indeed, I see a major incompatibility between actual selflessness and universal compassion - as selflessness would preclude compassion for oneself.

Selflessness merely means understanding that selfless service to others' happiness is a fundamental element of the spiritual path. We do not have to love them more than ourself, just equal, but we must take the chances we get to serve their happiness as much as possible.

You're right about the negativity of the ego's self-important nature via conceit and egotism. Those are negative traits of the self. The goal of self-improvement is to become a consciously virtuous person who puts the needs of the whole in its proper place, and doesn't indulge their selfish vices, which always cause unhappiness to those around them.

Positive self-esteem, when due to being a compassionate person, is a necessary component of the self-evolving person, because honesty in grokking the truth of ourselves is an important part of our growth.

And, remember, universal compassion also includes being compassionate to our own self, and as we increase our virtuosness, we are ever more beloved by the universe, itself. The happiness on that path is not known by but a small minority of the world's cultures/societies.

Sorry I'm not writing so clearly this late in the day, but know that the ego we have a birth is mostly selfish. It takes a definite turn towards the light to begin the process of purifying it by degrees from egotist to self-actualized bearer of compassion. It's a true fight, fighting against our own fallabilities and weaknesses and selfishnesses. But it's the most worthy struggle we will ever undertake.

Well the ‘pathology’ is clear, isn’t it?

They’re not actually smart enough to keep track of what every other team is doing, at any point in time.

FOSS works because there’s usually only at most a few dozen balls in the air simultaneously, so someone who believes they can keep track of balls in the air gets by without looking ridiculous.

But that’s just not viable when there are hundreds or thousands of balls in the air simultaneously… their eye muscles literally couldn’t move and focus fast enough.

I think FOSS really only works well for infrastructure type of projects, things where the customers are downstream programmers or at the very least very technical sysadmin types and power users who can understand the gory details to some reasonable depth. Those projects work because they are centered around proven abstractions that are broadly applicable, thus allowing for a tight charter and some stability in requirements.

End user software by comparison, has not really been successful in the FOSS model. There have been many attempts, but they perenially lag behind commercial offerings, and thus primarily see adoption from the ideologically motivated and/or very cost sensitive users.

Check out Hackers, by Steven Levy, for some fun tales from early in computing.

I've noticed that some of the worst ego-related issues arise from people who care the most about their work -- the craftspeople, if you will. There is a type of person who will pour their entire soul into creating the most ideal expression of whatever it is they are trying to do. Sometimes that level of investment is warranted and even required. But mixed together with others who don't -- or can't -- operate that way, that's what leads to trouble.

I've seen this manifest as long and scathing code reviews, attitudes of "give me that; I'll do it myself," low morale, burnout... I've never found an adequate solution. Sometimes it was my ego that was the catalyst in a situation. I recognize it now, could I have caught it earlier?

Our expertise in any kind of technical skill that allows us to participate in society is of no importance compared to our becoming a positive member of all the societies/cultures we encounter. This requires becoming a compassionate, empathetic human being via deliberate, honest, self-critical work on the areas of our personality that cause unhappiness to others via selfish negativity.

We are the only beings on Earth that can self-evolve, by using our conscience and mind to evaluate of our actions to find out where we are causing unhappiness. Then, we must engage our free will to choose to be better, and do the things that help us to grow spiritually out of the immature, selfish mammals we begin as, into the humanitarians that result from reaching our highest potential.

The most destructive lie we let our minds tell us is that this transformation is not possible, or is the figment of someone's imagination. The ego tells us this because the spiritual path entails the destruction of the negative ego. Under this existential threat, the ego defends itself like hell.

wow, thanks for this.

Thanks for the thanks, friend. You can find more info in my various comments in these last couple of days. I want nothing from anyone, I'm not trying to get anyone to convert to any religion or join any group. I just want you to be happy and learn how to help yourself help others. Happiness is only earned by making others happy. There are ways to help that process.

Peace be with you. You are loved.

I'm not entirely convinced that ego-less is even a better way of doing things. Sure, the ego can go overboard but it also gives a sense of drive and direction. It isn't just the bad stuff. Without it, there's nobody taking ownership of the design or it's just designed by an apathetic committee.

Taking ownership is very much egoless! You are doing that for the team.

Ego would be making sure you got "your" sprint tickets done, did no code reviews, skipped the retro. I think few people do that but they will if Goodhart's Law happens.

Pride and passion can exist without ego. I view this as appreciating things for what they are, not who they belong to.

I don't really agree with that unless you redefine the ego as being synonymous with 'being egotistical' or 'sinful pride'. You need a sense of self to feel pride and something more than base passion.

For practical purposes, if you don't acknowledge how good and bad behaviors can both spring from the same base emotions/thought processes then it's harder to grow out of the bad behaviors. You need to be able to reframe how the ego interacts with your work, not just try to kill it off.

Yes, and not thinking that one is better than anyone else. We are all equal, no matter how much better we are than another, with respect to either some job skill or even the spiritual path. Dunning-Kruger's true-experts are better than the slackers, but we must be humble to achieve that and then not be an ahole about our achievements.

It's a tricky business, being a human being, with its very many pitfalls.

You can never remove ego from the equation, completely. People are placed on different levels of organizations, with different incentives and agendas.

Thus, it's never a balanced setup where everyone's happily working towards a shared vision in equilibrium.

There's always someone having a larger incentive than the other person, overriding their decisions in a haste, in order to reach a bonus objective.

Welcome to the real World driven by capitalism.

The last paragraph is the interesting one, and here's the full quote in context:

    One of the reasons Communism eventually failed is that it assumed that we could all accept the philosophy "from each according to his ability, to each according to his need." The assumption that we could all subjugate our needs to those of others is about as faulty as the assumption that we can subjugate our egos for the betterment of the team. A system that works will have to acknowledge fundamental human traits and work within the bounds they create. And ego is one of those traits.

One of the reasons Communism failed was because of incentives. People were not rewarded with more compensation for working harder.

When you mean incentives - do you mean the threat of starvation or the promise of a glittering palace?

Perhaps the disconnect between effort and outcome was a factor, though as discussed above don't under estimate the satisfaction of a job well done.

I think it's more likely to be the centralized decision making, and how the people who make those decisions get chosen. A centralized system where people are choosen based on political ability/connections is likely to lead to corruption and mediocrity.

Note the above problem can happen in other systems as well - I'm not sure US politics is operating well at the moment for example.

>People were not rewarded with more compensation for working harder.

Nit: they had worker’s medals and similar non financial recognition.

However yes, the price paid for labour was far below the point to ensure supply met the demands of economic development.

I know its getting off topic but I never understood why people seemingly couldn't accept that.

Current systems don't have a 1:1 with "hard work" and success/comp but its about as close as you can get, IMO.

It’s fine if everyone gets the same. It’s not fine if some people are more equal than others.

Actually, no, it’s still not fine, because whole heaps of people will pretend to be unable to do much.

Did it fail though? China is doing pretty well and by most metrics Russia is doing worse post communism.

I actually like how the standing committee are the best capitalists of them all

S-Tier

I like it because its amusing and always gets a new generation of gullible people.

"hey, rent's pretty high, how about you all give the state all your property instead and I run the state until further notice"

The failure in this paragraph is that our highest and most important ability as human beings is to self-evolve ourselves out of our selfish ego into its selfless version.

That paragraph is as completely wrong in its understanding of human nature as a paragraph can be. Yes, it is difficult, but we are all capable of choosing to put ourselves through this self-evolution of our ego's vices into their corresponding virtues.

First of all, be it "self-modification". We all have some hopes about that, if we care enough. (Self-evolution implies playing with genes as species, which is a dangerous business.)

As I personally caught the last chance to see a country promoting the selfless version, my stance is that the quote is spot on.

We all have some hopes about altruism, if we care enough. But then you look around and 90% of people don't care enough. By default we want dollars to buy ourselves coca-cola and american jeans. That's how everyone was in kindergarten, and maybe <10% will attempt self-modification after they grow up. That's not enough for a system to work.

First off, you are right about the "90%". The breakdown is that ~90% of that 90% are the uncommitted "confused by confusion" folks. who have neither committed to trying to be virtuous, or have committed themselves to selfish evil, which account for less than 10% of that original 90%. The uncommitted (~80%) vacillate from virtue to vice in their actions depending on how their day is going; ultimately, overall, they end up acting out of selfishness, as that is our default baseline state, which is a result of our body's mammalian heritage, with its packs and squablles for power and pleasure.

Still, the odds what they are, with the negative momentum of the selfish, by either their ebbs and flows, or by their deliberate selfishness, we must become good within ourselves for our own peace and happiness and for the ripple effects our goodness will have on those around us. It does not matter that those ripples will likely not progress very far out into the populace, because we need to do it for our own peace and happiness; that is why the universe's sublime Law of Karma exists (only for we humans with our free will, conscience, and mind) to give us internal feedback as to how our treatment of others affects their happiness, positively or negatively. That is why regime dictators are never happy or peaceful, as the unhappiness of the countless folks they have oppressed comes back into their being as a force of unhappiness. Stalin may have died in his sleep, but he was NOT happy.

The most important thing to understand is that, as evidenced by our knowing of but not in-any-way understanding Dark Matter and Energy, we live in a universe we don't understand very well yet. Our souls, minds, and free wills, are parts of our multi-dimensional selves that have no direct observability in this physical world -- we can only see some bits of their effects, and only if we are very open-minded and observant. So, when I talk about self-transformation, you must understand that our soul ("energy/astral body" that we dream with and resides within our physical body's 3-space while we are conscious) is what the spiritual path evolves/changes from vice-eousness to virtue-ousness, from selfishness to selflessness, from callous disregard to compassionate, caring service.

The spiritual self-evolution of human morality happens on that plane, not in our physical body. Yeah, that's quite a leap from where common human understanding currently is, at this point in history, but the destructively selfish ignorance is so deep and pervasive in nearly every culture on Earth that an open-hearted person should wonder how deep this willful ignorance goes, and what is its source. Read my other comments to find the explanation, if you are bold enough, that is.

Peace be with you. You are loved.

My humble experience is different. There is no surer way to create shitty, incoherent code, flaky tests, architecture mistakes, and Rube Goldberg machines, than when trying to satisfy various people in your org.

Junior stays a junior in my book until they learn to "satisfy code" or to bring elegance instead of primarily satisfying specific people.

If Henry Ford was listening to customers, he would start breeding a faster horse. That perfectly shows that ego can have a good side.

Re ego, I think maybe the vocabulary choice is misaligned here. Anyway, these days, "team player" is becoming a sarcastic innuendo.

A read that book a couple years ago and thought it wasn’t very good, probably the worst of the “classic” 20th century texts. The Psychology of engineering is underrated though and someone should really write a new book on it.

What I have been thinking a lot about lately is that the focus should not be on the work. The focus should be on the handoff. If you build something, the goal is to have someone else use it. The work should focus on easing that transition. If it's a technology, what do you need to characterize so that the product people can work with it? If it's a product, how do you make it easy for your customers to get it? If it's an internal tool, what context and familiarity does the user group have?

It's also terribly ill-defined.

> It is all well and good to advocate egoless programming, but the fact of the matter is that human ego is a very natural thing, and it is difficult to find people who can—or even should—divorce their ego from their work.

Ironically, it's the "egoless" crowd which tends to be ego-obsessed and solipsistic. They imagine an egoless world which simply requires that everyone thinks just like me; in effect, everyone shares the same "ego"/perspective. Only in this bizarre fantasy world can we move past the ego and focus on "objective reality". Ayn Rand is an example of this worldview.

Claiming that the "egoless" crowd is egotistic, because "they want everyone to think like them" is like claiming the "tolerance" crowd is intolerant, because "they don't tolerate intolerance".

In my experience, It's both non-factual (ego-less people are the first to learn from others when poised with new ideas) and short-sighted.

There's a manifest difference between people who are naturally humble+curious, and people who are idealistically seeking an "egoless" environment. The latter is what I am referring to.

Now that you mention it, there are parallels with the "tolerance" ideologues. There are people who are naturally patient and empathetic, and then there are people who opportunistically pursue the in-vogue virtue of "tolerance", and end up practicing de facto intolerance in the process. Don't conflate the two.

I can agree that there's people who preach tolerance but don't actually seem to mean it, yeah. Have yet to see egotistical egoless-ness, but I'd suppose it'd just look like empty speech in a smilier fashion.

How predictable the ego's self-defensive reactions are. Merely encountering the suggestion that the ego is a necessary servant but a terrible master and it yelps "I'm not an egotist, you're the egotist!"

There's a complex of these passengers you can't discuss because it wakes them up and they reflexively defend themselves. They wrap themselves around your sense of truth and it's impossible to get them out.

Sleep tight. :)

We each have the free will to choose willful ignorance over humble learning.

You are correct, we can't "get them out"; only they can do that by exercising their free will to choose to become better human beings. We can, however, attempt to teach them with our positive ideals, attitudes, and behaviors, but we can only lead the horses' asses to water, not make them drink.

Note that we must remain humble and grateful in remembrance that we ALL used to be horses' asses, once upon a time, before we entered the Path of Love.

Which character is this referring to?

Ego loss comes from experience, age. Hopefully.

It is always our choice, each of us. If we want to become better, we can be, and will, if we ask for the right kind of help. If we don't give a sh_t, we will just continue being a selfish ahole. And remember that a person's religiosity has no bearing on this outcome; the truth resides in our heart's intentions and our ideals, attitudes, and behaviors towards others, where the rubber hits the road.

If our heart is aimed right, we can take advantage of religious practices to level-up, but with a callous or cruel or hateful heart, no amount of religious practices is going to do anything but cement our horrible behavior. This is because we each have the choice of how and why to behave one way or another.

The love one feels in one's heart is of little consequence if there is no selfless action in service to the loved person's happiness. It all adds up, as do all the petty callous treatments of the people in out-groups we don't give a sh_t about. And we should care about everyone; that is the way of compassion.

Kiva'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 will inevitably wander back to gatekeeping, control, and conflict. Much as in the world at large.

I was listening to Andrew Kelley (of Zig fame) in a podcast the other day. He talked about the fact that, because the zig foundation is a bunch of empowered experts, he doesn't really need to manage work because people following their own idea of good software leads to really great work. Having the psychological safety of "being trusted to do what you think is right" is critical.

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.

Chapters 4 and 5 of "Crucial Conversations" were an enlightenment for me, as full of cringe as it is.

Their hypothesis (intuitive, no science there) is that fear has second side beyond passiveness, wall-building and procrastination.

Fight or flight: people attack mostly out of fear. People micro-manage employees mostly out of fear. At work you don't think much about this aspect, as boss is simply a "jerk". (Bad mouthing, yet another way to deal with fear.)

Yeah you are right about this, psychological safety is a key ingredient in what “good” looks like. Blameless culture stuff is a bit of another ball of wax, so I didn’t get into it too much.

Years and years ago I helped someone with a remote team (quite a while before remote was common) try to get his team to be more productive.

We'd sit and chat about the state of things, ups and downs since we last spoke, and try to figure out strategies to improve process and get things working more smoothly. For a few months virtually nothing changed despite all kinds of small efforts scattered around.

He was dealing with pretty insane stuff. Clearly competent developers were letting PRs languish for weeks. They weren't producing code to their own standards consistently. Designers were dumping deliverables last minute with no documentation or guidance for implementation. Just assets, hurriedly put together, with some palpable hope that they'd just get used and everyone would carry on without their involvement. There was no collaboration, very low communication, and hardly any cohesion across teams.

After a few months I came to realize that everyone was struggling in their role in some way or another, afraid to admit it, and unsure of how to catch up and keep up. Expectations of them were remarkably low, but no matter who fell behind they would eventually begin this oscillation between scrambling and vanishing.

I recommended that he let everyone know it's okay. We all fall behind, we've all got life going on, and having no deliverables happens. I suggested that the messaging would need to be sincere, clear, and personal in order for everyone to really believe that it was okay that they weren't performing well. After a week or so of figuring out how he wanted to address everyone about it, he did it over a group call and was a total human being about it, describing his own struggles, challenges with staying on task, his inability to program "well" due to his lack of training, and so on. It was great, and very sincere. He made it clear that he knew what was happening, but he wasn't upset and he wasn't pointing fingers.

The results were like night and day, though not immediate. Everyone gradually started explaining where they were. Maybe they had kid stuff in the way, got stuck getting a test to pass, didn't understand the problem well enough, no sleep, sick, etc. PRs got reviewed more often because there was less shame around letting them sit at all. Everything generally got better. Not perfect, but workable.

At the time that I recommended he do that, I felt a little bit insane. Like, what if this just permits everyone to be even worse? What if it comes off like it's a trap, and everyone gets even more paranoid and insecure? Am I just imagining everyone wants this because it's what I've wanted in the past?

Since then I consider it one of the most essential components of functioning teams. People can still be high performers in unsafe roles, but the team as a whole suffers for it, then the company does as well. Especially the company, over time.

The success of any organization depends upon each member behaving selflessly to meet the needs of the group. Selfishness in any organization is a parasitic drain on energy and productivity.

Embracing compassion for all those who drift into our orbit is the only way to improve oneself in all dimensions. Compassion is the common factor in virtue, and the cure for selfishness.

It is also the measure of every person, so once you begin orienting yourself in the moral compass' proper direction, you can begin to see how others are aligned or misaligned. Such selfish folks are those who just don't give a damn to become a better person, which would result in lessening the amount of hurt they inflict on others. Treat such people as well as you can, but be wary of their nature.

Unfortunately, very few human beings really give a damn about anyone not in their in-group. Such is our baseline mammalian heritage, which we must each overcome with deliberate spiritual self-evolution.

"The Way goes in." --Rumi

> The success of any organization depends upon each member behaving selflessly to meet the needs of the group.

This is false. A well-designed system will align individual self-interest with what's beneficial collectively.

> Embracing compassion for all those who drift into our orbit is the only way to improve oneself in all dimensions.

What does compassion look like towards someone who's trying to mug me?

> It is also the measure of every person, so once you begin orienting yourself in the moral compass' proper direction, you can begin to see how others are aligned or misaligned.

I do not subscribe to your religion.

Feeling positively towards others, and acting beneficially to others, are not the same thing.

> A well-designed system will align individual self-interest with what's beneficial collectively.

A well-evolved human being will fit into the team in the optimal way, so long as the team is constructed by a well-evolved human being, who will do what you suggest without interference from their ego.

> What does compassion look like towards someone who's trying to mug me?

To beat the everliving sh_t out of them to keep them from earning more negative karma in the future, while earning positive karma from helping protect other innocents. Remember, letting the oppressors run rampant is not helping anyone, so you can earn good karma by selflessly preventing. And God does not want innocents harmed, so protecting yourself (and other innocents) is God's Will.

> Feeling positively towards others, and acting beneficially to others, are not the same thing.

You're right, the feeling of love is of little importance if one does nothing to benefit them. The key is action, not warm fuzzies.

> I do not subscribe to your religion.

That's your right, just as it is mine to love you anyway and try to educate you out of your ignorance. If you don't want me to, then I'll not bother you, but this is a public forum, so we can post so long as we remain within the guidelines.

That said, I'm not advertising for any specific religion, but to the core of all of God's religions, because they each have compassion at their core, or they have gone horribly astray. You must find your own path within the umbrella of God's Loving self-evolution. Seek and ye shall find what is perfect for you.

When you tire of your unhappiness, you can pray that God help you out of your ignorance and guide you to a suitable teacher. You don't have to do anything like that in your life, just like you don't have to wear clothes at the mall or drive on the correct side of the road. I do suggest, however, that you do what's best for both you and others, for you and those around you will be happier that way.

This is how human life works: you don't have to follow the guidelines, but there's hell to pay if you're an ahole about it. Imagine a world where compassion for all those around us was the norm, instead of this idiotic, wasteful, strifeful competition that is spoiling the Earth and causing so much misery.

> Such is our baseline mammalian heritage, which we must each overcome with deliberate spiritual self-evolution.

Personally I don't see it through such an individualist lens— I think this is a collective issue that can't possibly rely on an individual's "spiritual awakening".

As such, I think the bigger issue is that (in some cultures more and some less) people are actively encouraged to compete and feed their ego. At a societal level, for example, it'd be easy to blame schools or parents for this kind of education, but I think they're just doing what makes sense in their economic environment. If the world is winner-takes-all, I can't blame parents for wanting their kids to be "winners", lest they are left with nothing instead.

Going back to the post and the way this played out at the company— it was upper-management with the wide impact their decision-making has on organization as a whole, its rules and procedures, that led the change. It wasn't individuals each individually overcoming their own egos that led the change here. Once the precedent is set up-top, and the policies are changed, the rest could follow. It was top down and systematic.

Well, the higher-ups (in all organizations) do, indeed, have a greater cultural influence on the group's ideals, attitudes, and behaviors. The especially problematic aspect of this is that we often reward the least compassionate with greater responsibility. That is backward thinking from backward-facing people.

If a person wants more power so they can enjoy such "fruits" (more money, control over other people, more pleasures, ...), then they will support people who exemplify those negative characteristics. Believe me when I say that despots don't gain power without significant support from other low-virue folks. That is really the story of human history.

But, no, it is each person's personal responsibility to seek and attain some measure of spiritual growth, with humility, honesty, perseverance, and study. Just like a CEO with bad personality traits will cause negative downstream effects, any individual with those traits will poison the teams they work on or whose work they affect.

As to competition among humans, that is just our common delusion, whereby we are fearfully convinced that we are merely mammals competing for scarce resources, instead of human beings who are capable of cooperation, generosity, compassion, and selfless service for the benefit of the whole, including future generations.

What we are witnessing across the Earth's societies is nothing less than the apotheosis of the masses' majorities exercising their free will to choose ignorance over wisdom in how we treat each other and what we will allow our organizations (such as corps and govts) to produce. A human life committed to selfish competition against other groups is a life wasted on mammalian idiocy, and always results in degradation of the whole.

Why are we not all humanitarians? Because most people reject our highest possible ideals, attitudes, and behaviors. Their reasons are numerous, but none hold any weight, for none will bring them peace and happiness, because only by making other people happy can we be happy. And we can only make other people happy by giving of our selves selflessly and compassionately.

> What we are witnessing across the Earth's societies is nothing less than the apotheosis of the masses' majorities exercising their free will to choose ignorance over wisdom

There is a mismatch between your observations about humans as a whole, and the appeal to individuals and their individual values.

I am all for individual ethics, but half the people on the planet could have great ethics, and things could still devolve.

The way to scalable net-positive gains starts with oneself, but also requires finding ways to pull others into net-positive arrangements, in a way that generates value back to you. Then repeat on larger scales.

If a fraction of the planet worked hard from that standpoint, things would improve markedly. Even a lot of failures and a few successes would make a lot of positive difference.

Applying game theory, psychology and local conditions toward scaling up positive sum games, is another form of engineering.

Perhaps the highest form.

There is no mismatch, friend. "Pulling others in", as you put it, requires two ends of the leveling-up: first, the initiate explains how to begin the self-evolution, and second, the newcomer accepts the challenge and begins their own path to self-evolution.

For those who invite, we are to do so with loving kindness, because the result is wholly dependent upon the receiver opening and then walking through the door we present. There is no compulsion in religion, and we must understand and remember that it is everyone's choice, and we cannot be negative about their declination. No badgering, no negativity whatsoever, period. We are to keep being kind with the hope that they will catch on eventually, as the events of their lives surface the negativity that they, themselves, have sown into the world via their willful ignorance. Perhaps they will reach a point where they've had enough of ignorance and are willing to give the Path of Love a try.

And this is no game, though systems theory is the proper model of our situation, where there in an intrinsic gravity we each face to the idea of overcoming our intrinsic negative traits (the vices of the heart/mind). Now, construct the model with cooperating verses competing individuals in the population, positive contributors verses negative contributors. Of course, you already correctly intuit the fact that the more of us that viewed our aggregate impact upon the Earth (and each other) this way (that we can actually change things by being a part of the positive force), things could improve quite rapidly. The fact is that we are moving in such a diametrically opposite direction to cooperative compassion that we are literally destroying the Earth for our future generations.

And it is our choice, each of us, individually, but with billions of us aggregating into a miserable mass of selfish f_cks who are causing unnecessary strife, unhappiness, and destruction via our willful ignorance of what is possible for us both individually and collectively.

Thanks for the rebuttle.

You are right, I stand corrected - I think both approaches make sense for spreading change.

Yours on an every day basis, the viewpoint I gave requires opportunity, but matters too.

The thing with game theory, is it’s the right way to think of social structures that scale.

I think a lot of people’s behavior responds strongly to their incentives. All those people you (and I) are cynical about.

And ethics really are the positive sum “games”. Keeping one’s word, safety nets, helping our neighbors, win-win transactions and relationships - we adopt them as individuals for the immediate good it does, for us and who we interact with. And knowing if everyone did that we would all be better off. Even the self-isolating rich since society as a whole would run better.

Bottom up or top down encouragement are both with it.

Well said, my friend. Thank you very much.

Yes, changing incentives is the easiest way to provide a proper carrot to help people choose a better way.

And let's not forget that disincentivizing our leaders from being corrupt bastards is the proper use of the stick as well.

I joined my current company to work on Growth. I was added to Gitlab, and for the first 3 months I pushed all my commits as MRs that my manager reviewed and merged into main. Standard procedure.

One day I needed to get a hotfix out to prod STAT. I pinged my manager to accept the MR and explained all the testing I've done. He said I could just accept it myself if I wanted it up now.

Turns out I've had the permission to push to prod since day one. The only red tape I had to cross was my own confidence.

Definitely agree that domain experts are preferable to domain owners, and that overly explicit specialization causes problems, but at the same time I think it's quite possible to stray too far in this direction too, and that the author didn't really address that.

The problem is not just that the Designer might Break the Build or ship something broken one time (but know how to fix it). The problem is that stuff can (obviously, not in all cases, and not something you should just assume will happen without good evidence/reasoning) start breaking all the time because you have too many people changing things that interact with other things they only partially understand. Or it's that one team/"domain" ends up downstream or dependent on another, and locally optimal but globally suboptimal decisions made upstream (eg a bad but quick to implement data model, or adding more dependencies on something you're in the process of getting rid of) cause problems downstream. In these situations your "egoless domain experts" might actually need the authority to force these things to stop, or might get burnt out spending all their time firefighting or playing hero.

There are also some kinds of engineering mistakes that are literally business-killing, like major security breaches/data loss. Mandatory code review isn't a "feel-bad program", it's precisely to guard against disasters like this (also I'm pretty sure it's literally required by SOX/SOC2 and I'd certainly want my software vendors to implement this).

That's why I think this is actually a balancing exercise that is highly case dependent, not something you can merely say "just empower people we're all on the same team". If your team is highly skilled, conscientious, and motivated you can give people a lot of autonomy - if they're mostly unskilled and don't give a fuck about the quality of their work, you can't give them much autonomy. If the scope of what you're working on is huge (so huge that any one person can only have a working understanding of a small part of the whole) you probably do need more process and guardails in place than a smaller project.

> In these situations your "egoless domain experts" might actually need the authority to force these things to stop, or might get burnt out spending all their time firefighting or playing hero.

The broader approach here is to encourage frameworks where changes must go through policy-as-code frameworks. SMEs write policy that is then enforced (or just warned, for some period ahead of enforcement) by the policy framework. Policies can encode exceptions, but changes to policy (i.e. to add exceptions) require SME review. The benefit is - stuff that passes policy doesn't require explicit review, so in the normative case autonomous teams are not slowed down, and when they are (due to policy failure), then it is for Good Reasons.

> Mandatory code review isn't a "feel-bad program", it's precisely to guard against disasters like this (also I'm pretty sure it's literally required by SOX/SOC2 and I'd certainly want my software vendors to implement this).

High-trust environments trust engineers to understand the difference between "this is a serious change so I need someone to review it" and "I'm just fixing a typo here so I'm going to rubber-stamp it." But yes, SOC2 requires mandatory code review, tickets, the lot. Yes, it slows things down, but that is the price you pay to become a Serious Enterprise Vendor. No, it doesn't fundamentally erode high-trust culture. People can just mark their MRs as "I need a rubber stamp" and find someone else to rubber-stamp them.

If you care about the experience of your co-workers, you won't repeatedly break stuff. (Or if you do, it's because your tooling hasn't scaled enough to keep up; you need a staging area or precommit hooks or whatever.) If you know you're trusted to do your job, you will work to maintain that trust.

But things need to be architected for trust. If you have lots of rigid processes, then there's no use for manually executed tools that will only be used if someone decides to use them. People will lean on the process, and every time something goes wrong, the process will be "improved" (as in, catch one more potential issue, at the cost of taking longer and catching two more non-issues and making people batch up their changes more, causing more conflicts, etc.) In a high-trust environment, people will use the manual tools when appropriate, and so there's incentive for architecting things such that the results of those tools and processes is useful. Tests are more likely to test real things. Staging environments will be made to better reflect prod.

If people care about it, they'll make it work. If they don't, they'll make it "work".

But yes, I agree that as you scale up, more and more things will get missed and you'll need to balance things out. It's just so, so common to go too far in the rigid low-trust direction.

People are so terrified that something might go wrong that they'll do things that end up making sure that something will go wrong. It'll be something later, or somebody else's problem, or whatever.

Yeah you really can't go this hands-off on deployments when the stakes are high. If someone could be physically harmed by bad code, then it all needs to be reviewed. If you can be hacked by a rouge deployment, then it all needs to be reviewed.

And more generally, it is not fun using a lot of mainstream software these days because it is a buggy mess, and I believe a lot of that dysfunction is partially related to the low standards for correctness that development teams have.

Ok, 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 are just there for a paycheck and to divert any possible responsibility away from themselves…

First time: teach them the right way to do that

Second time: you did it again, did you forget the right way?

Third time: we've talked about this before, what's the deal? If this keeps happening, we're going to have to reconsider your employment here as a web developer

Fourth time: last warning

Fifth time: bye

Good people don't do this sort of thing repeatedly. If your organization refuses to get rid of people like that, you shouldn't stay at that place either.

I see that you gave the person 5 warnings - I feel 3 times is less and this is exactly what I would do. Its so much better to give people more chances rather than less and then letting them go instead of letting an ego or something similar come in detween earlier.

Please do not take number 5 so literally. It's the process that matters. You do 2, 3, 4, 5, 6, 7, 8, 9 or 10 chances whatever suits your needs. The actual point is you don't fire people on the first mistake unless you're an asshole.

I guess you need to put automation in-place that interrupts these people when they're trying to deploy something broken. Tests, linters, static analysis etc.

If it's clear someone is not acting in good faith, I can think of three options:

1. Find out why and try to fix it

2. Fire them

3. Embrace the low-trust environment by trying to mitigate the dysfunction with layers of bureaucracy

Strategy 3 seems quite popular, and to be fair it might be the only one that scales.

There must be a point in which they can be fired, unless there some nepotism going on.

If so, then it's already pretty messed up.

you fire them

That takes months or years if it's possible at all (at least in many places). For any place where you can neither fire bad devs nor find very good ones to replace them with, the trick is to make good processes and products using mediocre people. And that's hard. But that's also why a lot of processes appear, that would seem unnecessary to someone who is a good engineer and used to working only with good engineers.

You fire them anyway. The problem isn't incompetence. It's the inability to self reflect and see your own mistakes as mistakes that is missing.

This is great! The best teams I've worked on have worked towards the following:

Pizza teams that own the whole stack, and for the roles that don't need a full-time individual, specialists that come in and advise but also make it possible to DIY the things they do.

The best examples of specialists are Designers and Security teams as this talk highlights. They can make the tools and the means for other teams to self-service those needs. For example, security teams implementing CI tools and designers building design frameworks that are easy to apply. Conversely, they can feel free to make changes themselves and are empowered to at the best organizations.

Everyone else in product development is a generalist, including the managers, and everyone is on-call. When everyone is on-call then it results in far fewer alerts going off because when there is an issue, it's taken very seriously and remediated quickly in the following days & weeks.

I think GTM teams could also benefit from this same kind of process, but instead melding Marketing, Sales and Support roles and responsibilities.

My theory on why this wasn't more common in the past was that the work was too complex and specialized and that the tools and knowledge to do the job weren't as easy to acquire as it is today. LLMs have certainly leveled the playing field immensely in this area and I'm truly excited to see the future of work myself.

Part of me wants to say that it's best to work in a 'low-ego' environment as opposed to a 'high-ego' one - or to avoid working with people who have 'huge egos'... but I honesty find any discussion about 'egos' relatively devoid of meaning. As someone else said, it's difficult to find people who work without ego (whatever working without ego would mean). Most of my professional experience is as a working musician, and it goes without saying that artists have egos, in the sense that they try to bring something from their inner selves to the outer world, and that they invest a lot of effort in learning how to do so properly. Sometimes I've felt that the best musicians I've worked with were "low ego" but this could be just that they are supremely confident and also not lacking in affirmation from their audiences - and if they are kind, from their fellow musicians. The worst people I've worked with are talented people who can't seem to find the affirmation they crave, but feel they deserve. They feel constantly slighted and left behind. As a band leader, I realized I simply have to stroke these people's egos - no matter how confident, skilled, or amazing some people seem they are riddled with self doubt and absolutely need outside affirmation. I used to fight it, but eventually learned it was my job as a manager of sorts to do so...

I find "ego" to be really interesting — on the one hand you want high-ego: confidence to try things, strong sense of mission — and on the other hand you want low-ego: selfless giving, able to let go of ideas that aren't working. Are those egos the same thing? I really don't know.

The part about intentional team values is very good:

• Digs ditches. Nobody is too good for any task. • Returns shopping carts (even if nobody's watching). We leave things better than we found them.

It's amazing how most teams don't set norms/values at all!

Western society (or at least USA society) seems to me to foster the idea of "not my responsibility". My example would be, going to a fast food place and not cleaning your table even though there are trashcans and places to put your tray. Spilling something and not even attempting to clean up after yourself.

Unions have this in spades. "My job is X, I don't do Y, in fact I'm not allowed to do Y as that takes a job away from whoever is supposed to do Y"

I am from an eastern society, So my first day in western society I saw a blue collar worker clean up his food crumbs on a REWE deli table. This might seem normal to do for you, but I swear I never seen anything like that in my life in the eastern society. I was 27 this had profound impact on me than reading any book, I still remember it after a decade.

Huh? US society doesn't foster that. Sounds like you just live in a crappy area or a rich super entitled one. I've never lived in an area where people just left their fast food mess or just left spills. It's never been an attitude fostered anywhere I've lived. To be fair I mainly had experience with the midwest/western USA, maybe the east coast is different.

Maybe some things feel more prevalent. I'd say this is largely confirmation and/or sampling bias. Nobody knows without actually doing the sociology that there are these tendencies. To the extent that we have anecdata, we don't know how much more prevalent such tendencies are. The USA is a big AF place, 400 some million people.

there's definitely a "it's not my job to _____, why would I do someone else's job for them" attitude I've noticed from some people, though I couldn't say what traits they share so as to identify a subgroup.

If there's a country that doesn't speed and litter please get me a visa so I can go home

Japan, although both of these are taken to the opposite extreme.

Japan (only 80% serious here)

Go to the countryside and be amazed. Exactly why people litter to that extend 20km from civilization escapes me.

But yeah, most people just bring their trash home.

For those interested, Visas are really easy to obtain as long as someone is willing to hire you.

How is the work culture in Japan these days? Is it possible to find a company that doesn't have their peculiar (read "awful") work culture?

If they’re willing to hire you when you’re overseas they are generally reasonable. Or trying to exploit cheap labor, but then it’ll be abundantly clear and you can just say no.

Incidentally I noticed in India most fast food shops have enough spare workers to clean tables for you. So you don't have to clean your own table.

I've encountered people who sincerely dislike talk of "values", and I think it's because they have seen them used as a flog rather than an inspiration. My guess is that there was a leader in their past who set values but didn't actually follow them. "We dig ditches" means "everybody but me digs ditches". It's hard to be both technically and morally capable, but I think that's what leadership requires.

So an approach might be to set only the values you can actually follow through on, and be clear when a value is aspirational. If you really do dig ditches (perhaps metaphorically, maybe by fixing deployment script bugs or something), then you can use it as a value.

To be clear: I'm definitely in favor of team values. Is there a way to make them achievable, but also grow them over time as you get better at them?

I'm sincerely skeptical of values. "Customers first", except when we are making money off of them. It's in part observing the actual action, and not just the talk. It's funny how guidelines becomes the rubric for a performance review, yet you are promoted or fired for completely different reasons. Too often the values are whatever the hell the management wants to interpret them to be, whenever.

It's perhaps a difference of "We dig ditches", vs "the manager dug a ditch last week, the prior week, and this week we are digging these ditches together." All that can change, but the tract record and the habits speak more than just a motto on the wall.

This works both ways or it doesn't at all.

You want selfless devotion to the goal then you damn well better not be wasting my time and cutting costs at the expense of my productivity.

Managers who don't know what they're talking about and insist they do and insist they are right causing massive lost time, then want to hold meeting after meeting about how it is everyone else's fault. You've seen it. Why am I working long hours doing work, some of which is shovelling sand that need shovelling because I'm not too good for it when if that idiot had been restrained to their level of competence we'd already have delivered and I'd see more of my family. Selfless devotion? To what?

In the old days when SSDs were 'expensive' and companies economised and didn't immediately buy them for the team because my time isn't worth saving but they want me to stay back to get more done for a deadline? Selfless devotion to a goal you're showing clearly you don't care about.

This stuff is really normal. You have stories, everyone does. And so we take the path that is best for ourselves and those we like. Any other choice isn't "egoless" it's insane.

Managing a team is hard. Keeping idiots from having idiotic influence is hard. Spotting who is managing up is hard. Noticing, supporting and retaining who is good is hard.

Having someone with a massive ego who you might cross the road to avoid having to socially interact with other than they do a decent job of that hard managing might work out better than "Egoless."

Sports metaphors are a bit unpopular in tech, but the teams that win championships in sports have exactly the same dynamics as a good business team and we should be taking a lot more from that school of thought.

What are those dynamics specifically? How often do winning teams actually share those dynamics? Which dynamics are more important? Which dynamics are required but not necessary to win (ie: which dynamics are required to not fail, but not sufficient to win?)

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.

"They get up to building entire GraphQL monstrosities to avoid talking to each other."

I feel seen

The weird balancing of plates I have seen developers do to not talk to each other amazes me. I often have to remind frontend that we are on the same team as backend and we own the technology: if we need an api to behave differently, let's make that happen, not code around it. Similarly, I have to tell the backend team that the things they find frustrating can be automated, processes can be changed, and we can talk with ops and platform teams to come up with solutions instead of coding around it.

Yes, but when you do manage to get people to "say what they mean" I had the following response from a frontend bloke (me being on the "backend" side, even though I never refused to work on frontend per se): "I don't like you and I don't like your stack, I want to make decisions regarding frontend without consulting with anyone, I want to get promoted for running a team which overcomes any hindrances related to either how the product actually works or that human collaboration requires communication."

It is not about "nog being able to collaborate" - it is about refusing to do so.

On the other hand, people can't possibly talk to each other if they are always in a meeting.

I really liked the part about engineering committing to force multiplication of the other parts of the business. Once in a senior data engineering role I took it upon myself to just teach the PMs SQL and let them start running their own analyses, with regular weekly 1:1s and office hours. It totally wasn't my job but it saved me twice the hours I normally spent responding to their ad hoc requests, allowed some wild hairs to turn into actual profitable products, and hopefully stimulated some professional development.

Most of the issue exemplified in the article arise due to a lack of domain expertise, not ego. Parochialism, maybe, as it relates to lack of expertise. We fear what we do not understand, which translates into domain ownership and controls over guardrails.

The productivity of every single team that I've been apart of, that shipped fast, was enabled through permission, by highly experienced domain experts who knew how to build guardrails instead of controls. Canary releases, monitoring and rollbacks, not release managers. Automated testing, not codeowners.

Controls prohibit actors from doing certain things. Outside of regulated environments, they should only exist at the perimeter of your business, interfering in the nefarious activities of malicious external actors.

Guardrails on the other hand, guide actors in the right direction. Well installed guardrails can see your legal team pushing changes to your API schemas.

Those guardrails however take real expertise to install.

Was an interesting discussion, but lost me with the sort of pointless Musk bashing near the end.

I remember back in the late 90's and early 2000's it was similarly cool to bash anything related to Microsoft.

I spent a good bit of time writing a lengthy comment on slashdot about "Why to code". It was fairly poignant and well-received, except at the end of it I took a low effort pot-shot at Microsoft - because it was cool to do at the time.

Someone replied and (rightly) called me out on it. Why muddle an otherwise interesting talk / piece with a cheap, drive-by swipe?

That was nearly twenty years ago, but let's call this comment me paying it back (if the author reads HN).

The bashing wasn't quite pointless. Musk is an example of the exact management style that is the opposite of what is being advocated for in the article. Musk is notorious for being an asshole to his employees.

That you got so distracted by the bashing that you lost sight of the whole point of what you are reading, speaks a bit I think to a defensive reaction and bias on your part. Objectively, people can think of Musk as an asshole, he does have a reputation for a certain management style, and this article is about how that management style is on the wrong side of the fence compared to what they are advocating. The article starts off with a big description of a dysfunctional organization, a variety of CEOs/CTOs run organizations that are hallmarks of that type of dysfuntion - Musk is a very prominent example of that (love him or hate him). Some people rave about the idea of working for Steve Jobs; these are exceptions - survivorship bias. The point of the article is that it is survivor bias, that typically you get dysfunctional organizations instead. So, don't try to emulate these notable and notorious exceptions - it usually doesn't work out well.

Microsoft was doing all sorts of immoral anti-competitive stuff, and trying to strife free and open source movements to protect their monopoly. They deserved the hate. They came around and complaining about them mostly stopped.

The fact that they so readily call Musk as being "narcissistic" (or "asshole" or "cult leader") reveals the rather dark nature of these "egoless" souls.

It is good to evaluate people on their actions rather than what they claim to be. We saw a good example of this in the Elm community[^1].

---

[^1]:

From https://lukeplant.me.uk/blog/posts/why-im-leaving-elm/

> The leadership style in Elm is extremely aggressive and authoritarian.

> By that I do not mean impolite or rude. It is almost always very civil. But still ultimately aggressive and controlling.

...

> The team [at NoRedInk] shows a bewildering mix of cargo-cult inclusiveness coupled with inability to consider that anyone could be different from them in any way that matters.

From https://news.ycombinator.com/item?id=34746161

>> the core team has that "happy cult" vibe where they think that if they're (passive-aggressively) polite enough, they don't have to worry about anyone's opinion outside their insular little group.

> "Happy cult" vibe is exactly how describe that faux-niceness they throw around.

Where was the Musk bashing? I didn't see that in the slides.

I had to look pretty hard to find the Musk bashing - there's a (face redacted) photo of Musk carrying his sink around on the slide about narcissistic personality disorder.

The slide that has an iconic, well known photo of Musk, where his face is scratched out and "screw this dumbass" is written on top is pretty easy to find.

"Redacted" is a very polite way of describing what the author did.

Part of me wants to say "Using a picture of Taylor Swift when talking about successful recording artists wouldn't make anyone bat an eyelid. This was a discussion about narcissistic personality disorder..."

I honestly did not notice the Musk bashing, but yeah, now that you mention it, I agree.

Still 1 bad paragraph (or picture in this case) does not nullify 99 good ones.

> So that was a high-level overview of how all struggling companies are unique. But they’re also all the same.

Reminds me of Tolstoy's “Happy families are all alike; every unhappy family is unhappy in its own way.”

Kind of tangential, but:

> Then one day, our designer broke the build in the middle of the night. Everyone came in the next day and couldn’t work until they figured out what had happened.

I've heard this [campfire?] story before. A bad commit happens and now no one can do any work. And I don't understand... Is it really that big of a deal to have to revert to an older commit or comment out the broken code until it gets resolved? Sure, I can see it being annoying, but not bringing an entire group of developers to a standstill. What am I missing?

Stateless code makes for boring programs, but stateful code can be difficult to roll back.

As a toy example, imagine a database with columns for `first name` and `last name` and an update that combined them into a single `full name` column. That's going to be tough to revert for users signing up with just their full names.

While that would certainly impact production, it would be a bit strange for development environments to be stateful in the same way. Those not immediately involved in dealing with the stateful issue seemingly should be able to continue with their work away from production systems just fine.

Although in this case the build broke because the last committer didn't have authorization to deploy to production. The "fix" was giving him permission to deploy in the future. It is not clear why the developers going about their regular day wouldn't naturally resolve the broken build.

It's not a big deal usually to revert a commit. Sometimes nobody has no idea it was a commit done in some other code repo in some other distant team. It's a problem of visibility; it just turns out the cause was a commit somewhere. Figuring that out can be non-obvious.

I actually saw this happen at Google: no one could pinpoint the cause of the broken build for a while, and then it turned out to be a UX designer who broke the build. He was apologetic, like McFunley's example. But unlike the example, this guy never made another commit.

How does giving them deploy access prevent them from breaking the build, too?

This really hits

> Computer Scientists are also really bad at it

> Despite literally studying the asymptotic limits of work completion under various conditions

There are so many times that I'm looking at the workflow thinking "We know how to break this up using distributed systems knowledge, why are we doing it this crazed way"

Also, we literally invent a system that shows how our software mirrors the company we're automating (DDD) and completely miss that we're different parts of a distributed system ourselves.

I like his other two talks better than this one.

I find "this worked for me once at Etsy when we were a 20 person team" not a very convincing argument. That does not mean I think he's wrong. Just that the conclusion needs better arguments.

One argument that comes to mind is: If you treat people like children, they will start behaving like children. Treat people as adults if you want them to shoulder responsibility.

The main message of this talk is that when a designer tried to deploy a fix into production and it blew up production, they realized he had the wrong kind of permissions and their solution was to give him full deployment permissions.

Well, great if that worked for you. It might or might not work for others.

I would recommend not letting anybody deploy to production. You can deploy to staging, then tests are run, and only after those all pass can anyone deploy to production.

Also, the current process is not just the result of ego. It is also the result of evolution. We usually take steps to prevent things from happening because they have blown up in the past and we would like to not have that happen again.

Why can the tests not be ran automatically and why not let anyone deploy at anytime? Like, if super senior dev or first day intern deploy, I expect tests to run and the deployment to go out and for systems to be automatically monitored and the deployment reverted if errors pop up, and also manually revertable if a test missed something.

Absolutely, let the designer deploy. Let them have stage access first so they can play, sure. But let them not be blocked. And if they turn the site purple, consider revoking the trust. But default to trust

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

Really goes to show how the whole "I have the hardest job in the company and all y'all are just morons" attitude really needs to die.

I once had the pleasure of working with a guy who probably did have one of the hardest jobs in the company, but also had a very positive attitude towards everyone else.

He was in platform engineering, ensuring the server fleet was it top-shape etc. It wasn't over him to debug OS-level bugs. Very smart guy; if something was broken and nobody else could fix it, you went to him. He'd previously tracked product bugs down to the JVM garbage collector, or RHEL. He told me about the time he tracked a bug in a binary down to the OCaml compiler— if you read the x86 spec, it turns out OCaml wasn't using one of the registers properly and the binaries, under very specific circumstances, were technically buggy.

And on Fridays he hosted an informal get-together, open to anyone in the company, where anyone could go and chat about tech. Show something off, ask about a bug, bring up something cool found on HN— everyone was encouraged to pitch in (although often we wanted to hear him do the talking lol).

People like that are amazing, and I suspect he was that smart precisely cause he knew there was always more to learn; from the machines, and from other people.

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.

I want to go off a small tangent

> In Theory There Is No Difference Between Theory and Practice, While In Practice There Is

I for one used to believe in a cross functional team. I used to believe that everyone in a team should be able to do every task in the team. I still believe it somewhat but my ego is shattered.

I worked on one team where the lead believed in this more than I ever did. Consequently, I was doing tasks I sucked at and therefore didn't enjoy s lot more because as she said, it will help me improve.

Long story short, I didn't improve. I just got frustrated and I quit. I guess it was all fine from the leader's perspective as her team stayed the way she wanted anyway.

I went down this tangent to remind people that when things are going well, we can say a lot of things that are nice like kumbaya my lord but when things are tough is when our ideals and morals are actually put to the test.

When poop hits the fan, will leadership throw someone under the bus? Will team members feel like leadership will throw people under the bus? Kind of a difficult question that we can't answer until we are there and at that point it is too late.

I left a role because we owned it as a team, and as a lead on the team, I opted to take the shit work, so I found myself in yaml hell, configuring and tweaking configs in ever cryptic error messages. I was there to code and design efficient systems. Yaml sucked. Eventually, I left. We should have brought on someone who likes that shit.

Do you mind elaborating on the definition of "cross functional team" here? It seems either non-standard or something that may differ by industry.

Where I've worked, a cross functional team is one made up of functional experts from different groups. A team where everyone could do the work of everyone else was a team that was cross trained.

> I was doing tasks I sucked at and therefore didn't enjoy s lot more because as she said, it will help me improve.

I've been here. I find it helpful to try and automate away reoccurring dread tasks. Not everything can be automated, but most things can be.

> I for one used to believe in a cross functional team. I used to believe that everyone in a team should be able to do every task in the team.

Learning some skill requires X hours. Maintaining that skill requires Y hours/year.

Those numbers vary both by task (webdev has quite a bit of churn, where server OSes tend to have decade-long support lifecycles) and by person (not everyone learns at the same speed, and sometimes people learn different kinds of things at different speeds).

A team where anyone can do anything can work or now work, depending on how hard the things they do are, how many different things there are, and who's on the team.

"Like many of you, I was raised in the background radiation of Calivinist thought"

Sorry -- you lost me in the first sentence.

That's fair, but if it makes you at all curious to learn what he means, you night find it rings true - if not for you, certainly people you know.

https://en.m.wikipedia.org/wiki/Protestant_work_ethic

I feel like the concept of "protestant work ethic" has been coming up a lot lately. Make me wonder if this is going to be the stoicism of 2025.

I hope not. I, for one, don't view the Protestant work ethic in as positive a light as I do Stoicism.

also: "I also read Hackers & Painters at an impressionable age and was kind of a jerk about it for a while. This talk is about how despite this, I got better."

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.

Egoless engineering is such a great mindset—focusing on team goals over individual credit really makes collaboration smoother and ideas stronger. It’s amazing how much better things get when everyone’s just working toward the best solution, not personal recognition. Definitely something more teams should embrace!

I spent so much time at my last job trying to implement this with so much resistance. I felt so insane for getting resistance I ended up becoming a jerk and hated who I was. The worst part was because I was so good at what I did people started trying to protect me from getting angry. That made me even more angry and jerky. I hope I will be forgiven, I hope I can become better.

I like the idea but it’s something that must be implemented from the top.

How does something like this scale for more than 10 people? 100? 1000?

I was at Etsy after Dan left, and I think it scaled pretty well from the few hundred engineers when I joined to closer to 1000 when I left. Etsy's engineering culture had a lot of problems, but they weren't caused by empowering people. If anything, being encouraged to work cross-functionally built a lot of empathy and understanding for different roles and hats in the org, and made a lot of engineers a lot more effective.

There were some annoying parts of the ultra-permissive culture. Sometimes you'd need to literally beg people to stop YOLO-committing code into your UI component because they're not checking how it looks with your flag enabled and they're breaking your A/B test over and over and you just lost a week because you need to restart it. But we gained more than we ever lost.

fwiw, Etsy seems to have ~2.5k employees [1].

[1] https://en.wikipedia.org/wiki/Etsy

This is the problem all medium to large businesses face - red tape, faceless bureaucracy overloads the system

Every. Damned. Time.

Random comment: slide 10 talks about using Twisted and then adding a twisted middle layer. 2010 me (or earlier) liked Twisted a ton but not sure I would have foisted this technology on a development team. As a single dev doing all kinds of crazy shit it (sort of) worked but was pretty hard to debug or understand.

Twisted was aptly named. It was the only async python we used around that same time. We moved to Go. It was glorious.

Well that shows my age, I thought twisted was being used as an adjective.

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.

The section on Deriving the Equation for a Disaster is perfect.

After being acquired (~80 person startup) we were part of 1000 person org.

As the CTO of the acquired company, coming into a larger org, I was front row to this type of infighting.

Especially when the CPO wants direct ROI, and less worried about creating compound value.

Is there a video of the talk somewhere ?

I prefer recording over slides.

Unfortunately no, I've only done it as a private event within a company so far.

> I also read Hackers & Painters at an impressionable age and was kind of a jerk about it for a while.

My mom gave me Hackers & Painters when I was 13 or so, but I still haven't read it. What about it turns children into jerks?

This completely disregards the methods that brought us the most successful software ever written, which we all rely upon and which the world rely upon to function.

https://en.wikipedia.org/wiki/The_Cathedral_and_the_Bazaar

The points do "soften up" but it starts with this, at number one:

    1. Every good work of software starts by scratching a developer's personal itch.

> "We are living in the age of narcissistic personality disorder"

With a picture of the man who revolutionized EV vehicles, worldwide. Who created a company that sends rockets into spaces and then... freaking catches the booster down to the centimeter with giant chopsticks... And who created StarLink. And all this in record time.

If he considers Musk has narcissistic personality disorder then the world needs way more of those people.

How can seriously write about methodology and criticize the one person (if there's only one to pick) who has a proven track record showing he masters efficiency?

And I can tell you, for sure, a type of place where I go and see a lot of soul-crushed, egoless, people: public servants in inefficient public administrations.

It must be hard for egoless people to live in a world created by people with incredibly strong egos.

Linus and Theo de Raadt certainly comes to mind. And we all use and depend on the work of these people.

At some point when you see crap, you have to take a stand. Be it when you find crap at work or be it when you read crap online.

This is impossible without egoless software engineering managers.

OT: What is this presentation format called - slides on left, text on right ? Are there any dead simple tools to optimise making them ?

It's basically a powerpoint presentation. The slides are projected to the audience and you have a field for the presenter's notes. Any powerpoint style software should be able to do this.

In this particular case, there's a link at the bottom of the page, the guy used his own keynote-export tool to turn his Keynote presentation into a web page (Keynote is apple's powerpoint-like software):

https://github.com/mcfunley/better-keynote-export

I always check the ego at the door, but have a high threshold for persuasion if I've done due diligence.

This sounds healthy.

I find it's good to periodically examine things that you aren't persuaded by from the other person's perspective. Dig deep a little. Ask non confrontational questions to figure out where they're at and why they're there.

It usually uncovers useful understanding, even when your mind on the surface issue isn't changed.

From the title, I wanted to dislike this, but Dan McKinley drops another banger slide.

Giving people the keys to the car is both 1. how you make a happy person and 2. build systems that understand and operate with the bigger picture

There are a lot of big egos in team sports, and in high performing teams you often have a team full of big egos, although there are usually a few "team players". I wonder what coaches think about ego.

In my opinion very little of this has anything inherently to do with development, but organization science in general. All these problems exist is every org corporate or otherwise.

Why I don't hear such discussions coming out of other engineering fields? Is this type of hamletization specific to software engineering?

Unlike other engineering fields, software engineering is more similar to being a writer, and that’s another field that has big egos. The work you put out directly speaks about your personal abilities and worth.

Perhaps because you are not in tune with the goings on of other engineering fields? I don't know what the Hacker News of civil engineering is, but it is likely you will find similar discussions happening there.

I don't think engineers (especially non-managers) talk or write nearly enough about personality dynamics at the workplace.

Slides 25-26 filled me with hollow, empty laughter.

we don't have that problem where I am now, but we should teach queueing theory in middle school.

hahaha they gave the designer keys… to deploy to prod!

as a lead engineer this is something I don’t even want… as soon as you have keys to deploy to prod, guess what you’ll be asked to do? and always at the worst times!

Deliver fast! Always at the worst times.

the opposite of an egoistic programmer, is the anonymous one.

then how do you credit those who do produce results? Just put money into the anonymous one's bank account.

Those Galadriel memes had me in tears :')

I did not finish yet to read, but

"Executives are well-adapted to insisting on fundamentally contradictory goals"

Is so well worded (and also so hilariously true) that I wanted to symbolically tip my hat at the author in case they read here.

Glad that one landed, thanks!

This is pretty close to what's espoused in the Jim Collins books which are descriptive of specific companies but get turned into proscriptive nonsense by people who don't get that.

Specifically, in "Built to Last" the ability to hold two contradictory goals is praised as "Genius of the AND", as opposed to "Tyranny of the OR".

I think the discussion gets complicated but I’ll make an attempt at brevity: IMO executives/higher management must be able to juggle/balance _potentially_ contradictory goals. The issue is when they push this responsibility to rank and file employees.

I mean, these seem like good passwords at least.

[dead]

[dead]

[dead]

[flagged]

"How do we tear down parochialism and ego?"

First, by not writing rambling, pretentious, navel-gazing, ignorant powerpoints. This would be amazing if it were satire.

I don't see what you see. Would you mind what part of this seems pretentious, navel-gazing, ignorant? ( I think rambling was stated in the article :)

Literally on the second slide: "I’ve done engineering since the turn of the century, and led small teams and biggish orgs."

If that is not navel-gazing or humble bragging, what is?

I would propose to you that those might be factual statements. I don't really see any self-indulgence in stating where one is coming from when writing a post that is a critique of organizations.

It is a pretty common thing for people giving a talk to introduce themselves to give an idea of the experience on which the information that follows is built, normally at much more length.

I don't think it is uncommon for people on HN to have led small teams or biggish orgs :)

I‘m sure it‘s factual and common, but it‘s tone-deaf given the slide deck title.

The stab at Musk seems out of place. You might not like him, or his politics, but he took over and reformed a slow and bloated place, and despite all the doomsayers Twitter is still working and IMO better than before. And he has a solid track record of delivering: finance app, electric cars, rockets. Sure he over-promises and under-delivers, sometimes borderline lies, etc. but there is a huge amount of wisdom behind what he's doing, and you're doing yourself a huge disservice by just dismissing one of the most successful technical entrepreneur of our times.

He did all but the Twitter takeover prior to turning shitheel. And I wouldn't consider Twitter reformed, so much as its goals have changed.

Do we really have to do this? How can this possibly be in good faith? Like, its 2024 dude, he is literally going to hold unelected office in the US. He is unquestionably a polarizing person. I'm not saying you have to have one opinion or another, but unless you are truly living on mars right now, how can you even feel the need to make this comment? Are you not witness already to the surely GBs of text saying different variations of what you said and all the replies and all the next replies. Like it is borderline insane to me!

How can you possibly care? Do you really not feel like you have won yet? What is even at stake!?

I just dont even understand the discourse anymore. Can't yall all be like "oh he is simply genius, of course all these normies won't get it. we dont need their validation anyway!" And then maybe we can stop doing this? Please?

> despite all the doomsayers Twitter is still working and IMO better than before

a) According to Fidelity it is worth 80% less than when he purchased it.

b) Threads and Bluesky are growing at 1m users a day. Former at ~300m MAU.

c) EU is going to be throwing the book at X over a failure to manage trust/safety.

By any definition X is not doing well.

Musk aside, I personally don't think Twitter is working better than before.

On a technical level at least, there's times when it makes my phone warm up. There's random layout bugs, and things not rendering properly. At some point ads started opening on press-down, as opposed to a proper tap interaction (press-down, don't move, press-up). Now I accidentally open ads all the time.

Moreover, it's slower. Media and search specifically take longer to load. I work on web performance, so I very much noticed that suddenly one day things started loading more slowly for me. I thought it might be some temporary issue with their CDN or bad change messing up the way they schedule network calls, but it just stayed that way.

Perhaps you mean Twitter the company, in which case I don't know, maybe it's making more profit now and in that sense "works better"— but Twitter the app in my experience definitely doesn't.

Separate from Twitter the company and Twitter the app, there is Twitter the community. That is absolutely dead, rotting, and never coming back to what it once was.

And he'd be even more successful if he didn't insist on also being a complete, utter egotistical asshole. Leave whether or not you agree with his policy positions aside for a moment; it's fairly obvious that the guy is a complete shitheel of a person who's basically the dictionary definition of "brilliant asshole."

Steve Jobs seems to have poisoned the brains of whole huge swathes of people into thinking that "being an asshole to others" == "success," because it shows you're powerful enough to not have to deal with the consequences or something.

First, I have no idea if he's a "utter egotistical asshole". Never met the guy, and I assume that most people hating on him formed opinion of him by consuming heavily negatively biased sources.

However, I assume he is some type of an "asshole". And "he'd be even more successful" if he wasn't is just very wrong, IMO. From my experience the top of any organization is completely overrun by assholes. Some smart, some dumb, some more moral, some less, but generally assholes. Being an asshole is selected for in hierarchical organizations and simply required. Part of the reason why leftists dream about some socialist utopia, when attempted in practice is ruined by some asshole(s) taking over power and turning the social utopia into totalitarian distopia.

> and I assume that most people hating on him formed opinion of him by consuming heavily negatively biased sources.

You know what they say about assuming.

I won’t begrudge the guy his successes, but I formed my opinion of him based entirely on his own actions. He broadcasts every other brain fart he has, I don’t need to rely on reporting to influence my decision making when he had himself and his half baked shower thoughts inserted into my feed directly.

I’d probably agree on the asshole front but. As in it being a contributing factor in some manner to some of his upwards trajectory.

What is the wisdom, in your opinion?

Revenue and user ship are steadily decreasing according to most estimates. Glitches and outages started happening immediately. Third party apps have been exiled. Hate speech and misinformation has surged.

From the outside it seems like the ship is gradually, painfully sinking.

Lean and focused execution, quick iteration, over promise and under deliver (yes, in business it pays as much as engineers hate it), most people are actually a drag to productivity. Specifically with Twitter he drastically cut the head count and cost and all the people swearing how irreplaceable people being fired were and his Twitter is going to collapse any minute now were all wrong.

Unlike most people praising the idea of egoless I don't need to like the guy to learn from him.

> all the people swearing how ... Twitter is going to collapse any minute now were all wrong.

This I agree with you on. I was one of the people thinking that it couldn't last long, and I eat my words. It's remarkable how long a stubborn maniacal captain can keep a sinking ship above the water.

> I don't need to like the guy to learn from him.

This is the bit I don't get. Estimates put total revenue at well under $1b this year, compared with over $3b in 2023 and over $4b in 2022 [0]. Cutting the headcount would mitigate some of this, but surely not that much?

It seems likely that the daily active users are also seeing a big hit, although the company has been very guarded about this figure since Musk's takeover. Instead Musk has given platitudes about being the "number one source of news" in some countries. If the DAU was doing well I think he'd be talking about that instead.

[0] https://www.demandsage.com/twitter-statistics/

It was illustrating narcissistic personality disorder. Debating whether or not Musk delivers, or what personality traits might be behind delivering or not, is irrelevant to whether or not Musk illustrates NPD. It is easy to find examples of his behavior that matches [a layman's understanding of] NPD, so it seems fair.

Saying that Musk's personality resembles NPD doesn't say whether he is or is not effective at some tasks.

It has nothing to do with the rest of generally good article. It's just a forced personal stab at disliked public figure. Ironically quite the opposite of egoless. Your politics are a big chunk of your ego. If you can't leave them aside and when dealing with technical stuff, then it's very much egocentric. Which surprise surprise is typically the case.

good guide for allowing everyone to walk all over you

If you're a manager, you put this stuff in place in-part so that everyone understands that you will be watching for attempts to walk all over others.

Agree with you. Every successful team I've been on looked like this. Basically everyone just wanted to ship a thing. If that's the baseline norm, anyone motivated by politics or pecking order bullshit glow hot and everyone can see them.

I've seen multiple people fired on completely different teams for trying to walk over people in environments like this. It's amazing what those firings do to everyone else's morale. It skyrockets.

The message becomes clear "balance compassion for self and others and lets ship the thing, or you can leave."

If that messaging threatens someone, they've got work to do.

Work is not a zero sum game, sometimes, everyone can win.

Lots of people in the comments exemplifying why I would never want to work with them.

There is currently literally 1 comment disagreeing with some of the points in the article.

Are you saying you wouldn't want to work with anyone that agrees with the points in the article? If so, it would be interesting to hear your thoughts.

I'm saying the opposite. There are several comments that demonstrate an insecure "dog eat dog" mentality.