management

Pre-mortems can be helpful but often lack structure. Polling your team to find out what could go wrong can backfire.

Sharing ownership of an app’s codebase is easier than ownership of its configuration. The biggest impediment is failing to understand the dynamic between development teams and operations.

In Steve Jobs' March 2011 keynote, he shared his thoughts on Apple, technology & the humanities, all wrapped up in this frequently cited quote about how he viewed Apple at the intersection between technology and the liberal arts…

I tweeted something a while back which resonated with a few folks: I do find people find “politics” to be a loaded term. The way I frame it for them is that knowing how to “navigate the org” Is essential. They all seem to want that skill, even if they don’t know how to get it. There is an essential point here, even if I wrapped it in a poorly worded Tweet.

You’ve heard the phrase “hire when it becomes painful”, but did anyone ever tell you what that means in practice? In this article, I’ll break it down as best as I can.

Long ago someone asked me what helped me grow the most as a technical leader. My answer was immediate: reading management books. I started reading these books only after I exhausted my network of advice on how to manage effectively. I noticed people borrowing ideas they learned from books, and eventually, I started buying some of these books.1 Reading books on management provides a few advantages: Centers your perspective away from the immediate problem.

You did it! You’re managing a new team. Maybe it wasn’t your decision but either way I see you’re busy. We don’t have much time. Here’s some advice as you chart a course for your team: Make new problems into old ones Hire generalists, not specialists Own the problem space This may sound self-explanatory but give me a minute to expand on this. After a few years working and leading software teams, let’s just say, I’ve seen a few.