Serverless Craic from The Serverless Edge

Send us Fan Mail

We are looking at how to apply flywheel strategy from our book 'The Value Flywheel Effect, which will be published on 29 November.

In the last episode we spoke about the whole model and the four phases. They are Clarity of Purpose, Challenge and Landscape, Next Best Action and Long Term Value. This time we figured we'd deep dive into Clarity of Purpose. It's the first phase of the flywheel.

It's about knowing where you are going. And where you want to go next and what your purpose is. Are the things you're working on meaningful and valuable?  There's an onus on senior leadership and/or the CEO, to make sure this is understood. Purpose is what is your business going after. And clarity is are you specific about that?  Is it measurable? 

It's critical if you want high performance, autonomous teams. But if they're not aligned behind the clarity of purpose, they will go in different directions. And they won't have the impact you think they should have for your organisation.  Without clarity of purpose, you are just making stuff up. Because it doesn't really matter what you do! And secondly, execution without clarity of purpose is just busy work. You are just going but you don't know when you're done.

In some companies they'll build something because someone else built something. And sunken cost fallacy kicks in.. So they tend to invest in something that's already failed. But knowing when to stop and when to try the next thing is a core rationale for solid clarity on your purpose. 

As an IT person, you can come up with a million good ideas. But you've got to be prepared to say no. This is not going to have any impact. Or this is not going to affect the bottom line. This is not going to manifest as a benefit for what we're trying to do in relation to our Northstar.

But what happens if you ignore it? It's not default or mandatory. You don't have have to get into it. I remember being asked to stop talking about why we're doing stuff and just do it. That wasn't healthy. Organisations don't become healthy. They don't become places where people want to have an impact. Instead they'll turn up and clock in the hours. But they won't move the org forward. Teams begin to solve the same problems. Because there's a lack of collaboration and people aren't communicating effectively. It becomes difficult to prioritise and organise across teams. Which is another side effect. You start to guess at things. And build stuff for the sake of building. And not focus on the overall outcome.

We have talked about innovation theatre. Where the execs, all of a sudden, start wearing sandals, sports jackets and no ties! That's not innovation. It's innovation theatre when you start putting stickies on the wall instead of using documents. They are the traps you see people fall into when it come to innovation.

Another one is the build trap. When your teams building like billy oh. But nobody knows why they're building or what they're building. And then you have what we call gold plating. You get into a big ball of mud, where engineers went crazy building a complicated system. And then all of a sudden, you need a simplification programme because it's too complicated. Or you need a reuse programme because you've built the same thing four or five times.

I always think that startups are good at clarity purpose. Well, the ones that survive are. The ones that don't survive, probably had a bad clarity purpose. That's the final answer to what happens if you don't have clarity of purpose. Over time you go out of existence!

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

Our book 'The Value Flywheel Effect' is being published by IT Revolution Press on 29 November. We thought it might be worth having a chat about what the the value flywheel is. Things really start to work well, when you join the business and technology strategy. We came up with this model to describe how you do that in a company.

There are four phases. Phase one is 'clarity of purpose'. Phase two is 'challenge'. Phase three is 'next best action'. And phase four is 'long term value'. So we will deep dive into each of these in our next set of episodes. But for now, we will quickly go through them.

Clarity of Purpose 

So the first phase is 'clarity of purpose'.  Business and IT need to look at 'what is our mission'?  In your organisation, how do you prioritise, how do you make a decision on what you should do over something else? How do we establish that clarity of purpose? It's about getting alignment as well. And trying to clarify what your clarity of purpose is. Or what your North star is. And what your key input metrics are. 

They are valuable conversations to have. They spark off good thoughts and conversations with people on teams. And it doesn't need to be perfect. It just needs to start getting alignment and people pointing in the right direction together. 

Challenge 

The second phase, challenge, sits well with that. These first two are very much linked to the business strategy. And challenge is not to argue with the clarity of purpose. Once you're clear on the clarity of purpose, it's then what do we do to achieve that?  Do we have an environment that invites challenge? You need to make sure that socio technical systems are set up. And challenge is invited and not punished. Are people getting a chance to challenge? Are we bringing in the experts? Who should we be talking to? Where's their voices? That's where Wardley Mapping is a powerful technique, because you're challenging the idea and not the person. You're not challenging the individual telling the story, you're challenging the approach. It's healthy and it promotes psychological safety.

