How a startup loses its spark

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.

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&#x27;ve worked with were not &quot;intoxicated&quot; 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.<p>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&#x2F;employee relationship.

I&#x27;ll raise your spark for complete destruction.<p>Here&#x27;s an incomplete list that I keep around of the mechanisms that I&#x27;ve observed so far that have played a big part in the decline&#x2F;destruction of an engineering team (and product thereof):<p>1. Too-technical leaders:<p>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 <i>engineers</i> 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.<p>2. Non-technical leaders:<p>Inverse to the above - as startup scales, in desperation, new leadership roles are filled with <i>non-technical</i> individuals who have little to no engineering experience. This causes similar outcome to #1 (albiet slightly different, but equally perilous).<p>3. Problem engineers:<p>Small number of leaders lack a spine, conducting shallow interviews and let in &quot;problem engineers&quot; who spoil the party and wreak havoc. Lax hiring practices almost always are reflected into non-existent firing practices, leading to them lingering around.<p>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...<p>4. Micromanagement:<p>Speaks for itself. Leads to red tape, demoralization, timeline slippage and frustration.<p>EDIT: I&#x27;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&#x27;s nib...

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.<p>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.<p>I’ve burned out though on building these teams. It’s absurdly hard work on management. But management is <i>supposed</i> 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.

It almost feels like the &quot;efficiencies of scale&quot; you get from large organisations (e.g. specialised people for recruitment, people matters, quality assurance, user research etc.) are not really efficiencies. Perhaps it&#x27;s better to grow the organisation by repeatedly cloning the smallest effective team you ever had, rather than creating a more &quot;efficient&quot; organisational structure. How those &quot;mini-companies&quot; communicate with each other efficiently -- another matter.

&gt; 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.<p>This is painfully on point.

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.<p>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 &quot;team players&quot; instead of good engineers, rewarded loyalty over competence, and hilarity ensued. And then we were acquired.<p>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>I</i> thought was important. And that wasn&#x27;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.

The book Loonshots by Safi Bahcall describes this phenomena quite well. There&#x27;s a &quot;phase transition&quot; of incentives at around 150 people that can be fatal to many organizations.<p>The secret sauce is how a startup goes past this headcount. Ideally many software companies quite honestly don&#x27;t need more than 150 people!

&gt; hire less<p>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.<p>Unfortunately, the funding environment and growth expectations for startups often incentivize the opposite behavior.

I liked parts of this and disagreed with other parts.<p>Perhaps the part I agreed with the most is &quot;don&#x27;t hire too fast&quot;. It&#x27;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.<p>One piece I couldn&#x27;t help roll my eyes at is the &quot;don&#x27;t use Jira&quot; 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 &quot;dropped balls&quot; if things aren&#x27;t tracked well and issue ownership isn&#x27;t explicitly clear. Of course, it&#x27;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&#x27;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&#x27;re likely going to need <i>some</i> Jira-like tool to keep everyone aligned and informed.

The failure modes I&#x27;ve encountered:<p>1. Toxic team members who can&#x27;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.<p>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.<p>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&#x27;s time we had a solid 12 person engineering team while the business team was exactly the exact same as when we started.<p>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.

Startups lose their spark when they either:<p>1. Go from &quot;more to gain&quot; to &quot;more to loose&quot; thinking.<p>2. Growth slows and either ethics or vision are sacrificed.<p>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 &quot;aligned&quot; with other orgs. The Infra org, I mean the *internal&quot; 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: &quot;After 3 months quietly toiling, you ship something.&quot;. In our org, we toil for at least 3 quarters to ship something because everyone has to be busy to align.<p>A comment below says &quot;Go from &quot;more to gain&quot; to &quot;more to loose[sic]&quot; thinking.&quot;, which summarizes the mentality of my org. If anything, it&#x27;s not &quot;more to lose&quot;, but &quot;everything to lose&quot;, 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&#x27;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.<p>There is no skin in the game as there&#x27;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&#x27;t use it for your own stuff either.<p>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.<p>Working on something you want? Haha, right. Do what you&#x27;re paid to do, no exceptions. Coworkers of course all remote or hybrid so there&#x27;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&#x27;t slacking.<p>The result is 100% turnover.

