The CTO vs Status Quo series studies how CTOs challenge the current state of affairs at their company to push it toward a new height … or to save it from doom.

What does an IT leader have to do with playing Tetris?

A single piece is falling down the screen. You’re focusing your attention on moving it to the right place. Now, you’re bracing yourself because you know that another piece is going to follow soon. And it’s going to move faster than the previous one.

That may be a rough description of Tetris’ gameplay, but it also captures what our guest Martin Mazur has to say about the software development process: focus on the present – prioritize action over inaction.

Outcome-driven development ditches the practice of crafting detailed feature-oriented roadmaps in favor of giving software developers problems to solve and letting them figure out the best solution here and now, whether by writing code or through creative problem-solving.

But an approach like this requires creativity that doesn’t just appear out of nowhere. You need to help foster it. Martin helps us understand how to build teams and foster skills like this to navigate VUCA (volatility, uncertainty, complexity, and ambiguity). Stick around to find out:

• why schools kill creativity and how to help employees reclaim it,
• how to encourage people to be self-driven by leading with context,
• why doing implementation and discovery in parallel is better than discovery in iterations,
• why you need a diverse talent pool to tackle the challenges of today.

Let’s get creative.

Say hello to Martin

Hi, Martin. You recently visited Warsaw to speak at the 4Developers conference. Tell me more about it.

My friend in Sweden told me about 4Developers. Despite its name, they have expanded into the tech leadership space. I was one of just a few to present in English.

I presented “Leading Tech Teams in Uncertain Times” – one of my most popular talks. I’m not surprised by this. We really live in uncertain times.

I wish I could watch you live. I saw the online version, and it inspired me to talk about the need for more creativity in software development.

You said that hard-to-predict events shatter the most well-researched plans and roadmaps. To address this, you recommend reorienting your team’s focus from features to problems.

How do you see your mission as a C-level manager in light of this? 

If you think your job as a CTO is to make decisions, you’re not likely to succeed. You will eventually get overwhelmed and make poor choices.

The best leaders focus on shaping the big picture and providing their teams with context. They do that because they want their employees to be motivated and self-driven. Then, they can delegate decision-making to them – the people who are closer to the problems.

Tell people the problems and let them figure out the answers – that’s how you build a scalable organization today. I think it’s much more exciting than the old way of commanding and controlling.

Part 1 – outcome-driven development

Problems-over-features is also what we discussed at length in our interview with Smartum’s Mika Pauralahti. It’s the essence of outcome-driven development. How do you see the role of outcome-driven development today?

In most cases, the best approach is to empower your teams, give them problems to solve, and then focus on delivering real customer or business value. Outcome-driven development creates people who care and better customer experiences, too.

However, I don’t think we should disqualify feature teams wholly. In some cases, it might be worth pursuing them. Running a product team is hard. Not that many engineers want to work in an outcome-based team. This approach creates an extra layer of tasks – you need interpersonal skills, empathy, and a deep understanding of users, business, and design thinking.

As a CTO, you need to examine your organization and decide which teams can potentially be outcome-driven and which can be output-driven. There is no one-size-fits-all approach here; it’s more case-by-case.

Why and how should a CTO — who has never used this approach — warm up to the idea of an outcome-driven team?

The best thing about CTOs is that they usually have a technical background. I use two mental models that help them understand the need for decentralized decision-making.

One is about a messaging delay. When I decide as a CTO, I need to communicate it to my tech leaders. They need to tell their architects, and then the architects talk to developers about it.

So, every time something changes, the decision takes time to reach everyone. When instructions aren’t clear and new questions come up, the information must return the same way. This delay in communication limits the ability to respond to ongoing challenges.

The second mental model is about building your organization as a good piece of software.

As a CTO, you are the “catch-all” at the top. Ideally, you don’t want any exceptions to hit you. You want to implement your organization so that any errors are caught earlier. If you get a lot of exceptions of the same kind, it means something is wrong with the structure of your organization or application. You need to go ahead and tweak it.

Your organization won’t scale if you have slow communication paths and manage all the exceptions yourself. To grow sustainably, you need to distribute decision-making and problem-solving.

Outcome-driven development requires a lot of creativity. There are no predefined requirements, just problems to solve as you see fit.

