Serverless Craic from The Serverless Edge

Send us Fan Mail

We are just back from The Value Flywheel Effect book launch at DevOps Enterprise Summit organised by IT Revolution with Gene Kim and crew. 

Learning Sprint 

The first thing I did was a learning sprint. I did an hour on creating a cloud strategy with Wardley mapping, which I thought was interesting. I used Ben Mosior's Wardley map canvas from LearnWardleyMaps.com. And it was great taking people through that. Once people start connecting the elements of the value chain, they can start to ask why is that over there and not over here? Then you're into a nice conversation. 

People can get very micro at the start. And you say just pick one and keep moving. Just keep pushing through, because you can always add more later. You are getting people to move quickly. And you are giving people a couple of steers. But the first 20 minutes is complete confusion. What are we doing here? And then once you draw the map out, people go 'Ah right!'. And then when you start to plot movement and inertia, that's when people get really excited. And it becomes crystal clear.

Creating the Value Flywheel Effect Talk

I deliberated on what to do for my talk because I wanted to do something different. So I decided on 'Creating the Value Flywheel Effect' looking at how came up with this stuff. So I did an intro to the book. And then I told the story through maps, similar to our Map Camp talk.

I started with one of the drawings we had done five or six years ago. Which was a scribbled messy drawing of a map. And I contrasted with the map in the book to show the evolution of the map. So it was a nice mechanism to tell the story. It's important to remember that the map is not important. It's the communication! And the interactions. The maps are always wrong at the start. People try to go out of their way to create the perfect map. But that's not the point of the exercise.

The Value Flywheel Effect Book Signing

There was a huge queue and I was there for two hours signing 200 books. Propelo sponsored our book signing and they were great. 

It was fantastic to see Dominica DeGrandis' comments on LinkedIn. She wrote the book: 'Making Work Visible'. It is a brilliant book about visualising flow. She has a couple of posts about our book: 'The Value Flywheel Effect'. And she popped up a maps from her LinkedIn called 'Mapping Psychological Safety'. It was the name of the post on her blog: DDeGrandis.com. And she said that it had never occurred to her to map psychological safety. I thought that was insightful.  Psychological safety is usually the base or foundation of the map. 

It's built into the flywheel. You need an environment where it's safe to challenge. And having safety to challenge requires psychological safety. It's cool that it's resonating with people and they're starting to zero in on those sorts of things.

DevOps Enterprise Summit was a great event. Look up the slides on GitHub. All the videos are on videos.itrevolution.com.

Serverless CrAIc from The Serverless Edge
Check out our book The Value Flywheel Effect
Follow us on X @ServerlessEdge
Follow us on LinkedIn
Subscribe on YouTube 

Send us Fan Mail

Today we are talking about a big DevOps Conference. And the first book signing of our new book, The Value Flywheel Effect.

It's at the DevOps Enterprise Summit on October 18-20 with IT Revolution who also published our book. It's the first live event in three years. DevOps Enterprise Summit is the leading community for driving change in technology. 

It's scary and challenging tying to drive transformational change. So it's brilliant to be able to talk to practitioners who've done it before. I'm interested to see how 'The Value Flywheel Effect' lands. I'm doing a talk on the book and a book signing. And I am doing a couple of Learning Sprints at DOES. We are focusing on Wardley Maps because that's what a lot of groups find super exciting. 

One of the best things about mapping is that invites challenge. So hopefully the audience will be debating if I have my components in the wrong spot. Then we will have a good conversation and interaction.  At the Learning Sprint we will sit down with a table full of people and walk through the Wardley mapping process. It is a really good way of learning the technique and asking questions in a safe and comfortable space.

One of the cool things about DevOps Enterprise Summit is they've been running for over 10 years. They have all their IT Revolution books, which are all brilliant. But what's neat is the Repo on GitHub. where they put the presentations for all the talks. There are two events a year. So you have about 20 repos full of presentations on GitHub @DevOpsEnterprise, which is the name of the organisation.  It's an absolute goldmine of free information.

There are videos as well on events.itrevolution.com. You have to register for it, but it's very unintrusive. Once you register, you get access. And they don't send too many emails. It's a fantastic and supportive resource for people trying to drive change.