&gt; But no incentive is as good as a fat chunk of equity + the power to influence its value.<p>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.<p>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.<p>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.

i&#x27;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&#x2F;business&#x2F;sales&#x2F;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.<p>Here is a specific example: schedule the company holiday party <i>the night before the one major software release of the year</i> so all the engineers are sitting at the party with heavy GPU laptops coding away on build issues after bug fixes.<p>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.

&quot;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&quot;<p>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?<p>I&#x27;m sure we&#x27;ll work it out right..

At a past company, we went from 3 promotion levels to 10. There is a document that outlines what engineers at each level should be working on, much like <a href="https:&#x2F;&#x2F;substackcdn.com&#x2F;image&#x2F;fetch&#x2F;f_auto,q_auto:good,fl_progressive:steep&#x2F;https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fbcff882f-083e-4512-b91e-36fc0a117134_1348x1270.png" rel="nofollow noreferrer">https:&#x2F;&#x2F;substackcdn.com&#x2F;image&#x2F;fetch&#x2F;f_auto,q_auto:good,fl_pr...</a><p>The goal of the company was to provide standard ways to calibrate engineer levels for promotions and performance management.<p>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.<p>Nothing got delivered from the team. Morale in the team dropped. And nothing really mattered except the career ladder document.<p>Engineers spent more time managing the career ladder document than actually delivering anything.<p>Managers spent more time rating people than actually delivering anything.<p>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.<p>Early on, you joined the company knowing exactly who you get to work with. You were probably involved in hiring for a while too.<p>But at some point 100+, you’re put on a team with people you’d never met, never hired, and might not vibe with.<p>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.<p>Not to mention the deliverability of software gets affected negatively with more and more contributors to code and things becoming &quot;legacy&quot;. More time gets wasted on managing tasks, tickets, meetings, project management, and simple things end up taking exponentially longer now. I feel it&#x27;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&#x27;s just the way it is.<p>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&#x27;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.

I think the best takeaway here is - don&#x27;t hire until you absolutely have to.

New ideas getting shot down for fear of cannibalizing existing revenue.<p>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.<p>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 &quot;new&quot; will impact marketing budgets, Sales incentives and revenue goals, threaten those who are working on the &quot;legacy&quot; 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.<p>I&#x27;ve had this happen at 2 startups I&#x27;ve been through. Both had successful exits, but could&#x27;ve been more and build a much better future path for themselves.<p>Now trying to avoid this in my current home.<p>What if Apple had stopped the iPhone for fear of it cannibalizing* the iPod line of products revenue? * <a href="https:&#x2F;&#x2F;www.imd.org&#x2F;research-knowledge&#x2F;economics&#x2F;articles&#x2F;apples-dwindling-sales-show-importance-of-self-cannibalization&#x2F;" rel="nofollow noreferrer">https:&#x2F;&#x2F;www.imd.org&#x2F;research-knowledge&#x2F;economics&#x2F;articles&#x2F;ap...</a>

&gt; Talking to users is for PMs, silly!<p>I particularly don&#x27;t understand why an organization would hire a PM for an internal infra team. It&#x27;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&#x27;d thought Google&#x27;s infra engineers would be perfectly capable of driving the features of their infra services.

The article mentions Rippling as still having that &#x27;spark&#x27;, but they&#x27;ve been pretty awful the past few months. Between layoffs and data loss, it&#x27;s looked pretty dire when I&#x27;ve talked to them.

