19 ms·

How a startup loses its spark

568 points by _xivi 3y ago

physicsguy 3y ago
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.
- kijin 3y ago
  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.
  - physicsguy 3y ago
    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.
    - kijin 3y ago
      Doesn't matter if you have multiple large customers and "other customers" are rounding error at best. Case in point: Palantir.
tinyhouse 3y ago
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.
- quickthrower2 3y ago
  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.
Werewolf255 3y ago
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.
- deleted 3y ago
  [deleted]
LarsDu88 3y ago
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!
- K0balt 3y ago
  This argues in favor of organizations that hold close to their core business and allow for the additional cost of outsourcing non-core functions.
- mjklin 3y ago
  See Miller’s “Barbarians to Bureaucrats” for a description of the full corporate lifecycle. Barbarian -> builder -> explorer -> administrator -> bureaucrat -> aristocrat.
- Terretta 3y ago
  See also "Dunbar's Number": 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. https://en.wikipedia.org/wiki/Dunbar%27s_number https://en.wikipedia.org/wiki/Dunbar%27s_number The world scaled past this millenia ago. You can scale your company past it too.
- yousif_123123 3y ago
  When they say "100" or "150", do they usually mean total company size or number of engineering+product people?
  - NickC25 3y ago
    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.
adaml_623 3y ago
"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? I'm sure we'll work it out right..
- thumbuddy 3y ago
  If only people could think from outside themselves for two seconds to assess technological impacts like you just have.
  - fhd2 3y ago
    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.
    - throwaway80492 3y ago
      Let's keep sci-fi worlds designed to make a good story out of serious discussion, please. Or let me raise a The Culture argument, where computers/AI is hyper-advanced, AIs are friends, and no regulation whatsoever is needed.
      - fhd2 3y ago
        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.
bhouston 3y ago
Brilliant short essay that captures the maturity changes and challenges.
hliyan 3y ago
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.
- K0balt 3y ago
  This is an intriguing idea. I wonder if the paradigm has a name or a following?
  - bombcar 3y ago
    Isn’t that basically what franchising is?
    - K0balt 3y ago
      Hmm, that is an interesting parallel. I think it misses the mark somehow though. Idk why people don’t like the question, I’m actually looking for a developed model/ paradigm around this concept. No sense reinventing the wheel.
- srcnkcl 3y ago
  k8s the company, infinitely scalable
- toyg 3y ago
  This is what the author suggests towards the end of the piece, and points out some issues with it.
  - hliyan 3y ago
    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.
moffkalast 3y ago
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. The result is 100% turnover.
- esafak 3y ago
  > The result is 100% turnover. Problem solved? Just be sure to leave a note online for potential hires to avoid the company.
simmschi 3y ago
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.
mfwgenerics 3y ago
> 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. This is painfully on point.
- fallingknife 3y ago
  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."
  - naijaboiler 3y ago
    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
lifeisstillgood 3y ago
I think the best takeaway here is - don't hire until you absolutely have to.
- dclowd9901 3y ago
  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.
dangus 3y ago
> 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.
- fallingknife 3y ago
  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.
m3kw9 3y ago
When companies get bigger you likely don’t want to use spark to continue building it out
fnordpiglet 3y ago
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.
- lukaszkorecki 3y ago
  > The arguments articulated are entirely false 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
  - fnordpiglet 3y ago
    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.
Terretta 3y ago
> 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. --- [^1]: see wicked problems: https://en.m.wikipedia.org/wiki/Wicked_problem https://en.m.wikipedia.org/wiki/Wicked_problem [^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.
- 3y ago
deleted 3y ago
[deleted]
flowerpew 3y ago
If only some guy wrote about alienation from labor. That would be crazy.
- handsaway 3y ago
  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.
rm_-rf_slash 3y ago
Decent analysis, but what kind of solution is “don’t use Jira” with no alternative suggested? Jira is a fine tool in and of itself, just don’t turn it into a religion.
- snowstormsun 3y ago
  A fine tool would have a functional full text search...