There's nothing more comforting than seeing something that resonates with what you're trying to do. And with the challenges you're facing. And you can send it to peers, friends or around your organisation. It can give you additional support and credibility for what you're trying to do. And it can drive adoption. That level of external validation for what you're doing can accelerate internal adoption of the change you're trying to drive. We've definitely benefited from that in the past. Don't listen to us. Go watch this video or read these slides. It's a great technique to the leverage.

We have two playlists on IT Revolution's blog. One on Lean Engineering and another on Effective Cloud Adoption, with links to a bunch of videos. Years ago, you would have been hoping to get on a course to learn this stuff. Now it's on tap! You end up going away from DevOps Enterprise Summit with at least 10 things that you want to try or at least look into. And you have repositories of resources available which are great getting your hands on to take back into your own organisation.

DevOps Enterprise Summit 

Serverless CrAIc from The Serverless Edge
Check out our book The Value Flywheel Effect
Follow us on X @ServerlessEdge
Follow us on LinkedIn
Subscribe on YouTube 

Send us Fan Mail

This week we look at 'What is Value Engineering?' with BMK Lakshminarayanan from DevOps New Zealand.

BMK is based out of Wellington, New Zealand working as Transformation Architect and Independent Consultant for Section Six.  He also worked for 15 years with Bank of New Zealand.  As part of that work he connected and became a central part of the DevOps community. 

BMK uses the term value engineering a lot. It's about making tech impactful for your business. When he says impactful for your business, it's about value for your customers. That includes making wise decisions about your technology investments. 

Value is what is your customer getting out of your service and product? You need to look at three things for customer value. 
1. What value is the customer getting from spending their time? 
2. What value do they get for the money they spend on that product or service?
3. Are they really happy with the service or product that you're offering? 

The other side of the coin is actually business value. What is the business getting out of the software you're running in production? Is it generating revenue for your business? What IT investments are the business making? Are they getting a good return of value? 

As an architect or developer your job is not just building and committing code. You look after the code that you're running in production. And how customers are using the system and the experience they have. The feedback you get goes back into your architecture, design, planning and development. 

There's a huge piece of engineering culture that needs to be put in place. We are talking about psychological safety. If you ask engineers to own an outcome and it's not happening.  They need to be able to speak up and drive how that outcome is met. 

I use a term called engineering excellence. It's the mindset and culture within software units or the technology itself. An enterprise may have top talent and high density talent. But who can solve problems for customers? 

People need to feel comfortable sharing their experiences from an organisational point of view. In order to do that, you need a friendly environment where people can stand up and speak up.  

I've seen the other side of things.  When engineers don't feel they are in an organisation that's promoting, safeguarding or helping with psychological safety. They keep moving to a different organisation to look for different opportunities. 

 A lot of people have moved to the cloud. But they haven't realised the value they thought they would have. Have you seen that? 

I would say a lot of organisations are struggling in this space. Moving to the cloud is not just a business decision. You need technology experts to make this viable for your business to run. 

In traditional IT, you have a datacenter and you have design and a lot of capitalizable work in that space. But when you move to a rental model, the Capex is very little and the Opex is more. The business previously never worried, cared or thought about how much data cost to run their business application. Because it's a shared infrastructure in your data centre. 

There's a whole education required. We talk about that in our book. FinOps and Opex versus Capex. The organisation has to change the entire process, their thinking and the working culture, when you adopt the cloud.  

You need to let developers loose with guardrails and the correct governance. You can't build the same way in the cloud. You've got to build in a different way to take advantage of the newer services.

Serverless CrAIc from The Serverless Edge
Check out our book The Value Flywheel Effect
Follow us on X @ServerlessEdge
Follow us on LinkedIn
Subscribe on YouTube 

Send us Fan Mail

Grady Booch is a fantastic software architect who has done a lot of pioneering software engineering. One of his latest messages says that it's a good thing that AWS, Azure and Google are offering guidance on building with well architected. But he also warns that when cloud providers talk to you about well architected, it comes with a bias towards their products.

There is an inherent bias among providers who are investing in these frameworks. They lean towards their own ecosystem and services. But the interesting thing about the AWS framework is if you squint at it sideways, you can extract the implementation details. And focus on the principles and values behind delivering a well architected solution. 

It's the collaboration, questions, mindset and thinking that are good. And they are fairly consistent across whatever tech stack or platform you're leveraging. 

I remember having discussions with people who were asking what architecture is? They weren't quite sure what architecture was and were trying to redefine architecture. With less technical colleagues, you need to give them a definition of what architecture is.

