Seven Scourges of Startups | Part I

I’m an individual contributor. I don’t know how companies are started or how they’re kept running. I’m happy in front of a screen building things out of keywords, curly brackets, and SubjectPhrasesPutTogetherLikeThis.

I’ve also worked at about a half dozen “startup” companies, some tiny, some in the throes of a national-news-worthy acquisition. When I said “scourge” I meant it in both the figurative sense and the more literal sense. Startups have interesting ways of whipping your ass if you point it in the wrong direction. I recognize that the word “scourge” may be insensitive given the circumstances as of March 2020, but the alliteration was just too tempting.

My intention with this article is to provide a kind of survey of articles on avoidable “growing pains” of startups, so you’ll find a lot of external article links alongside my own perspectives. I recommend the reader visit them for some greater depth of insight.

1. Founderism

Every growing company had to start out with a smart, entrepreneurial contributor or two. In the beginning, they’re the ones burning midnight oil, building proofs of concept for potential investors. Without them, all the company’s subsequent hires would never have had the chance. They’re the dynamite that blasts through the mountain, inspiring others to stumble in and start building a tunnel.

If you can bear my analogy for another moment, a problem arises when those early arrivals continue being the dynamite even after the company starts to run into problems that cannot be solved with blasting. Most folks come in with sledgehammers, drills, even little chisels one could use to carve figurines. They all bring value, but their abilities go to waste when more explosive techniques remain in use.

“Founderism” is often used synonymously with “entrepreneurship,” which of course, is a wonderful thing. On the other hand, consider the gravity of the term “founder.” It’s bestowed on the likes of Benjamin Franklin, Arnold Schoenberg, and Colonel Sanders. So, let’s get real. Is the title entirely deserved by those who, as far as later hires are concerned, may have simply found themselves in the right place at the right time? Are the privileges it often entails anything more than a particularly blatant and generous reward for seniority?

That would probably be giving most founders too little credit. But when a company — its leadership, its employees at large, or both — maintains a culture that demands special reverence for early arrivals, everyone starts believing that if something needs to be done right, the founders had better do it. For instance, I’ve seen founders wander off to Siberia to build a product in secrecy, apparently out of concern that getting a bunch of non-founders involved would be prohibitively slow. In another instance, I adopted parts of an entire core platform that was written by a single founder and had approximately zero percent test coverage. I was told to add tests to it but was warned to otherwise keep my filthy paws out of the code. Prohibited from contributing meaningfully in those sorts of cases, I languish and before long, I leave.

In How To Scale Your Startup With The Best Talent, Ron Carucci writes,

Founderism is a dangerous byproduct of great entrepreneurs with great ideas. Founders build organizations so exclusively around themselves, they can’t scale them.

That cultural expectation can stress newer hires by creating ambiguity in the organizational hierarchy. Employees might be unsure whether they can challenge the decisions of a founder and keep their job, even if their responsibilities are pretty much the same.

Let’s not dismiss the importance of founders in all stages of growth of a company, not just its earliest ones. A crucial responsibility of a growing organization is to demand that the roles of founding contributors evolve to allow regular folks to come in and start, you know, building tunnels with their chisels. A founder in an organization that has grown to a size many times what it was when they started possesses a momentous opportunity to shift into leadership and enable others to flourish too.

Aaron Skonnard, CEO of Pluralsight, writes in Why the Best Leaders Learn to Let Go:

When it comes to tough decisions, many leaders cling to the frame of mind that “I need to take care of this myself.” But if you trust the people who you hired to do their jobs with full autonomy, you may be surprised by how well it works out.

2. Heroism

In a way, I’ve presented founderism as a special case of heroism, but heroism doesn’t relate so much to seniority or position. According to Will Hayes in The Trouble With Heroes On Your Startup Team:

Heroes achieve major, outcome-specific change under high pressure and in short periods of time. […] While the occasional heroics on the team level are important by nature, individuals who operate solely in hero mode create a toxicity that’s detrimental to any team.

It probably goes without saying that the biggest risk of heroism, or its organizational equivalent, “hero culture,” is in the proportionally spectacular failures that often result from it. However, the failures aren’t the cause of the toxicity that Hayes mentions; the toxicity comes from a mode of operation that sets developers apart from each other and inhibits collaboration. When it’s encouraged by leadership, the toxicity becomes the norm. Team members with no interest in competing for the sparkly tiara in the software deliverables pageant, so to speak, find themselves without recognition for their efforts. It’s pretty consistent with the broader American culture in that way, but I think a company full of creative professionals can do a lot better.