samhuk 3y ago
I'll raise your spark for complete destruction. 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...
- endorphine 3y ago
  Maybe by avoiding fast scaling, which implies avoiding VC money.
  - WJW 3y ago
    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.
  - Aurornis 3y ago
    The first startup I worked for was a slow-growth company that had slowly expanded over 7 years to only about 50 people. A dinosaur in startup terms. It still had the same problems as above. Expanding slowly doesn’t automatically protect you from these things.
amelius 3y ago
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.
geophile 3y ago
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.
- Aurornis 3y ago
  > 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.
hn_throwaway_99 3y ago
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.
- alexchantavy 3y ago
  +1, I was also confused about the don't use Jira part - what is the alternative that will let dinosaur companies "operate more like startups"?
  - bfelbo 3y ago
    Linear is nice although it’s getting more and more like Jira (read: bloated)
l5870uoo9y 3y ago
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.
jSully24 3y ago
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. Now trying to avoid this in my current home. What if Apple had stopped the iPhone for fear of it cannibalizing* the iPod line of products revenue? * https://www.imd.org/research-knowledge/economics/articles/apples-dwindling-sales-show-importance-of-self-cannibalization/ https://www.imd.org/research-knowledge/economics/articles/ap...
zbentley 3y ago
> hire less 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.
- fidotron 3y ago
  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.
  - quercusa 3y ago
    > sources that require commitment to hiring plans Are these local/provincial development funds that need to show job growth? Any case where "we need to hire someone in the worst way" seems to deliver exactly that.
    - fidotron 3y ago
      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.