In your talk, you gave an example of how schools kill creativity by teaching students that what matters is that you solve a problem with the provided formula rather than your way. The research you cited shows that the expectation to follow a pre-defined line of thinking turns bright children into adults who can’t do anything without a step-by-step recipe.

Can people taught the traditional approach reclaim their creativity?

What you are referring to is research done in 1968 by George Land and Beth Jarman. They gave children the NASA test for creativity, which NASA also gives to engineers and scientists to measure their creativity.

Overall, 1,600 children between 3 and 5 participated, and 98% scored in the genius category. However, when they retested them many years later, the results dropped significantly and continued to drop with each try.

So why is it happening? I can only give you my assumption. Our school system developed during industrialization and never moved past it. The school tells you to sit and do your work in 50 minutes. Then, you get a 10-minute break. This is how factories work.

Creativity is not appreciated because a factory worker needs to do everything predictably and by the book. If you look at math classes in primary school, you aren’t just expected to give the right answer but to arrive at the answer in a predetermined manner. That becomes ingrained in all our minds as we age.

Can we unwind this? The short answer is yes.

There are two types of thinking — divergent thinking, commonly called creative thinking, and convergent thinking, which is more about finding a solution. The problem is that convergent thinking kills divergent thinking.

When we are divergent, we don’t dismiss or rationalize ideas. Everything is allowed. You can create something crazy, like painting a rhinoceros in your brand’s colors and running it through the city streets. 

Then, in the convergent phase comes the time to rationalize it. Perhaps you could make a digital rhinoceros run through your page?

By allowing divergent thinking to exist independently, e.g., not judging ideas in brainstorming sessions, you open yourself to childish creative thinking.

Once people understand how these modes of thinking work, they can use them in practice; just knowing about them is enough.

Part 2 – VUCA – Volatility

It looks like there is hope for creativity among adults!

In your talk, you mentioned VUCA, a problem-solving framework initially introduced by the U.S. Army War College in 1987. It tackles the world’s unpredictability and considers four elements: volatility, uncertainty, complexity, and ambiguity. You used it to provide interesting examples of fostering creativity.

The modern world is volatile, and IT companies must act quickly. But they won’t be fast enough if they conduct product discovery only within iterations. Can you explain this?

Doing discovery work in iterations, that is, having a discovery sprint and then a delivery sprint one after another, may not be effective.

You do almost waterfall – you have a research phase and then an implementation phase. You fail to capture what you learned during the delivery, don’t feed it back into discovery, and risk wasting resources building the wrong thing.

When you look at models that run discovery and delivery in parallel, you see constant feedback loops on the things you build. Let’s look at an example.

You have a huge drop-off rate of customers in the shopping cart. You look at the data and develop a thesis. You feed that back into the delivery phase. Engineers can start figuring out how to implement this and put in some early work. You can see how the data changes and can feed that back again into the discovery work. You might also discover that your first thesis was wrong when you get deeper into the discovery. You need to refocus your delivery immediately.

The Agile model is sometimes problematic because it forces you to split things into iterations. But not everything is splittable. If you try to build a car, you need to deliver a car, not a skateboard. Delivering a skateboard is not customer value; that’s not what the customer expected.

So, it seems that an outcome-based approach forces you to put less emphasis on structures or processes. You need to be more flexible. How do you mediate conflicts between opposing ideas from different departments, then? Where is the line between unrestrained creativity and chaos?

There shouldn’t be any cross-department conflicts if each team is responsible for discovery and implementation only within their part of the product.

In a setup like this, conflict should only exist within one team. Department interdependence is, ideally, largely removed.

To get the best results in parallel discovery and delivery, I recommend having a strong trio of a tech lead, a design lead, and a product manager on each team. Without them, discovery cannot be done efficiently.

Part 3 – VUCA – Uncertainty

The inherent uncertainty means that you can’t have a plan for success that will definitely work. And yet, you need a plan to convince investors to fund your projects and talented people to follow you. Your answer is to lead with context. What does it mean?

It means giving people enough information about what you want to achieve without overwhelming them. 

There are a couple of layers to leading with context.

The first layer is about being good at painting the vision of how the world, especially your clients’ world, will look when your company reaches its ultimate objective.

The next layer of context is the current application you work on. You can envision how the product will look in 5-10 years. Amazon uses the working backward method seen in its press releases to show what it thinks its product will look like in 10 years. Asana made a cool video of how people will use its tool in 10 years as well.

