[throwboatyface]

My read is that he was one of those early employees that is a huge pain to manage. They want to do what they think is fun and interesting and they have strong opinions about shit that is ultimately inconsequential. It's a nightmare to manage an IC who is friends with the CEO and doesn't think you're making the right choices. But ultimately they don't accept accountability for any decisions, they just move bop around and cause problems.

One tell-tale sign is endpoint security and using his own device. It's the kind of permissive cultural thing that does not scale because of compliance issues and developer productivity overhead. But it's very hard to wrench these long-time devs away from their preferred Linux distribution which requires conditional build stuff everywhere to support. Use a work computer for work, let them monitor the updates and stuff, as long as they're not using the webcam to record you who cares?

The database backup story - my guy you were on the database team. Backing up the databases is job 1. You can't just passive-voice away "oh there were no backups". But of course he's more interested in fighting about sharding architecture than actually keeping the site running day-to-day.

His big takeaway is that Gitlab didn't spend enough time on performance for their hosted offering which was a huge money loser. Just because he thinks performance stuff is fun to do, if the hosted offering is a money pit of course they're not throwing more resources at it. You have to make an actual business case for why your thing is more important and makes money more than another project. You don't just engineer in a vacuum for the fun of it.

[returningfory2]

Your read lines up with another point in the article that I found to be stated in strangely absolute terms:

> you need to be able to deploy your code fast, i.e. within at most an hour of pushing the changes to whatever branch/tag/thing you deploy from.

This sweeps under the rug all of the potential issues with fast deploys. I guess it depends on the product. I work on a managed database service, and one category of potential bug is that we accidentally delete or corrupt customer data. We have to be much more careful and can't just deploy what was submitted to mainline in the last hour without doing significant regression and performance testing.

But anyway essentially the main reason they give for fast deploys is:

> being able to see your changes live is nice because you actually get to see and make use of your work.

I think this is true. But, it lines up with this negative interpretation of this article. The author seems to prioritize themselves over the health of the product they're working on.

[julik]

> It's a nightmare to manage an IC who is friends with the CEO and doesn't think you're making the right choices

Since I find this take harmful, let's rotate the scene: what if you have no business being in the manager's seat above that IC in the first place, and you are effectively being used as a tool by someone who is not the CEO, but, say, a newly-appointed CTO? What if you _are_ making the wrong choices? What if that IC is one of the few people in the org having the experience and the knowledge to tell you that you are? What if that IC is making the right calls and suggestions, but your implicit directive you got from the newly-appointed CTO is actually to manage that IC out "because they are such a pain for everyone"?

I have been on both ends of this situation and I do believe most scale-ups are _not_ doing a good job retaining and nurturing their early-stage staff+ ICs into their larger era. This has multiple reasons, but it does often feel like there is a lot of value to be had if just those staff+ ICs weren't so horribly mismanagemed. A hire-above-from-the-outside is prime example.

And if I sound bitter - let's just say I have experience being "that IC". It wasn't pretty, and no - I was not an asshole.

[throwboatyface]

In every startup I've been in, there was undue deference to long-time ICs. They didn't normally stir up public fights with execs but they would openly undercut line managers and then move around in the org as people tried to stop being responsible for them.

It's not really clear what you do with a staff+ long-term IC. A lot of them don't want to manage or be involved in leadership, but they want to pull down a huge salary and just do work that is frankly replaceable by a senior eng.

To be clear I do believe there are levels of IC experience above staff, but being 21 and joining a startup doesn't make you a Principal Engineer just because you hung around until you're 30. Especially if you've only worked at that one startup.

[julik]

> It's not really clear what you do with a staff+ long-term IC

Set clear expectations in the first place. "I want to run things my way here, I'm the new management and I don't like you" is not an expectation - and that's what I have observed happen all too often.

[cousin_it]

Sure, you could argue such people are needed only at the early stages of a company, and counterproductive when the company gets bigger. But I don't buy that. Why then are big companies asking all the time: "Oh, where's our internal startup spirit? How can we bring it back?" Right after firing the people who encapsulated that spirit, for being "hard to manage".

[depereo]

I think this trend to talk about startup practices in large orgs is more executive nostalgia and a complaint about all the processes put in place to catch mistakes that have been made before.

