Devon C. Estes

It's pretty well known that for teams to work well, there needs to be trust. The thing is, it's said so often that I think it's lost its meaning a bit. Everybody says they trust folks, but then their behavior doesn't actually show that. Personally, I think many people don't even realize that the behavior they're exhibiting indicates a lack of trust, and this behavior comes from a misunderstanding of what it means to really trust someone, and so that's what I wanted to cover today. »

For most of my career, the software I was building was basically the entirety of the product the company sold. We worked with our colleagues in Product to decide what we would build next to serve our customers' needs, we wrote some code to solve those problems, and then we shipped it. It's easy to show impact when the value your team delivers is derived almost entirely from the software you ship to production. »

Nearly every conversation I've been in about software quality treats it as a tradeoff with speed. You can move fast, or you can be correct, and your job as a lead is to pick a point on that line and defend it. I've never really believed in this, and with AI speeding things up further this is a bigger topic. After a few years of being the person accountable for both the speed and the quality of what a team ships, I've come to think that bugs in production aren't really the problem here. »

Today I'm taking a bit of a different track on what I'm writing about. Instead of something very technical, I'm going to talk about something completely non-technical - estimation. Estimation is one of those things that everybody wants, but nobody ever really gets, and this is something that can be really hard to explain to product folks, but I've used this example to explain our faults in estimation quite a lot, and so I wanted to actually write it down and share it with folks in case they could use it as well. »