Serverless Craic Ep27 Challenge Tech Strategy - Phase 2 of Flywheel

Serverless Craic from The Serverless Edge

It's important that engineers challenge tech strategy. We talk about Challenge in our book: The Value Flywheel Effect.

In a previous episode found we went over the Value Flywheel in general. There are four phases: Clarity of Purpose, Challenge, Next Best Action, and Long Term Value. Today, we're going to deep dive into Challenge, which is phase two.

Challenge is about the environment. When you decide on a strategy, do you have the right environment to challenge it? We've found this to be hugely important. In the last episode, we talked about 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 in a safe and constructive fashion. You don't have your architecture leaders setting the direction and imposing it. You need to do it together. And you need to do things in a collaborative and facilitated to invite challenge.

Techniques we use like Wardley Mapping, Event Storming and Threat Modelling are done as a team and collaboratively. People have an opportunity to challenge the process and artefacts. They're not challenging the individuals. That's very important. Because you need to have a good feedback loop. To understand if it can be better. Or if this could be improved. In high performance organisations in the cloud, things move very fast. You can't know at all.

Challenge is about engineers. Our greatest engineers know the nuts and bolts and the nooks and crannies of the system. If you silence their voice, you're going to lose a huge amount of 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 richer system. So design your organisation and your tech around the ability to challenge. It's absolutely critical.

Architects and senior leadership teams are there to enable and empower teams to deliver the best outcomes they can. 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. If you hire smart engineers, your best technical strategy is to get out of their way. Make sure they know what the goal is, and get out of their way. You have got to put in the right support systems to make sure people can work effectively.

In traditional leadership, there can be a struggle. The team is carving out their own way and traditional leaders don't like that. But if you hire smart people, you need to let them do the work. You need enabling constraints as well. To guide engineers along the path. You need to enable teams to grow really fast, but you want to do it in a secure and well architected way. So that you're not going fast and creating lots of technical debt. Part of an environment for success is making sure guardrails are in place to enable engineers go fast responsibly.

A big part of this is understanding where we are on the journey. 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 for secure development, Wardley Mapping or Serverless, for example. If you don't then what are you going to do to get them in place for your teams?

The last thing is pathway to production. By making sure you have a rapid feedback loop into the hands of real users you're part of an environment for success. Because you are removing impediments to the flow of value to end users. You have a well oiled pathway to production. So you're not waiting months and sometimes years for feedback on the things that your teams are working on. What happens if you don't have a good environment for challenge. You'll start to see people disengage. They'll 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, then that lack of engagement will drive them away. Also you're not getting the best out of your teams. You're not going to be able to meet your Clarity of Purpose. Or your goals because the teams are following a plan that was decided in advance. So there is no push back on that. You will see frustration and people will not feel part of the process.

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. You'll see teams competing with each other. Instead of enabling and empowering each other. 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 have to bring those two together and look at them through the same lens. And that's something that I think architects have to do.

Serverless Craic from The Serverless Edge

theserverlessedge.com
@ServerlessEdge