This content doesn’t tell investors what features you will build. Instead, it aims to inspire them and also to demonstrate what problems you want to solve.

You might think that inspiration is not that much, but that’s what stakeholders need to make decisions. When they decide to go right and left, you say: do you remember the vision? If you still believe in it, we must go that way.

The final layer concerns the short-term context. You might say, “This is how our finances look. That’s why we need to focus on profits now. Revenue is now less important.” When making decisions, people must know what metrics you use at a given moment to deliver on that.

So, there are different layers to leading with context. There is the big company vision for the world, the application you build and how it makes the vision possible, and various short-term considerations.

So, having a product vision is the key to attracting investors. Does it also attract creative minds?

It does because it attracts people whose interests align with your company’s. When your vision resonates with them, they want to embark on a journey with you.

A strong vision has that kind of effect. Remember that you will not manufacture such a vision out of thin air. It needs to be genuine and inherently tied to the nature of your company and its work.

Unfortunately, most companies today spend way too little time developing such compelling visions. They are too eager to build.

Speaking of the urge to build, when the time comes to do that, you advocate focusing on the immediate problem ahead. You used the example of the game of Tetris – only the next block moving towards you matters. That sounds great for fostering creativity. 

However, some CTOs can’t help but focus on the future. They read industry reports and use trends to predict long-term changes. Is there still a place for that if you want to focus on speed?

I used the Tetris game analogy to tell people that sometimes it’s important to make a decision regardless of whether you have all the data. It’s to avoid paralysis.

Often, people avoid tackling a problem because they don’t believe they have all the data to decide. The thing is, you will probably never have all the data. But not making a decision is also a decision – the brick will fall anyway. Keep doing that, and you will lose the game.

In VUCA, the worst thing to do is to abstain from making a move. If you make a mistake, you can always compensate for it later.

Let’s say you read a report on Artificial Intelligence. It says that AI is on the rise. You need to decide whether to invest time and effort in it. Are you looking at possible GPT integrations? The worst thing you can do is to say: let’s wait and see what happens. If you don’t want to do it, that’s fine, but say it clearly so that your employees know that they shouldn’t distract themselves with AI for now. You can revisit the decision in 6 or 12 months.

Part 4 – VUCA – Complexity

In previous interviews, we also discussed observability as one way to embrace the complexity of modern development. However, data is just one aspect of complexity. The sheer pace of changes is another. Your answer is to work with constraints. Tell us more about it. How to use constraints creatively?

I love constraints. The smaller the room for action you give yourself, the more creative your solutions must be.

A deadline can encourage creativity. If you have infinite time to solve a problem, you might develop a very complex solution. But in just three months, you may develop a much simpler idea. You may be forced to use your creativity more.

Time constraints are typical for startups: “We need to do it in 3 months, or we’re dead.”

Better yet, you should foster creativity in your teams on an ongoing basis so that they can tap into their creative potential in response to any constraints that may arise, not just the ones you designed.

You even believe consciously imposing constraints on product development may be a good idea. How does it work? Instinctively, it seems at odds with fostering creativity. 

Let’s say you want to attract more users to your platform. This is a huge issue with many potential implications and ways to solve it. However, it changes when you put some constraints on it.

For example, you may choose to attract people in the 25-35 age bracket interested in buying vinyl records. Now, that’s a much more tangible problem that is less likely to change. You narrowed down problem spaces.

Of course, this constraint is particularly clear because I made it up. However, you can develop realistic constraints to help you solve problems from within your organization.

Part 5 – VUCA – Ambiguity

Ambiguity is about embracing differences. People can tackle the same issues from different perspectives, each contributing something to the organization’s creativity.

Can you give me some examples of how it helped make a difference in the software development environment?

You can think of a problem as a beach ball. When people stand around it, they see it from different perspectives.

I have a friend who works with UX. He discovered many UX-related issues only after he got a color-blind person on the team.

Let’s consider another example from a broader engineering world. Back in the day, only men worked on airbag development. All crash test dummies had a male profile, too. They didn’t account for women, who had smaller bones, lower bone density, and less muscular necks. As a result, the first airbags were less effective for women.

Embracing ambiguity is about leveraging different experiences. The way I experience the world and the way a black woman experiences the world is different. Even if we grew up in the same neighborhood, we still have different experiences. You can’t change your perspective to somebody else’s perspective, even if you’re the most empathetic person in the whole world.