Dirak 3y ago
> [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.
- esafak 3y ago
  Untrained people might want to read these books: * The Mom Test: How to talk to customers & learn if your business is a good idea when everyone is lying to you * How to Measure Anything: Finding the Value of Intangibles in Business.
- dwarwick 3y ago
  [flagged]
xtremedata 3y ago
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.
spacecadet 3y ago
Amen, less headcount more founders! Bootstrap!
Zetice 3y ago
> 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. What. How is an engineer deciding what to work on like this, even at a small startup?!
- ajkjk 3y ago
  What do you mean? They just.. Do it? Nothing about an engineer precludes having good sense at other things.
  - Zetice 3y ago
    Nothing about an engineer includes having good sense at other things, either. In fact, many of the best engineers are profoundly bad at figuring out what to work on.
    - ajkjk 3y ago
      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.
      - Zetice 3y ago
        That’s what the non-engineers are doing though, and it’s not work everyone should do. Engineers should do engineering things at startups because nobody else can.
        ajkjk 3y ago
        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.
        3y ago
victor9000 3y ago
The failure modes I've encountered: 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.
- zenlf 3y ago
  How do you bully people into joining a company?
  - victor9000 3y ago
    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.
    - zenlf 3y ago
      I see, thank you. You would assume that one would use tactics accordingly.
- dwarwick 3y ago
  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.
hintymad 3y ago
> Talking to users is for PMs, silly! 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.
indymike 3y ago
Startups lose their spark when they either: 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.
ccorcos 3y ago
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.
rlifer 3y ago
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.
princevegeta89 3y ago
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.
g9yuayon 3y ago
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.
- silentsea90 3y ago
  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?
  - g9yuayon 3y ago
    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.
    - silentsea90 3y ago
      Sounds very cool. Were failures punished by low ratings, bonus? How did they incentivize taking risks? Did the focus on being a leader make you stronger? Were Netflix employees from then valued very highly?
simon_000666 3y ago
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.
- esafak 3y ago
  How? Profits are short term indicators while equity is longer term.
bryanmgreen 3y ago
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.
nine_zeros 3y ago
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 https://substackcdn.com/image/fetch/f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fbcff882f-083e-4512-b91e-36fc0a117134_1348x1270.png https://substackcdn.com/image/fetch/f_auto,q_auto:good,fl_pr... 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.
andrewstuart 3y ago
OK imagine you’re the founder of a fast growing startup. How do you organise the software development ? What’s a great way to keep it exciting and fun and productive?
flimsypremise 3y ago
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.
- deleted 3y ago
  [deleted]
- spoonfeeder006 3y ago
  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
adra 3y ago
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.
mvncleaninst 3y ago
> 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
pixel_tracing 3y ago
I think Apple does a great job at this too, they under hire and operate each team as a small startup.
william_T 3y ago
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.
starsea 3y ago
[dead]
wallist 3y ago
The stability of the business can make startup companies lose their fighting spirit.

568 points by _xivi 3y ago

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.

kijin 3y ago
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.
- physicsguy 3y ago
  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.
  - kijin 3y ago
    Doesn't matter if you have multiple large customers and "other customers" are rounding error at best. Case in point: Palantir.

tinyhouse 3y ago

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.

quickthrower2 3y ago
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.

Werewolf255 3y ago

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.

deleted 3y ago
[deleted]

LarsDu88 3y ago

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!

K0balt 3y ago
This argues in favor of organizations that hold close to their core business and allow for the additional cost of outsourcing non-core functions.
mjklin 3y ago
See Miller’s “Barbarians to Bureaucrats” for a description of the full corporate lifecycle. Barbarian -> builder -> explorer -> administrator -> bureaucrat -> aristocrat.
Terretta 3y ago
See also "Dunbar's Number": 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. https://en.wikipedia.org/wiki/Dunbar%27s_number https://en.wikipedia.org/wiki/Dunbar%27s_number The world scaled past this millenia ago. You can scale your company past it too.
yousif_123123 3y ago
When they say "100" or "150", do they usually mean total company size or number of engineering+product people?
- NickC25 3y ago
  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.

adaml_623 3y ago

"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? I'm sure we'll work it out right..

thumbuddy 3y ago
If only people could think from outside themselves for two seconds to assess technological impacts like you just have.
- fhd2 3y ago
  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.
  - throwaway80492 3y ago
    Let's keep sci-fi worlds designed to make a good story out of serious discussion, please. Or let me raise a The Culture argument, where computers/AI is hyper-advanced, AIs are friends, and no regulation whatsoever is needed.
    - fhd2 3y ago
      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.

bhouston 3y ago

Brilliant short essay that captures the maturity changes and challenges.

hliyan 3y ago

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.

K0balt 3y ago
This is an intriguing idea. I wonder if the paradigm has a name or a following?
- bombcar 3y ago
  Isn’t that basically what franchising is?
  - K0balt 3y ago
    Hmm, that is an interesting parallel. I think it misses the mark somehow though. Idk why people don’t like the question, I’m actually looking for a developed model/ paradigm around this concept. No sense reinventing the wheel.
srcnkcl 3y ago
k8s the company, infinitely scalable
toyg 3y ago
This is what the author suggests towards the end of the piece, and points out some issues with it.
- hliyan 3y ago
  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.

moffkalast 3y ago

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. The result is 100% turnover.

esafak 3y ago
> The result is 100% turnover. Problem solved? Just be sure to leave a note online for potential hires to avoid the company.

simmschi 3y ago

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.

mfwgenerics 3y ago

> 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. This is painfully on point.

fallingknife 3y ago
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."
- naijaboiler 3y ago
  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

lifeisstillgood 3y ago

I think the best takeaway here is - don't hire until you absolutely have to.

dclowd9901 3y ago
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.

dangus 3y ago

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

fallingknife 3y ago
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.

m3kw9 3y ago

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

fnordpiglet 3y ago

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.

lukaszkorecki 3y ago
> The arguments articulated are entirely false 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
- fnordpiglet 3y ago
  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.

Terretta 3y ago

> 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. --- [^1]: see wicked problems: https://en.m.wikipedia.org/wiki/Wicked_problem https://en.m.wikipedia.org/wiki/Wicked_problem [^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.

3y ago

deleted 3y ago

[deleted]

flowerpew 3y ago

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

handsaway 3y ago
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.

rm_-rf_slash 3y ago

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

snowstormsun 3y ago
A fine tool would have a functional full text search...

samhuk 3y ago

I'll raise your spark for complete destruction. 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...

endorphine 3y ago
Maybe by avoiding fast scaling, which implies avoiding VC money.
- WJW 3y ago
  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.
- Aurornis 3y ago
  The first startup I worked for was a slow-growth company that had slowly expanded over 7 years to only about 50 people. A dinosaur in startup terms. It still had the same problems as above. Expanding slowly doesn’t automatically protect you from these things.

amelius 3y ago

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.

geophile 3y ago

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.

Aurornis 3y ago
> 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.

hn_throwaway_99 3y ago

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.

alexchantavy 3y ago
+1, I was also confused about the don't use Jira part - what is the alternative that will let dinosaur companies "operate more like startups"?
- bfelbo 3y ago
  Linear is nice although it’s getting more and more like Jira (read: bloated)

l5870uoo9y 3y ago

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.

jSully24 3y ago

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. Now trying to avoid this in my current home. What if Apple had stopped the iPhone for fear of it cannibalizing* the iPod line of products revenue? * https://www.imd.org/research-knowledge/economics/articles/apples-dwindling-sales-show-importance-of-self-cannibalization/ https://www.imd.org/research-knowledge/economics/articles/ap...

zbentley 3y ago

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

fidotron 3y ago
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.
- quercusa 3y ago
  > sources that require commitment to hiring plans Are these local/provincial development funds that need to show job growth? Any case where "we need to hire someone in the worst way" seems to deliver exactly that.
  - fidotron 3y ago
    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.

Dirak 3y ago

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

esafak 3y ago
Untrained people might want to read these books: * The Mom Test: How to talk to customers & learn if your business is a good idea when everyone is lying to you * How to Measure Anything: Finding the Value of Intangibles in Business.
dwarwick 3y ago
[flagged]

xtremedata 3y ago

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.

spacecadet 3y ago

Amen, less headcount more founders! Bootstrap!

Zetice 3y ago

> 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. What. How is an engineer deciding what to work on like this, even at a small startup?!

ajkjk 3y ago
What do you mean? They just.. Do it? Nothing about an engineer precludes having good sense at other things.
- Zetice 3y ago
  Nothing about an engineer includes having good sense at other things, either. In fact, many of the best engineers are profoundly bad at figuring out what to work on.
  - ajkjk 3y ago
    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.
    - Zetice 3y ago
      That’s what the non-engineers are doing though, and it’s not work everyone should do. Engineers should do engineering things at startups because nobody else can.
      - ajkjk 3y ago
        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.
        3y ago

victor9000 3y ago

The failure modes I've encountered: 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.

zenlf 3y ago
How do you bully people into joining a company?
- victor9000 3y ago
  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.
  - zenlf 3y ago
    I see, thank you. You would assume that one would use tactics accordingly.
dwarwick 3y ago
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.

hintymad 3y ago

> Talking to users is for PMs, silly! 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.

indymike 3y ago

Startups lose their spark when they either: 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.

ccorcos 3y ago

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.

rlifer 3y ago

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.

princevegeta89 3y ago

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.

g9yuayon 3y ago

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.

silentsea90 3y ago
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?
- g9yuayon 3y ago
  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.
  - silentsea90 3y ago
    Sounds very cool. Were failures punished by low ratings, bonus? How did they incentivize taking risks? Did the focus on being a leader make you stronger? Were Netflix employees from then valued very highly?

simon_000666 3y ago

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.

esafak 3y ago
How? Profits are short term indicators while equity is longer term.

bryanmgreen 3y ago

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.

nine_zeros 3y ago

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 https://substackcdn.com/image/fetch/f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fbcff882f-083e-4512-b91e-36fc0a117134_1348x1270.png https://substackcdn.com/image/fetch/f_auto,q_auto:good,fl_pr... 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.

andrewstuart 3y ago

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

flimsypremise 3y ago

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.

deleted 3y ago
[deleted]
spoonfeeder006 3y ago
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

adra 3y ago

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.

mvncleaninst 3y ago

> 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

pixel_tracing 3y ago

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

william_T 3y ago

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.

starsea 3y ago

[dead]

wallist 3y ago

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