If leadership sees a particular hero as critical to their business goals, that hero can get away with some bad behavior and even abuse of other team members. Please note: if you work with someone who has obtained hero status, I recommend documenting your interactions with them as much as you can. Even if you do, and they target you for harassment, your HR contact — a slave to the C-suite as much as anyone else — isn’t likely to take your side. I’m sad to say that I’ve experienced this myself. The fact that, in a hero culture, certain people will continually get away with being assholes is a tough pill.

Heroism can be confused for narcissism, a personality defect that is less common but can devastate the culture of a company at any stage. Heroism can be just an intuitive and adaptive strategy for fitting into a high-achieving group or getting promoted. However, like narcissists, heroes can just as easily alienate themselves, even when their intention is not only to advance their own careers, but also to raise the bar for their team.

I’ve certainly been guilty of this. At one company, when I saw a need for advanced infrastructure for a new set of services we were developing, I jumped on the opportunity to build it, and I really rolled with it. I thought that since no one else seemed interested, it was on me and myself alone to make it happen. Thinking that way should have been a red flag to myself and probably was to others. I was confident that what I was doing would work and would bring value to the organization— eventually. But the large degree of additional complexity it introduced combined with the lack of peer review of my work resulted in a hesitance from the team to adopt it, and it was a struggle to avoid being an information silo. The whole effort didn’t earn me any friends, either. In retrospect, a more incremental, more collaborative, less heroic approach would have had greater impact.

Heroism takes various forms. A hero can also be a developer who gives themselves a flimsy kind of job security by throwing bad hot-fixes around everywhere and making themselves a guru about large parts of proprietary code. Most of us have worked with that type, especially in larger corporate settings. Here’s a fun article on this kind of (anti-)hero: How To Prevent Coding “Heroes” From Destroying The Team.

3. Tribalism

One could see this as another variety of heroism. It’s heroics on a communal level.

The term “tribal knowledge” is commonly used at startups to refer to expertise that’s vulnerable to the bus factor anytime the development team goes out to lunch together. Chris Scharff shares another definition of tribal knowledge in his article, How Do You Kill Tribal Knowledge?

Keeping knowledge within a “tribe” inhibits the ability of new hires to ramp up on the code base. When nothing is documented, they’re forced to knock at the gates of the tribal village to ask questions about every little code block, not just on how it works but also on how it’s supposed to work, especially when test coverage is low. They’re forced to play the role of Dick Torvalds, Code Detective, in The Mystery of the Legacy Monolith, until they get sick of it and leave for some greenfield project somewhere, anywhere. I’d capitulate that this is an acceptable state of affairs for more junior developers, who can appreciate mystery-solving work, but it’s obnoxious and kind of disrespectful to put that burden on someone who comes in at a senior level, someone with more experience and less patience.

I’ve heard plenty of excuses for not documenting code:

• We didn’t have time, we were under too much pressure!
• Documenting is a waste of time, it’s not “agile!”
• My pet goat ate my MacBook, lithium battery and all!

And in my experience, most of these will fly in most startups. To me, they indicate either a lack of concern for growth of the business (which obviously involves onboarding additional developers who will be expected to hit the ground running), or a failure of management to allocate resources for work that confers benefits at some point beyond two weeks into the future.

To lessen the appeal of maintaining tribal knowledge, it might help to keep this in mind: your company’s source code isn’t special. Compared to the countless excellent open-source software components that you use for free, your proprietary application is poorly documented, inadequately tested, and insecure. It’s like keeping your LEGO Death Star model locked up in a bank vault. I’m being a bit extreme, but the point is that your code probably would not be worth anything to competitors beyond the extent to which it would reveal your trade secrets.

In contrast, the cultural element of tribalism entails tribal knowledge, but is essentially a web of relationships among contributors who have worked together for a while, trust each other, and collaborate productively. In Startups Are Tribal — Are You A Shaman Or A Hunter? John Greathouse describes roles at startups in terms of those of ancient tribes. Tribalism is a uniquely humanistic quality of startups, and to be part of a tribe is one of our basic desires, at least as a competitive strategy.

Problems arise when a tribe isn’t inclusive. Your company’s competition would probably be pleased to hear your engineering department is split between a knowledge-hoarding clique of veterans and a group of newer hires struggling to make themselves useful.

Summary

I’ve offered some observations on three startup-company phenomena: founderism, heroism, and tribalism. In Part II, I’ll share a few more. Thanks for reading.