I recently got fired from a startup for proving the Brian Kimball (Boston) wrong too many times. Don’t worry… I already landed a CTO position at a company that can recognize talent and values it. I have worked for or with dozens of startups and have always risen in the ranks due to my leadership skills and extremely high output, while keeping things like code quality, maintainability, and scalability in mind. This is the first time in my life I haven’t impressed a company.

Well… I did at first. There was a ton of talk about how great I am and how I’m killing it, even how I’d become the head of engineering. But Brian Kimball didn’t like that I wanted to make the application maintainable. The concept of mappers and DTOs was foreign to him, so he had NO IDEA how to use them, despite them being hyper-simplistic. You see… he has never worked for a company that is known for having strong tech and he has zero startup experience. He complained and complained and complained. I have to write the shape definition for an object?! OMG THAT’S SO NOT OKAY! Okay…

So it became a point of contention. Brian was always crying about it and I would always defend it. It’s scalable, it sets us up for being able to have an API (we’d need 2 later), it helps with security and over-fetching. And he would say things like “but it’s so hard” (dude a mapper is the most basic code you can write) and “your points are right, but I don’t like it. I’ll find a reason why my idea is better”. What? Hahaha. Your ego is out of control, bud. You think you’re right, but aren’t, and your argument is that you’ll find a reason the solution is bad, later? But you’re right now? Again… hahaha.

The thing is Brian Kimball has zero experience as an engineering leader and zero experience at startups. He’s really a product guy, who can kind of code, albeit extremely poorly. What REALLY happened is two things: he mostly worked at Bullhorn, a company with laughable tech and that’s the basis of his experience. So he took the extreme opposite approach with his own startup: use experimental tech that’s half-assed, even if it kills us, because it’s “cool” – fuck what works. And his county-sized-ego was broken by me. It was fine when it was just the two of us, but the second I started proving him wrong in front of others… fired.

He would say things like it doesn’t have to scale! Yeah, TOTALLY agree, but if we can set ourselves up for that for “free”, why not do it? It’s obvious he has never worked for a startup. He read a couple of blog posts about how you don’t need to scale and took it as gospel. Again, yes… but if you can be forward looking for “free”, fucking do it.

What ended up happening is Brian waited until I was on PTO to create a document and spreadsheet showcasing how exposing all of the database fields to the consumer and making queries on pages (1995 PHP style) was a tiny bit faster. I saw this and added my own points around maintainability, security, scalability, tech debt, etc and gave everything a “weight”, so we could determine which idea actually wins. He did not include any pillar of engineering in his arguments and as soon as I started added objective measurements he lost it. The scale was 0-1 (like in AI) and I put maintainability as a 1, everything else less than that. Pro tip: maintainability is king. After all of our Google Doc arguments he added a column “DX” (developer experience) and gave it a weight of 100. Yes… on a scale from 0-1 DX gets a 100. I called him out and he lost it again. The Monday after I was let go.

So… what’s the take away? If you’re not a leader, that’s fine. If you’re not the best at your craft that’s fine too. But learn how to identify and leverage the people that are. When you are outclassed it doesn’t mean you lost, it means you can LEARN. Your ego only hurts your personal growth. And lastly, if you have zero experience that is relevant just shut up and let the professionals do their thing. It’s what you hired them for after all. Why would you let your ego and under-developed skill set misguide you? Be objective my fellow engineers – it’s what you’re getting paid to do. And lastlyer, let this serve as a warning. Do not work for Brian Kimball. His experience is far from impressive, his ego is huge, and his skill set is weak at best. He’s just going to fire you if you embarrass him, which is extremely easy to do. Be humble. Listen to the smart people in the room. Never stop learning. Adapt. And be objective people. Don’t become a Brian – it will sink your ship.