Heck, even if you start a project within a company and it gets successful, the company can just slot in people above you, so you become employee #n in a project that you started, and then these people can say you underperform and so on.
Heck, even if you start a project within a company and it gets successful, the company can just slot in people above you, so you become employee #n in a project that you started, and then these people can say you underperform and so on.
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.
> 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.
* 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.
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!
Big organisations are stable, mostly due to the often frustrating inertia and lack of risk taking coupled with their existing, mature revenue streams.
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 :)
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.
> 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.
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.
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".
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.
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.
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.
Words to live by.
sorry, this seems ... too vague for me to understand what's going on, and how it connects to their greed.
are they trying to 'scale up' this project? why aren't they keeping you? replace you how? in what capacity? are you currently wearing too many hats according to them? can you please give some details?
The trouble with these stories is that they’re n=1 anecdotes and we only get one side of the story.
There’s an implicit claim in many comments here that we need to assume that the employee was actually a higher performer, didn’t need managers, didn’t deserve a PEP and so on. That’s understandable given that we tend to put ourselves in the shoes of the person writing a piece and being anti-corporate is always popular on HN.
However, those aren’t safe assumptions in cases like this. I’ve worked at a couple early stage startups that acquired early employees who couldn’t (or wouldn’t) grow with their role and the company. It’s common to keep early employees around out of respect for their past work, a belief that they hold difficult to replace historical knowledge, or simply because they’re well connected to founders and other early employees who have grown into leadership positions.
But in reality, simply being an early employee and being involved with early important projects doesn’t necessarily mean that person is the best person for the job or even a good fit for continuing to do it. Some of the early stage employees I worked with were great at cobbling something together from scraps and keeping it functional with a collection of cron jobs and manual interventions, but their operating style doesn’t work at a bigger company at all. If they can’t adapt and change or they become disgruntled about having to work on things the way you have to at a bigger company, they start to become more detriment than help. That’s just one example of many different potential failure modes of early employees as companies grow that we don’t like to talk about.
> I wanna say this story is pretty standard, and probably a big part of the reason why people in big companies often don't do great things.
It’s “standard” in the sense that every early company has a number of early employees who don’t grow with it, but it’s not the only or even a common fate. GitLab has plenty of employees who have been there for a long time, but you’re not hearing about them from disgruntled blog posts. Consider the selection bias when reading this.
As for the claim that they can’t do “great things”: I’ve used GitLab for a very long time and I disagree. The product continues to evolve. It’s not a stagnant product at all.
btw, that restaurant in Amsterdam is apparently the go to place for startups. I am certain I sat in one of those chairs (was this on 2nd floor facing the canal?) with another fabled startup.
GitLab is fully remote. Everyone works remote, including leadership.
I think one angle I'll nitpick though is this doesn't have to be related to whether or not the employee was a high performer or had particular leadership needs or whether they're adaptable to the current maturity level of the org. There can and likely are many other elements such as whether the manager/employee even get along, or agree on direction, strategy, problems, etc.
And the difficulty is, these types of issues can often show up as performance issues. In lots of cases, is the performance issue the employees fault or the leaders.
In my anecdotal experience where a job went from the best role I ever had to one of the worst happened over a very short week or two with the change in a manager. And I think to the point you're making, when I resigned I outright said... each of us is going to blame the other for my departure. The hard truth is the answer is likely if either of us had been different people I'd still be in that role doing work I really enjoyed, but in that particular leader/follower relationship we simply didn't get along well at all.
If I ever did a what it was like or why I left post, I'd probably have plenty of arguments for my side, because I think to your point, I'll be the hero in my own story.
Two managers in my case, both of whom were, let's say, not successful in their roles. And a glass ceiling so that I had to do most of the work _and_ be a tech lead, yet "could not manage the team because reasons".
Sudden reorgs + hire above + glass ceilings = golden ticket for horrors like this.
You’ll be telling, showing, raw stats, massaged stats, appeals to authority, what have you, but if the only thing the directors care about is features, it’s all for nothing.
After 3 years it finally became a problem because they noticed that releases kept failing, but I don’t think it had anything to do with me so much as someone typing ‘how to stop my releases failing’ into Google.
I don’t know how to solve that, as I’m going through the same thing again now (with a different subject).
I wonder if this is what is behind years old stale issues of gitlab, especially regarding Gitlab CI. From the outside you get the impression, that they completely lost ability to build great things, since they do not seem to care to fix years old bugs that still come up again and again.
- Organising the work and steering it in the right direction
- Ensuring that people work well together, help them grow, deal with "people problems"
If and when both of the above is achieved without a person holding the title "Manager", you don't need them.
This can be achieved by hiring 51%ers for example [1] and by actively monitoring the health of your organisation.
[1] https://news.ycombinator.com/item?id=39333921
[1-1] https://www.amazon.com/Setting-Table-Transforming-Hospitalit...
[*] YMMV: the hardest problem in any organisation is the "people" aspect, there's no silver bullet.
EDIT: Added the link to my other comment about 51%ers
> To me, a 51 percenter has five core emotional skills. I’ve learned that we need to hire employees with these skills if we’re to be champions at the team sport of hospitality.They are:
1. Optimistic warmth (genuine kindness, thoughtfulness, and a sense that the glass is always at least half full)
2. Intelligence (not just “smarts” but rather an insatiable curiosity to learn for the sake of learning)
3. Work ethic (a natural tendency to do something as well as it can possibly be done)
4. Empathy (an awareness of, care for, and connection to how others feel and how your actions make others feel)
5. Self-awareness and integrity (an understanding of what makes you tick and a natural inclination to be accountable for doing the right thing with honesty and superb judgment)
[1] https://www.amazon.com/Setting-Table-Transforming-Hospitalit...
This description helped me put words on the type of people I enjoy working with
That's why I love HN so much: a helpful answer with a source to boot!
Someone "whose skills are divided 51-49 between emotional hospitality and technical excellence" [1]. Seems quite bizarre to me to define it so precisely. Even if skills were measurable in such a way, how many people will be exactly 51% emotional hospitality, and why is 52% or 50% not suitable?
[1] https://www.nrn.com/corporate/meyer-51-percenters-have-five-...
Many of those books are selling well because they are well written and say exactly what reader thinks might work, but if you ask anyone else who worked with the author, the reality can be quite different.
I do not have experience running it at a company level, but at a team level (I have been an engineering lead in two companies for the last 6 years).
From all the books I've read (I read a lot), this is the one that was most "spot-on" about treating other humans and making them feel valued and therefore building a team with strong bonds.
> Many of those books are selling well because they are well written and say exactly what reader thinks might work, but if you ask anyone else who worked with the author, the reality can be quite different.
Absolutely agree.
In my experience I resonate most with any books when I have already, unbeknownst to me, been applying what they preach (which has been the case with Setting the table that I'm currently in the process of finishing).
I believe that it requires a lot of introspection to be able to apply new knowledge (ie, if you haven't thought about it or experienced it before reading about it)
EDIT: formatting
So what is his job then?
NIMS, the National Incident Management System, talks of ICs having between 3-7 direct reports, when there is a need to be connected to what they are doing, because beyond that, you can't reconcile things easily.
With authority comes responsibility for your actions. Without responsibility, no authority. The product manager is a manager in name only, and product owner even less so.
That doesn't mean you can't have several direct reports. The classic matrix organization for example. But it means semi-managers without real responsibility have no real mandate for doing a good job at the slightest hint of trouble.
If there's a conflict of interest, it needs to be discussed based on merit, not based on who has the bigger authority.
If there's no agreement, it needs to be escalated to somebody who has the authority (manager). But IME this doesn't happen very often.
I like this model, because the default position is that none of the engineering, product, process is the "master", so you need to negotiate. If one of the roles also has reporting authority, that automatically skews the decision making towards yielding to them.
That list of “skills” is spot on. I also especially like his use of the term “skunking” to describe how somebody’s personal opinions/problems/issues impact the rest of the team. “51%ers” are exactly the kind of people I want to work with.
People managers do the performance evaluations and various HR administrative tasks (signing time cards, hiring, firing, etc.) but they rely on feedback from their group which are both individual contributors and project managers.
Project managers lead the projects and have to select/attract the right combination of individual contributors to their project if they want it to succeed.
A project that 'gets more management' will usually have to justify the addition of PMs from a cost-benefit perspective. And a project that is overburdened with management types will usually see the ICs migrate to other projects in order to improve their impact.
All this happens organically, so individual contributors are empowered instead of being disenfranchised through organizational changes.
>> If it's something else or they don't have power over projects then they are encouraged to play constant politics.
Why would they need to play constant politics if they don't have power over projects? Not everyone is motivated by the same things.
They do have power over the projects. Being able to PIP someone is power over everything that person does including which projects they work on. Including which projects no one works on. Except it's not their direct power which means to leverage it they need to play politics. Adding layers doesn't remove that power but simply increases the amount of politics they play to make up for it.
But there is no good reason for the People manager to care anything about what projects have people working on them. If they start to care about which projects are successful instead of all projects are successful then they're not a good fit for the job. And yes I have experienced that, as well as it's opposite.
no, of course, there's a lot of value in providing escalation/descalation/rehoming processes, and dedicated ways for org-wide feedback on people's and projects' impact, but people are not just three orthonormal roles on top of each other in a trenchcoat, if there's not clear hierarchy then - as others pointed out - the informal chaos takes over (because it's the human default)