Becoming an empowered team means solving problems rather than shipping features. Empowering software engineers and involving them early in discovery work can result in better products. If we measure outcomes rather than output, we can also hold teams accountable. Martin Mazur spoke about unlocking engineering potential at NDC Oslo 2023.
Supporting software engineers to empower them means trusting them and getting out of their way, Mazur said. We have, for years, broken down software engineers’ innovation capacity by removing them from the discussion on what to build, he mentioned. Innovation happens when real customer problems meet new technology - nobody knows what tech can do except for the engineers. By involving engineers early in discovery work, we can create products that exceed our customers’ expectations, Mazur said.
In order to cope with empowered work, engineers need to be able to navigate uncertainty, plan their work, have meaningful conversations, and understand how value is created, Mazur said. These are skills that they can learn, but in the context that most engineers have been working, they’ve never had a reason to learn them, he mentioned.
Mazur mentioned that if we look at competence as both width and depth, at some point in your career you really don’t get a huge effect from going deeper. Instead, broadening skills and looking at things, such as business models, design principles and interpersonal skills can raise engineers to new levels, he suggested:
It’s easy to get started by, for example, attending an unusual talk at a conference or picking a book you wouldn’t normally read.
Keeping teams accountable for results can be tricky if you don’t have the right culture and organization, Mazur said. People must feel empowered and in control of their work to accept accountability. He mentioned that the best thing we can do is to measure our team’s success on the outcome, that is, the impact they’ve created for the user, product, or business, not the output they have generated:
If we measure outcomes, we can also hold teams accountable for that outcome. If we measure output, we only know that they’ve worked at a desired pace, not what value that work actually generated.
Mazur suggested that software developers should invest in other types of skills than purely technical skills. These investments have a greater payout for those individuals, their teams, products, and, ultimately, the world, he concluded.
InfoQ interviewed Martin Mazur about how to unlock engineering potential.
InfoQ: What makes solving users’ problems more important than delivering features?
Martin Mazur: It’s all about the value we create with our software. A feature is only valuable to the user, their organization, and ultimately the world if it solves something - i.e., features we build that are never used are a huge waste of human potential.
InfoQ: What do teams need to be able to solve problems?
Mazur: It’s not one single thing, there are several factors that need to be present in order for teams to be able to solve problems. Ultimately, most teams and organizations need a culture change. We need to reach a point where people deeply care about their software’s impact on the end user. This requires organizations that are led with context and not control; teams must be delegated problems, trusted to solve them, and held accountable for the results.
InfoQ: How can teams improve the way that they make decisions?
Mazur: The most important thing around becoming better at making decisions is distinguishing good decisions from good outcomes, and vice versa. A good decision is something that, given all the information at hand, is the correct course of action. That means if you had to redo the decision, you would have made the same call again and again. Good decisions can still lead to bad outcomes.
Once we understand that, we know we have to act on the information we have, not the information we wish we had. To summarize, a decision is like a bet - and just like a bet, it has odds; the correct decision is the one with the best odds.
Often engineers get stuck on all the information they don’t have and end up in analysis paralysis. What happens then is that there is usually no time to wait, and not making a decision is also a decision. We end up with the default option which could be either good or bad - the equivalent of a coin flip.
InfoQ: What’s your advice to teams? And to individual software developers?
Mazur: The best advice for both is always asking two questions about your work.
"What is it for?" and "Who is it for?" and not do a surface-level job answering those questions. Really dig deep and figure out what problem the product solves and for who - this will create a new perspective for your work.
