I guess if AI is what it takes to finally get people to care about architecture and team structure then mission accomplished?

Younger engineers keep asking how I prioritize in a chaotic environment. Here's my approach.

A hard-won lesson for ya: Always deploy when you've got lots of traffic.

A project is something you do, a product is something you own.

Whenever I talk about sprints, someone mentions Shape Up. So you have 9 week sprints – what's the difference?

For the past few months I've been introducing sprints into a chaotic startup that's been growing so fast everyone's got whiplash. Since August, 5 engineers turned into 12. I think it's starting to work.

A few engineering principles I aim to instill in every team I join. Lead or not.

Let go of your legos and let others do the work.

Going from Big Vision to Series of Executable Steps is a key skill for senior+ engineers. PMs can help but they don't know everything.

How do you choose what to work on first? As an empowered engineer that's a key skill.

Working with AI is here and it's skill. Just like google-fu became important in the mid 2000's. A few things I've learned.

Why do some projects ship and others seem to drag on forever? You need 3 people to get this right.

You can't prevent bugs. You'll burn out. Instead focus on making them quick to fix.

A long design phase without shipping kills many software projects. Here's a story from production I haven't shared before.

Been thinking about what needs to be in place for engineers to ship with confidence

effective engineering teams should work *with* their product owner/manager, not *for* them

A shift in your code review process can boost your team's productivity. Empower authors to make the call.

Don't get stuck being a critical member of the team.

Team dysfunction where everyone's a soloist? Try this fix: Force the team to work on ONE story at a time.

Ever felt like your software team is just soloists in a trench coat? You may be right!

The secret to effective standups that don't suck