Next Best Action

The third phase is next best action. And this is having a bias for action. What can you do quickly, to prove your direction. This is where serverless comes in.  Sometimes you have good priorities, you've challenged and you know what you want to do. But then it can get locked up in technical bureaucracy. It's  about removing those impediments to fast flow. Can we quickly get an idea into the hands of real users to get valid feedback. If you've got an urgent business problem, you don't want to be off doing low level stuff. You're never going to get to it. So how can you make progress? Well not quickly!

Long Term Value

The fourth phase is long term value. It's about bringing in architectural and sustainability standards. How can you go fast without burdening yourself with lots of technical debt? And how can you go fast and at a sustainable pace? Or how can you deliver a well architected solution? With capabilities that enable the flywheel to turn faster. And it doesn't clog everything up and slow you down. Once you get to that, you're back into clarity of purpose again. 

You keep revisiting and you keep improving. As you turn the flywheel, you create more space for innovation and emerging value. You will start to spot where you should invest next. It becomes becomes a good muscle that you can exercise.

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

Clarity of Purpose with the North Star Framework 

For many teams, trying to figure out why you're building what you're building is a good question to ask. I have found out in my career that most teams don't really understand why they're building what they are building.

It's interesting to look at the models for creating great software, like The British Design Council and the Double Diamond. On the left is discovery, and on the right is delivery. So discovery and delivery. We always talk about delivery. We obsess over it. We very rarely do product well, or discovery well. And a good product is really about discovery.

One person who has nailed it is Melissa Perry. In her book, 'Escaping the Build Trap', she talks about people blindly building. And building backlogs It's comfortable for teams because they are in their groove. And they knock out another widget, ticket or feature without thinking about the impact and who it's actually for. Get the JIRA tickets closed, get the storage complete, get the sprint done, and move on!

The move from project to product was supposed to fix this. But I don't think it has. Because product managers have people building things like 'billyo'. But often they are building the wrong thing. A great saying is: "Build the thing right, build the right thing, build it quickly". We're good at building quickly and good at building the thing right. But we're not very good at building the right thing. And that's what breaks companies. Because building the wrong things can be expensive.

If you don't understand the impact you're trying to have, how can you do the right thing? Or build the right thing? How can you know what success looks like? What conversations are you having on potential approaches and ways to achieve that success? It all ties back to data, metrics and understanding the problem you're trying to solve. If you're not doing that, it dilutes the good intent of good teams and engineers. How can they build the right thing if they don't understand what success is? Or the problem they're trying to solve? And what are our options? It's a challenging thing to do. The frameworks on mindset and helping you think in the right way, lead you to what you need to solve.

One thing we find helpful, which is not well understood, is the North Star Framework from Amplitude. We discovered it a few years ago. And it collectively blew our minds. We have used it ever since. It's a simple framework that people can get in an hour long session. Your teams can share and collaborate. And online collaboration tools have helped make this a lot easier.  Your users and their needs sets the context leading into the Northstar. It gets everybody back on the same page if they have forgotten about a user. Or if they have forgotten that they do something for a set of people and their needs.

One big thing we've noticed with this and Wardley Mapping is that it invites challenges. You are not challenging the person or the team, you're starting to have a conversation about North Star metrics, KPIs and the work aligned to that. You're not challenging a person. It provides a safe space for the right challenge to happen.

I love the traceability of the Northstar. You can go from business metrics back to your work. Or you can go from your work to the business metrics. I think that's the real power behind it.

Melissa Perry: 'Escaping the Build Trap'

Marty Cagan: 'INSPIRED: How to Create Tech Products Customers Love'

Amplitude: The North Star Framework

Jon Cutler

Simon Sinek: 'Start with Why' & 'Golden Circle'.

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

Today, we decided we'd have a chat about the 8 principles or tenets for a high performance serverless first team.

1. 'Chase a business outcome or a KPI'

A team should know what business KPI they're working towards. You should be able to tap a person on the shoulder and have them tell you what they're working on. And what business impact the work they're doing is going to have. If the team says 'I don't know', then you run a Northstar workshop. 

2. 'Be secure by design'

Don't do security afterwards. Bake it in from the start. It's everyone's job. It's such a difficult thing to retrofit. Use threat models and get it done early. Try to solve for what you can and what you know. Bake it into all your engineering practices. And bake it into your pipelines. 