When you compare all three Cloud Providers, they roughly have the same stuff. But AWS is driven by principles or tenets. A lot of the principles in the framework are applicable elsewhere. Azure is almost like a wizard as it takes you on a path, which is good 90% of the time. And Google sets the bar was quite high with hardcore SRE. The culture of each of the providers comes through. But they are all really good frameworks.

A cloud provider writes a framework in their own language. And it will have a bias towards their own products. If you ask a cloud provider to do a well architected review on your product, a solution architect from that cloud provider to will come in and do it. And all they know is their products. So if you get an AWS solution architect to review your product, they'll start recommending AWS products.

The lesson to learn is that it's not the framework that's important. It's the process that you put around it. And the process does not need to involve the cloud provider. We can run that ourselves. And we can apply the framework ourselves.

It is a big shift, to use well architected as a benchmark to self assess to learn, measure and improve. The great advantage of doing this yourself is that your feedback loop is established. So you're actually seeing what works, what doesn't work and where your gaps are across all the different pillars. And where you should be investing your time and your team's time across the org. 

When you use Clarity of Purpose, which is Phase 1 of the Value Flywheel, with the well architected framework, you can combat that bias. Your focus will be on solving the problem with the tools you've got at your disposal. And you're able to leverage tools faster and more efficiently.

It should not be something that your architect does to you. This is something that the team should be embracing themselves through an iterative and incremental process. We've written about this a lot in our SCORPS process, which is in the book as well. It doesn't need to be a big, scary thing that an architect from on high comes down and imposes on you. It can be a very useful learning and enablement tool.

Grady Booch Search for 'Grady' 'Well' 'Architected' to find that tweet and discussion

SCORPS process on TheServerlessEdge.com.

The Value Flywheel Effect book 

Twitter @ServerlessEdge 

Transcribed by https://otter.ai

Serverless CrAIc from The Serverless Edge
Check out our book The Value Flywheel Effect
Follow us on X @ServerlessEdge
Follow us on LinkedIn
Subscribe on YouTube 

Send us Fan Mail

What is the Second Cloud Transformation?

In this episode we are talking about the second cloud transformation. A lot of people are talking about what happens when you get to the cloud? You have already moved to the cloud. But you are not achieving the cloud successes like being event driven or serverless.

It can be a surprise for organisations that work in traditional ways. Their frame of reference is all on premise like big data centres or new mainframe stuff. So this new paradigm causes uncertainty around what can be done. What does a good cloud solution look like?  There's a learning curve that people need to climb and to become more comfortable.

When companies move to the cloud, it's usually part of a transformation. But the reason why we call it 'The Second Cloud Transformation' is because there's another step change. The best person I heard describe this is Shaun Braun from 3M. He did a keynote at AWS re:Invent in 2021. He talked about people moving to the cloud and measuring data. And then they transform by shutting things down and redoing other things.

Enterprises and people from mature companies are struggling. They are in the cloud but having problems with account creation, observability, security or how to deploy or provision things. There are infrastructure things that they haven't done. Because they haven't modernised. Sometimes the move to the cloud happens quickly. People have not been left behind. But they've been focusing on other things and they haven't gone back to first principles. To rethink how the software capabilities work.

You need to move away from big upfront design. And shift design, decision making and architectural decision making onto the teams. Because they're the ones who know the business problem and business aims best.  But you have got to encourage experimentation in a safe way. A good enabler for that is thinking about and setting up policies for the services you want to start leveraging out of the box.

In the second phase of The Value Flywheel Effect you map out your capability. So you do need to have an honest assessment of the capabilities you have and the teams in the organisation. Because maybe the engineers don't understand security. At least then you know that you've got to level people up. 'Shift left' is a great mechanism, because your teams have to do more and there's going to be gaps. So in some ways the second cloud transformation is filling those gaps. 

We talk about asking the question: 'what does good look like?' One of the best books to answer that question is 'Accelerate' by Nicole Forsgren.In the book there are four key metrics for building and scaling high performance technology organisations. Another go to book for this particular topic is 'Reaching Cloud Velocity', by Jonathan Allen. How to spin up new teams and the mitosis approach? It's a phenomenally good reference, similar to 'Accelerate'. And we reference both those books in our book 'The Value Flywheel Effect' which is available for preorder!

