M&Ms: Expensive Baggage

When I left Bank of America Merryl Lynch (BAML) to join a startup, I brought some baggage with me that almost hurt my career.

The Big Banks back then were on a kick to do things perfectly right.

Post 2008, they'd been fined hefty amounts by the government for seemingly doing things wrong. They had vowed to do no such wrongs anymore. Or so it seemed to me back then.

They hired agile coaches so we could get those ceremonies perfectly correct. I was young, early in my career, and impressionable. For example, retrospectives were a time to blare out our souls about what went wrong. This seemed cool to me back then. And in true bank fashion, we always dug deep and found more processes we might add to improve things after each sprint. The product managers, project managers, and program managers felt like kids at Christmas with all this new process to take in, implement, and shape up.

Getting agile at the Bank back then was like getting a new computer before anyone installed any crapware to slow it down.

Spoiler: Every sprint, we kept installing more and more crap onto the new metaphorical computer until it looked a lot like the old computer with the waterfall background on it.

But we software engineers got into it, too. You know, this idea of doing everything perfectly at the Bank.

We wrote our code using Test Driven Development. We did regular code reviews. We pair programmed. We spent a bunch of time hashing and rehashing out our implementations. We found the epitome of value, we thought, and it involved having over 95% unit test coverage. And let's be real, it feels good to have clean code. It's less painful for the software engineers on a big codebase. And, after all, what is a software engineer if not someone who follows all the best practices with code?

And so much like the PMs, it felt like Christmas for us engineers, too, with all these best practices. And we always found more ways to make code better. But with all this clean code, we thought, there was no way the Bank would get into trouble again. There is no way the government would be back here to fine them again.

Spoiler: The government went back later and fined them again.

But then, I left the Bank and joined a startup. I was the only developer on a team with an immense amount of stuff to build. So, at first, I thought, we've got to do things exactly right. Get the agile right with a Jira board and the ceremonies. Get all the abstractions right, get the test suites in place, the automation, and get that code coverage up really high from the start.

But my partners on the business side looked stressed and increasingly more nervous each day. I showed them how well-designed our pipelines were and how high the test coverage was; I told them not to stress we’ve got well-tested code. But their stress levels didn't change. They were nice, and they thought what I'd build was neat. But I sensed my clean code didn't make them feel a bit better.

But after attending many of their meetings and working closely with them, I figured out what ailed them. They needed to acquire more users. But most importantly, they needed revenue to go up.

So, one day, on the train ride to work, it hit me. I grew up in The Bronx, so forgive me because some of my thoughts tend to have explicit language. But I thought to myself, "You know, Louie, the business does not give a shit about your clean code. They're just being nice. All they seem to care about is user growth and revenue growth. And they are so damned stressed because they might not hit their numbers, and we as a firm might not be around." Then I thought, "Shit, we really might not be around if we don't hit those numbers." And then I started getting stressed myself.

I learned recently that Pavlov, the guy who trained dogs to salivate at the ring of a bell, also figured out that stress is the only thing that got the dogs to snap out of their classical conditioning. After being stressed, Pavlov learned the dogs stopped responding to the bell.

And so, like one of Pavalov's dogs, I, too was stressed that the firm might not make it. So, I began to shed all my classical conditioning about code and process. I shed all my expensive baggage I had brought with me from the bank.

Instead of worrying about unit test coverage or agile ceremonies, I hacked like a madman. I put together anything I could that I thought might help the business grow users or grow revenues. If my former colleagues at BAML saw the code I was pumping out in those days, they would've been appalled at how much I was sinning and how far I'd fallen from their graces.

But it worked.

My business partners were no longer just aiming to hit their numbers but, as one exec put it at the time, "we can crush them." Pretty soon, I went from some geek that they had to be nice to, to a goddamn hero that can hastily make machines do crazy things, like increase revenues. That baggage, those notions about perfection, had cost me more than I’d realized at first.

But my career skyrocketed from those business metrics moving up. And then, I had the opportunity to hire more software engineers, and we wrote and re-wrote things at each new phase of the company. Ironically, each new phase becoming possible because of the metaphorical sins of the last phase.

As all that happened, I also internalized that speed and quality are a dial that I need to tweak based on where a business is at. Sometimes, if the firm is in a certain phase, the dial might need to be tuned all the way at speed, and I might have to ignore all other notions. But as I tell this to many software engineers who have only prayed at the church of perfection, as I did back at the bank for a little while, they get emotional about it. To them, tuning the dial away from quality even a little bit is a sin far too large, and I must be banished from that garden of real software engineers for suggesting it.

But as it turns out, a real professional software engineer is simply someone who writes code and understands the tradeoffs they are making along the way.

Thank God I was stressed into shedding that expensive baggage because I see how much this hurts engineers on their side projects or when they start their own thing. They focus on all the wrong things for too long, and many never make it to the dollars.

Learning to care more about business metrics rather than perfect process and perfect quality helped my career back then.

But it continues to help me today on my own stuff, too.

---

A Promo from Me:

I sent an email to my customer list yesterday, and I want to share it with you as well.

And if you are interested in joining us in the Small Bets community, you can join here.

---

Three Things: VC Dollars, A Long List, Output

VC dollars invested are coming down globally as interest rates rise.

It is also very interesting to see the correlation between VC dollars and interest rates.

---

Peter put together a list of things one needs to do when starting their own thing. The only unfortunate thing is that the list is so long it does not fit in this newsletter.

But Peter’s list is a reminder of more reasons why the expensive baggage needs to be shed if you want to make it on your own or with your own projects.

---

---

Two Memes: Rare and Neumann.

Unfortunately, this meme probably reflects the market right now for Software Engineers.

---

Perhaps one of the few upsides of the reduction in VC dollars is that it will force more sustainable companies to be built and fewer companies like this.

---

-Louie

P.S. You can reply to this email; it will get to me, and I will read it.