3. 'Keep a high throughput of work'

That is borrowed from the DORA metrics in the 'Accelerate' book by Nicole Forsgren. This principle looks at high throughput, which is deployment frequency and lead time. For serverless teams, it is key to make changes fast and frequent. And always be learning and driving observability. As Charity Majors says, "speed is stability". The more frequently you do something, the more you deploy to production. You're actually improving your stability. 

4. 'Reliably run, high stability system'

That's the other two DORA metrics of throughput and stability. A lot of discussions with test teams, QA and software engineers drive the need for investment in world class quality and testing capabilities/practices. If you're not stable, where's the gap? What scenarios and behaviours have you not covered? 

5. 'Rent or reuse with build as a final option'

How do you do that? Serverless! With Serverless and SaaS and our background you're used to going straight to the workspace. And with the FORESEE diagram, we find out what we are doing and it is coding. It's a mindset thing. It's back to knowing your business purpose. And then knowing your business KPIs. If you can achieve business outcomes without doing code you are at your most optimal.

6. 'Continuously optimise the total cost'

This is the best question to ask any team. Good teams will tell you how much their cloud costs are. But loads of teams have no idea. This is a great measure of a good team. They have a cost in mind. A good team will tell you the run cost. And a great team will tell you the total cost. 

7. 'Build event driven via strong API's'

This sounds very easy. But from talking to Sam Dengler, nobody is doing this properly. We've been talking about this for 20 years. Proper integration is still a mystery to most people. It is about making sure you've got the right things in the right places. But also at the right size. And having things that are composable. It's about breaking things up into their smallest constituent parts. And change things as frequently as possible. 

8. 'Build solutions that fit in their heads'.

This principle is borrowed from Dan North. In other words, don't build crazy systems that are too complicated. This has a nice nod towards Team Topologies and setting proper boundaries. We've seen teams become victims to crazy architectures. Where there's too much to fit in your head and the cognitive load breaks people. 

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 found out that 'how to start cloud computing' is a burning issue from our meetup BelfAWSt. And it is a community Meetup in Belfast, to talk about all things AWS! 

• How do you set up your account? 
• And how do you learn? 
• Or build your career? 
• Who do you reach out to? 
• And when you are more familiar with the basics, what can you leverage to build higher order systems and solutions? 

Questions on certifications came up a lot. 

• Are they valuable? 
• What workshops can guide me through the Getting Started phase? 
• How do you become part of the community to help me and my organisation? 

It is daunting when you look up aws.com and there is an ocean of stuff on the website. If you sign up, pick something relatively straightforward and follow a quick lab. I also have used A Cloud Guru.  More recently, 'Skill Builder' has become freely available. Udemy courses are really good.  And other Cloud Providers have similar educational materials. I really like the foundational white papers. There's four or five core white papers that are worth reading. If you attempt a certification, and you read those white papers, it's still beneficial. The PDFs are free and you can download them. 

But real learning happens when you go and do something. Get into a workshop. Go and follow an AWS workshop or whatever cloud provider workshop applies to you. The developer advocates and AWS have been great at codifying their getting started workshops. Workshops that were only available at re:Invent/conferences are now freely available on AWS.workshops. 

The last thing is the whole idea of patterns. Matt Coulter has CDK Patterns and CDK Day.  SAM has a bunch of patterns. And there's the Serverlessland.com site. When you codify an architectural pattern, like a CDK pattern, it's a great way to accelerate and get something up and running. 
Patterns: 

Community:
https://aws.amazon.com/developer/comm...
https://aws.amazon.com/developer/comm...
Other:
https://bahr.dev/2020/12/02/surprise-...
https://www.youtube.com/watch?v=ryXnj...

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 have picked out our top books that have influenced us and our 'The Flywheel Effect' book.