When you get into the cloud you need to enable real transformation! This is what we are calling the second cloud transformation.

TheServerlessEdge.com and @ServerlessEdge 

Shaun Braun from 3M at AWS re:Invent

Accelerate

Reaching Cloud Velocity

The Value Flywheel Effect Book with IT Revolution

Serverless CrAIc from The Serverless Edge
Check out our book The Value Flywheel Effect
Follow us on X @ServerlessEdge
Follow us on LinkedIn
Subscribe on YouTube 

Send us Fan Mail

We are talking about Event Driven Architecture examples today. There was an event in London a few weeks ago, called EDA Day. It was organised by GOTO with a lot of AWS contributors. It was neat because it was one day focused on event driven architectures. It showed the coming together of a 15 to 20 year old pattern of EDA, plus serverless. And all the bigger services on top of that, like Eventbridge and Step Functions.

Gregor Hohpe's Keynote 

Gregor Hohpe did the keynote talk: 'I made everything loosely coupled. Does my app fall apart?' Gregor is an AWS enterprise strategist. And he talked about the event landscape and the complexities behind event driven and architecture. He had a diagram called: 'A calls B'. It looked pretty simple until you get to the million things you need to think about when A calls B!

Serverless Espresso 

Julian Wood, Ben Smith, and a few others from Serverless Land, put together a demo called Serverless Espresso. You scan a barcode and through an event driven step function, event bridge sequence, you can order a coffee from your phone. So look up AWS labs, to see Serverless Espresso. It's well put together to show how you build an event driven architecture from the ground up.

Ben Ellerby - Minimal Viable Migrations 

He worked in Theodo and is an AWS Serverless Hero. He has a thing about Minimal Viable Migrations. A lot of people think event driven is a greenfield or brand new thing. But he had a great talk about existing architecture and going event driven. He talked about doing a small part of your architecture and going bit by bit. By using an incremental model.

David Boyne - Awesome EventBridge

David Boyne joined AWS and does ‘Awesome EventBridge’. He has open source projects. And he does a great talk on 'Thinking Event First'. How to approach events and get your schemes right. And really think about your domain model and lock it in from day one. Look up his resources on ‘Awesome EventBridge’.

Marcia Villalba - FooBar Serverless 

Marcia Villalba is a developer advocates at AWS. She's got great content on good practices and getting started. She has a really nice way of explaining these concepts.  Check out her FooBar Serverless YouTube channel. There is tons of developer friendly content from beginner to more advanced. 

Lego Talk - Sarah Hamilton and Sheen Brisals

The last one to talk about is Lego. They sponsored the event. And they had two talks. Sarah Hamilton is one of the software engineers and she gave a really good talk about the advanced techniques they're using in their event driven architecture. My friend, Sheen Brisals was speaking as well. They have a fantastic story, which is well worth listening to. It's about how they moved to an event driven serverless architecture. There's a socio-technical element to this. How you organise your teams and the attitude is what I would call a core engineering competency and mindset. As opposed to an architectural pattern. Lego tells their story brilliantly.

Product Leader panel

The event ended with a panel of product leaders from Eventbridge, Step Functions and MongoDB. It was a really relaxed panel. Emily Shea, who we know well, was there. She works in go to market for serverless. It was a relaxed chat. No one was pushing any tools. They were shooting the breeze on good practice and what's coming down the track. The evolution of event driven architecture and the tie in with serverless. There's something in it! I don't want to say Serverless is becoming EDA or EDA is becoming serverless. But serverless enables EDA for sure.

 https://gotoldn.com/

 https://theserverlessedge.com/ 

https://twitter.com/ServerlessEdge

Serverless CrAIc from The Serverless Edge
Check out our book The Value Flywheel Effect
Follow us on X @ServerlessEdge
Follow us on LinkedIn
Subscribe on YouTube 

Send us Fan Mail

In this episode the team talk about AWS Serverless Services with Paul Swail. Paul is an independent Serverless Consultant helping teams get started with serverless on AWS.

The Value Flywheel Effect Book Review

Paul also reviewed our book The Value Flywheel Effect. The team talk about his views of the book. And the fact that it is essential reading to get higher level buy in to serverless in your organisation.

Serverless Mindset versus Serverless First

