Playing Company
Jason Warner, now VC but ex-CTO of Github and VP Engineering at Heroku, posted a Twitter thread in May of 2022 about two “bad patterns” at companies, Playing Company and Playing Product. Playing Product is a big-company thing where slowing growth leads to bloated and unproductive PM orgs. Playing Company is when small companies do what large companies do without understanding why, implementing “maturity” prior to when it is needed. Jason says:
“IMO no startup should build these monolithically bespoke processes cargo culted from other SF/SV companies....if one doesn't understand them first, they'll always end up in disaster”
I agree, but I think the nuance here is less about the individuals involved than the system of incentives that create these bad behaviors. The Playing Company bit struck a nerve. Jason says Playing Company comes from the top where 90% of the time the CEO, Board Member, or Exec imports it. In my time evaluating companies at Salesforce, I very much believe in the Anna Karenina principle of technology companies: “All happy tech companies are alike; each unhappy tech company is unhappy in its own way.” I think it’s a little more nuanced if you take into account survivorship bias.
Cargo cult thinking has been pervasive in startups, but was also pervasive in large companies like Amazon and Salesforce. Some of the stuff Salesforce did was thoughtful, even if giant, monolithic and bespoke: V2MOM, opportunity open market and GUS1. Scaled down, it lets you keep your employees happy and motivated. At the same time, Salesforce would import two-pizza teams, six pagers, domain-driven design, unit-test obsession and all manner of other big company or fashionable stuff. Some of the stuff imported definitely worked: hybrid engineering2 and agile being two. Those things applied to a “giant multitenant database in the sky with some nice forms,” but a lot of the engineering-driven or customer-facing paradigms did not.
Why does a big company import “cargo cult” processes?
Big company processes inhibit innovation
Executive from another big company imports it.
Inherent Bias against all the code that came before you.
Why Startups Cargo Cult
Now I’m at a small company and there’s some of this “big company stuff” I’m importing: V2MOM and CI/CD practices being first, and other stuff that I want to but is too expensive right now, like GUS or monorepo. Yet I have to be mindful that I’m not doing the same thing. Why does a small company import “cargo cult” processes and big company nonsense? Some versions I’ve seen came from:
Executive Cognitive Load
“Big” Customer Pressure
Missing Business Functions
Breakout from Process Inertia
Fractured Culture
Second Product Syndrome
I’ll concentrate on the startup issues around this I’m facing now.
Executive Cognitive Load
Being a manager or an exec in a startup is hard. You have to wear a whole lot of hats, deal with all sorts of customers, and there’s a constant context switch going on. Some people live to multitask, but it’s not as common as you’d hope. I don’t like it; I live for flow. So there is some natural selection against pragmatic management.
When something is going wrong: hiring is behind, the product is late, lots of bugs in production, an executive in a startup is hard pressed to find the time to go deep into why the problem is there. So instead of data-driven pragmatism, you often get further with sloganeering. Googling “how to hire in a startup” doesn’t help, but reading a substack beats delving into the details of why the issue is with your interview process. I mean, you’re reading my substack: is my material about switching back to a monolith any different?3
It’s easier to point to something on the internet than to take the time to do the business analysis of the fundamental problem.
“Big” Customer Pressure
The big company processes often come in because of customer pressure: PCI, SOC 2, GPDR, etc. Or you hire a CISO because your board tells you to, and that person says we need to follow NIST even if you have 15 engineers. You need to start offshoring because you have too many customer specials for your onshore/remote team. You hired too many people and now you feel like you’re less productive.
If you go to that customer and say “we’re doing what Google, Meta, etc.” do it’s a shorthand. Even in consumer-facing companies, avoiding the pitfalls of running a business on the internet means doing things bigger than you thought. You need to build faster and you’re sluggish; let’s do a reorg. And that Amazon blog post about your issue is just a click away.
Missing Business Functions
Hiring engineers is hard. Sourcing them is difficult, outsourcing them is difficult, interviewing takes time from the team, compensation changes all the time. If you don’t have a full time HR person and a full time recruiter, you’re going on feel. After a couple of “misses” where you hired the wrong person, you want some easy answers. You’re a busy engineering manager/CTO/etc, and without any guidelines or ownership. You move to one of the things you found online or did at your last job where there were those function, or rely completely on online leetcode/hackerrank sites.
Don’t: you’re at a startup and the mass hiring techniques from FAANG won’t help. Adaptability, Enthusiasm, Communication, Resilience, and Technical Competency matter more than esoteric knowledge of your underlying stack, ability to whiteboard code, or whatever random sift questions your last job had. Translation of business requirements into code as part of a large system is, for now, still a human job, and the internet’s pretty good at boilerplate code these days.
Look to consultants/outside firms to help fill in the missing job functions that are specialized and/or outsourced, like recruiting or benefits. Spend your time and energy on something you can’t spend money on: like fixing onboarding. You can’t interview for being good at debugging, and you’ll make mistakes, but you can try and make sure that people you hire can check in code on day one.
Breakout from Process Inertia
If a process is broken, it’s easier to obsess over replacing a tool in the process than examining why the process is broken. For example, say you’re having issues with communication between teams and talking about bugs and you’re using Google Chat. “If we only used Slack, like we did at my last company…” we’d solve the problem. When doing a big bang, you can break the inertia and show large changes for the better.
But it becomes a Slack enablement exercise, instead of a communication improvement exercise. Google Chat isn’t great, but are you sure that’s the problem? Is there an issue with project management, or alerting, or in JIRA, or something else that you could fix. You can move everyone to Slack and while aspects of communication may improve, the fundamental problem won’t. But we fixed the underlying process issue, bad GitLab integration and alerting, in GChat. It’s not as good as slack, but the main communication issue got better.
Fractured Culture
If you have an issue with team culture or dynamics, a common front against an enemy where both sides are bad can win out. One team has 50 microservices deployed in k8s written in multiple languages with three backend stores, the other team has a giant monolith deployed in Lambda with a single RDBMS. The culture split that lead to one side letting 100 flowers bloom and the other build a tank is not going to get fixed overnight. Those teams aren’t going to agree on much, despite their dislike of the current architecture: they probably didn’t make the decisions, and neither did you. But you have issues integrating, testing, and securing the two products and the customers don’t like the fact you’re shipping your org chart with dual maintenance. Everywhere you look is double maintenance. We have to “integrate the products” but you really need to integrate the cultures.
So bring in a common enemy! Let’s bring in a CI/CD or testing platform from another company that’s “awesome” and everyone can move to that. Problem solved, neither side wins, and I don’t have to face the fundamental differences in outlook. Monorepo and Bazel are “obviously” better: Google does it. Much easier than a multi-year plan to harmonize the architecture and the endless debates about it.
Second-product Syndrome
This is the most pernicious one. If you have product market fit for your first product, you build a second one and misinterpret what you did to get there. Then you constantly compare the new to the old, bifurcate your engineering and product team while they build “old” and “new” products, and end up with either a bloated system to support two products, or two completely different systems you have to organically integrate. This provides the perfect excuse to bring in the big-company stuff, without understanding if the issues are second-product related, as opposed to normal engineering scale.
When it’s OK to bring in this stuff
Big company stuff isn’t all bad. Sometimes the technique, process, or tool is actually better in and of itself. Kubernetes and Kanban are popular not because they came from Google or Toyota, but because they work. Bring it in if:
It addresses a specific, known deficiency in the business.
It can be implemented in a way with objective criteria to evaluate if it is working and better than the old way.
The implementation cost is proportional with the deficiency
It can be done with broad, but not unanimous, buy-in
Is your OKR process broken and should you bring in V2MOM? Maybe. I brought in V2MOM at my current company because they hadn’t done an OKR process in engineering in 2 years. The implementation cost was relatively low and the deficiency in not having clarity on goals had broad support. Eventually, the whole company switched to Lattice, but I’m still keeping track of engineering in KATA.
Would I get the same buy-in by switching from JIRA to Agile Accelerator? No. Even though I think it would be objectively superior, it would be too disruptive and expensive to implement and there isn’t broad support.
Tools don’t fix problems, but they can break everything.
Not everyone agrees. The switch was made due to a set of specific issues including hiring QA talent vs other large companies. Sometimes you have to do what everyone else does to compete.
Yes, yes it is. My substack is different.