&gt; <i>Is this preventable? I think not. If you look closely, all these problems fundamentally come from…</i><p>It is preventable.<p>I built an ISP in mid-90s, a digital agency in late 90s, another digital agency and a streaming CDN (world&#x27;s first VDN) in 00s, as well as worked as chief architect for cloud at world&#x27;s largest hedge fund and CTO of world&#x27;s second largest bank. I&#x27;m currently an entrepreneur again, co-founding and building a hedge fund from scratch.<p>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.<p>These are hard[^1]:<p>1. No domain versus technology divide. If you hear &quot;The business wants...&quot; or &quot;I need I.T. to...&quot; it&#x27;s not going to work. At a fintech, for instance, all teams should have both fin and tech on the team, owning their outcomes.<p>2. No command and control managerialism better suited for piecework than building. No project managers. No scrum-masters. Importantly, and apparently pure heresy: <i>no projects</i>.[^2]<p>Instead of projects, think, what should we do better?<p>Instead of controlling for budgets and delivery dates, control for focus (like priorities but mostly about saying &quot;no&quot; to things instead of &quot;yes&quot; 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.<p>Hitting dates well becomes easy <i>and fun&#x2F;rewarding</i> 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.)<p>It is preventable, and I&#x27;m happy to talk live with anyone building a work management tool that is interested in our approach.<p>---<p>[^1]: see wicked problems: <a href="https:&#x2F;&#x2F;en.m.wikipedia.org&#x2F;wiki&#x2F;Wicked_problem" rel="nofollow noreferrer">https:&#x2F;&#x2F;en.m.wikipedia.org&#x2F;wiki&#x2F;Wicked_problem</a><p>[^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&#x27;re proud of.<p>It&#x27;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) <i>don&#x27;t want to even listen</i> 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.

&gt; [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.<p>Not necessarily. At the large companies I&#x27;ve worked at (&gt;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.<p>Working with UXRs is a dream, as they&#x27;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.

Decent analysis, but what kind of solution is “don’t use Jira” with no alternative suggested?<p>Jira is a fine tool in and of itself, just don’t turn it into a religion.

Y Combinator has helped the world realize that inspiration should go the other way--large companies should try to operate more like startups.<p>What is the survival rate of companies &lt;5years? What is the survival rate of companies &gt;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.<p>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&#x27;t make any sense.<p>Startups fail all the time because they are doing risky things. Successful businesses take less risk and fail less often. You&#x27;re taking a strategy that has proven to not work and saying it should work.

&gt; 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 &quot;enjoyable&quot;. Why does this happen? Is it inevitable?<p>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 &quot;relatively&quot; easy (just look at the vast open source ecosystem) for engineers but integrating&#x2F;pairing&#x2F;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&#x27;t dovetail into the pandemonium described, but doesn&#x27;t mean that the general sentiment is wrong. Scaling a company is a non-zero operational cost, and and it&#x27;s largely impossible to be relevant and involved in all aspects of the business (unless you&#x27;re bill gates in the 90&#x27;s), but for those that can compartmentalize their aspect of the larger picture, good times can be had in large companies.

If only some guy wrote about alienation from labor. That would be crazy.

I think there&#x27;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.<p>It&#x27;s something I&#x27;ve personally seen and have read about so many times. Some make it through this stage but it&#x27;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.

When companies get bigger you likely don’t want to use spark to continue building it out

&gt; If you find an idea that you think is both valuable to the company and interesting to you, you can just drop everything to work on it.<p>What.<p>How is an engineer deciding what to work on like this, even at a small startup?!

I think Apple does a great job at this too, they under hire and operate each team as a small startup.

The stability of the business can make startup companies lose their fighting spirit.

Brilliant short essay that captures the maturity changes and challenges.

Amen, less headcount more founders! Bootstrap!

OK imagine you’re the founder of a fast growing startup.<p>How do you organise the software development ?<p>What’s a great way to keep it exciting and fun and productive?

Great points. I agree with everything but I&#x27;m not sure about the conclusion that work will be fun for everyone. I don&#x27;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&#x27;t need many people they will become more selective.