Foghorn Software Inc., A Manifesto

"All happy families are alike; each unhappy family is unhappy in its own way."

This is the opening line from Tolstoy's Anna Karenina. I've never read that shit, but the opening line has clear parallels to software teams. Let me propose to you my version for software teams:

"All happy software teams are alike; each unhappy software team makes you want to kill yourself with novel methods of mental torture."

The funny thing about this is that it's all luck of the draw. If you magically get lucky early in your career and enter a good software team, you can RL the fuck out of that team and have a good base framework for how to do things without even THINKING about it. But, if you are like most of us, you will be unlucky enough to experience shit team after shit team, and you will only arrive at the ideal way to do software by process of elimination - seeing shit fail, and being like "let's NOT do that next time."

Foghorn Software and all names are pseudonyms. Locations, timelines, counts, and technical details have been changed. The events and opinions reflect my recollection.

Foghorn Software was one of the first companies I worked for, and shortly after I joined, we got acquired by a Big Tech company. Getting acquired is typically a good sign, a fuzzy signal that your startup did at least a couple things right, and that therefore you can learn from the people who made those decisions. This was not altogether incorrect, but became wholly incorrect when the CEO and CTO, the only two competent members of leadership, left to do bigger and greater things inside the acquiring company.

Left to their devices, the three managers, good and faithful drones who had earned their golden ticket to Big Tech by ruthlessly grinding and obeying the CEO and CTO, began to believe that they themselves were hot shit. Who wouldn't after an acquisition? They made some incredible blunders, fueled by a growing belief in the infallibility of their own judgment. So many that, one stormy night somewhere in the Bay Area, which is a lie, because it never storms in the Bay Area, I typed out a 15 page manifesto. I was early in my career and desperate not to carry their corporate brainrot into my next gig. By the time I left Foghorn Software, it had grown into 33 pages. Now I'll tell you all about it in considerably less.

Let's start with the main characters: three managers named Karim, Himani, and Amir. Karim was dick-hard for bringing military hierarchy into corporate life. He sat in front of me, so by virtue of bathroom breaks, I knew he browsed LinkedIn for, I kid you not, 6 hours a day. Yet he insisted on occupying the front-most cubicle, where he could turn around and inspect his little kingdom by direct line of sight. He became very angry when a senior engineer sat out of view after we ran out of seats. Karim was their general, and Himani and Amir were his lackeys, each spineless in their own way. By the way, spineless people should never become managers.

Himani's mind, despite decades of tech experience, was still a blank slate, meaning that whatever fucked up doodle Karim drew on that shit was her new gaslit reality. Independently of that, she was also like a crazy toxic ex that would misconstrue whatever the fuck you said in the worst way possible. Real story, I once told her that I was interested in "product work". As best as I could tell, “I'm interested in product work” went through a full corporate game of telephone: he likes product work -> he wants to become a PM -> he will leave the team -> therefore he should not receive meaningful work or a promotion. That interpretation led her to urge a senior engineer I worked with to “keep an eye on him” numerous times. Another time, I asked her about promotion while nearing my one-year mark at the acquiring company. I kid you not, she put her face down into her hands, held a ten second sigh, and then glared at me like I was an idiot for even asking that question. Her reasoning was that I should not even worry about promotion because it wasn't important and, paraphrase, that I should be a good little drone, and knock out the tickets I was assigned. Which is fucking insane because in big tech, part of a manager's job is to get their employees promoted, and make them do well! It even helps with their own career advancement if their managed employee gets promoted.

Amir was arguably worse than Himani. He saw straight through Karim's bullshit, but instead of standing up to him, kissed up to him, and fired down ruthlessly at his team members who made mistakes. I'd seen many such scum like him in the Korean military. He especially had a hard-on for abusing the fuck out of my good friend and coworker, Walid. I'd see his face go from puppy-dog smile in front of Karim, then morph into a glare at Walid like he wanted to fucking hit him over the head with a server rack or something. Once, he brought Walid into a meeting with all of leadership, and they collectively chewed him out for spending $400 in AWS credits on scale testing our infrastructure. $400 at a big tech company? The places where people get free lunch and snacks every day? Are you fucking kidding me?

The defining characteristic that united the three managers was a paranoia of failure that was manifested in all the wrong ways. Honest mistakes became public humiliation rituals, useful features that had been tested thoroughly were scrapped for fear of bugs, and engineers were banned from talking directly to customers. They were more concerned with hiding the problems our software had than actually fixing them in public with good faith discussions with internal customers. It wasn't uncommon for them to go into a meeting, whisper amongst themselves for thirty minutes, then come out with top down orders for engineers to follow. Product and customer context was gatekept, and if you asked, you'd never get a straight answer.

But despite it all, I did learn some things. This dynamic trio of idiots who desperately needed therapy taught me some valuable lessons about what NOT to do. Let's get into it.

When everything is important, nothing is important

Every single day, we would have a morning standup that lasted 30 minutes, involved ~40 people, and was a complete fucking waste of time. Let me tell you why. During the meeting, Himani would talk about 10 different action items that were "very very very very important", and the only way you could differentiate between what was more important was by counting the number of "very"s used. Which is to say, nobody could distinguish what was important. Every day brought another unique 10 action items, they would go on someone's list of tasks in unordered fashion, and some would simply get forgotten, whether they were important or not because there was no clear guidance on importance. Even worse, 5 out of 10 tasks ended up on Wally, our devops lead's plate, and Karim would yell at him in front of all the other devops engineers every devops sync because his constantly expanding list of 1000 tasks was not finished.