You say that everyone can bring a fresh perspective to the team. But how can you ensure that all these diverse voices are equally appreciated in an IT organization?

Assuming you have covered all the basics of diversity and inclusion in your organization, leaders can also “lend their privilege.”

People listen to you because you’re a leader. Use it to everyone’s advantage.

When you tell somebody, ” You should listen to Janet because she’s an expert in this,” or “I’m not going to come to the meeting, but I’m going to send somebody else because they know their stuff,” you can help diverse, talented people get into more positions and places.

Ideally, it shouldn’t have to be this way, but it sometimes is. On the other hand, by lending your privilege, you can change the landscape little by little.

Also, you should watch out for misconduct and react decisively when you see it.

Some leaders fear losing face and fail to intervene when they see someone interrupt another person or steal their ideas. You need to be able to call that out. I do this myself. It quickly changes the culture of your organization.

At first, it felt a bit scary. However, try asking, “Hey, did you just do that?” and see how quickly your organization changes into one that welcomes all the diverse voices and talents. 

And then, there is the no-assholes rule. If you have those on your team, get rid of them.

When I coach a team, I can sometimes see that a specific person is a problem. They bring the whole team down and take too much space, pushing their ideas aggressively. They don’t let other people speak up. I tell the client about it and suggest removing them. They often say this person is their most productive contributor. But I’m almost sure that the rest of the team will make up for the productivity if they eliminate them. That’s because the person has been holding back the growth of the entire team with their attitude.

Part 6 – Fostering creativity in the long run

Let’s sum things up. You’re a fan of improving things as you go. However, CTOs should always focus on the long-term game.

You discussed a retrospective as a way for everyone to share feedback and improve upon it. You said a retro shouldn’t be limited to a specific time slot. How do you see its role in fostering creativity?

I see room for both formal and informal retros.

Doing retrospectives regularly is a good facilitator of change. But focus on one or two things you want to change. One mistake organizations make is trying to change too many things in each retro. Let it take time. Find your biggest pain point and figure it out properly.

Informal, impromptu retros are very useful and underrated. If something happens and the site goes down, you should work hard to pull it together. Then, sit down to talk about what happened, what went well, what went badly, and what you can do better next time. If there is a disagreement, do a quick 15-minute retro in the morning with the team.

There’s more room for reflection in most organizations than people think. Retrospectives don’t need to be confined to fixed time slots.

Does this approach scale? If your organization becomes increasingly complex, can you foster each individual’s creativity that way?

Some huge companies, such as Amazon, Netflix, Spotify, and Google, work with these models. They all have outcome-driven teams.

None of the companies I mentioned use the same processes. They all have different ways of working or structuring their teams. However, they all try to foster creativity in their teams through empowerment and accountability for the products they deliver.

Watch the whole Leading Tech Teams in Uncertain Times talk for more details!

Part 7 – Resources

I know you publish content that helps CTOs foster a creative environment in their organizations. I’m sure that you’ve also come across many interesting titles from other creators. Can you share some of your best finds?

Leading in Flux is a podcast I started with my friend Ebba Laurin. She is an excellent expert in entrepreneurship and leadership and taught me about VUCA.

The idea behind the podcast is to discuss what it takes to be a leader in uncertain times. We hope to provide a foundation for leadership that is not afraid of constant change and always ready to act.

If you want to learn about fostering creativity specifically, then A Beautiful Constraint is a book for you. I’ve read it with my management team. It tackles the issues we discussed and has many specific stories and examples.

If you want something even more practical, try Google Venture Sprint. It covers what you called the problems-over-features approach. It teaches you how to organize sprints focused on solving problems creatively. The book is good, too, but I think the web page is enough to get the idea.

What’s next? Three actions for CTOs to take

So, what do you think? Are you now ready to lead a creative organization that can move fast and decisively in a VUCA world?

Efficient outcome-driven development is within your reach – just make sure to sow the seeds today. Do this by:

1. letting your teams choose measurable goals to achieve and the best method to get there,
2. permitting your teams to do product discovery and retrospectives asynchronously and when needed, not just within rigid processes,
3. using divergent thinking and constraints to power and grow the creativity of your organization.

So, what would you do If the rules of rationality didn’t apply?