‘Meet the Challenge’ is essential in Tech. In a previous article, we introduce the ‘Value Flywheel’ and the four phases: Clarity of Purpose, Challenge, Next Best Action, and Long Term Value. In this article, we dive deep into ‘Challenge,’ Phase Two of the value flywheel. Challenges need an open environment. When you decide on a strategy, do you have the right environment to challenge it? We’ve found this to be hugely important.
Creating a safe environment for Challenge
Our last article discusses Phase One of the Value Flywheel, Clarity of Purpose, and setting direction. Part of bringing people along with you is creating an environment where they can question purpose and challenge direction. But also, it’s doing it safely and constructively.
What techniques can we leverage to challenge? And what sort of environment allows challenges to occur? How can teams participate? It’s worth thinking about the socio-technical aspect of the organization. It’s about how we talk to each other and how the organization collaborates and communicates.
You need to have your architecture leaders set the direction and impose it. You need to do it together. And you need to do things collaboratively to invite and facilitate challenges. Techniques like Wardley Mapping, Event Storming, and Threat Modelling are done as a team and collaboratively.
People have an opportunity to challenge the process and artifacts. They’re not challenging the individuals. That’s very important. Use techniques, methods, and practices that are open and invite challenge. It’s not a case of presenting a PowerPoint deck. And announcing that this is what we’re going do. So make it so!
‘Challenge’ helps to set up an effective feedback loop.
You must invite challenges for a good feedback loop and understand if you can improve. In high-performance organizations in the cloud, things move very fast. You can’t know at all. My challenge is to ask yourself if you have ever fully understood anything by listening to a PowerPoint. If you want to understand something, you have to dig into it. You have to ask questions And make sure you know. That’s why the challenge is so significant. My computer science teacher told me:
‘Show me the person who knows it all, and I’ll show you the fool.’
Many people need to understand the challenges to their strategy or plan. In fact, ‘Challenge’ is good in the right environment. You need to take that feedback on board. But in a bad environment, ‘challenge’ used as a weapon is dangerous and damaging.
‘Challenge’ is about engineers.
Our most excellent engineers know the nuts and bolts and the nooks and crannies of the system. If you silence their voice, you’ll lose much value. If you create a good environment, your engineers can point out where things won’t work. Or bring new ideas to the table. You get a valuable system. So design your organization and your tech around the ability to challenge. It’s critical.
Set up the team as the fundamental delivery unit and flip the org to enable teams to deliver value to customers aligned with the clarity of purpose. The architects and senior leadership teams are there to encourage and empower teams to provide the best outcomes. It’s about flipping the hierarchy. The team is at the top of the pyramid. And from a hierarchical point of view, we’re there to enable and support. That’s the type of environment you need to set up for success.
The team does the most. You need to give the people with the context every ability to make decisions. And have rapid feedback loops to validate their choices to see if they are good or bad. So getting the proper environment is critical for success. We talk about why ‘Challenge’ is essential. If you hire intelligent engineers, your best technical strategy is to get out of their way. Ensure they know the goal and get out of their way. You must put in suitable support systems to ensure people can work effectively.
Traditional Leaders Struggle with ‘Challenge’
In traditional leadership, there can be a struggle. The team is carving a way, but some traditional leaders don’t like that. But if you hire smart people, you must let them do the work. You need enabling constraints to guide engineers along the path. You need to allow teams to grow fast, but you want to do it securely and well-architected to prevent technical debt. Part of an environment for success is making sure guardrails are in place to enable engineers to go fast responsibly. The organization and team need to understand what type they are. And how teams communicate and operate within the organization.
Mapping enables Challenge
A big part of this is understanding where we are on the journey. In the Value Flywheel Effect book, we talk about mapping within specific contexts. You may be an organization that’s trying to get up and running. You’re trying to define your ‘team topologies’ and setting up your system and environment for ‘challenge.’ But, to get there, we must move from A to B to C using mapping.
‘Challenge’ is an excellent way to gather feedback. It’s a good place for empathy. Your leadership may be saying we’re going here. And the teams may be saying we need to do this.
With the correct method of ‘Challenge,’ leadership can acknowledge and explain why we’re doing these things. We’ve done that with Wardley Maps in the past. You map your stack, platform, area, and business. ‘Challenge’ can help you work out your position. And the big things that we need to move to set up the org to operate correctly.
Identify your capability gap.
By mapping your org capability and environment, you can see if you have the capabilities to set you up for success. And if you have expertise in secure development, Wardley Mapping or Serverless, for example. If you do, you can consider how to get them in place for your teams. Because you want to avoid saying that you are going serverless and not giving teams any support or enablement to get there, you need to map out your org capability to see where you should be investing. And where you need components to enable the teams to go fast.
For example, if your leadership wants DORA scores at elite. But you’re on a monolithic stack and running your infrastructure. You can use a Wardley map to show that most of the system is custom-built. That raises the operational concern of what we are doing to fix that! It’s a good Challenge point. We need to invest in our move to serverless. Or reduce our operational burden so that we can do more delivery. And do better at our DORA scores. It’s also a good communication and collaboration tool to have conversations and challenge constructively.
Pathway to production
The last thing to consider is your production pathway. By ensuring you have a rapid feedback loop in the hands of real users, you’re part of an environment for success. And the path from idea to production is as optimal as possible. You have a well-oiled pathway to output because you remove impediments to the flow of value. So you’re not waiting months and sometimes years for feedback on your teams’ work.
What happens if you skip over or ignore Challenge?
You start to see people disengage. They feel that they are not listened to. And they will leave eventually, especially if they’re talented engineers. If they don’t have an avenue to challenge, contribute or give their opinion, that lack of engagement will drive them away. Also, you need to get the best out of your teams.
You’re not going to be able to meet your Clarity of Purpose. Or your goals because you are forcing teams to follow a plan you decided in advance. So engineers need more time to push back on that. Otherwise, you will see frustration, and people will not feel part of the process.
Architects at the Intersection of People and Technology
Team interaction modes will be suboptimal. Lots of teams will do the same things. There will be ‘repeat work’ because there’s no way to challenge. Or ask: ‘Hey, I should be doing this, or you should be doing that!’. Without socio-technical topologies, you’ll see teams competing with each other instead of enabling and empowering each other.
The intersection of people and technology is critical. There are two systems. The system of all the employees in the company. And then the system or the technology we’re working on. You must bring those two together and look at them through the same lens. And that’s something that architects have to do. Because it’s hard for other leaders to do it, they will see one half, not the other. You need to see both to make them work together. That’s going to be a massive area going forward.
One original writing talks about DP1 and DP2 systems. Purpose-based and function-based. And function-based is everyone doing their job function. They rarely work well together. The chapter on ‘Challenge’ in The Value Flywheel Book is probably the deepest.