We talk about the difference between the terms serverless mindset and serverless first. And how it is essential to be pragmatic in your approach and not insisting that serverless is the default for all your architectural decisions. It is better to use serverless as the architecture or service of choice. And then fall back to non serverless or less serverless services for certain parts of the architecture.

Wardley Mapping your Tech Stack

Wardley mapping and mapping your tech stack became really useful. Because you can see the individual components that can be moved to serverless. Instead of insisting the whole thing must move.

The origin of Serverless

Ben Kehoe came up with the term 'the serverless spectrum'. And it captures the notion of falling back. You can see if you have fallen back to things on one side of the spectrum.

Leading with Context

There's a fundamental thing with developers. Generally, they identify with the technologies they've use frequently. And they get really attached. And fanboy/girlism kicks in as well. There is a natural tendency to do that. Before your rational mind kicks in and says hold on. What is this? And what are the drawbacks of this? Or what sort of context would this not work in?

Context can be vague

I split it up into the application context of the actual system. What are the features or operational, latency and performance concerns you need the system to have. And the actual organisational context. The first application context is usually known. People know that they are building a specific app. It has these features and these requirements.

But the second organisational context is what developers do you have available to you? What skill sets do they have? Are they developers without ops skills so we need to hire infrastructure folks. Or do we have infrastructure folks, and they might not have much to so because we're using serverless? These things need to be considered when you're adopting technologies for a new project.

Serverless Maturity

We have reached maturity in the serverless ecosystem. Developer advocates are starting to codify and articulate their patterns. We have CDK patterns and things that are Google-able. Teams can reach out to see how to do it in an API gateway, lambda or dynamo. And see videos, tutorials or documentation of workshops that are maturing and established.

AWS effectively becomes a platform team, if you follow the serverless first approach. And they're going to keep investing in making it easier and adding more features and capabilities.

How will Serverless evolve?

 Tools that optimise for small teams to get stuff done are essential. Like operational stuff or standardised CICD pipelines and testing mechanisms around that. There's a lot of good work being done on the friction that serverless had over traditional app development. Because it's a big overhead for for developers to learn without AWS certifications.

ServerlessFirst.com and @PaulSwail 

TheServerlessEdge.com and @ServerlessEdge 

The Value Flywheel Effect Book with IT Revolution

Serverless CrAIc from The Serverless Edge
Check out our book The Value Flywheel Effect
Follow us on X @ServerlessEdge
Follow us on LinkedIn
Subscribe on YouTube 

Send us Fan Mail

What is Long Term Value?

We've spent the last couple of episodes talking about the value flywheel effect and the value flywheel itself. There are four phases: Clarity of Purpose, Challenge, Next Best Action and Long Term Value. We've been talking through each of these phases in detail. And today, we're going to talk about phase four, which is Long Term Value.

So the simple question is, what is long term value? Long term value means continuing to deliver value for the medium to long term, because you've invested in a sustainable way of working. You have invested in well architected and paid down your technical debt to get long term value. And you're not going to hit a wall in the short term, because you've not built in quality or architected appropriately or built a sustainable solution.

 If you don't invest in long term value and the well architected framework, you'll hit the wall. You might go fast for a quarter or two, or a sprint or two. But sooner or later, it's going to catch up to you. You may be going fast and delivering value, but you're not doing it on a sustainable way. You're not paying down those debts. And you're not building things that are resilient, scalable, performant and cost effective.

What happens if we don't do it? You see teams in a false economy where they get their first or second build done quickly. But then things start going wrong. And you build up technical debt very quickly. Things start to go wrong. You end up firefighting. And it really slows down. It's the perfect velocity thing. You start off quite fast. But it starts to slow down rapidly as things start to creek.

Is there anything else you can think of that happens if you don't think about this? Your business, execs and key stakeholders start to wonder why am I not getting value out of meetings anymore? Where's the next differentiating capability? And where's my next feature? Or my next capability that can differentiate us in the marketplace? I've got the same teams and they were good last month. Why are they not delivering this month. Or they were good last year? Why are they not delivering this year. You'll have a lot of noise from the execs wondering why is it not working anymore?

The problem becomes the dreaded rewrite a couple of years in. And realising that this big ball of mud just needs somebody to take a sledgehammer to it. You turn around and talk to your stakeholders because you are going to want to do next generation version of this. It's going to be brilliant. With all of the same functionality. But it'll be better. And the response is: 'why would I pay you to build it again? You built this five years ago, why are we building it again?'. That's a very difficult conversation. And the real answer is we didn't bother doing architecture, so we have to build it again. That's not a good place to be.

