Product/Culture Duality

At many startups, culture happens organically. It’s just built around the personalities and values of the founders and early team. But anyone who has built a company before learns a pretty vital lesson: culture is important, and when something is that important you have to be intentional about it. We wanted to build a companyContinue reading “Product/Culture Duality”

Organizational Psychologist vs. Organizational Mechanic

When a team or company is not functioning as it should, two types of problem-solvers often emerge. The organizational psychologist tries to debug the culture. The organizational mechanic tries to debug the process. The mechanic asks what meetings or what documentation is missing. Organizational mechanics love “reviews” (meetings that force decisions to be made). WhenContinue reading “Organizational Psychologist vs. Organizational Mechanic”

Using Systems Thinking to Understand Personal Finance

I always struggled with double-entry accounting, even after I got an MBA. I could do it and mostly memorized my way through a lot of the jargon, but it wasn’t until I took a systems view to accounting that I really understood the mechanics of how things worked. I figured I’d share some thoughts aboutContinue reading “Using Systems Thinking to Understand Personal Finance”

A Small Difference in Developer Productivity Can Amplify Over Time

Small differences in the productivity of software developers on a team can easily magnify themselves over time. On many software teams, one engineer seems significantly faster than the others. Now, in some cases, it’s because that engineer is cutting corners left and right. They get stuff done, but they cause damage. They’re a tactical tornado.Continue reading “A Small Difference in Developer Productivity Can Amplify Over Time”

Mission Tactics: When Under-Specifying is Good

On my product engineering teams, I under-specify product requirements by design. That is, the work that engineers are asked to do is always left a little ambiguous. I used to have a very naive view of how militaries made decisions. You had a formal chain-of-command, and detailed instructions were passed down that chain and implemented,Continue reading “Mission Tactics: When Under-Specifying is Good”

Good Architecture: Data Model vs. Data Flow

Most architectural mistakes I’ve seen in software stem from a mistake either in the domain model or the data flow. Understanding what each of those two things is, how to do them both well, and how to balance the tensions between them is an essential skill every developer should invest in. Let’s use an exampleContinue reading “Good Architecture: Data Model vs. Data Flow”

4 Hiring Myths Common in HackerNews Discussions

Another day, another HackerNews discussion about hiring being broken. The most recent one I saw was triggered by a blog post by the formidable Aline Lerner (disclaimer: Aline is a friend and we collaborated on a hiring book last year). Now, I 100% agree that hiring is broken, and Aline’s post is really thoughtful. InContinue reading “4 Hiring Myths Common in HackerNews Discussions”

The Shape of Technical Debt

The term technical debt is so common that you’d be hard-pressed to find anyone in the software world that hasn’t heard of it. But what is technical debt? There are a few frameworks out there, so I’ll list them quickly, but then I’d like to present one I’ve found especially useful with the teams IContinue reading “The Shape of Technical Debt”

Hire people you believe in—believe in the people you hire

I was reading an amazing Twitter thread about Bill Grundfest, founder of The Comedy Cellar and the guy who discovered some of the most famous comedians. In the thread, which includes stories of Jon Stewart, Bill Maher, and Ray Romano, the pattern is essentially: Bill is able to detect talent, even early on in people’sContinue reading “Hire people you believe in—believe in the people you hire”

Code is a liability, not an asset

I loved this quote from the book Software Engineering at Google. Found it a helpful reminder. Earlier we made the assertion that “code is a liability, not an asset.” If that is true, why have we spent most of this book discussing the most efficient way to build software systems that can live for decades?Continue reading “Code is a liability, not an asset”