1. 'Continuous Delivery' came out in 2011. And it has been massively influential in how high performing teams deliver their software today.  It is still as fresh as it was when it was written.
2. 'Domain Driven Design' describes good domain models and the importance of collaboration, communication and shared understanding, You can be in different types of stacks or scenarios, but the knowledge is abstract so it's applicable.
3. The Simon Wardley Book I find myself always going back to it. It's chunky and quite academic. But it's as deep as well. I don't take every word of it literally. But it's definitely a good read and will challenge your thinking still to this day.
4. 'Accelerate' This is a game changer.   It distills down and captures (with scientific backing) all of the things that we were trying to articulate or were trying to push or evolve in our ecosystem.The capabilities to drive improvement, the scientific backing and little snippets of good advice and guidance.
5. 'Extreme Ownership' There's some cracking guidance on how to own something and lead. One that sticks out is centralised command and leading up and down the line.   It's a well thought out and structured book on how to think, modern leadership and how to motivate people to be successful.  I enjoy reading about how to think through systems, particularly in a leadership position.
6. 'Team Topologies' It's such a powerful question to ask 'what type of team are you?'  The answer is that you're a platform team, an enablement team, a value stream team or you're not anything. And all the techniques are in it with different tools and team API's etc. You can pick it up and implement tomorrow.
7. 'Reaching Cloud Velocity' It covers how to succeed in the cloud.  In other words what are the principles and tenets that you should apply. What are the cultural, organisational and architectural approaches you should adopt.
8. 'Designing Data Intensive Applications'  is almost a bible for anything data related such as streaming, different types of databases and why you make decisions on  certain types of databases. You get into the design and the nuance of it. And understanding the landscape. 
9. 'Creativity Inc' The book is about Pixar, who went up against Disney by direct selling films. The full title of the book is 'Overcoming the Unseen Forces That Stand in the Way of True Inspiration' . They talk about the inspiration of creating and then actually making it.  And how they structured the company and all the challenges they had.
10. 'Working Backwards' We see Amazon from the outside eg. amazon.com, Amazon Prime, deliveries and Alexa. But how do they actually do it? How can they be so successful and set themselves up for success? What way are their leadership structured? 
11.  'Ask Your Developer' looks at the developer centric approach at Twilio.  There's a lot of good content on how to inspire great individuals and teams to be creative and on developer experience, their golden path and off roading.
12.  'The Software Architect Elevator' I love his concept of an architect riding the elevator to talk to the executive in the penthouse, going down to the basement to write code and then all the floors in between. He talks about the how an architect can behave and operate to be successful in a company. Gregor is the 'architect's architect'.

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

This is the sixth and final piece of our Modern Cloud series.

Modern Cloud has to represent value for the different personas across the business. The customer is an obvious one. But it's good to talk about internal stakeholders.  The CEO and Product personas are very interesting. I think we were happy talking about the Developer and CTO/Architect perspectives. They are our personas!

Wardley Mapping guides us towards our users and their needs. Having those conversations and distilling that down helps us with our thinking. And to articulate the benefits.  What are the good approaches for 'time to value'? And to realise the potential of modern cloud ecosystems. It's been useful to talk and clarify the mental model of what the cloud is and what it can be.  And what benefits teams and organisations following this path can get out of it. This has been democratised globally. If you pursue this properly, you can compete with anybody in the world.

