BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News Unlocking Software Engineering Potential for Better Products

Unlocking Software Engineering Potential for Better Products

Bookmarks

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.

About the Author

Rate this Article

Adoption
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

  • The inmates are running the asylum

    by Javier Paniza,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Maybe agree with Alan Cooper and the empowered software developer is the reason why software is making the life of people misserable, many times.

    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


    True. But most developers do not understand it. They are eager to rewrite their Java application with Kotlin, or rewrite all their applications to use microservices, or looking for an excuse to use docker or a reactive JavaScript framework. While the user has to wait, expend a lot of money to get a system slower and plenty of new bugs. Rarely the new programming buzzword solve end user problems. Rarely writing applications from scratch is the solution.

    Developer want to enjoy and be happy and many times this collides with the users happiness.

  • Re: The inmates are running the asylum

    by Darin Rogers,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    If I'm understanding correctly, you're saying that developers want to play with new toys, which conflicts with creating customer value. I agree partly. But I think that newer tools help developers deliver value more quickly and more consistently.

    I also think that cleaning up tech debt, which can include migrating to newer tools, is a necessary part of building long-lived software. But if developers are writing buggy software that costs the customers more money and delays schedules, all so they can tinker with a new tool, then that seems like a systemic problem.

    But that's the point of the article, is that there needs to be a culture change towards aligning what developers value with what customers value.

  • Re: The inmates are running the asylum

    by Martin Mazur,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    I think there is a misconception about what an "empowered software engineer" is. Many interpret it as engineers being free to do whatever they want, which is far from the truth.

    What I mean is that engineers need to be empowered to solve problems however they want - and then held accountable for those solutions. When I say problems, I mean real customer or business problems.

    Company leadership still needs to provide vision and principles for the product - these are the boundaries. If we are an e-comm company, you are not allowed to build spaceships just because you feel like it.

    I believe most engineers really want to do good for the user. However, instead of seeing the user's problems, they are fed with tickets to implement. This funnels the creative energy into tech problems (i.e. rewrites, framework updates, etc.) instead of keeping it to user problems.

  • Re: The inmates are running the asylum

    by Martin Mazur,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    When it comes to cleaning tech debt and implementing new tools, these are choices that can only be made if the developers have the full context of the business and user space. Most developers lack this today and can't make the call about whether speed or quality is more important. Wether getting it out the door or getting it right is more valuable.

    Hence they are forced to fallback on the craftsperson myth - I'm going to do my job well regardless of consequences. These developers are not empowered; they don't have the context to make the call - hence many managers feel they need to micro-manage these teams.

    Most people in tech are ridiculously smart; if you give them the parameters, they will be able to make the call - but they need to pickup a few new skills to do it.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

BT