minware

Managing engineers based on what people say doesn’t cut it anymore in the era of tighter budgets. People are insanely biased, so you need data to make good decisions. If you rely only on conversations and surveys, you’re going to have these major efficiency problems: (1) You’ll put a lot of effort in the wrong places We did a test at Collage.com where we surveyed the customer service team. We asked how many times they personally experienced a severe bug in the past week that corrupted customer data. The catch is that we knew this bug had only happened once based on system logs. The results? The combined surveys indicated that the issue had happened OVER 50 TIMES! Availability bias is super powerful and everyone is susceptible (including leaders), so you need data to know the real impact of issues associated with strong emotions. (2) You won’t put effort where it’s badly needed Bias is even more dangerous when it runs the other way and people normalize major inefficiencies. We had another bug at Collage.com where the shopping cart wouldn’t scroll and it was impossible to check out with multiple items. The way customers describe this when they call support though, it sounds like “user error” or “browser issues.” This went on for days and days before someone actually found the bug while testing, even though a bunch of customers had called us about it. We had become so used to dealing with similar-sounding non-issues that we didn’t think anything of these warning signs. As a manager, you may be shocked to see what people endure every day without thinking to speak up when you dig into the data. (3) You’ll create a highly political organization Not having data doesn’t prevent people from forming strong opinions. At best, engineers will waste a ton of time arguing about things. At worst, the loudest voice will be the wrong one, and your quieter, more talented engineers will quit. -------- WHAT TO DO INSTEAD It’s still important to listen to people, and the fact that someone feels bad about something is a problem itself. But, people are very bad at estimating the MAGNITUDE of problems. In 2024, engineering teams have to use data if they want to survive. It’s fine to use qualitative feedback as a starting point, but you need to measure how often the things you hear about are actually happening. Exploring that data to see what people aren’t telling you is also important, either because they’ve normalized inefficiency or can’t see the big picture from their perspective. It’s critical to have full observability of your development systems, including Jira, GitHub, CI/CD, etc. This lets you see things bottom-up, not just top-down. Ticket data can provide some context, but most of the information about tech debt, slow processes, poor developer experience, etc. requires looking across lower-level metrics and matching sequences of events across different systems. Start small, start big, but start now before it's too late.

A programming language should be judged not by its power in expert hands, but by how well it prevents inexperienced developers from doing stupid things.

The #1 way to improve productivity is to work in smaller tasks. Virtually every productivity metric (cycle time, dora, WIP, etc.) is a function of task size. “But the overhead of each [ticket/pull request/deployment/approval process] is so high, I’d never get anything done with small tasks!” That’s a feature, not a bug. Small tasks expose other stuff that sucks so that you have to fix it. “But some important things just take a long time!” Really? Are you absolutely sure? The human genome evolved one mutation at a time, and is way more complicated and important than anything anyone has ever built.

How long should you keep someone who's performing poorly due to legitimate personal issues, like taking care of a sick family member? This is hard because we'd all expect some leeway in that situation ourselves. There's no perfect answer, but I think it comes down to whether the team feels like the person is doing enough given their situation. The person still needs to meet commitments and communicate effectively, even if those commitments are scaled back. Keeping someone beyond this point starts to damage morale. If you as an employer still want to support the person financially, that is a separate decision. You can put them on paid leave, but keeping them on a team when they are bringing others down isn't good for anyone.

Bad processes can make a good team fail, but no amount of process can make a weak team succeed.

If your functions take complex objects as arguments and only access a few properties, then you’re not doing functional programming — you’re doing object oriented programming with all the problems that entails.

If CrowdStrike had dev observability, this wouldn’t have happened.

The word “playbook” is a major red flag. Beware of anyone who sells or uses one. Businesses are a lot more complicated than football, and no two play by the same rules.

Engineering observability is so far behind the physical world that it’s embarrassing. Imagine a factory running at 25% efficiency *for an entire year* and the CEO has no idea why. This would never happen. Everyone in charge would be fired after the next board meeting. Yet, the first thing the CEO (who had been there for nine months) told me after I inherited the combined engineering team following the sale of my last company was: “The engineering team has been working on XYZ project for the past year. It was supposed to take three months, and I have no idea why it’s late.” And he’s not alone! This is common with software businesses, and it’s totally insane.

Few people create their own programming language, but everyone should. Read how it 100x'd our productivity at Collage.com.