When we started talking about the cloud we thought about building ephemeral event driven architecture. But our CEO was thinking, can you be faster and cheaper? It became a value proposition. Remembering some of those things is important! You need to keep that commercial lens as you design applications and processes. And as you build up teams. One thing that is interesting (we've been talking about it for a long time) is the term 'serverless'.  But the serverless term itself is problematic. One of the reasons why we use the term modern cloud is because Serverless has turned into a type of religious war. When people hear the word Serverless, they think of Lambda. But it's much more than that.

Lambda was the first 'go to' for ephemeral event driven or function based workloads. And it's been fantastic. But the ecosystem has evolved with managed services becoming available. And direct integration between managed services is available. So you don't need as much glue! You don't need to worry about operational burden or code liability. You can offload that to the cloud provider and to the services. Serverless, as a term, is probably coming to a close. It was a useful vehicle to describe what emerged. But it has gone through an evolutionary journey. Now, I think the term modern cloud supplants it.

Serverless exists within the IT org.  With the modern cloud, you are working with Product and Business.  And you need to start talking in the language of capabilities. You need to develop a ubiquitous language about building blocks to describe getting capability into production. We know what the modern cloud has under the hood. But we have to evolve to talk in business terms.  The well architected approach helps to frame it.  Is it secure and operationally excellent? Is it performing and reliable? Is it cost optimised and sustainable? Those capability conversations are supplanting the discussions on whether you are using serverless or not.

Another thing we have been thinking about is modern cloud versus legacy cloud. Legacy cloud is the traditional call stack in the cloud. There's a whole bunch of stuff that's going to be running hot all the time. It's really just stuff that should be in your data centre,  but it's now in the cloud. It's a very interesting question. It's quite a challenging question. But a lot of people look back at their traditional stack and suddenly realise it's actually a legacy monolith in the cloud.

A lot of people think transformation ends with moving to the cloud. But transformation starts with moving! Legacy cloud is where you need to start. Then you need to measure and actually start modernising. A lot of people miss that point.

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 are continuing our series on the modern cloud. During our six part series, we've covered an ‘’Introduction to Modern Cloud’, and talked about the CEO, Product and Developer perspectives.

Today, we're talking about the technical leader or CTO perspective, which is linked to long term value. As CTO, you need to be on top of this because you own the rationale behind the decision to go for modern cloud. It may require a big initial investment despite it being hard to see the pay off at the start. One big pressure 'straight out of the gates' for a CTO is platform choice. You have to bet on a platform. And you have to guess how the platform will evolve in the next 10 years.

You need to base the decision on the business in order to make the right bet on the platform. Another decision to make is picking a platform or staying platform agnostic. You're probably better off minimising your liabilities and your platform by having the thinnest but valuable platform you can get away with to meet those needs.

As CTO, you have to create an environment to encourage evolution. . As you scale up, different factors apply and you may decide that you need to change tack. You need to arm yourself with as many building blocks as possible. You may have separate platforms, or separate ways of building things to support your business model.

Once you're on a modern cloud platform, you need a problem preventing culture. You're thinking about how to build so we don't have any problems as opposed to problem creation culture, where you're celebrating people for fixing stuff that should never have been built in the first place. The well architected framework is a great way to put guardrails in place.  You need to empower and enable teams to make decisions. You need to arm them with good principles so that they can assess their choices. As they're starting to pick technologies, they're starting to leverage the building blocks. You need a feedback loop on what works and what doesn't work.

It's a shared responsibility thing. You need to trust your cloud providers in relation to things like HA and availability, and factor that into your decision as well. A good example of that is using industry standards. Look for a standard and use it. Sometimes there's a lack of trust when people don't do that. Companies that have to customise are very small in number and they are pioneers. 99% of companies can use the standard and be very successful. You need to be clear about using standards and not deviating except for a good reason. And usually there's not a good reason. Otherwise it can come back to bite you with issues around data, security etc.

The hardest thing for CTO's is dealing with regulations and compliance, like SOC compliance, for example. At a certain point in time, managed services may not be 100% SOC compliant. But typically, I find over a short period of time, they become compliant. Unfortunately, people go down the 'Build Your Own' route and the teams and orgs that waited, pass them by because they don't have to invest in Ops to maintain their own custom solution with its limitations. You need strategies and solutions for these issues.

In the role of CTO of the modern cloud, sustainability has to be something to start thinking about. Whatever application or stack you build in the cloud, there will eventually be a carbon burn measure for how much carbon you're using. It's a forcing function for all the other practices we have just talked about. If you're able to deliver a well architected, serverless first solution across your entire org, as CTO, you are building the right foundation to deliver a sustainable solution.

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're continuing our conversation on Modern Cloud. There are a couple of previous episodes: an overview of the CEO's perspective and an overview of Product's perspective.

I figured we would look at the Developer perspective today. Sometimes when you meet with developers, you don't know what's working or not. By mapping out the tech stack, it's easy to spot things that are in the wrong place. In the modern cloud, capabilities are evolving and merging rapidly. So mapping out your tech stack and understanding what's available in a modern cloud environment is very valuable.

You can have a conversation with your teams on the components of the tech stack and see if there are more advanced modern cloud capabilities to take advantage of. Is there a managed service capability that can offload some of the burden in our tech stack? Can you leverage DynamoDB, step functions or some other evolved modern cloud capability to meet those needs?

It's a cracking exercise to involve business or product people who don't understand the full value stream. Typically in organisations, investment is done at the UI or UX level. Perhaps they want to make a change but don't really understand the level of complexity that's involved. A map can be a vehicle for a conversation to get investment to replace a legacy part of the platform. With mapping, you can't change everything there and then, but you can plot a path. It's a good way to set goals, look for opportunities and work towards those goals.

As well as having that conversation as a team, you're implicitly putting the concept of evolutionary architecture into everyone's head. In other words, it's okay to keep changing. There isn't a sunk cost fallacy where we hang on to something for years, because we built it. You want your engineers to deliver features into production quickly. There's lots of ways to do that. One way is by using decent developer patterns like CDK patterns.

Composable building blocks are critical for rapid delivery. You need proved patterns to compose your solution from. With the emergence of infrastructure as code, CDK, SAM and other infrastructure code capabilities, you can bring expertise and patterns to your teams to rapidly stand up solutions. For example a single page app pattern is a building block that can be deployed. Or an API gateway that connects to a new SQL database with step functions in the middle to do workflow.

With modern cloud, you should be able to find a well proven pattern that you can leverage or customize to your needs. If you're going to build with those patterns, then you need to build quality in! You actually need to start by having a high standard of technical excellence to make sure those patterns have quality attributes, in the first place.

Building up squads is a huge aspect. You start off with the basics and get your observability set up which takes time, and you will go slow. But it's amazing, because after one or two months, you begin to see the philosophy creep in and before you know it you're ten times what you were at the start and you've got all the confidence in the world. The engineers are empowered and they're very creative.

If you have mapped your tech stack, have situational awareness and if you are leveraging modern cloud properly, you can apply the features that are being announced today. That is the differentiator for your team and for your business. You have happy developers! Nicole Forsgren describes it in her 'Accelerate' book: if you invest in your team to make them go fast and safely, then employee engagement shoots up. It's quite hard to explain because some people see it as money spent. But the business benefits at the other end.

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

Welcome to our conversation on Digital Product Leaders and the Modern Cloud.

First of all, the good news is that our book has been announced: The Flywheel Effect. Let's just get that in there first! 

But let's continue our discussion on the modern cloud. We've talked about what the modern cloud is from the perspective of the CEO. What about from the perspective of a product leader? What are the things that a product leader would expect from modern cloud? The first one is operational overhead. As a team, if you're building in modern cloud, there's less lower level stuff to worry about. So there's maybe more capacity for other things.
 
When teams are using a serverless method and taking advantage of the modern cloud, operational overhead is the main advantage.  I'm not spending time setting up servers, building a full specification and veering away from traditional MVP.  It gives me more time to think about product, measurement, hitting targets and understanding the business problems. 

Responsiveness is critical. Teams are set up to leverage modern cloud. They're more aware of and responsive to the needs of product leads. If you're not focused on patching your servers and scaling network architecture, you are much more focused on the actual to address, the users, and their needs. And how can I leverage rapidly? You're part of the conversation.  

For a product leader, your engineering teams should be more engaged with the problems that you're facing, the innovation you're trying to achieve or the issues you're trying to solve for customers. For product in the modern cloud, you should be expecting your engineering teams to be responsive to your needs. And there should be a good feedback loop. Because the time from idea to validation in production should be very short. It can be down to minutes, if you've architected and engineered it correctly.

It's the right type of operational overhead. I advise teams that getting the business view of your workload and getting the IT view of your workload is Day Zero work.  You're going to need observability for production to be able to make rapid decisions.  There is still operational stuff that you do. It's now aimed at product evolution and making good decisions for what you're building.

If you're leveraging modern cloud correctly and following well architected and serverless principles, you should be comfortable that you will scale globally to meet the need. It shouldn't be something you need to think about six months in advance.  Having that mindset allows you to experiment rapidly.  It allows you to be iterative in your product approach,

You've got the apparatus to see how your workload has been received, how it's being used or not used.  When you talk about continuous improvement or evolution, your organisation has got to be set up for that.  You are driving a culture of innovation. You will  be constantly evolving what you're doing to move towards the business purpose set out for your team or organisation. 

You'll find that you're moving into new areas and having conversations that you wouldn't have had previously, because you were so invested  in setups.   If you're leveraging modern cloud you'll have composable building blocks that your engineering teams can experiment with to meet needs in almost real time. From ideation, discovery and framing sessions, engineering teams will be able to stand up a prototype live and give you working code solutions that you can validate. The feedback loop is the flywheel turning rapidly. You're able to experiment at a pace that is previously unheard of. 

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