I really like the approach of Netflix of 10 years ago when it was still small. They hired mature people so they could get rid of processes. Indeed, they actually tried to de-process everything. As a result, things just happened. Non-event was often mentioned and expected in Netflix at that time. Case in point, active-active regions just happened in a few months. A really easy to use deployment tool, Asgard, just happened. The VP of CDN at that time said Netflix would build its own CDN and partner with ISPs. Well, it just happened in merely 6 months with 12 people or so. Netflix said it was going to support streaming and move away from its monolithic Tomcat app, and it just happened. And the engineers there? I can't speak for others but I myself had just one meeting a week -- our team meeting where we just casually chatted with each other, to the point that the team members still stayed close to each other and regularly meet nowadays. I also learned that the managers and directors had tons of meetings to set the right context for the team so engineers could just go wild and be productive. At that time, I thought it was natural, but it turned out it was a really high bar.
Importantly, this requires mature engineers and managers. Nothing worse (from personal experience) than working at a place that hires experienced engineering talent and then has a bunch of junior "leadership" telling them what to do. That's how you end up inundated with meetings and frameworks and blablabla. Obviously you need experienced developers to get stuff done without handholding, but you need managers that can "manage" - I say coordinate, without handholding.
One of the strangest experiences in my career involves working for a very well known startup, which had lucked out into an extremely high talent pool, thanks to some key early hires. The problem is that while they had top engineers, their engineering management was no good, all taken from companies way bigger than them. The end result is that, as the layers of self-entrenching management grew, basically every engineer left within 3 years. They went from a results-oriented company, to a Jira-centric organization. Fortunately they had a working system and good product market fit, so the company could keep doing well via coasting. But the extremely high performance organization basically disappeared due to 4 bad hires, which then made many bad hires from their network.
Hiring extremely good engineers is hard, but hiring good managers is far harder. They also are much better at driving out the good talent tan a bad engineering hire is.
In addition to your last point, an employer may have good engineers and not even know it if their system discourages excellence. A lot of what the author mentions can cause good engineers to coast because merely changing a string can be an absolute slog of PRs, spurious feedback cycles, and code deciphering. Cash is king, so as long as an engineer gets paid and isn't totally driven insane, they'll stay just for the paycheck. Yet the whole time the employer has extra talent sitting there just being wasted.
Hiring extremely good engineers is hard, but hiring good managers is far harder. They also are much better at driving out the good talent tan a bad engineering hire is.
> The end result is that, as the layers of self-entrenching management grew, basically every engineer left within 3 years
I'm currently in this situation. Our small company was bought out a couple years ago. Before, we had one meeting every quarter and now we have at least one meeting every day (if not more). The managers aren't listening when I tell them that engineers are leaving because there are too many meetings. The crazy thing is that most of the meetings aren't even related to what we actually work on, it's absolutely insane.
Hiring managers from a bigger org into a startup is the easiest trap I've seen companies fall into. And the more experienced the manager and the more successful the big-co, the worse it gets - but also, the more seductive it gets especially if the founder feels like they personally are a bit out of their own engineering management depth.
Everything needed to keep a giant super-successful post-product-market-fit company running smoothly and reliably as, say, a VP at Google, is completely the opposite of what you need to move fast when you're trying to figure out how to thrive (or even just survive).
I haven't worked in one of those "this is like a startup inside a big-co" places that you often hear about, but I imagine it's why those struggle to compete with actual startups. It's hard to act like you are facing existential risk when you just plain aren't.
Absolutely. To start with, leaders must not be afraid of their teams making mistakes. Copying from another comment: "Netflix's culture demands very strong leadership and probably works only when the company is small enough. From CEO and down, leaders in every level need to know how to set context for their teams, give enough freedom to their teams, while making sure failures are manageable and success rate are maximized. That is, Netflix assumed that people would make mistakes and fail, but the trick was to ensure that failures do not hinder overall success of the teams and the company."
I'll give an example of the leadership style of Netflix. Jordan Zimmerman, a great engineer who created Apache Curator, once asked then the director of cloud platform, Yury, if he could open source Curator. Yury just casually said: okay, do it. Jordan was puzzled and asked: "don't I have to talk to an attorney? ". Yury smiled and asked: does an attorney help you write code? Jordan said no, and Yury concluded the conversation: then you don't have to talk to an attorney.
Someone just forwarded this to me. It's absolutely a true story and it changed the course of my career as well as starting Netflix OSS. I'm forever grateful to Yuri and Ruslan Meshenberg for their support.
I suppose that's a tangible benefit to hiring well- you don't have to ask your team basic questions like these. Presumably the engineer well knows to check licenses.
Don't mind me then. I think early Netflix' management philosophy -- as far as I know about it from the outside -- was exemplary. I strongly recommend No Rules Rules: Netflix and the Culture of Reinvention.
Sort of. You can always license your IP (code) how you want. However if you distribute the GPL code together with your product you can’t say the whole bundle is BSD. (I understand you can dynamically link to GPL libraries distributed separately if you want that, but I’m not 100% sure where bundling .so/.DLL files leaves you).
This just kinda sounds like the common trope of software engineers ignoring everything that isn't involved in software engineering, and then proclaiming that they are so much more productive for it.
I mean like yea, technically they get more "done", but only because they steam roll all their other legal responsibilities
This makes a lot of sense at deep tech places that don't sell to enterprises where one can put their head down and just work on technical challenges. A similar place like Mongo DB or the hardware division of NVidia comes to mind. But if you're supposed to iterate with any input from more than 2 people that isn't highly objective (technical metrics that can correlate well with product satisfaction), communication and diffused collaboration is important and necessary. That doesn't mean it has to suck. But the Netflix model you described isn't applicable everywhere and shouldn't be blindly replicated.
This. In our tiny company, Lowdefy, we try to distinguish when something is done as part of innovation, or as a deliverable or chore. The work that falls into the two categories are vastly different in nature, stakeholder expectations and outcomes. Being deliberate about what category of work you are busy with provides freedom to thrive when innovating required while introducing the structure needed when deadlines are on the table. Mixing the two results in frustration and reduces quality and output. I would be interested to know if this applies same to larger orgs?
I assume these storie-lets are true but the timeline is wrong, it was much more than 10 years ago. I went to an Adrian Cockroft talk in 2012: they had thousands of engineers and hundreds of services at that time, Asgard already existed and was in the process of being open-sourced, etc.
Do you think this is thanks, at least in part, to the fact that Netflix is a rather narrowly defined product? It is a library of content and it streams to your screen.
In the places I've worked, the product is poorly defined. Not because we've neglected to define it, but because it's novel and amorphous and nobody knows what it should be, let alone what it will be.
Netflix on the other hand, in my view, has a clear goal: get video onto screens as efficiently as possible. It becomes much more of a pure technology problem solving situation.
Of course, I won't assume there aren't ongoing product development tasks constantly. I'm sure there's a massive back office suite, along with ads, etc.
But the overwhelming majority of the Netflix product "mandate" is pretty solid, so you don't need to spend a lot of time making sure folks are on the same page, or am I way off?
My own experience is that there was enough ambiguity in what we needed to build. Take building a CDN for instance, what tech stack would you use? How would you deploy them? What's your caching strategy? How would you partner with ISPs? What kind of hardware would you use? A large company may spend months approving every single such decision.
Wow that's so cool but makes sense! Is it not like that there anymore? They still hire experienced engineers, so I wonder what changed? As an aside, is there any low hanging fruit / interesting work left to do at Netflix?
I left Netflix years ago, so I don't know their current culture. Netflix's culture demands very strong leadership and probably works only when the company is small enough. From CEO and down, leaders in every level need to know how to set context for their teams, give enough freedom to their teams, while making sure failures are manageable and success rate are maximized. That is, Netflix assumed that people would make mistakes and fail, but the trick was to ensure that failures do not hinder overall success of the teams and the company.
Netflix was known for being very fast to fire if you stopped producing. Netflix didn't even value Netflix employees beyond what they could produce in the moment. They leaned into the zero loyalty to employees model that US corporations rely on.
Read this article which is pushing this as a positive. Grep for "Tell the Truth About Performance" to see where they talk about changing what an employees job needed. An employee they recognize had done a good job for 5 years, but wasn't what they wanted going forward so they weren't even going to try and help get her the skills to do the new job, but just lay her off immediately.
Netflix's culture stack used to say that culture is all about who gets rewarded and who punished. So, yes, people did get punished for their failures. The key here is what behavior led to a failure? We have to analyze consider the failure and the associated human behavior together and see if there is a lesson or a punishable pattern - this is where strong leadership is needed for a just assessment and action.
There is no rating. At that time, one either their job or not. There was no bonus either, as bonus contradicted to the no-rating system.
> How did they incentivize taking risks?
Taking calculated risk was also part of the culture. Good people actually wanted to take risks. So the incentive systems is to take road blocks away.
> Were Netflix employees from then valued very highly?
I think the success of the company and the quality of the employees make them marketable. Everything else is secondary.
It was a very very special place to work for a time. Everything changes, though, and I will leave it to say the Netflix I left early this year was a completely different place from the one I joined almost 8 years ago.
To expand a bit on what Aaron said, 2022 was a year where the company experienced drastic culture changes: introduction of levels, new VP&director-level leadership with more traditional / "big corp" management styles, push to hire junior engineers, decrease in transparency during decision-making, to name a few... These changes have alienated a lot of people who self-selected for the unique culture the company had, which was truly remarkable.
Netflix's competition changed. They were one of the few players in streaming. Now, there are infinite streaming platforms, all angling for their cut of the pie. For Netflix to continue to be profitable, it decided it needed to spend more on original content. Then I suppose the cost cutting came for other expenses. Hiring a bunch of very experienced engineers does not come cheap. Netflix was known for having the highest cash comp in the valley. They've started hiring new grads again, because it's cheaper to hire one senior engineer to lead a bunch of junior engineers instead of a few seniors to do everything themselves.
I’ve no clue about Netflix specifically, but at some point as an industry we have to hire some junior people in order to have new seniors a few years down the line…
Whenever I read something like this I roll my eyes and assume the person writing it is either pretty junior or the specific founder type who has weirdly dysfunctional expectations about why their employees work for them. I think a lot of this stems from the bizarre culture of the SF tech world, but outside that bubble people do not really think about their jobs in this way. I emphasize _job_ here. The best devs I've worked with were not "intoxicated" with the job. They were professionals who knew what they were doing, were well paid for that knowledge, and outside of the job they had full lives with friends and personal interests.
This sort of narrative is type of propaganda designed to get young, impressionable engineers to commit more of their lives to their job than the salary they are paid would justify. Do not do this if you are a young engineer. There are a lot of bosses out there who will take advantage of your excitement and naivete to utterly destroy you personal life at the expense of the business, but for every one of those there are others who will have the normal expectation of the employer/employee relationship.
I am bookmarking this comment. My first job out of college was a great project for the world, but also at nearly grocery store wages. It was a small company with literally 2-3 people. The CEO was an old man "with no retirement" and also "2 million dollars in debt"
Later when I offered to defer my wages until the product was released (it seemed he was "running out of money"), eventually all the trust building tactics he had used on me over the years were cashed out on as I gradually became disillusioned to realize him paying me dirt was deliberate. He could have easily paid me a decent wage for that work, but ultimately I met nothing but resistance and breadcrumbing and stonewalling when trying to get a decent pay
"I don't have the money to pay you" he said at one point after the fact when I asked to be paid what he owes me. But afterwards and after I had rage quit, he simply hired someone else to start from scratch on my 2nd project after I had told the other developer that one thing I saw first hand working for him was how corporations don't care about people
Granted I wasn't the fastest developer in terms of the number of hours I worked, and the new person he hired seems to have been pretty good, definitely above my level, assuming they implemented all the features I did. But I was getting my work done just fine as far as I and the other dev could tell
Just browse /r/sysadmin and the sheer number of people with a Messias complex, it’s just stunning.
“Yeah so three of my colleagues got fired so now I’m doing the work of four people, but my boss won’t listen to me when I say I’m overworked”.
Professional people would likely been gone before the firings, but if this situation would have arisen, they would have set boundaries and negotiate what work is and isn’t done within a normal work week. They don’t let themselves get tricked or fooled like this. And the fun part is that management never even asks to take over the work.
So many people are so brainwashed they care more about a company that would fire them without a single thought than their own life, it’s so insane.
Depends on how everything else is going, but being one person doing the work of four is great if you handle it well.
If you do what you can get done, and go home at a reasonable time, it's great. You don't have to worry about justifying your position, or trying to find work to do, you've got a bunch of stuff. You can pick from your choice of tasks, cause there's a ton of stuff. You don't have to bother with knowledge transfer, cause everyone else was fired. You can nope out of meetings because you've got a lot of stuff to do. When you leave or get fired, whatever, not your problem.
No need to collaborate with other contributors becauase there are none. Not great if you're junior, obviously.
If those other fired people did anything substantial it’s an illusion to think you can take that work on. Otherwise the firing was justified as one person can apparently do the work…
Yes, for example, if the team was building new features, being 1 not 4 could just means it takes longer. As an example (hmm doesn't strictly mean s/he is doing 4 people's work though)
Everyone's not the same. They don't have the same motivations. For the first decade of my job, I worked a steady, stable job that paid decently. It wasn't bad, but I was bored. Bored as in counting down the hours until the end of the work day each day, booking out all my vacation months in advance to the day.
I switched over to startups and have not looked back. Yeah, I work more, but I enjoy it a lot more. I can't do it forever, but the financial rewards have been better too, so I probably won't need to work to 65 like when I had the more stable, boring job.
There are plenty of people that are passionate about their work. Just because it’s programming computers and not curing cancer doesn’t change this. It also doesn’t mean they don’t lead full lives. It doesn’t mean they are being taken advantage of.
In my experience people that claim otherwise are just getting less out of work than they could. Kind of a waste of 40 hours a week.
(Sure, bad situations exist etc. etc. but that’s just true of everything.)
I don't think it's true that outside the SF bubble people don't believe in their jobs like that.
My father is an orthopaedic surgeon and he definitely thinks about his job as much as I think about mine. My cousin is a cardiovascular surgeon who also does. Another cousin is a lawyer and she does too. A friend I met through another friend is a school vice-principal and he does too.
All of these people have family and friends who love them and who have hobbies that they spend time on.
I think people like this would just prefer to work with others like this. And so they write these things advertising that this life exists.
The market for engineers is pretty hot right now. To any junior engineer who wants to love their job, I'd say go for it. You have at least 40 h a week dedicated to your vocation. That's enjoyable.
Many people don't treat this 40 h as an enjoyable time of their life. But the reward is you have 40 more hours of enjoyment per week. Just remember that hard work and outcome are correlated at less than 1.
Literally every person who is the best in the world at what they do is intoxicated with their job. You don't get that good without putting in the extra effort. You need to recognize some people favor work in the work / life balance.
People have different reasons for working, different risk appetites, and different motivations. This sort of narrative is aimed at people who want to be obsessed with their work. It's pretty clear from the context that the author lays out.
Here's an incomplete list that I keep around of the mechanisms that I've observed so far that have played a big part in the decline/destruction of an engineering team (and product thereof):
1. Too-technical leaders:
As startup scales, there can sometimes be a mad dash to fill new leadership roles (e.g. VP of Eng, Arch, CTO, etc.). Super-star engineers present at startup phase sometimes move into these when they are not the leadership type, causing engineering team to devolve into a visionless, directionless zoo.
2. Non-technical leaders:
Inverse to the above - as startup scales, in desperation, new leadership roles are filled with non-technical individuals who have little to no engineering experience. This causes similar outcome to #1 (albiet slightly different, but equally perilous).
3. Problem engineers:
Small number of leaders lack a spine, conducting shallow interviews and let in "problem engineers" who spoil the party and wreak havoc. Lax hiring practices almost always are reflected into non-existent firing practices, leading to them lingering around.
From experience, it only takes around ~5-10% of a team being this type for it to have a large negative impact, as they tend to derail progress, dodge responsibility, reputation farm, push rubbish, all that nonsense. It harms morale, and the skies turn grey in the office...
4. Micromanagement:
Speaks for itself. Leads to red tape, demoralization, timeline slippage and frustration.
EDIT: I'de love to hear how these foot-guns have been avoided. From experience it seems really challenging, as if like magic; as if cultivating and maintaining a good engineering team and culture therein is like balancing a pencil on it's nib...
As a corollary of these people problems, I would add:
1. Not correcting problem hires fast enough.
First time founders are often too hesitant to give negative feedback, demote a too-technical manager who should have stayed an IC, or remove a problem employee who isn’t working out.
The anecdote that comes to mind is a local startup that hired a C-level executive’s UI designer friend into their VP of Product role. He was wholly incapable of doing the job but they kept him in the job for 2 years to “give him a chance to grow into it.” Everyone below VP level openly talked about how the VP of Product was incompetent and how to work around him.
The company’s product initiatives ultimately failed to even get started and they had to pivot to entirely services based work. Do not stay at a startup that insists on keeping unqualified people in leadership positions long after everyone in the company has given up on them.
2. Firing the wrong people
The same startup was forced to downsize, largely because their product plans failed to even become defined enough to start under the incompetent VP of Product.
It was the perfect opportunity to fire the VP of Product and his sprawling empire of people who did very little, but they avoided that due to his connections to a C-level executive. Instead, they started cutting engineers. They focused on cutting engineers with the highest compensation out of a misguided effort to cut as few people as possible.
In the process, they lost their key engineers who were holding things together. They sent a message to everyone that incompetence is tolerated if you know the right people. And they lost even more core engineers who quit in the months after those layoffs.
Everyone makes hiring mistakes. It’s how you respond to those hiring mistakes that will seal the fate of the company.
Yep, this very much resonates with my experiences.
At the end of the day, startups are run by people, who generally prefer to work with their friends, avoid conflict, etc. There's no great mystery. The mystery is when things work well.
Terrible advice (from a broadly terrible book, I hasten to add). The reason that this is terrible advice: if you "fire quickly", it is because something is either grievously wrong (a mishire) or you are firing based on limited evidence. If the former, you have a hiring problem, not a firing problem; if the latter, you will generate a fear-based culture. Now, if you're running a prison, a fear-based culture may be exactly what you're after -- but fear is anathema to innovation, and if your endeavor requires any creativity whatsoever, you should be seeking to build mutual trust, not foster institutional fear.
It's very old school and discounts how many problems can actually be corrected faster and less expensively than by firing ASAP.
The reason "fire quickly" may be appealing advice to some is that solving problems takes effort without a clear guarantee of return, and leaders usually end up trying easy solutions that diffuse blame or create the illusion that something has changed. Then they wonder why productivity is not up or why employee sentiment is middleing.
About your point 2, can you summarize what you heard about Bridgewater Associates from people who were there? I also stopped reading the book, probably further in than you did, and I felt uneasy about Dalio's description because it seemed internally inconsistent given rudimentary knowledge about working environments and their psychology. He felt like a good boss because people wanted to work at Bridgewater ($$$) and nobody criticized him much - but probably, people had reason to do so but just didn't dare to.
I also wonder what their actual competitive advantage was. My guess is Dalio himself had a good way to think about economic questions, and that they used not-too-simplified computer modeling before most others.
I honestly think the book is so bad that it's not worth a lengthy critique, but in short:
1. Dalio doesn't understand what a "principle" is -- but I can understand that "Aphorisms, Cliches and Hunches" is a less arresting title, if much more accurate. (See [0] for a fuller review on this.)
2. Dalio's version of Bridgewater doesn't line up with the experience of others -- which I have heard from so many people as to completely undermine whatever he might say.
Now, in the book's defense: I didn't get through it and perhaps it got suddenly palatable or interesting. However: I also couldn't get through it -- it was just that bad.
I agree that his descriptions are less "principles" and more like "heuristics". The overall message of the book, as the referenced reviewer points out, is "do what's sensible." As someone so young, what is sensible to me is not obvious, so I find value in this.
What, in your opinion, defines what is sensible in business and leads to your frustration with Dalio's message? Can you give personal anecdotes?
In Germany it is very hard to fire people but there is a six month period in the beginning, where one can be fired without reason. Is it possible to gauge a new employee during that timeframe?
I would say you can generally (from my experience >95% of the time) identify a bad hire in roughly a month, mostly in two weeks and then give yourself / them additional two to be very sure.
We just hired for a management position a couple of month ago and I could tell from the very first meeting that it was a bad hire. I made sure with my team that I’m not totally wrong and then communicated my doubts to the C-Level. It took some time because they wanted to give them a real chance but just before the probation ended there was an evaluation meeting and the feedback was, without exception, negative. Took two days and they were gone.
Of course there will be hires that can uphold their charade for six month but I would say that’s an exception.
If you can tell from the first meeting, why was this person even hired in the first place? The only time i experienced something like that was when the CEO hired someone without asking anyone else to vet them.
Some people are just good at interviews or talking themselves up.
Back in university, most of the students in my Chemistry course had A-Bs (grades were published publicly). The final for the course though was set up by some national body (in the US), and all but a few in the class got no higher than a D. Why? Because the national test was reflective of what students actually learned. The typical university multiple-choice test just self-selected good test takers. I myself got in the habit of only attending certain classes once a month because I knew how to game the tests and still walk away with an A-B average (e.g. have a good idea of what will be tested, know the material well enough that you can eliminate 50% of the false answers, and then make an educated guess on the rest.)
The same is true in hiring. It can be easily gamed if you don't have a great interview process (most companies don't). Even worse, part of that is by necessity. Each candidate has a different set of experiences, but the interview is made to be as routine and consistent as possible to weed out any potential biases (e.g. candidate given purposefully hard question or colored feedback because interviewer didn't like them). To truly vet a candidate, you would need situational questions and feedback, like they quickly glossed over some part of the question, so I'm going to go off-script and drill down into this area. Big companies especially run far away from that due to risk of discrimination lawsuits.
You answered it yourself, no? The people who could vet them were not involved. And the reason doesn’t have to be malicious, it’s just that not everybody can be involved with every interview.
Not only that but you run into the very expensive reason why literally every large company has a lengthy documented process for firing (outside of layoffs of course, lol):
Honestly, european common approach of "trial period" is better for this.
Details vary, but for example in Poland you can (simplified case):
1. Hire for fixed-length term of a year
2. First 3 months of that are "trial period" - you have minimal paperwork for firing during that time, effectively no chance of lawsuit (if someone brings a lawsuit that gets far enough for any paperwork to reach you, you have much worse things to take care of internally)
3. After the fixed-length period, if you're happy with the employee and want him to continue you switch to "permanent" contract. If not, the term lapses and that's it.
The problem (I’m not in Poland but I’m in Berlin, which also has strict rules about firing long term employees) is that senior talent has a lot of choice of where to go to so why should they bother with a place that would only give them a 1-year contract at first?
A mishire situation is what usually this advice is about. Maybe if you hire only people you previously worked with you can bring the mishire rate way down but for majority that rate will probably be very high is what I commonly hear.
After 25 years in the full range of IC and management positions, I'm convinced there's no substitute for expertise, maturity and judgement. I could come up with some rules of thumb (eg. ICs need the maximum amount of agency they are capable of handling), but every rule has its exception. Distilled wisdom is easily misinterpreted, taken out of context, and cargo culted by those with insufficient experience to apply it.
I've seen how small dynamics resulting from individual personalities and nuances of org structure have led to massive dysfunction and productivity loss, even though everyone was well intentioned and doing their job to the best of their ability. I could list out hundreds of behavioral "flaws" that individuals exhibit, but there's no way to fix them all directly, good engineering can't be done by top-down edict and central planning. Instead, you need a critical mass of people, including engineers on the ground, with a good end-to-end understanding of the product and business so that micro-decisions can be suitably informed by the big picture, and the right concerns can be escalated for leadership attention. You need to be able to weigh the cost of product, design, legal, financial, support, security, and operations across both short and long-term to make the right decisions. This is only possible with a high degree of mutual trust and safety for experts to voice their opinion and find the right tradeoffs. It's very easy for egos and personality conflicts to come in the way, hence the need for maturity in leadership. Balancing a pencil on its nib is not a bad analogy.
"Distilled wisdom is easily misinterpreted, taken out of context, and cargo culted by those with insufficient experience to apply it." - so true.
The surprising/unfortunate thing is that dysfunctional unproductive organizations can survive and even thrive. There isn't an obvious cause and effect and the time it takes until effects are seen can be measured in years or decades.
One thing I'll add - or maybe it expands on too technical of a leader - is when a brilliant outside hire is brought in to fill the arch/principal/whatever role.
Then they start looking at the app and questioning every decision calling everything they don't have context on "technical debt"
I've seen it a few times. I told a new VP of Eng he was being asinine because he wasn't there for the original problem, decision, or timeline and saying we made a bad call is just showing ignorance.
Thankfully, He pulled me aside later to thank me and asked for more background on it. After hearing the whole story he agreed. We did the right thing.
Now, that could have gone the other way. And I've seen it happen. When it does, it sucks.
It sounds like the VP Eng was actually a great leader if he could take feedback like that in stride and admit when he was wrong. Bad leaders would have dug in their heels and sidelined the person with abrasive feedback (you).
Absolutely. My point is that it doesn't always go that way. He had his faults, but he could take string feedback. If I recall, he said something to the effect of "not many people speak to me like that. I forget how helpful it is to be challenged"
Also, wow, that took some courage. Personally, I deeply value this way of direct communication when everybody feels free to speak up when things go wrong, and nobody has precious egos they feel need protecting.
Sometimes it goes the other way around. New people hired from bigger company, advocating for solutions that are known to work if painful to start, opposed by "old guard" who finds nothing bad in their hundreds of SSH windows with root logins into machines and where the "technical debt" is actually reaching the point where it will result in losing important clients through a legal statute impacting said technical debt
Big +1 on too technical leaders. Seen this a couple times with brilliant engineers who, once they became in charge of 50 different teams, appeared to try to just do the same work they did in one team but "scaled". Put every team in a spreadsheet and try to automate management through uniform metrics instead of focusing on managing and growing his direct reports.
And another time, seen a less technical leader step in, see engineers around me roll their eyes a couple of times at the lady (with maybe a smidge of male chauvinism blended in), but then see her actually fire bad hires, hire star players, and get everyone to align their priorities so they could be productive. Leadership is a very different job from the kind of technical excellence that too often gets rewarded by promotions (vs raises or bonuses).
It's interesting that you have experienced both sides of the leadership problem space. Honestly a bit glad to hear that others share my experiences and that I'm not just unlucky or something.
Also, oh my do I ever have an extremely similar experience of an IC-type engineer going into a leadership position and trying to "engineer" it: put all teams, sprints, tech visions, growth frameworks, etc. in huge spreadsheets. I look back in jest now, lessons to be learned!
I've seen this in science as well. Analysts get promoted to managers and managing is a completely different skill set that involves social skills, communication, empathy- all people skills that they didn't need to be a good analyst. They were promoted because they were good at being an analyst- meticulous, quiet, just do their job and don't interact with others. Unfortunately almost none of this carries over to being a good manager. I wished many times that they just hired people with management skills from some field completely outside of science, a manager doesn't really need to know the intricacies of the work to do their job well.
My last industry job saw the company implode from this cycle as everyone got pissed off and left the company. My old ex co-worker sent me a letter from the CEO last week saying layoffs were starting because revenues were down and they keep losing clients...
That's true. It's also the case that, if you polled people here, you'd find no shortage of people with zero respect for managers without technical backgrounds.
Academic science is pretty much designed this way.
You get a faculty job based on your brilliant work as an IC (i.e., first author papers) but running a research group is a totally different skill set—-and often one people get very little training for.
> I wished many times that they just hired people with management skills from some field completely outside of science, a manager doesn't really need to know the intricacies of the work to do their job well.
Having been there too, I feel like this is another recipe for disaster. Technical management needs to be able to make calls on escalations — that's in fact one of their main jobs — and when they don't have the depth of knowledge to make the call on merit, they make it on rash impulse, or favoritism, or (perhaps worst of all) don't make the call and let issues fester.
Another +1, I left a startup over exactly this, all the managers, directors, and VP of engineering were IC engineers maybe 2 years prior. It was a shame, because I really enjoyed my role at that company in general, but ended up opting to leave after getting a really terrible leader.
Here's an idea I've seen work: stop assuming people over 35 aren't a good fit for a start up. People who've been in leadership for a while but have the chops and in their day did on the ground work, and who can - given enough time and guidance - understand the minutest detail of a new tech stack or financial maneuver, command the respect of the super stars doing the day to day for their contribution of far seeing leadership.
Preface: I'm not saying that this norm is necessarily right, rather just explaining the mechanism that I believe is at play here.
Isn't part of the issue that early on in a start-up, everyone is indispensable, and often that comes with putting in extra hours and going the "extra mile" for the viability of the company?
When you are over 35, 30 even, you are much more likely to have a spouse, children, etc., and all these command more of your time that the business wants to capitalize on.
Personally, I've seen some real rock-star engineers both at 20 and at 40, however more often than not for different reasons. Honestly, not once have I ever learned a decent life lesson from engineers around my age (I'de say I'm on the younger side), however it's been several highly memorable times that an engineer on the older side has pulled me away, given me some real hard-hitting, incredibly valuable engineering and life lessons, and changed my career and sometimes life for the better.
> Isn't part of the issue that early on in a start-up, everyone is indispensable, and often that comes with putting in extra hours and going the "extra mile" for the viability of the company?
There seems to be a strong culture in American companies, and especially in startups, of rewarding heroic efforts. But if I see people putting in heroic efforts to get things done I tend to look for ways to not need those efforts in the future.
Good experienced engineers can help ensure that you don’t keep having to go that extra mile to get the job done in the first place.
Problem engineers are not necessarily all new hires. It could also be people who were there initially but fail to transition into a role more suitable for a growing company.
A classical example, which I've seen before, is a cowboy coder who can be a useful asset in the very early stages, but who later demonstrates a total lack of teamwork ability.
Such people are even worse than bad new hires because they have a certain clout with management who is therefore more willing to turn a blind eye.
This sounds like the opposite of what the author had in mind. The cowboy coder is the one with spark, and the need to "transition into a role more suitable for a growing company" is the problem.
Companies change, and if you can't adapt then the problem is you. Being able to work together with your peers and not alienate them is not too much of an ask.
Don’t forget: Hiring remote contractors to “speed up” things. Dev will slow to 50% and meetings will double as you attempt unsuccessfully to teach them how to code.
Anytime a leader sees new hires or contractors as a "speed boost" is when it all goes to the dump. The sooner we get past this idea, and start viewing new hires/contractors as "speed bumps" the better. Bringing anyone new into the fold should always be a slow process!
Depends on the scope of the change and the objectives of the company. This is more true in larger organizations than startups, but not all technical problems you’re working on are directly linked to your value prop. I’ve seen good results in many cases where some systems are handed off to be managed by contractors so the FTE devs can focus their attention on improving the product which actually makes them money.
What I haven’t seen work is (which is what I think you’re describing more specifically) bringing on new hires or contractors to a project in flight in an attempt to deliver it more quickly. That’s where we get into Mythical Man Month territory.
From experience I can say that these problems can occur just as well in bootstrapped companies when they reach a certain size. It's a problem with the number of employees regardless of how fast the company gets there IMO.
What is to be done if you find yourself in the first situation (too-technical leader)? I found myself there before a few times...reporting to someone who was no doubt a brilliant IC but has no concept of things like communicating vision or even basic project management. Would be curious to understand if anyone has been able to "fix" this from the IC side.
I find it hard to imagine that it's possible to, in all likelihood, improve a too-technical leader problem from the individual team member position. There's only two ways through which that I can conceive it being solved:
1. Too-technical leader realizes they aren't fit for purpose, perhaps due to indicators like stress, missed targets, team morale, etc.
2. Higher-up leadership notices aforementioned issues and give them the ultimatum: leave or side-/demote to more technically-focused role.
Re: 3. "Problem engineers" are a similar problem to those users in a forum who don't actively break the rules but destroy the community.
And for 4, the opposite is even worse, aka "no management". So when you develop something but it turns out the outcome was not needed or in a different way.
That's a great taxonomy of foot-guns! As to how they can be avoided, I can only describe some of what has worked for us so far, with the caveats that we are still small (~60 employees); that none of this is formulaic or perfect; and that there are many reasons why what we have done might not work for others -- or may not work for us as we get larger! That said, here is some of what has broadly worked for us:
1. Writing-intensive hiring process
This is controversial for some, but I have the personal advantage of having previously made The Worst Hire of All Time -- one that forced me to accept that using resume + interviews as the sole (or even primary) criteria left me extraordinarily vulnerable to Problem Engineers. We ask candidates not just for a portfolio of their work (and analysis samples and so on), but also ask them values-based questions[0] -- the answers to which are astonishingly revealing. Our review of candidate materials constitutes the bulk of our hiring process.
2. Transparent compensation
Another one that is surely controversial, but in my professional experience, an amazing number of anti-patterns arise from the scramble compensation -- and usually not for itself per se (that is, not for the marginal dollars), but rather for what it represents in terms of validation, power and so on. Making compensation transparent forces some measure of organizational health -- to say nothing for the bright light it shines on any institutionalized inequities.
3. Uniform compensation
One that even more people will find controversial. ;) When we wrote our blog piece on this 2+ years ago[1], we assumed that it wouldn't last as long as it has -- but it honestly is more important to us now than ever before. Especially as we go to expand the team with roles that are often less well compensated (e.g., customer-facing roles), the fact that we explicitly compensate them as well as everyone else allows us to attract extraordinary folks to the company. We still don't know if this is going to last forever, but we have seen so many incredibly benefits from it that we have stopped burdening it with asterisks.
4. Very, very careful hiring
We are deliberately lean. We add people to the company very carefully, and we have no one inside the company who is incentivized by the size of their team (see #3, above!). When we add people, we keep a sharp eye on versatility and intrinsic motivation. This allows us to do more with relatively fewer people -- helping us avoid the foot-guns you've outlined. That said, it is also not without side-effects: a consequence of this is that we are extraordinarily selective, which means we have many more people that want to work at Oxide than we can reasonably accommodate -- and it can be really, really hard to turn down someone who you think will likely be successful!
Big +1 for #1. A brilliant IC that has an impressive contribution history tells only a small fraction of the story. Skeletons may lay behind that green square matrix!
Also big +1 for #4. It may slow growth for some start-ups, but I think it's always better in the long term if hiring is deep, versus shallow.
As for compensation, those certainly are controversial. I believe in honesty, but your extent of it is quite...towards one end of the spectrum? Certainly interesting.
Ha -- "towards one end of the spectrum" is a fair (if not generous!) way to describe much of our approach, on many things. ;) And it has been interesting -- with surprising ramifications in many areas. As a concrete example: when people are assessing a hire to be a true peer with respect to compensation -- being paid neither more nor less -- the level of expectation is really high, and the reviews are thoughtful, thorough, and candid. This is but one of several examples; at some point, a blog entry on our experience is probably called for...
I'll throw in greed as another factor. Being ambitious is fine, but being greedy will wreck a startup in no time flat. Or in the case of my previous employers, in about 13 months ...
I've always assumed that greed, particularly when it's egregious and endemic, would more rapidly unwind a start-up. My OC was more focusing on those mechanisms that tend to be at play at start-ups that cause them to gradually decline/implode.
However, I totally agree with your point. Also, sorry that happened to you!
I recall a teamwork study that found few if any superstar team players can really make any given team better, but they did discover that one bad apple can easily kill a team’s productivity, happiness and etc.
I once worked for a company that was really great about “no finger pointing” and lots of trust of employees to do the right thing.
We acquired a small troubled company along the way, they were a mess with finger pointing and empty accusations. Within a year they had infected our entire department:(
I think your question about avoiding these mechanisms isn't the right one; the real question is, how does one succeed despite these inevitable problems?
In other words, I don't think you avoid these, I think you understand they're coming and accept the trade off, making sure it's worth the issues you invite when you do have to promote those engineers/non-technical people, for example.
From somebody who, perhaps sometimes can be quite full-on about software quality, craftsmanship, and just generally doing good, here's what's helped me in the past when faced with a company/team that has morale, skill, or other problems:
1. "The extent to which you publicly complain about something should be proportional to the robustness of your solution and your confidence in it."
2. If you think things need to be done better, lead by example. I've found that you will be hated for saying things are bad, but loved for proving how things can be good (by example).
3. Note down your concerns (Notion is free!). Wait on them, then talk about them >=1 day later if you still feel like they are valid.
4. Ensure you have enough employable skills on the side so that you can jump ship if the company or your place within it is totally DOA.
I would like to change many things I feel could be solved in better ways.
Unfortunately Im not a rockstar engineer and stuff takes me more time. I care a lot about maintainability, so writing docs or good explanations to design decisions simply take time.
As you can guess we often dont have that time in the industry thus most things look like they look.
My biggest issue right now is communicating those findings.
Curse of things seeming too obvious, trivial or simply requiring more time.
I'm an Engineering Manager, i wouldn't consider taking time to do any of the things you listed be what I would consider to be the definition of a "problem engineer".
To me, a problem engineer is someone who blocks the discussion, or that any solution needs to fit the specs of what the problem engineer wants, even before anyone has outlined what the issues are. Basically someone everyone walks on eggshells around. Anyone who breaks collaboration, team work, and especially anyone who ignores good engineering practices just because that makes that specific person happy... Is a problem.. for all the engineers.
You take a little extra time, that's fine. You're taking that time to do good documentation, or writing higher quality code.. you're an engineer, that's what I expect. Higher quality code and better documentation helps boost velocity in so many ways. You're doing yourself, and everyone around you a good service.
Well, nobody has the intention of being a problem engineer. That said, from your comment I haven't really understood why you're considered (or are considering yourself) to be a problem engineer?
Most things are not written in stone. You can probably change even if it's not comfortable to do so. Maybe a different role or organization would be a better fit. But typically just getting your part done and moving on isn't the best fit for a lot of jobs and, even if you work for yourself, you probably even have more interactions with clients at that point.
Elaborating a tiny bit on #2: It is a dangerous situation when non-technical leadership comes up with very specific technical opinions - based on hearsay & evangelists on their Twitter/Instagram.
"I saw X on his Reel telling changing everything in our frontend to purely Coffescript will be more durable" is a kind of advice which does not bode well generally
I disagree - as someone who has started up small companies and worked in megacorps, including FAANG and major banks, it’s entirely possible to build that intoxicating environment anywhere. It’s more about having a dynamic leader who assembles teams into collections of individuals who know precisely why they are there - and are given the work they excel at and the work they don’t the manager ensures someone who does helps them. Then the manager has to make sure the mission of the team is crystal clear in its value to the mission of the enterprise and the enterprises mission on earth. Finally the manager has to relentlessly break down barriers to production and impact.
The arguments articulated are entirely false: ex. N^2 communications. This is reductionist and absurd. No team depends on every team in the org. Their domain is often fairly small and their adjacent teams extremely finite. The exception are “core teams” (which have been my specialty). However a well functioning core team doesn’t have n^2 communication overhead - they act as a concentrator and teams come to them - which is N. N can be large, in which case effective triage is crucial, but so is automation and self service, coherent platforms that are self documented, and some folks on the team that really really enjoy teaching.
I’ve burned out though on building these teams. It’s absurdly hard work on management. But management is supposed to be absurdly hard work. My next gig is as a distinguished engineer at a late stage startup - back to the roots for a while.
I’d would disagree - I had the exact experience that the autor described. But you are right on this point
> it’s entirely possible to build that intoxicating environment anywhere. It’s more about having a dynamic leader who assembles teams into collections of individuals who know precisely why they are there
I still think it’s related to size and bad incentives. I heard stories of people at FAANG that said that department X is like a startup but Y is soul sucking boredom
Yes, thats correct. However the existence of X department at all refutes the authors premise and conclusion - and if X exists, it’s entirely possibly for Y to become better.
Specifically this is entirely false due to the existence of X:
> Is this preventable? I think not.
I> f you look closely, all these problems fundamentally come from:
> Decreased skin in the game, which reduces team alignment
> N^2 communication, which creates need for managers and specialization, which reduces individual agency and breadth of learning
> Reduced risk tolerance, which slows everything down
> #1 and #2 are inevitable results of having more employees. #3 is an inevitable result of having more users, partially due to government regulation.
I think a large company enables Y departments to exist without the company imploding immediately. Survivorship bias ensures most startups that last longer than a short amount of time to appear like X, when I know there are plenty of dysfunctional startups (a friend tells me Ghost is a great example). But due to the economics of a startup they evaporate quickly. In a large company Y departments can limp along for a long time or indefinitely because Y’s function needs to exist and the company can afford for it to suck ass to work there without it going out of business. However invariably X departments in large corporations are where the magic happens, where people want to work, and what moves the large enterprise forward.
I’d also note that not everyone wants to work in a startup environment or are able to. Many engineers got into it for a good paycheck and don’t have much interest in anything particularly dynamic or engaging. They’re perfectly happy committing once a month and sitting in meetings. That’s not me, but I can also see when you build an army, you can’t build it out of special forces only.
So, instead of saying X can’t exist, when it clearly does, I think it’s more useful to say you should be careful where you work in a large company and seek out actively the X departments by learning what Y departments look like and how to spot an X department.
> I’d also note that not everyone wants to work in a startup environment or are able to. Many engineers got into it for a good paycheck and don’t have much interest in anything particularly dynamic or engaging.
This is an excellent point. In my experience a majority of people value stability and predictability in their lives. They would rather have someone tell them what to do within well-structured bounds than contend with the ambiguity inherent in an early stage startup, or with solving massive product/business/technical problems with too many stakeholders to fit in a room.
I think the challenge is the people with the intrinsic motivation and stomach for the ambiguity can struggle to grow in large corporate environments that are full of good soldiers who stay in their lane. It's not uncommon for entry level ICs to come in with 3 or 4 layers of management between them and VP level, and then become pawns in middle management games, or stuck reporting to Peter-principle cases who teach them all the wrong lessons.
This is why I was really glad to have worked in startups when I was young, to really get exposed to all the moving parts and fundamentals of an operating business. It's just much easier to learn when the big picture is more legible, you have the latitude to iterate faster, make more mistakes, and see first-hand how things scale (or don't!) from the ground up. These days I see too many ivy league grad ex-FAANG who have all kinds of ideas of best practices with no understanding of why things are done that way at the tech giants, and extremely limited ability to reason from first principles about what makes sense in a different context.
Absolutely. The most exciting work I’ve done that has literally changed our world was done at systemically important multinational megacorps, where we created environments of unfettered innovation and an assembled teams of amazing individuals working as a coherent team. I had some really great leaders early in my career that showed it’s not only possible it’s the only way to enjoy any role at any company no matter the size. While you can’t clone their method to work in any environment, you can adapt their method to any environment with enough energy applied. The essential secrets are the ones I outlined. As an IC though it’s all about finding those leaders among the functionaries.
Likewise, most of the startups I worked at were exciting by not intoxicating. They were relatively banal in their goals (change the world through prestige makeup e-commerce or something), their technology modern but not innovative, and the teams tight but not always coherent like a well oiled machine.
big companies have resources that give you reach (channels, marketing, human talent, legal, international presence, longer term investments) that you can never get with a smaller company.
being able to apply them effectively can really be really frustrating though. and there is always the danger that your two year development arc will be demolished by 'shifts in overall strategy' or 'belt tightening' or a reorg.
> I had some really great leaders early in my career that showed it’s not only possible it’s the only way to enjoy any role at any company no matter the size.
I'm not persuaded anyone is in a position to know that there's only one way for people to enjoy work, and to know what that one way is.
That’s the secret. Most management is about the one way people work. The right way is to realize everyone is an individual and everyone has a different way of working, and what they enjoy about work. This forms a complex optimization problem for the manager, whose job, IMO, is to figure out the puzzle of how to maximize everyone’s individual value in the team. The way you do that is match their style of work and strengths with the teams needs and find other team mates to backfill their weaknesses. Then giving people the space to do things the way they prefer it while keeping a strong common collaboration medium within the team.
Return to office is a current example. My strategy here is that people know how they work best and that’s up to them. We have ways of getting together and collaborating, asynchronously and synchronously, and don’t enforce a mandatory hybrid approach. I encourage the team to intentionally meet up in person regularly, and the team self organizes synchronous in person time on a regular basis. I set up a drop in zoom room that’s always signed in on a conference room and people drop in for adhoc stuff all the time. Some people stay signed in all day on the conference room. I make sure ticketing systems, chats, and other mediums are well used. I regularly talk to people about their well being to be sure folks remote are OK, as sometimes fully remote can mean fully depressed.
Compare this to a “standard” managers approach. “We will be in the office three days a week, with a mandatory day on Wednesday. This is necessary because people work best in person but we want to give people flexibility because we know employees value that. Failure to comply will result in performance review impact. Our company’s culture is built on in person interactions. We do this for the children.”
Typical management is about treating people as butts in seat filling a role with a define set of measurable performance metrics - aka conforming cogs in a machine. that is the method that assumes there is one way for people to enjoy work, and knowing what that one way is.
My way is acknowledging I don’t know any one way that’s best, and specifically, there is no one way for people to enjoy work. It’s my job as a manger to figure out what each and every person on my teams way is, and to do my damnedest to create that environment for each individual. I work hard to hire managers that will also do this, and I meet randomly with people at all levels of my org to be sure they’re being treated like this by the people on my direct team.
The down side for me is I stick out like a sore thumb in the great cog machine of other managers. They don’t understand what I’m doing, it bothers them, and they feel like I’m getting some sort of preferential treatment. And maybe I am, because my organizations are almost always considerably more effective and successful than the rest of the org, so we get enormous latitude. But shielding my people from the game of thrones is exhausting - more exhausting than the rest of my job.
All this said, I’m not the only one who does this. I have encountered a lot of leaders that do this. They’re the ones people want to work for. That’s why I paid attention to what my early leaders were doing and emulated it - the one way is there is no one way ;-)
That was a pleasant read, thank you for the comment. I've felt something similar about management, but not quite clear enough to put in to words.
Maybe I'm late in my comment but, I have two questions if you do not mind.
If you have a manager that is not quite like that, but probably somewhere in their mind would agree to that stance, how could one push that person to that direction? I have my manager (and a friend) in mind, gives good autonomy and let everyone work in the way they feel is optimal. But it also most often lead to aimless or fuzzy goal setting, a lot of ambiguity. My guess is that the thing lacking is the inquisitive nature; like you mentioned you do, he does not check in on people how they feel, what's blocking them, what's suboptimal for them. He simply check in for an update on progress and set meeting to update what he's up to.
Is there any good material or pointer that could make someone manage more like that?
I also informally manage one person due language barrier and the question also applies to me.
I am the most senior engineering IC by position and years of experience at my current company in a 100+ person engineering group. The only problems I deal with are non technical and organisational in nature, despite on paper being expected to code 30 percent of the time.
Sound advice - currently going down the path of try to make the role better. It will however be a long journey, so need to work out whether I am sufficiently committed to the path. Also need to work out what the ejection criteria are, regardless of my commitment or not.
But it doesn’t exist. For any task the number of contact points is almost always fairly small. Just because the possible N might be large most are occluded by lack of relevance to any specific task.
I would note that the author categorically says it’s not possible for a startup like environment to exist in a large company. That’s what I disagree with.
How have you developed a sense for organizational friction? What observations of culture can I use to make an educated guess about how easy it is to do my work?
I agree with your point that a large org does not guarantee what the author claims. The author claims that the organizational friction can be measured by productivity, but you recognize culture as the better diagnostic criterion. The big O metaphor does not extend well to the argument, as you point out.
I'm looking for hard hitting interview questions so I don't waste my time on "soul sucking" positions.
That’s the trick isn’t it? As “the boss” I’ve been able to self create my culture around me so it’s been easier. I have landed in management teams that were so oppressive I couldn’t even then. I’ve watched my peer leaders for signs. It’s very hard in an interview to know where you’re landing.
A few things I’ve noticed that might help:
* ask people in the team what they do and how they work, and how the team helps them work best. If they answer “oh I’m a programmer 2” and have wishy washy answers on the rest, that’s a bad sign. They’re being managed by a “by the book” manager. If they describe some complex role that isn’t out of the HR leveling guide, and a unique way of working that’s accommodated by the team, that’s a good sign. If you hear everyone in the team describing a role that’s unique and tailored to them, then that’s a great sign.
* this is controversial but I think any org that slavishly follows modern day agile / scrum can not be dynamic. Nothing more to say other than back in the 90’s Bay Area hanging with thought works and those folks, agile was something very different than today.
* the manager themselves should be very open to questions with thoughtful answers that aren’t rote. They should likewise spend more time understanding you than usual. They should be assessing your fit in their team - do you fill a gap? Do your weaknesses complement others strengths? Are you looking to turn the crank or are you looking to innovate?
Also, be aware of yourself. Not everyone does well in a dynamic environment. It’s more chaotic and less structured. If you like clearly defined and regimented work, go for the clearly defined and regimented team.
Organizations are structured as trees as a strategy to combat N^2 complexity. You talk up, or down. The tradeoff is of course N^2 relationships still exist in reality , so you duplicate effort, and sometimes collide, but it's a good tradeoff.
I think it’s more like an adhoc graph that’s more dependent on the task than the organization. Tree based management is only useful for reporting and dictates. The actual work is more like “I need to get X done, I need to work with I,j,k to do it.” Often the real issue is NOT that it’s N^2 interactions, but the space for identifying who I,j,k actually are is quadratic and there’s no index. This is often the immense value of “lore masters” in a team - they have an unnatural ability to know who to talk to about what. If you don’t have one in your team, get one.
That coordinating is a quadratic mess, because no task requires bidirectional communicating with everyone else.
I also disagree with all the other points they make about large companies. Not that there exists teams in large companies that suffer these issues, but that there exists no teams in large companies that don’t have these issues. I further extended it to say startups also aren’t without issue, and many are totally screwed up. They just don’t last very long.
Let's set aside value judgements. After all, I don't know that small startups are optimal any more than you know that they aren't. Hopefully, what we can agree on is that small startups are different from large companies, even those with teams. Given that, someone who LIKES their small startup for whatever reason may feel it's lost its lustre when it evolves into a large company. For those people, this article offers an explanation for why that might be.
Or, it gives a guide for the problems to avoid and figure out strategies to solve for to avoid that path. But, yes, if the article were written that way, I would have agreed with it more. But it wasn’t :-)
I agree here. The opening statement of the article is simplistic and inaccurate. Sure, most big corp jobs might be rather dull, but you can lit that spark in the right circumstances.
It almost feels like the "efficiencies of scale" you get from large organisations (e.g. specialised people for recruitment, people matters, quality assurance, user research etc.) are not really efficiencies. Perhaps it's better to grow the organisation by repeatedly cloning the smallest effective team you ever had, rather than creating a more "efficient" organisational structure. How those "mini-companies" communicate with each other efficiently -- another matter.
I think it's about more than just efficiencies of scale. You kinda play by different rules at a certain scale (not just based on employee count, also based on revenue), and suddenly you're subject to a lot more regulatory scrutiny. Plus, as a company becomes more valuable and attracts shareholders and managers with lower appetite for risk, a lot of money needs to be poured into risk management and avoidance. At a previous company, a competitor was blatantly breaking the law to solve user needs we couldn't solve without breaking it as well. Somehow they got away with it, presumably because they were tiny and (to my knowledge) unprofitable.
Now, if it wasn't for all that, there's still the problem that, from personal experience, most employees don't invest as much energy as a founder would - which is perfectly understandable. As the founder to employee ratio gets smaller, you find yourself hiring three people to do a job you could do yourself, just to make sure it gets done reliably and timely. In a smaller startup, early hires are more similar to founders because they're close to them and stand to gain a lot if the company succeeds and grows. For employee #213, they sell 40 hours of work per week and their fixed salary is all they really stand to get out of it.
So while I like the romantic idea of having a large company comprised of multiple independent startups, I haven't seen that work and I can barely picture it work :( One can get somewhat close to this with the right organisational structure (e.g. sacrificing efficiencies of scale for team autonomy where feasible), but it's not even close to the same thing.
You're correct. It doesn't work. A lot of ails are necessarily inherent in scaling up. Once you get to 80ish, you just necessarily have to change your setup
The challenge is cloning teams is impossible. Teams are a collection of individuals. It’s like saying the way to win the World Cup is to simply clone the best team.
I think the best way to scale is to build processes that reinforce the traits you want in a team, and hire managers who understand teams are collections of unique individuals, as is the manager. The manager should be free to manage their people in a way that optimizes delivery and reduces churn. Between teams there should be a very high bar for quality of communication and delivery. The culture of the organization should be built around respect for each person hired and a relentless focus on ensuring individuals end up in teams that they are effective in and are therefore maximally effective as teams.
I agree and this is a practical method that I've seen work well in several companies I've worked for. However I think there's a bigger problem that contributes to the loss of "spark" that the author strangely didn't address at all.
The fruits of labor grow ever higher. By which I mean: In the early days of a startup the problem space is ripe and plentiful, the impact you can have is outsized, and the pool of people with which to share it is the smallest it will ever be.
As a company grows, all three of these factors are subject to strain. The problem space becomes sparser, outsized impacts are recognised further up the ever-growing hierarchy, and the pool of people with which you're sharing your impact becomes larger and recognition becomes shorter lived and more diffuse.
There is also a dynamic aspect to that: the original team who started the startup has battle scars, they used to take risk, but now they have a natural incentive to be more conservative, preserve the way things were done.
I met them back in 2014 when they were making insane amounts of money from Clash of Clans and their DS who was building LTV models for the game was doing it as a part of his job.
In lots of other (worse) companies they had huge teams delivering a lot less.
Adding people/roles can be beneficial when it frees other people from onerous or distracting work. When it increases onerous or distracting work for everyone else, that's a problem. To a large extent, the art of managing growth is finding ways to liberate everyone instead of handcuffing them.
Yes. Maybe one can design some sort of internally budgeted token based economy between these internal teams (distinct from mere gamification). But based on past experiences, I worry that that will lead to unanticipated perverse incentives.
> Most startups needlessly accelerate their corporatization by copying the processes of larger companies, usually by poaching managers from large companies who bring their playbooks with them.
And no one ever stops to think "is that company doing that thing because it's effective, or is it something that they are getting away with because they are big."
Or that big companies are just solving big problems which are different from yours. There nothing i hate more than just rote copying solutions from bigger orgs
I went through this cycle a few times. My favorite, and last successful startup was acquired by a gigantic international corporation four years in (2007), and I stuck around for another two years.
After the product shipped, the need to support customers and sales definitely slowed things down. Our fantastic VP of Engineering became CTO, and hired a middle management moron as VP, and that was the end of the good times. The new VP then hired "team players" instead of good engineers, rewarded loyalty over competence, and hilarity ensued. And then we were acquired.
My fun startup-like time was reduced to ONE WEEK per year -- the week between Christmas and New Year. The rest of the year, all the layers of management were present and doing what they do. But that one week of the year, nobody was around, so I found myself much freer to do what I thought was important. And that wasn't just self indulgence, (I mean, it was, but not only), and having an alpha version of a shiny new thing forced the organization to go along.
> Our fantastic VP of Engineering became CTO, and hired a middle management moron as VP
Hardest lesson I learned when I got promoted to upper leadership positions: Hiring middle management is incredibly hard. The number of absolute sharks in the candidate pool is wild. People will show up, sense that you’re new, and tell you everything you want to hear about how they’ll solve all of your problems. They’ll claim they’ve done exactly what you need at every prior company they’ve worked for. They’ll flatter you and tell you they’ve been waiting for an opportunity to work or someone like you.
Imagine the schmooze-iest IC candidate you’ve ever interviewed, but 5 times better and harder to see through. These people have charisma you wouldn’t believe (when you’re new) but they don’t really care to do the hard work. They just want to worm their way into the company and then extract. They’ll extract compensation for themselves, extract headcount to hire their friends and build an empire, extract compensation for their friends (who will return the favor at a future company), extract lucrative contracts for their contracting buddies (where they might even be in on the take). Years can pass before people realize they haven’t really done much despite producing a flurry of activity. They may have even driven away the good employees who got tired of their BS or were pushed out for identifying their incompetence.
I was unlucky-lucky to watch this play out under a fast rising CEO at a lesser known unicorn. The number of sharks who showed up and charmed him after he became successful was unbelievable. The same thing plays out with less experienced middle managers who get thrust into high-budget positions at smaller companies.
A highly successful hedge fund with a highly successful group got one of these senior managers and they managed to spends hundreds of millions on crazy ideas (not my money syndrome) while the people who actually built the machine originally were sidelined.
1) Don’t hire mediocre people. We knew this new VP was terrible. But the guy being promoted was impatient and wanted someone to take over.
2) Upper management and the board must not forget the reason why the company exists, and put profit ahead of the mission. Otherwise you end up with 1980s GM, or the Boeing 800 Max. Read this speech by Dave Packard, a founder of HP. https://sriramk.com/memos/packard.pdf. A very clear, concise summary of how to run a company, and how to think about your job. And anyone who has experienced corporate America can immediately see that nearly no companies are run this way.
The book Loonshots by Safi Bahcall describes this phenomena quite well. There's a "phase transition" of incentives at around 150 people that can be fatal to many organizations.
The secret sauce is how a startup goes past this headcount. Ideally many software companies quite honestly don't need more than 150 people!
Dunbar's number is a suggested cognitive limit to the number of people with whom one can maintain stable social relationships—relationships in which an individual knows who each person is and how each person relates to every other person.
See Miller’s “Barbarians to Bureaucrats” for a description of the full corporate lifecycle. Barbarian -> builder -> explorer -> administrator -> bureaucrat -> aristocrat.
Total company size. The book argues, if I recall correctly, that over that size, there are too many moving parts within the organization to be focused on anything but preservation of the organization at large, rather than the product or service the organization offers. It's been a while since I read the book but it was quite a good read - highly recommended.
The value of this recommendation cannot be overstated. Put another way: only hire when there is no other way to solve a problem, and even then do so carefully. Be willing to elongate timelines substantially as a result of this practice; the medium- and long-term costs of over hiring are much worse than the cost of later launches.
Unfortunately, the funding environment and growth expectations for startups often incentivize the opposite behavior.
Coming from Canada (and Quebec especially) it's curious to see a recognition of this emerge in SV. Quebec has a problem that historically small enterprise funding came from sources that require commitment to hiring plans (i.e. in two years hire fifty people or you get nothing), which leads to absolute madness, and a unsurprising lack of successful exits.
I had seriously underestimated how bad the hiring situation for startups in SV had become though, and a lot of people are using them as a bench to either recover from FAANG burnout or to put on a resume while training for interviews. With that dynamic a hiring manager is going to end up leaning towards being too optimistic because you can't risk not noticing the few that can build your company. You just need to be aggressive about removing those that aren't working out.
Precisely. Can also apply to tax credits. Luckily since the tax credit war race to the bottom ran out of steam this nonsense has been far less prominent, but for a long time many of the game studios in Montreal were dependent on this sort of thing.
I regarded many of these subsidies as killing the business dead before it had even started, but missed that if you can keep it going for two years at least the managers escape with some decent money.
I liked parts of this and disagreed with other parts.
Perhaps the part I agreed with the most is "don't hire too fast". It's difficult for me to think of a startup (or, honestly, any company) that failed or experienced pains from hiring too slow, but I can think of tons of problems (often from personal experience) from hiring too fast.
One piece I couldn't help roll my eyes at is the "don't use Jira" bit - like the sun rising in the East, bashing on Jira is the favorite past time of engineers. Depending on your type of startup, Jira may be a great tool for the job. E.g. if your company has lots of different workflows it needs to support, it can be very easy to waste a ton of time due to "dropped balls" if things aren't tracked well and issue ownership isn't explicitly clear. Of course, it's easy to waste a ton of time over-complicating Jira with a million unnecessary issue states, but IMO Jira has made it much easier for small teams to use it and be productive quickly (i.e. team-based projects). I'm also not saying Jira is the best tool to start with (my last startup stated with Trello and it worked well), but once you get into production and have a lot of operational issues to manage and prioritize alongside new feature development, you're likely going to need some Jira-like tool to keep everyone aligned and informed.
1. Toxic team members who can't be fired. These people will reduce morale down to zero and force your best people to leave. In one case it was the CEOs long-time friend, and in the other case it was one of the technical founders. If you find yourself as an employee in a similar situation, then go ahead and pack things up because it will never get better.
2. Selling to Fortune 500s without investing in a sales team. Basically, we built it and they never came because B2B at this level is much much different than B2C. So if this is your move then your sales team should be bigger than your engineering team by at least 2x.
3. Toxic team members in recruiting positions. I once worked with a business partner whose recruiting strategy boiled down to bullying people into joining the company. After a year's time we had a solid 12 person engineering team while the business team was exactly the exact same as when we started.
4. Focusing too much on writing code and not enough on building relationships in your domain. When it comes time to sell, you will need to reach out to someone, so start nurturing relationships early.
For #1, see the book "The No Asshole Rule". Does a great job at expanding on this. It happens not just with nepotism, but sometimes because management legitimately believes the employee is valuable. But you have to look at net impact on the org and not just individual impact. You can have an exceptionally talented engineer that chases everyone away due to horrendously toxic teamwork.
By employing high-pressure sales tactics to trigger fomo in candidates, except it never worked. He climbed the ladder at a well known tech company, almost to the very top, and tried to use those same "skills" in a startup context.
1. Go from "more to gain" to "more to loose" thinking.
2. Growth slows and either ethics or vision are sacrificed.
Both of these are natural, and the people will have to change. In most companies, eventually growth stops (at least growth driven by the original vision). Eventually you really do have more to lose than gain. The signal these transitions are happening can be spotted by proliferation of guardrails and process controls, and a cultural change towards risk aversion. The drive is to make everything predictable, controlled and safe. The focus is no longer on acceleration, and is on momentum.
Oh my god! This is like someone in my company writing about my org!! We offer a game platform. We have merely a few hundred people in the infra org. Yet we run like a 300-thousand-people company. Even a god-damn internal tool owned by a fucking single engineer in a sub-team needs to be "aligned" with other orgs. The Infra org, I mean the *internal" infra org, has a PM who draws boxes for engineers to build and has huge influence and therefore power over any engineer in the org. What the author writes rings true in every word, except item #5: "After 3 months quietly toiling, you ship something.". In our org, we toil for at least 3 quarters to ship something because everyone has to be busy to align.
A comment below says "Go from "more to gain" to "more to loose[sic]" thinking.", which summarizes the mentality of my org. If anything, it's not "more to lose", but "everything to lose", which saddens me greatly.
How this can be made even worse is when you have a startup company that in principle operates like a large company because it wasn't founded on equal terms by all employees as a group, but started by one or a handful of people that fund and hire everyone else.
There is no skin in the game as there's no stock options nor revenue share (founders want to keep it all for themselves ofc) and you can be fired on a dime without any due process, software proprietary and closed source of course, so you can't use it for your own stuff either.
Only the PM spends hours on the phone talking to users and then gives you a direct task to work on. The task is always max priority and comes in randomly so you must drop whatever you were doing before to immediately implement it, usually getting the next one before the previous one is even done, making sure that critical tasks inevitably get forgotten and end up at the bottom of the backlog, leading to catastrophic software cohesiveness.
Working on something you want? Haha, right. Do what you're paid to do, no exceptions. Coworkers of course all remote or hybrid so there's no meaningful cooperation and endless Jira review meetings to tell everyone what to do. Daily progress reports of course, gotta make sure people aren't slacking.
> But no incentive is as good as a fat chunk of equity + the power to influence its value.
Meanwhile your sales team colleagues get their incentives paid out right away, in the very next quarter, and instead of equity lottery tickets it’s just cash.
I’d like to see engineering get some of the types of cash incentives that sales teams get. Perhaps the only reason they don’t is because it’s too hard to come up with metrics to base commission on. Instead, they rely on equity awards even though the value of the company is often quite detached from the quality of the software.
The fun of a startup is nice but it’s probably not worth it if you’re getting below-market compensation, crappy healthcare, long hours, and the IOU of an equity stake that’s probably crafted by financiers to screw over regular employees.
It's not too hard to come up with bonus structure for engineers. Managers have bonuses for team targets at tech companies. The mistake is that those bonuses don't trickle down to the team. That's how it works in the oil field. There are bonuses for on time or early well completion. And everybody, even the newest roughneck, gets a cut of the bonus.
i'll chime in with a personal experience. I joined a highly technical startup (think C++ and CUDA) with an incredible engineering team. Now hire a bunch of strategy/business/sales/success workers, create two tiers of society, and ensure the engineers get thrown into the back room. Great way to make a startup lose spark.
Here is a specific example: schedule the company holiday party the night before the one major software release of the year so all the engineers are sitting at the party with heavy GPU laptops coding away on build issues after bug fixes.
Here is another specific example: recently hired workers on the business side become Directors and VPs three out of undergrad while engineers waiting for years for promotions are not given any.
"And as tools (especially AI) get better, the number of users a small team can support increases. Founders of the future may not need to worry so much about these scaling pains, and work may become fun for everyone"
Except fewer of your users will have jobs because the AI multiplier means smaller teams. So your addressable matter will shrink. So another race to the bottom?
Except more of your users will have jobs because the AI multiplier means new opportunities to provide cheaper services available to more businesses, new companies that weren't economical before will be founded, entire new markets and whole new professions will be created. So your addressable market will exponentially grow. So another bull run?
I'm currently consulting for a logistics/wholesale company that uses AI to massively cut down on product catalog management and vendor/customer support costs. Their services are now affordable to much more vendors. It's been a month or so in production and they have already onboarded many new SMB vendors who previously didn't have the means to pay for their services - and thus couldn't sell nor ship through my client. The cost of onboarding a vendor has decreased 100x thanks to using AI instead of doing it manually and it's not limited by headcount and personal schedules.
The products of these new vendors are now available to many big customers in a major city (a single one where we are doing a pilot), and the vendors are reporting they are already getting 2 times the volume of orders they used to get. They didn't even have the means to deliver that much product before - now they are able to do it because their logistics are handled for them by my client (economy-of-scale advantages) instead of them DIYing it, and they use the freed time to do more of their main business.
The customers are super happy because now they're getting fresh food produce from local farmers just days after it's been actually produced, which increases the quality of their products (food in restaurants/catering, usually) and they are already getting significantly more positive reviews thanks to that, which brings them even more new business of higher value. And funnily enough, the products they are getting are cheaper than what they got before, even though the quality is incomparable.
AI is a huge win for everybody involved:
- My client is no longer forced to deal only with the biggest vendors.
- The employees who used to do sales/onboarding, vendor/customer support and product catalog management are still doing it, only now they're handling 10 times more products from 3 times more vendors, and focus on special and more interesting cases instead of doing grunt work.
- The vendors have gained more customers than they ever dreamed of, make more money per unit and have much cheaper logistics that they don't need to think about nor spend their time on (we're talking about guys who used to hop in a truck themselves to deliver their stuff).
- The customers are getting much better quality for lower price per unit. There's also much more product categories they can choose from now.
- It's more environmentally friendly and supports the local economy.
AI has been around for the last 300 years of recorded history of technological progress? Or is every piece of technology guaranteed to make life easier? Did the slap chop markedly improve people's lives?
I understand theirs optimism (and pessimism), but optimism in and of itself doesn't make something true.
Awareness barely helps, it's the tragedy of the commons. I can't think of a solution other than regulation. But then if some countries regulate and others don't, you're right back at the tragedy of the commons at the international level.
Reminds me of the Mass Effect games, where AI is essentially outlawed (because they revolted against the humans of course, but I can picture less scifi-ish reasons in the real world). I'm sure they're still allowed to use pathfinding algorithms and such, so they probably defined a level of net negative (to society) AI and just regulated that. Starships for example are manually piloted (surely with intelligent support systems and basic auto pilots) IIRC.
Fair, not the best example of regulation countering the tragedy of the commons, because it's just made up. Unfortunately, any real world examples I can think of (nature preservation, gun control, ...) are seemingly controversial.
Isn't the tragedy of the commons how developing technology consumes our attention spans?
Human attention span is a finite resource (we can only do so much in one life), and tech startups can consume a lot of that for relatively little payoff. Building a successful startup is like solving the bitcoin hash on your first few cycles. The barrier for entry is low, but you can hit it big (and consume a lot of cheap, finite* power too).
The payoff is worth the risk since our communication technology is nascent and underexplored. We have an abundance of time right now because of what tech has done for us, but the cultural and environmental costs of growing tech are not well understood.
Use of attention span is difficult to measure right now, but that could change in the coming decades. That said, parent comment seems to use "tragedy of the commons" as a stand in for "human nature."
The goal of the company was to provide standard ways to calibrate engineer levels for promotions and performance management.
Guess what happened: Most managers started rating engineers on exactly that rubric. If you miss something in the rubric, you get a lower rating. So engineers started following the rubric precisely. Which meant, every senior engineer spent more time on managing 2-3 junior engineers. Wrote at least 1 RFC every 6 months. And basically checked boxes on the sheet so as to not miss out anything during a performance review.
Nothing got delivered from the team. Morale in the team dropped. And nothing really mattered except the career ladder document.
Engineers spent more time managing the career ladder document than actually delivering anything.
Managers spent more time rating people than actually delivering anything.
Features were half-assed, customers started getting frustrated. And clueless upper management started putting more pressure on engineers instead of looking at themselves and asking how they can improve processes.
Another failure mode: Not being allowed to choose who you work with.
Early on, you joined the company knowing exactly who you get to work with. You were probably involved in hiring for a while too.
But at some point 100+, you’re put on a team with people you’d never met, never hired, and might not vibe with.
A direct, “let’s hit the ground running” attitude runs up against a ex-FAANG person with softer personality, prefers a “compliment sandwich”, and wants to write a 50 page technical specification before getting started.
I convinced myself these days that companies going to a size of more than 30 people or so automatically unavoidably switch into lower gears where workflows start to pile up a lot of friction, and politics start creeping in from all directions, thereby degrading satisfaction for everyone in their jobs and losing on the efficiency front.
Not to mention the deliverability of software gets affected negatively with more and more contributors to code and things becoming "legacy". More time gets wasted on managing tasks, tickets, meetings, project management, and simple things end up taking exponentially longer now. I feel it's basically the killing of fun in running a startup.
Companies that grow naturally form a kind of immune system that fights all kinds of change. That's just the way it is.
I guess the lesson to be learned is to be very careful when scaling up your organization. Past a certain point change becomes very difficult. I.e. only grow headcount above 100 when you're certain about product market fit.
As soon as you start dealing with large customers, these things become inevitable. People can’t start doing whatever they like because it becomes riskier to do it. What might be good for that one customer may not be good for the big customers you actually need to keep to make a profitable business. Big customers always want to know about the roadmap.
That depends on what kind of large customers you're doing business with.
If a customer is large enough, and their pockets deep enough, you can absolutely justify building what is good only for that customer, and shipping it only to that customer. Keep that branch separate from the general-purpose product you're selling to the pleebs.
I've seen several companies think this is a good idea but in practice it's a really bad idea to do this because you get captured by the customer and effectively become an arm of them without the benefits. And you end up dedicating so much time to them that other customers won't be happy and if that big customer ever cancels or leaves (which is often a board cost cutting decision rather than a user decision), then you end up absolutely screwed.
I think that’s probably still reductive — in some environments (like a couple years ago), it was very hard for companies, especially startups, to lure in talent.
Perhaps, though, if you only hire when you need, you can be more competitive with pay.
New ideas getting shot down for fear of cannibalizing existing revenue.
The product that was the breakthrough is likely (somewhat) wonderful and loved (or at least used) by many and generates the bulk of your revenue. However we all know that solution that has gotten you this far has problems and there are many ideas to be able to go to the next level.
But any idea that is seen to take away from the focus of that main revenue generator will be fought unless there is VERY strong leadership. Anything "new" will impact marketing budgets, Sales incentives and revenue goals, threaten those who are working on the "legacy" project, not to mention external forces who are only interested in the bottom line revenue and EBITDA numbers for the next quarter, not the next 1, 3 and 5 years.
I've had this happen at 2 startups I've been through. Both had successful exits, but could've been more and build a much better future path for themselves.
I particularly don't understand why an organization would hire a PM for an internal infra team. It's like hiring a PM for Go to design the features of Go. Funny enough, executives from Google love to do this kind of things. I'd thought Google's infra engineers would be perfectly capable of driving the features of their infra services.
The article mentions Rippling as still having that 'spark', but they've been pretty awful the past few months. Between layoffs and data loss, it's looked pretty dire when I've talked to them.
> Is this preventable? I think not. If you look closely, all these problems fundamentally come from…
It is preventable.
I built an ISP in mid-90s, a digital agency in late 90s, another digital agency and a streaming CDN (world's first VDN) in 00s, as well as worked as chief architect for cloud at world's largest hedge fund and CTO of world's second largest bank. I'm currently an entrepreneur again, co-founding and building a hedge fund from scratch.
My experiences across these, particularly at the digital agencies (where I got to help hundreds of clients go through growth) and the mega bank (where I got to see how things working when small can also work somewhere global), tell me all the goodness from the initial list can be built into the operating model, with a couple caveats.
These are hard[^1]:
1. No domain versus technology divide. If you hear "The business wants..." or "I need I.T. to..." it's not going to work. At a fintech, for instance, all teams should have both fin and tech on the team, owning their outcomes.
2. No command and control managerialism better suited for piecework than building. No project managers. No scrum-masters. Importantly, and apparently pure heresy: no projects.[^2]
Instead of projects, think, what should we do better?
Instead of controlling for budgets and delivery dates, control for focus (like priorities but mostly about saying "no" to things instead of "yes" to everything with stack ranking) and outcome value (e.g. RoI or RoE instead of hitting dates). Then you can manage the money as investments in teams delivering outcomes, instead of budgets for projects.
Hitting dates well becomes easy and fun/rewarding when you scope using focus instead of pre-defining all (probably imperfect) requirements and you ensure teams are equipped with people (will, skill), and resources (tools, space) to own outcomes. (If people are called resources, run away.)
It is preventable, and I'm happy to talk live with anyone building a work management tool that is interested in our approach.
[^2]: You can do time-boxed work with an outcome. That could look a lot like a project. But the word “project” tends to bring with it a pile of practices that all kill the intrinsic motivation for building things you're proud of.
It's interesting even companies as smart as Linear (the Jira alternative, check out their Linear method pages for a lot of better than usual thinking) don't want to even listen why they should (and could just by allowing renaming a few terms in their tool) support a non-project-centric view of building your company and enjoying doing it.
Wow - I’ve been thinking very closely to what you describe here, but never completely pieced it together until I read “No projects”. You’re completely right. I find that often process is used as an excuse to ignore outcome ownership - even if things didn’t work out, well at least we can say we did things by the book. No one is at fault, and no one needs to learn from it.
> Instead of controlling for budgets and delivery dates, control for focus and outcome value. Then you can manage the money as investments in teams delivering outcomes, instead of budgets for projects.
Maybe if you sell to end users. If you have clients with SLAs, requirements etc and legal penalties for missing them, not working to delivery dates isn't going to work. Even in teams with projects, ensuring deadlines are met is still tricky.
What pile of practices are you trying to avoid? When I see time boxed work with an outcome, that’s the very definition of a project to me. There’s nothing else. I had a weekend project building a desk. It’s timeboxed to the weekend. There’s an outcome. What am I missing?
On the contrary, "time box" means the time is fixed, the work achieved is variable.
Projects: the project comes in "on time and under budget" or is "late", but the work is fixed.
Time boxes: The difference is if you are targeting an RoE curve, you can decide when to continue investing in that or pivot to something else. You pick a date to re-evaluate. This is how VC work with startups.
You also make sure have minimum viable outcome well before that re-eval date, and then viable increments. It's effectively just CI/CD for outcomes!
I should mention that by running a video streaming VDN, in the 00s we carried the world's largest streaming events white labeled for other CDNs. TV deadlines are real: the Oscars, or the State of the Union address, are happening when they happen. So you can have to deliver outcomes in a time frame. The way to always always hit that, never miss it, is let the work within that outcome, the "definition of done" be the variable. Somewhere inside the effort is a minimum viable outcome. Ship that, then iterate until your date or additional effort is below your RoE bar.
Managers love to invent deadlines to "motivate" a team, and everyone pretends they don't know the deadlines are nonsense. Actual deadlines -- if you're not working, you're dead -- teach you a different way to work.
A project tries to fix both work and date, which doesn't work and is rarely on time.
A time box fixes the date, not the work. Iterative delivery always hits the date and generally works.
---
Using your weekend desk example:
You could want a wood inlay desk.
For the "job to be done", the desk has to support you doing work.
In this toy example, the wood inlay is a desired constraint, not a required constraint. Business analyst will still call "wood inlay" a requirement, even though that "requirement" might lot let you ship a viable desk within the weekend.
If you do the work project style, you might work the wood inlay for each panel before assembling them into a desk.
The problem is, until you assemble it, the desk isn't a desk, it can't do the job to be done. If inlay takes longer than you thought, because it's your first time doing it and you had to research and built a couple test panels to throw away, then when the weekend is over, you have no desk.
If you do it time-box style, and if "usable desk" is the required constraint, you might assemble the desk first, then do the inlay. Or you might design the desk where panels can be removed and inlaid whenever. Either way, if you ran out of weekend, you can already use the desk, just not fully inlaid.
Certainly, doing the inlay after assembly will require more effort.
So then ask yourself, was the deadline real, or was the inlay requirement real?
If you know in advance that desk with inlay is the absolute requirement, you're willing to take two weekends instead of one, so then the deadline wasn't real.
---
What's funny about this is, within a firm, everyone would jump on me and say the desk and the inlay are requirements.
But if you don't know how to build desks, and need a vendor to provide it, you suddenly become tolerant of the differences in soft and hard requirements.
Say you have to work from home, and you want a desk with inlay, but can't get one in time. You will iterate instead!
You'll work at a table (the minimum viable desk) immediately and for a while, then maybe iterate to an Ikea desk while the custom one is ordered and hand crafted, then iterate to your custom desk with inlay when it arrives, with the added flexibility of arranging shipping to deliver when it's most convenient.
If we handled work among groups internally the same way we understand we have to handle work among groups when we can't control them, companies would have a lot less jank.
I understand what you're saying. I just don't understand what makes it a project vs. not. Fixed-scope projects, fixed-time projects, projects that are fixed in time and you have to fight the stakeholders on in scope... these are all projects with different features.
It sounds like you prefer to work in an env where there are only fixed-time, variable scope projects. I like that better too.
For the layperson definition of project, of course you're right.
The problem is the professional definition of project, which comes with project management practices and preconceptions.
Those are generally harmful, because they try to manage or control both time and resources needed to deliver unknowns in advance of an inherently discovery-based process that results in (re-)scoping as you learn:
> It sounds like you prefer to work in an env where there are only fixed-time, variable scope projects. I like that better too.
I posit it's not just "prefer", it's reality. That all "projects" are in fact "fixed time, variable scope" in hindsight. In other words, "it takes as long as it takes" to uncover and ship a minimum viable scope for the "job to be done".
As an entrepreneur, it's preferable to create a workplace that acknowledges that reality up front, and designs the "way of working" for it.
As an engineer, it's preferable, as you note, to join one.
---
Some more musings:
The OP's post says work stops being fun. A key reason why is all the unfortunate beliefs, management overhead, and recrimination for practices trying to override reality and failing.
Small startups don't care. The cost of 5 people being wrong seems irrelevant compared to charging at the problem and getting it done, or finding out it doesn't work so you can pivot. How many "Show HN" are after a pivot? How many "Launch HN" for that matter?
Enterprises care. The cost of 500, or 5000, building the "wrong thing" seems unacceptable (even if less cost per person!), so big companies keep piling on layers of risk management that delay getting in touch with reality.
One reason they do this is the value of the outcome isn't clear. Perhaps it's political, perhaps it's make-work to keep someone's department full sized, perhaps it's a failure of imagination. So they develop scar tissue about shipping multi-year boondoggles that deliver no value. The problem was, it wasn't valuable in the first place, and if they'd just tried it out in the small and iterated, they'd have learned with fewer man-hours than all the planning.
For a great take on this, see Tom DeMarco (author of Peopleware) rethinking his entire stance on projects after 50 years(!) trying to tell people how to project-manage better:
He even throws in the towel on estimation with the now famous phrase, "All projects that finish late have this one thing in common: they started late."
He effectively accepts reality: the needful is the needful, the value is the value, so if it's valuable you'll do what you have to do, just start already and get it done.
What I've found is, a big enterprise can understand this. The CEO can hold his business leaders accountable to telling the value that an effort should generate, the CFO can "venture capital" an appropriately sized investment in a fixed capacity team, and the team can focus to deliver value -- or offer a pivot -- before they run out of funding and can't raise another round.
If they're shipping well, and getting market traction, the business leader looks good, the CEO is happy, and the CFO can continue to invest. One neat thing with this is the remarkable "budget" predictability that comes with investing in teams instead of in projects. Control your capacity and focus, you'll always hit your expense numbers, with net higher RoE as a nice side effect. So not only are customers getting value early, boards and shareholders are impressed with "hitting the numbers".
So this solves that iron triangle.
By continually focusing in on shipping what brings high RoE, you can let "the business" pick any arbitrary amount of time (quarterly? annually?) to announce sets of new features as releases. You can keep teams steady and employed delivering instead of wastefully scaling up then laying off as if tacit knowledge loss didn't have a cost.
And people can feel good about building value they can see as they work.
> [At larger companies...] Talking to users is for PMs, silly! You stick to what you’re good at. At best you get a summary of user insights and a reasonable task priority list derived from it. At worst you get a confusing task list built off a mistaken understanding of users and the manager’s selfish vision, and no one can explain why each task matters.
Not necessarily. At the large companies I've worked at (>200 people), a UXR will drive the interview process with users, starting with compiling a list of questions from engineers, then conducting the interview sessions with users in which engineers can sit in, and then disseminating the insights and setting up a meeting to make the insights into a actionable engineering projects.
Working with UXRs is a dream, as they're trained to conduct interviews in an impartial way, leading to insights that are less biased and higher quality. Contrast to when I worked for startups and I or someone on my team would interview users, very often the feedback would end up contaminated because the interviewer would ask the wrong question, projected their biases into the questions, or even worse into the insights.
Y Combinator has helped the world realize that inspiration should go the other way--large companies should try to operate more like startups.
What is the survival rate of companies <5years? What is the survival rate of companies >50 years? The author himself points out that as your organization grows, you become more risk-averse. You have more to lose, but that also means you have something.
When John Qian throws 60% of his total assets at a problem, you can get a few intoxicated engineers to work hard at it and have a lot of fun doing it. What if Amazon, or Home Depot, threw 60% of their assets at an entirely new idea every few months? It doesn't make any sense.
Startups fail all the time because they are doing risky things. Successful businesses take less risk and fail less often. You're taking a strategy that has proven to not work and saying it should work.
> At a well-run seed stage startup, engineers will often describe the work experience as intoxicating. At a larger company, the best you get is "enjoyable". Why does this happen? Is it inevitable?
Oh cool, I can work super hard to make someone else a bunch of money! What an exciting prospect. At least let me put on some clown makeup first
There is an incredible important step missing: find a viable business model. Getting ideas and building them is "relatively" easy (just look at the vast open source ecosystem) for engineers but integrating/pairing/merging them with a business models that generates revenue within a limited time period is hard.
Ok, so a simple solution is to compose your larger company of a bunch of startups that remain to operate as such, no matter what the larger company does. So anything that runs on top of these startups acts as a customer of these startups.
Yikes, scaling up certainly sucks, but the article is rather over the top and defeatist about their experiences. Many companies and teams don't dovetail into the pandemonium described, but doesn't mean that the general sentiment is wrong. Scaling a company is a non-zero operational cost, and and it's largely impossible to be relevant and involved in all aspects of the business (unless you're bill gates in the 90's), but for those that can compartmentalize their aspect of the larger picture, good times can be had in large companies.
The article even reaches the conclusion that granting more ownership to employees might be a solution. What an idea! You could make a new mode of production out of this.
I think there's an inflection point at around 40 employees where terminal velocity starts to slow down due to a combination of sheer headcount and founder exhaustion.
It's something I've personally seen and have read about so many times. Some make it through this stage but it's extremely difficult because it requires a very different set of skills and experiences. It becomes less about grinding, which in theory is very simple to explain and encourage.
Love the summary, don’t agree org entropy is inevitable and also don’t agree that equity is a silver bullet. Many times the cure is worse than the disease, it creates a whole bunch of behavioral anti-patterns e.g. people sticking around too long, politics and grandstanding in order to win more equity.
In my experience profit-share provides same positive incentives without the downsides.
Sure fine but if the question is 'how does an engineer know what's good to do' the answer is, "get good". Ask questions, learn what's important, and think about more than code.
That's naive. A competent well rounded human is far more of an asset than an engineer who can't handle anything else. I would never want to work with an engineer who had no good sense about anything else unless I had to, like if there was some skill only they had.
Great soapbox; not at all how the real world of startups operates, however.
If you have a nonfounder engineer, that person for sure shouldn’t just be doing whatever it is they feel like doing. They need to allow the founders to drive.
Nobody claimed or believes that an engineer "should be doing whatever it is they feel like doing". You've misread what you're arguing against and assumed it is saying something it very much isn't.
"If you find an idea that you think is both valuable to the company and interesting to you" means just that; you. Not your partner, not your boss, not anyone else. You.
The comment is wrong, both in theory and in practice.
Engineers at small startups are generally founder minded. They’re like founders, and are passionate about the product and the problem. That’s how they get to decide/involve in the decision about what to work on
Great points. I agree with everything but I'm not sure about the conclusion that work will be fun for everyone. I don't think there will be work for everyone. The author implies that but saying that with AI startups can do more with fewer people, which I agree. The author also recommends to hire less. Yes, there will be more companies but the question is how the average person will be able to compete. If companies don't need many people they will become more selective.
In such a world progress is made faster and companies are solving more meta-problems. That is why people hand crafting html for their local businesses is no longer a thing and that kind of work is almost non technical now.