The definition of prioritization means that when you decide the 3-4 things that are important, you consider everything else unimportant. This will forever be important because no matter how many agents you have your resources - human, compute, etc. are always finite.

Shit code compounds

Not all bugfixes are equal. Before senior engineers joined our team, our code was mostly written by junior engineers who didn't know any better than to fix minor bugs by writing wrappers on top of the problematic code. This was made worse by the fact that every engineer was told to fix bugs "as fast as possible, and to never let it happen again." The code ended up so bad you had to read five different files before you even knew what was going wrong. When some senior engineers joined our team and inevitably complained about "the worst codebase they'd seen", Amir didn't care, Himani got defensive, and Karim claimed codebase quality didn't matter and refactors were a waste of time.

Typically when you release new features or ship new code, you want your graph of bugs over time to look something like this.

That is to say, the number of bugs probably don't decrease to zero, but they level out over time, and the system reaches stability. This is only possible if you fix the root cause of issues, which will often involve some refactoring and focus on code quality.

However, this is what our graph looked like.

Because with each individual bugfix, code quality decreased, and no refactoring was done, the root cause of the bugs was never solved and we were stuck in perpetual firefighting mode. Which meant that we were wasting time fixing bugs and not building features that would give our product actual business value, asides from it not breaking all the fucking time.

Cracked People Leave First

For the smartest people working in tech, or most other fields for that matter, unless your field is underwater basket weaving, there are a plethora of job opportunities available at any given time. Their LinkedIn inbox will be stuffed with messages from recruiters. Their ex-employers will be lovebombing them. That is, if you give them a hard time, they're going to flip you off, and leave. Sometimes simultaneously.

Churn is a major red flag for any team or company, and it's especially concerning if you see the smartest people on the team leave. You should be asking them for a coffee, asking where they're going next, why they're leaving (politely), and if they can take you with them if you're interested (even more politely). One leaving once in a while is natural. But if they leave just a couple months after joining the company, before their stock even vests, that's a different story. And that was our story. Cracked people leave first. If they leave in droves, be scared.

you are still you no matter what your title is or what your achievements are

There are many more faults of this team that I have not talked about in this article. But if you try to perform a root cause analysis on why this team failed, it was not due to a lack of talent. We had an abundance of senior talent, and many hardworking junior engineers on the team. We had no unreasonable time constraints, and we did not get shafted by company politics. I theorize that our managers had begun treating their decades of tech experience and the acquisition as proof of their infallibility.

The logic went something like this: Foghorn Software got acquired by Big Tech. They managed people at Foghorn Software and had managed software teams before. Therefore, they were exceptional managers whose judgment should never be questioned.

QED, apparently.

But success is not a transitive property. Succeeding yourself or being present when something succeeds does not mean that you are actually exceptional. Achievements and titles are meaningless external status symbols that make your LinkedIn profile look prettier. At best, a fuzzy signal for capability. If you were smart before success, you'll still be smart, and if you were incompetent before success, you'll still be incompetent.

I have been lucky enough to work with engineers whose level of skill I will honestly never be able to rise to. Even if I managed to found multiple startups, sell them all, and become a billionaire, I wouldn't actually be a better engineer than them. I would simply have a decorated LinkedIn profile, and multiple yachts.

The real question is - who are you without the ornaments? There's no virtue in pretending you aren't good at something, and raw charisma and confidence can open many doors. But confusing external validation with internal ability has the potential to really fuck you in the ass. Your pride will blind you to your own faults, you'll be stubborn in the face of obvious evidence, and when you finally jump off a skyscraper in New York because you believe you can fly, you will quickly discover on the way down that you, as a matter of fact, cannot actually fly.

Denouement

As you can guess, the team did not meet a good end. But I mean, hey, you sold your startup to a massive technology company. Not many people can say that, and Big Tech does not buy companies for charity. I will say that the team had great work ethic, despite all the flaws, and that has to count for something. But rowing hard in the wrong direction will only get you further from your destination.

Bonus: The Bingo Card I used every morning standup

Foghorn Software Bingo

B	I	N	G	O
Someone gets assigned a task with no deadline—the implied deadline is ASAP	An acronym or name nobody understands except management gets tossed around	Morning standup goes overtime	A manager walks up to someone’s desk with an emergency task	A prod cluster breaks with no useful error logs
Wally gets blindsided by an action item he had no idea existed	Someone is given one minute to provide an update	Today’s sync material is completely unrelated to yesterday’s	Debugging requires tracing code through three services written in different languages	The overseas team gets called into a meeting during US hours
Karim gets pissed off and tells Wally to drive something to completion	Half the sync is spent on something affecting five people	FREE: Himani says something is “very very very important”	A newly discovered bug becomes a critical blocker	Someone gets blamed for a systemic issue after making one mistake
A new cluster or customer is added without consulting the teams and receives another terrible name	DevOps upgrades a cluster without muting alerts, spamming the on-call channels	Someone pushes a regression fix without adding a test	A flaky integration test gets skipped or disabled	A failed test locks the branch after someone pushes to master
A tested feature sits undeployed for months because releasing it is “too risky”	A feature flag is enabled by manually changing a value in the cloud console	Nobody writes down action items, owners, or timelines	A manager gets angry because an engineer talked directly to a customer	Another internal team deploys thousands of jobs and leaves the on-call engineer monitoring them for days