A team that's leveraging and operating the flywheel will see their software appreciating in value over time. As opposed to depreciate. If you're not thinking about long term value your system is always depreciating. You are going to have to invest in patching, upgrading and dealing with issues. The terms we use are 'code is a liability' and 'the system is the asset'. You need your teams focused on the system delivering the value. And removing as many code liabilities as they can.

And this phase of the value flywheel is about minimising liabilities and offloading more responsibility to the cloud provider. Or how can we leverage managed services and SAS providers. To remove custom build and evolve into a commodity. So all of those things are at play in this phase of the value flywheel.

Serverless Craic from The Serverless Edge

theserverlessedge.com
@ServerlessEdge

Serverless CrAIc from The Serverless Edge
Check out our book The Value Flywheel Effect
Follow us on X @ServerlessEdge
Follow us on LinkedIn
Subscribe on YouTube 

Send us Fan Mail

We've been going through the Value Flywheel Effect in the last few episodes. And talking about the different phases. The Value Flywheel is the core mechanism we talk about in our book. There are four phases. The first is Clarity of Purpose, then we have Challenge, Next Best Action and Long Term Value.

Today we're talking about Next Best Action. When you boil it right down, you've got understanding, your Northstar, Clarity of Purpose and you understand your landscape. But how do you start? What is the next best thing you can do? What is the simplest thing you can start today to improve your lot. And help the flywheel turn a little smoother and remove some inertia barriers. In very simple terms: what is the next best thing you can do today, tomorrow or this week.

Conceptually, you need your next best action to be focused on business value. And not focused on building a huge platform. Or spending the next six months organising runtime or infrastructure strategy. You need to get going and start adding value as quickly as possible.

There are two things to consider: a frictionless developer experience, so your engineers can create value very quickly. And a serverless first mindset, how you decide what choices you make. A serverless first mindset is selecting a serverless option first, when you review services and techniques to use in the cloud. 

It's trusting your cloud provider platform to have the capability to do something. And just use it.  Next best action implies responsiveness and speed. It's not about how quickly you type code. It's a time to value. How quickly you can get value in the hands of customers to see if it works.

Code is a liability. By mapping out your tech stack and adopting a serverless first approach you can tackle those code liabilities. So you're not going to be hit by old systems that have been left to decay over time. And when you need to make rapid changes you can't respond because you haven't paid down your code liability. Mapping your stack and embracing serverless helps to minimise code liabilities and get you on the right path. What happens if we don't do this?

We call it the framework mentality. Someone decides they're going to write a framework and they can do it over the weekend. And that becomes the foundation for the next big project. You get version one into production and everyone's really happy. This developer is a rockstar, because they have rocked out a framework. But a year later, that framework is the very thing that's slowing down the project. And no one can understand why we did this thing in the first place. So if your next best action is let's write a framework, it's not the right idea. Sometimes quick fixes in your first release in code will absolutely slow you down in future releases.

You need to adopt a serverless first mindset and approach so that your cloud provider is basically your platform team. Who are constantly upgrading, making performance improvements and making things more secure. And you're getting all that for dollars. You're focusing your time on differentiated stuff. On delivering value, outcomes and impact. If your next actions are always around hardening, patching and securing, you need to think about what you can do to minimise that in the future? If your next best action is to fix the infrastructure and you're not an infrastructure company, then you've done something wrong, it needs to be something about your own business value proposition.

Serverless Craic from The Serverless Edge

theserverlessedge.com
@ServerlessEdge

Serverless CrAIc from The Serverless Edge
Check out our book The Value Flywheel Effect
Follow us on X @ServerlessEdge
Follow us on LinkedIn
Subscribe on YouTube 

Send us Fan Mail

It's important that engineers challenge tech strategy. Challenge is about the environment. When you decide on a strategy, do you have the right environment to challenge it?

 In the last episode, we talked about Phase 1 of The Value Flywheel Effect: Clarity of Purpose and setting direction.  The Value Flywheel Effect is our book which is available for preorder.

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.

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.

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. 

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. 

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

Serverless CrAIc from The Serverless Edge
Check out our book The Value Flywheel Effect
Follow us on X @ServerlessEdge
Follow us on LinkedIn
Subscribe on YouTube