The same people as developers would be pursuing rewrites of rock-solid 20+ year mature software projects because there's a trendy framework.

Large organizations don't have 'startup spirit' because 'startup' companies fail. Employees of large mature orgs with 6000 employees didn't sign on to a company that's got a good chance of not existing next quarter. They're not taking massive risks and throwing halfbaked features into a brand new product with 1 client hoping to get bought by facebook or maybe an insurance company.

If those big companies are really complaining about not having startup spirit maybe they should provide an exit for the VCs and aquihire (briefly because the engineers will all leave asap) a startup!

[ParetoOptimal]

You make it sound as if big companies are generally really effective and its enabled by their bureaucracy.

[depereo]

Not my intention, sorry!

Big organisations are stable, mostly due to the often frustrating inertia and lack of risk taking coupled with their existing, mature revenue streams.

[julik]

Sometimes it is not even about the "startup spirit", but more like "why is it that we didn't do any projects of significance in the last year, and why is our incident rate 3x from what it was just 3 quarters ago, and why are all these migrations not finished yet?"

[SheddingPattern]

Because sometimes all they're after is for slideware on GenAI. The people they fired encapsulated a spirit of innovation that doesn't fit the operating model and therefore is of no value to them.

[Rapzid]

Such an interesting article because there are two main reasons I never thought to apply at GitLab:

* Even in the USA the col based pay made them non competitive compared to what I could get elsewhere.

* Incidents like the database backups, and others, lead me to believe they weren't executing at a high enough level.

[YorickPeterse]

I can assure you that me being a pain to manage wasn't the problem, nor was it ever brought up. In fact, the only negative/improve-upon-this-thing kind of feedback I got once or twice was to adjust my communication style to be less blunt/harsh, something I agreed with and did end up improving upon.

I can also guarantee you that the work I did very much did good work instead of "cause problems". Feel free to ask anybody that worked at GitLab during the same time (or is still there) and see for yourself :)

[throwboatyface]

> I didn't get along well with this manager,The resulting conflict lead to a "performance enablement plan"

Respectfully, in your post you literally say you got a new manager who PIPed you for being hard to work with. The whole tone of the article feels like rehashing old disagreements.

[YorickPeterse]

Respectfully, I didn't. I specifically wrote the following:

> I didn't get along well with this manager, The resulting conflict lead to a "performance enablement plan", a procedure meant to get things back on track before the need for a "performance improvement plan" (PIP). A PIP is meant to be used as a last attempt at improving the relationship between an employee, their work, and their employer.

Not getting along with someone doesn't imply or mean that a person is difficult to manage. Instead, it means there's simply friction between two people.

In this specific case, the main source of friction was that my messed up working hours resulted in me performing tasks later than expected (though still within any deadlines), though I recall those time frames not being well specified to begin with (i.e. it was more of an implicit assumption that X would be done by hour Y).

I believe I was also a little late for a meeting because I'd overslept. That's not good, but it certainly isn't a case of "Wow this person is so difficult", instead more of a case of "This person needs to get his schedule back together".

Either way, you seem to be interpreting the story in a way different from what's written down. I doubt I can change that, so I'm going to leave it at this comment.

[pas]

how can you assure that? it seems like a classic self-fulfilling prophecy of arrogance.

changes bring some adjustment uncertainty, and sometimes it goes well, things get better, sometimes it gets worse. with enough time you'll draw a short stick. it sucks.

[YorickPeterse]

> how can you assure that? it seems like a classic self-fulfilling prophecy of arrogance.

Because colleagues have told me so, and the annual employee reviews were positive as well. In fact, outside the PEP the only actionable/to-improve feedback I got was essentially "Sometimes you can be a little harsh/blunt", which is vastly different from "this person is difficult to work with".

[julik]

Yorick, your article struck me as incredibly reserved and thoughtful. Props to you, honestly.

[LtWorf]

Who makes more career? The guy bullshitting about architecture or the guy ensuring stuff works that nobody notices even what he's doing?

[grogenaut]

The dev who makes shit work and and tracks measures the ops gains / reduced headcount needs and reports their impact up the chain. Who also gives talks on how everyone can make their stuff run as simple as they do.

[LtWorf]

You can give talks without do anything. That works just as well.