After taking a four year break on his Oklahoma ranch, Blake Shelton is back on the road and riding the high of his new album, For Recreational Use Only . After 29 number one hits, and a detour into Hollywood, Blake’s scorching hot single “Texas” proves he’s still got it. Country Thunder CEO Troy Vollhoffer recalls meeting Blake Shelton during a crazy storm that really put the “thunder” in Country Thunder. After 23 seasons on The Voice , Blake opens up about spreading himself thin and making the choice to be “a TV guy or a touring guy.” The two reminisce about Toby Keith and why being a road dog is the best way to learn how to entertain a crowd. Blake reveals how his worst on-stage “ass-kicking” taught him how to be himself in front of a crowd. After taking so much time away from the spotlight, Blake shares that it was Post Malone who reminded him that he’s still a country singer at heart.…
Player FM - Internet Radio Done Right
Checked 4d ago
اضافه شده در three سال پیش
محتوای ارائه شده توسط Serverless Craic from the Serverless Edge. تمام محتوای پادکست شامل قسمت‌ها، گرافیک‌ها و توضیحات پادکست مستقیماً توسط Serverless Craic from the Serverless Edge یا شریک پلتفرم پادکست آن‌ها آپلود و ارائه می‌شوند. اگر فکر می‌کنید شخصی بدون اجازه شما از اثر دارای حق نسخه‌برداری شما استفاده می‌کند، می‌توانید روندی که در اینجا شرح داده شده است را دنبال کنید.https://fa.player.fm/legal
Player FM - برنامه پادکست
با برنامه Player FM !
با برنامه Player FM !
))
Daily Deals
پادکست هایی که ارزش شنیدن دارند
حمایت شده
Serverless Craic Ep49 Team Engineering with SCORP
Manage episode 384111258 series 3304957
محتوای ارائه شده توسط Serverless Craic from the Serverless Edge. تمام محتوای پادکست شامل قسمت‌ها، گرافیک‌ها و توضیحات پادکست مستقیماً توسط Serverless Craic from the Serverless Edge یا شریک پلتفرم پادکست آن‌ها آپلود و ارائه می‌شوند. اگر فکر می‌کنید شخصی بدون اجازه شما از اثر دارای حق نسخه‌برداری شما استفاده می‌کند، می‌توانید روندی که در اینجا شرح داده شده است را دنبال کنید.https://fa.player.fm/legal
Team Engineering with SCORP - there are practices we do like SCORP, which is our agile way of doing well-architected in every sprint with teams. Our practices are connected to engineering excellence, looking at what you're doing and constantly improving. And HP (high performing engineering), as a way of capturing key metrics to define good engineering or architecture, and then talk about it as a team.
Even though the practices are out there, it's really just a mindset.
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
66 قسمت
اشتراک گذاریManage episode 384111258 series 3304957
محتوای ارائه شده توسط Serverless Craic from the Serverless Edge. تمام محتوای پادکست شامل قسمت‌ها، گرافیک‌ها و توضیحات پادکست مستقیماً توسط Serverless Craic from the Serverless Edge یا شریک پلتفرم پادکست آن‌ها آپلود و ارائه می‌شوند. اگر فکر می‌کنید شخصی بدون اجازه شما از اثر دارای حق نسخه‌برداری شما استفاده می‌کند، می‌توانید روندی که در اینجا شرح داده شده است را دنبال کنید.https://fa.player.fm/legal
Team Engineering with SCORP - there are practices we do like SCORP, which is our agile way of doing well-architected in every sprint with teams. Our practices are connected to engineering excellence, looking at what you're doing and constantly improving. And HP (high performing engineering), as a way of capturing key metrics to define good engineering or architecture, and then talk about it as a team.
Even though the practices are out there, it's really just a mindset.
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
66 قسمت
Усі епізоди
×
Send us a text 🎙️ Serverless Craic: Exploring Socio-Technical Systems for Change Welcome back to Serverless Craic! In this episode, the team dives into Chapter 10: Challenge – A Socio-Technical System for Change from the book, The Value Flywheel Effect. This thought-provoking conversation unpacks how organisations can effectively bridge the gap between people and technology to foster meaningful, sustainable change. 🔍 Topics Covered: What makes socio-technical change so difficult The importance of flow, team design, and time to value Lessons from Team Topologies and Drive by Daniel Pink Frameworks like Cynefin and Wardley Mapping Democratising AI and enabling change through feedback loops Why architecture alone won't save you 🤔 Whether you're a tech leader, architect, or engineer, this episode offers valuable insights on how to navigate complexity, decentralise expertise, and embed purpose and autonomy at every level of your organisation. 📚 Referenced: Team Topologies Drive by Daniel Pink: Cynefin Framework (Dave Snowden) Wardley Mapping Fred Emery’s Design Principles 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 a text 🎙️ Environment for Success & Psychological Safety Welcome back to another episode of Serverless Craic! After a short hiatus (thanks, ServerlessDays Belfast!), Dave Anderson and Mark McCann return to dive deep into one of the most critical – and timely – topics in modern software delivery: creating the right Environment for Success. In this episode, we unpack Chapter 9 from The Value Flywheel Effect and explore the fundamentals that enable high-performing teams, including: 🔹 Psychological safety and why it’s the foundation of great engineering cultures 🔹 The danger of hero anti-patterns and the myth of the “rock star” developer 🔹 Challenging assumptions safely – using artefacts, not egos 🔹 Simon Wardley’s doctrine and Dr. Ron Westrum’s organisational culture model 🔹 How aligned autonomy and clarity of purpose help teams focus on what matters 🔹 Why generative, learning organisations adapt best to AI-driven change Whether you’re a tech leader, architect, or engineer, this conversation is a masterclass in building sustainable, modern digital organisations. 🧭 Referenced resources: The Value Flywheel Effect by us! The Fearless Organisation by Amy Edmondson Accelerate by Nicole Forsgren Simon Wardley’s Doctrine Dr. Ron Westrum’s organisational models 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 a text In this episode of Serverless Craic, Map the Market and A Cloud Guru Case Study, we dive into Chapters 7 and 8 of the book The Value Flywheel Effect. The discussion focuses on "Mapping the Market" and a fascinating case study on clarity of purpose, featuring the story of A Cloud Guru. Discover how mapping the value chain helps companies identify their place in the market, understand competitors, and predict strategic moves. Learn about the transformative impact of a laser-focused North Star and how serverless-first approaches powered scalability and success. The episode includes insightful anecdotes, practical mapping techniques, and lessons from real-world examples like Tesla and A Cloud Guru. 🎯 Key Topics Covered: - Mapping the market and competition. - Understanding and leveraging the value chain. - Insights from A Cloud Guru’s journey to a $2 billion acquisition. - Practical tips for mapping your strategy effectively. 💬 Join the conversation! Share your thoughts and subscribe for more discussions on engineering, strategy, and innovation. Thanks for tuning in, and see you in the next episode, where we’ll explore "Challenging the Environment" in the Value Flywheel framework! 🚀 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 a text Welcome to the latest episode of Serverless Craic! 🎙️ Today, we're diving back into our series on The Value Flywheel Effect, focusing on Chapter 6: "Obsess Over Time to Value." Join us as we explore the significance of delivering value quickly and efficiently in tech organisations. We discuss the concept of "Time to Value" over "Time to Market," reflecting on how innovation labs and agile structures can help companies pivot, react, and respond to both threats and opportunities. In this episode, we touch on key topics like: - The importance of creating a feedback loop to see real user value - The challenges of organisational inertia and how it can inhibit innovation - Real-life examples of experimentation and pivoting, including building "trap doors" to validate product assumptions - The role of situational awareness in overcoming barriers to change We also delve into how high-performing teams can increase an organisation’s "rate of turn," making it more adaptable in a rapidly evolving market. Whether you're dealing with big projects or experimenting with new technologies, empowering teams to focus on value, rather than just speed, can transform your business outcomes. If you enjoyed this discussion, don’t forget to subscribe, like, and share. 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 a text This episode centres on Chapter Five of the book "The Value Flywheel Effect," focusing on the North Star framework. We explain how this framework helps teams align their work with a clear, meaningful metric (North Star) and its related leading and lagging metrics. North Star Framework Overview We explain the North Star framework, emphasising its use in helping teams coalesce behind a mission or purpose with a visual, collaborative tool. And the importance of leading metrics and lagging metrics, explaining how the North Star framework helps teams reverse engineer leading metrics from lagging ones. Application of North Star Framework We look at the usefulness of the North Star framework at both the small startup level and the enterprise level, where it helps link lead measures back to overall business impact. The North Star framework is powerful for team and individual morale by making work meaningful and aligning it with organisational objectives. We reference Dan Pink's "mastery, autonomy, sense of purpose" to emphasise the importance of knowing what you are doing and why. The North Star framework is complementary to mapping for strategy, helping to narrow down on value and focus conversations. Challenges and Benefits of North Star Framework It is valuable to ask teams about their metrics and how their work influences them, leading to valuable conversations about measurement and alignment. We look at the importance of measurement, referencing Grace Hopper's quote about the power of accurate measurement. Having data and clear alignment to organisational strategy helps teams advocate for change more effectively. The North Star framework can sometimes reveal that teams are not aligned or that the overall strategy is flawed, likening it to the emperor's new clothes. Connecting North Star to Business Value A structured North Star often reveals disconnects in the work being done and its impact on business value, serving as a corrective measure. We compare the North Star framework to impact mapping, both helping to create a compelling narrative and understand the story of what the team is working on. It is challenging to craft the North Star for behind-the-scenes teams, but the framework helps align value delivery with business goals. We discuss Amazon's working backwards process and its similarities with the North Star framework, emphasising the importance of understanding the customer's need and working backwards from there. Critical Thinking and Leadership These frameworks are enablers of critical thinking, challenging teams and organizations to question their assumptions and goals. North Star metrics and key input metrics make it easier to write a compelling press release that aligns with the company's strategy. Clarity of purpose is the foundation of everything, requiring leadership and courage to implement. 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 a text In this insightful discussion, we explore mapping techniques from Chapter 3 of our book The Value Flywheel Effect and their applications in organisations. Key topics include: Anatomy of a Worldly Map: Breaking down the components of a map, including visible, aware, and invisible items in the value chain. Mapping Teams and Tech Stacks: How mapping helps in identifying team roles and modernising technology stacks. Starting with Maps and Collaboration: Tips for overcoming the blank canvas fear and leveraging tools like GitHub's "Awesome Worldly Maps" and VS Code extensions for map annotations. Open Space Collaboration: The value of engaging everyone in discussions and validating inputs. Mapping the Stack, Organisation, and Market: Using mapping for situational awareness, aligning teams with core domains, and understanding market dynamics to respond effectively to opportunities and threats. This conversation provides practical insights into using mapping for better organizational awareness and strategic decision-making. - Learn more about The ServerlessEdge - see link below - Explore GitHub's Awesome Worldly Maps for useful mapping tools. Don't miss this deep dive into mapping strategies to enhance your organisation’s situational awareness and tech evolution! 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 a text Wardley mapping is a strategic tool to visualise the evolution of products or services. The two axes of a Wardley Map are visibility and evolutionary stage. Products and technologies evolve through four stages: Genesis, Custom build, Product or rental, and Commodity or utility. Understanding context and phase of adoption is crucial in the business world, especially with AI and LLMs. Identifying and moving commodities versus custom-built solutions is important, and optimizing organizational structure for autonomy involves concepts like movement, time planning, and sub-maps. We explain the anatomy of a Wardley map, starting with the anchor (customer) and emphasising the importance of understanding the map's axis and how space and position have meaning. Evolution of technology from Genesis to Commodity, with stages of Custom Build and Product. Product evolution from Genesis to Custom, Commodity, and ubiquity, tailored to specific contexts. We explain the evolution of products through usage and competition and product evolution is context-dependent. Leveraging AI and LLMs in business contexts. We highlight the varying perceptions of LLM and Gen AI across different contexts and note that DBT is marketed as a product or consumer depending on the context. We discuss the importance of understanding user needs and dependencies in designing a successful product. Mapping components to move from custom-built to commodity products. We look at the importance of mapping components to move a business forward and identify inertia as a challenge in moving components, and discuss ways to overcome it. The conversation highlights the importance of leveraging commodities and building a database in 2024. We discuss the evolution of AI, from its early stages to its current utility, and the importance of having the right team types, including explorers, settlers, and time planners. We emphasise the need for all three team types, as each one plays a crucial role in the AI development process, and spikes in team performance can be identified and addressed accordingly. Mapping for autonomous organisations, including optimisation, movement, and sub-maps. We look at the importance of optimising for movement in engineering teams, with different strategies for 'pioneers', 'settlers', and 'villagers'. And the need for organisation-wide alignment and the use of mixed methods within Wardley Mapping, with a focus on stacking boxes when necessary. We look at the importance of mapping in software development, highlighting different types of maps and their uses. And we provide tips for creating effective maps, including using sub-maps for detailed areas and avoiding too many components on the map. Wardley Mapping Resources: Ben Mosior and https://learnwardleymapping.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 a text We discuss facilitating effective collaborative mapping workshops and creating Wardley maps for strategic planning in businesses. We look at the importance of creating a safe environment, effective facilitation techniques, and involving all stakeholders in the mapping process. We also highlight the benefits of embracing diversity and respecting different opinions. And we share various approaches to creating and utilising Wardley maps, including Miro and Lucid, and learning more about the technique through Ben Mosior LearnWardleyMapping.com resources. Wardley Mapping techniques and anti-patterns. Dave Anderson and Mark McCann discussed anti-patterns in Wardley mapping, including "gaming the system" (Dave Anderson). The speakers shared their experiences and insights on how to avoid common mistakes in Wardley Mapping (Dave Anderson, Michael O'Reilly). Collaboration is key in mapping exercises, as it helps to identify blind spots and improve the overall quality of the map. It's important to strike a balance between mapping by yourself and collaborating with others to ensure a richer feedback loop and improved map quality. Michael O'Reilly suggests mapping a subject matter to identify blind spots and derive questions to ask (0:05:10) Dave Anderson advises against re-creating architecture diagrams and instead focuses on higher-level abstraction (0:06:27) Software development, components, and abstraction. Dave Anderson and Mark McCann discuss the challenges of defining and understanding components in software development. Experience and wisdom are key to summarising complex conversations and determining the appropriate level of abstraction for components. Dave Anderson and Michael O'Reilly discuss the importance of context in understanding a Wardley map, with examples from their own experiences. They emphasize the need to introduce new people to a shared conversation gradually, rather than expecting them to pick it up quickly. Facilitating workshops, mapping, and collaboration. Michael O'Reilly and Dave Anderson discuss the importance of mapping in strategy development, highlighting its ability to shake out key elements and dependencies. Mark McCann emphasises the value of psychological safety in a top-down environment, where managers must create a safe space for team members to share their thoughts and ideas. Dave Anderson and Mark McCann emphasise the importance of creating a safe environment where participants feel comfortable sharing their opinions and asking questions. Facilitators should be open and non-forced in their approach, allowing participants to take the lead and challenge each other's perspectives. Using Wardley mapping to understand user needs and dependencies. Dave Anderson and Mark McCann discuss the importance of identifying the user and their needs in the mapping process. They use specific examples and exercises to help the group understand and clarify their thinking. Dave Anderson and Mark McCann discuss the importance of collaboration in product development, using sticky notes and online tools like Miro and Lucid to facilitate brainstorming sessions. They emphasise the need to keep the collaboration process simple and focused, with clear goals and a structured approach to e 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 a text Dave, Michael, and Mark discussed the application of Wardley Mapping in understanding movement and making strategic decisions. They share their experiences with the method, emphasising its ability to visualise and track changes in tech stacks and capabilities. They also discussed the importance of context, user needs, and facilitating meaningful conversations through mapping. Additionally, they highlighted the benefits of mapping for challenging each other's thinking and fostering creative dialogue. Later, they discussed the importance of understanding user needs during agile transformations, including the value of having a shared representation of collective experiences and strategies for removing barriers to change in an organization. Outline Using Wardley mapping to improve understanding of complex systems and software development. Dave Anderson and Mark McCann discuss the history of Wardley mapping, including when they first learned about it and how it has evolved over time. The hosts emphasise the importance of mapping movement and tracking progress in the context of technology and capability, citing examples from their own experiences. Mark McCann: Focusing on user needs in Agile transformations helped teams understand why they were delivering code. Michael O'Reilly: Participating in mapping sessions helped him understand technical nuances and communicate with non-technical stakeholders. Mark McCann: Identified value chain visibility as key to success Dave Anderson: Custom skill sets and implementations were hindering progress Challenging inertia points in team decision-making. Dave Anderson and Mark McCann discussed the importance of mapping out problems and inviting team members to contribute their perspectives. The team used a structured approach to thinking deeply about problems and coming up with solutions, which helped to challenge assumptions and identify areas for improvement. Identifying and addressing inertia points is crucial for strategic maneuvering. Leadership principles, including courage, collaboration, empathy, and narrative. Dave Anderson and Michael O'Reilly discussed the importance of courage and collaboration in tackling complex problems. They emphasised the need for shared understanding and mapping with other teams to make better decisions. The importance of context in mapping: Understanding the user's needs and perspective is crucial for effective mapping. Empathy and narrative: Mapping can facilitate empathy and storytelling, but it's important to show the map to the right audience. Principles of Wardley mapping for strategic planning. Michael O'Reilly and Mark McCann discuss the importance of simplifying complex systems through Wardley mapping, focusing on the principles of abstraction and dialogue. Dave Anderson emphasises the importance of not overcomplicating the model, and using it as a facilitation for meaningful conversations. Dave Anderson and Michael O'Reilly discuss the importance of mapping in facilitating creative conversations. They outline the eight principles of Wardley mapping and its benefits in understanding a company's value chain. 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 a text The Value Flywheel Effect is a pattern seen in organisations where business strategy and technology strategy align, leading to more sales and growth. The hosts discuss the concept of the value flywheel effect, its origins, and how it applies to creating software for customers. Dave Anderson and Mark McCann discuss the four phases of the value flywheel process, with three principles for each phase, aimed at building momentum and sustainability in organizations and teams. Clarity of purpose is the first principle, visualised as a data-informed Northstar, helping teams understand their core user needs and improve situational awareness. Software development principles, including focus, clarity, and understanding the market. Michael O'Reilly and Dave Anderson discuss the importance of aligning individual and team goals with the overall organisational Northstar. They emphasise the need for a clear problem statement and direction to focus attention and achieve success. Michael O'Reilly and Dave Anderson discuss the importance of focusing on time to value in product discovery, rather than just time to market. They emphasise the need to map the market and clarify the business's purpose, rather than just focusing on individual silos or software pieces. Dave Anderson looks at the importance of understanding a company's strategy and market position, even for software engineering teams. Mark McCann suggests that junior engineers can gain valuable insights by analysing a company's website, LinkedIn, job postings, and press releases to understand their competitors and industry landscape. Engineering team structure, process, and enablement. Michael O'Reilly: Embrace diverse teams for success, learn from failures. Mark McCann: Socio-technical systems crucial for successful teams. Michael O'Reilly and Dave Anderson discuss the importance of enabling and empowering engineers in High Performance Engineering, including creating a generative environment and mapping the organisation for enablement. Mark McCann adds that removing friction points and impediments is crucial, including developer enablement, handoffs, and carving off certain things to encourage smaller approaches. Prioritising tech stack, offloading non-differentiating tasks, and mapping solutions to customer needs. Focus on delivering value, not just building code. Dave Anderson emphasises the importance of prioritizing tech stack and deciding what to move to the right, while Michael O'Reilly and Mark McCann discuss the benefits of mapping out the tech stack and identifying key differentiators for the business. Modernising software development and delivery using AWS Well-Architected Framework. Dave Anderson looks at the importance of preventing problems before they occur in software development. Mark McCann highlights the need to understand the ecosystem and constraints when implementing continuous delivery. Mark McCann: Celebrate successes in fraud prevention, reward employees for going above and beyond. Dave Anderson: Keep a low carbon footprint, measure efficiency and sustainability in cloud workloads. Mark McCann and Dave Anderson discuss the importance of well-architected frameworks for cloud migration and sustainability. They highlight the 12 p 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 a text We discuss why we wrote 'The Value Flywheel Effect,' emphasising our desire to give back to the community and help others who have contributed to their success. We share our experiences and insights on navigating the cloud transformation journey, highlighting the importance of luck, collaboration, and upskilling in overcoming challenges. We also discuss modernising engineering practices, prioritising meaningful outcomes, and providing insights on change leadership and decision-making techniques. Modernising software development and delivery in the cloud. Michael O'Reilly and Dave Anderson share their experiences working together in the cloud industry, mentioning luck and serendipity as key factors in their success. They emphasise the importance of being high up the value chain and delivering meaningful outcomes, even in the face of economic ups and downs. Michael O'Reilly and Dave Anderson discuss the shift towards modernisation in engineering, with a focus on agility and speed. They emphasise the importance of thinking differently and acting collectively to drive change in the industry. Modernising software development and embracing new technologies. Organisations must adapt to changing industry expectations and evolving technologies to remain competitive. Dave Anderson and Mark McCann discuss their book on modern software development, with Dave crediting Mark for encouraging them to write it. Mark McCann recounts how they met and shared ideas before writing the book, with Dave describing it as a "big confidence boost." Modernisation strategies for technology and business. Dave Anderson and Michael O'Reilly praise Simon Wardley's mapping technique and strategic thinking, citing his ability to make complex decisions and decompose things down. Simon Wardley's 2015/2016 talk on serverless computing is highlighted as a standout moment, with Dave Anderson calling it "super important" and Michael O'Reilly praising his ability to entertain and carry a message. Dave Anderson and Mark McCann discuss modernisation in organisations, emphasising the importance of leadership and decision-making. They suggest a framework for driving modernisation, including techniques like event storming and Northstars. 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 a text AWS Serverless Developer Advocate Team news is breaking. We discuss this and the importance of community events and fostering a culture of curiosity and collaboration in the tech industry. We emphasise the value of attending events like ServerlessDays Belfast and looking outside one's own silo to drive enterprise transformation. We also discuss the significance of developer advocacy in promoting AWS adoption and we look at the challenges of quantifying the impact of advocacy work and the importance of learning about new technologies and driving change within companies. Outline Serverless development and engineering history in Belfast. ServerlessDays Belfast provided a great opportunity for attendees to engage in meaningful conversations with both beginner and seasoned experts in the field. Serverless technology and its impact on software development. We emphasise the importance of applying new ideas and learning from others in the tech industry. Jeremy Daly's keynote at the event inspires attendees with his innovative approach to serverless computing at AMP. We praise the AWS Developer Relations team for their helpfulness and unbiased opinions. The team has been a valuable resource for learning and validation, with their content and opinions shaping the field. Leveraging serverless technology and its benefits in modernisation and migration efforts. We credit the DAs with breathing life into the serverless movement and discuss how serverless technology can help modernize enterprises by leveraging existing work and tailoring it to specific contexts. Developer advocacy and its impact on the tech industry. We highlight the valuable insights and expertise of various serverless experts, including Julian Wood, Eric Johnson, David Boyne, Marcia Villalba, and Chris Munns. We recommend reading the ServerlessLand site as a go-to resource for understanding serverless technology and strategies. We discuss the impact of their developer advocacy work on AWS, highlighting the need for continued investment in Dev Rel. We emphasise the difficulty in measuring the impact of their work but noted anecdotal evidence of significant change driven by their efforts. Modern cloud solutions and their evolution. We discuss the evolution of developer advocacy at AWS, highlighting the importance of feedback loops and professionalism. And emphasise the value of connecting customers with the product team to address feature requests and shape product direction. We discuss the evolution of cloud services, including the term "next gen" and the importance of situational awareness. And reflect on their favorite team and thank engineers for their work, encouraging listeners to follow TheServerlessEdge.com website and channels. Serverless Craic from The Serverless Edge: https://theserverlessedge.com/ ServerlessDays Belfast: https://serverlessdaysbelfast.com/ AWS Serverless DA Team: https://serverlessland.com/ Check out our book The Value Flywheel Effect: https://theserverlessedge.com/the-value-flywheel-effect/ Follow us on X @ServerlessEdge: https://twitter.com/ServerlessEdge Follow us on LinkedIn - The ServerlessEdge: https://www.linkedin.com/company/71264379/ Subscribe to our Podcast: https://open.spotify.c 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 a text We use the Cynefin Framework in our cloud modernisation work. Dave Snowden created the Cynefin framework. Cynefin, pronounced "ku-nev-in," is a Welsh word that translates as "place" or "habitat." However, it can also be used to describe the elements of our situation and personal history that influence our thoughts and decisions in ways we don't understand. It's a sense making framework. As architects, we find that the Cynefin framework is a good thinking model. In the Cynefin framework there are four domains and a fifth disorder domain. The first four domains are: 1. Clear, when something is well understood, 2. Complicated, it's understood by few, 3. Complex, where there are a lot of unknowns. 4. Chaos, when you don't know what's happening. The 5th domain in the middle is called Confused. If you understand which domain you're in, you can assess where you're at, and if you're not aware of where you are, you're just confused. When you deal with situations and teams, it's sometimes easy to see the problem or situation. It falls under one of the domains and there are a bunch of practices to apply. When something's well understood and clear, the practices are different than for something that's complex. There are different ways for you to handle situations. And if you're a manager, there are different ways to manage. A chaotic project needs different practices to a project that you know well and when know what to do. We explain each of the domains and we apply them to Software Development. 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 a text ServerlessDays Belfast 2024. ServerlessDays Belfast is back at Titanic Hotel Belfast on Thursday 23rd May 2024 Our theme is 'Building Beyond Boundaries: ServerlessDays Belfast celebrates the spirit of Innovation'. Find out why you should come to the birthplace of Titanic and what you can expect from this year's ServerlessDays Belfast. From the 100-year-old Drawing Offices at Titanic Hotel Belfast, we will celebrate how the Serverless Mindset enables engineers and organisations to break barriers and build like never before. We ask our speakers to speak of the courage, ambition and resiliency needed to build big. We will showcase international and local speakers, attracting interest across Europe and the US. Most importantly, we want to inspire Engineers in Ireland, the UK and the local tech community. Serverless has transcended technology and is now a synonym for Digital Transformation. Engineers working for large and small organisations need a dedicated space to hear and share innovation stories, with Serverless First as the enabler. Senior executives sense that Serverless is at the intersection of technology and business. Everyone needs a network to access the playbook for the Modern Cloud. Everyone is welcome, especially: Engineers who are curious by nature are excited to explore new technologies and ways of working. Leaders seeking the latest solutions and innovations, including product managers, programme directors, and CTOs. This event is a dedicated space for you to network, share, learn and become inspired about Serverless and Modern Cloud. We look forward to seeing you there! What’s on offer Food and Beverages ServerlessDays Speaker Agenda: Listen to renowned experts on Serverless Network with fellow attendees ServerlessDays Belfast 2024 Call for Papers We’re looking for speakers who can share their stories about how serverless technology has helped them achieve amazing things. The theme for this year’s event is “Building Beyond Boundaries”. We want to celebrate the spirit of Innovation and share stories of real change. Tell us about something incredible that happened, how you felt and how the tech helped out. If you’re interested in speaking, submit your talk by March 31st! We will cover travel and accommodation expenses for speakers living outside commuting distance. Take advantage of this opportunity to share your knowledge and experience with the serverless community on the island of Ireland. Learn more and submit your talk on Sessionize . serverlessdaysbelfast.com/ twitter.com/BFSServerless linkedin.com/company/serverlessdays-belfast 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 a text The Software Development Lifecycle - how does it apply to modern cloud? We are kicking off this episode with the term modern SDLC. The software development lifecycle (SDLC) is changing. When you get into this new way of working, you start differently. It's no longer a straight waterfall/ABCD, or starting with an established system like SCRUM and iterating. So how do you get into a fast flow state? We have discovered a lot of things over the past couple of years. In this episode, we talk you through the phases of the modern software development lifecycle. 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 a text We talk about what we would like to see announced at this years AWS re:Invent 2023 looking at Observability, Generative AI, PartyRock, Developer Experience to name a few. 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 a text Team Engineering with SCORP - there are practices we do like SCORP, which is our agile way of doing well-architected in every sprint with teams. Our practices are connected to engineering excellence, looking at what you're doing and constantly improving. And HP (high performing engineering), as a way of capturing key metrics to define good engineering or architecture, and then talk about it as a team. Even though the practices are out there, it's really just a mindset. 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…
S
Serverless Craic from The Serverless Edge
Send us a text There were a few stories in the news about working remotely from another country. We talk about the pros and cons of working remotely versus returning to work. We work remotely and are globally distributed, but we've worked for many years in the office to, so we have experience of both to make a fair analysis. 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 a text Developer Productivity and discussions on developers and productivity have never gone away. You heard people talking about this in the 80s and the idea of paying developers by lines of code. And it was even rubbished in the 80s as a foolish thing to do. There's a famous story about developers removing bad code from the code base and having negative numbers by the end of the week and then asking if they have to pay the company back money. It's never been a good idea. It strikes me as strange that in 2023, we are having the same discussion. 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 a text How important is Resilience Hub, Chaos Testing and Well-Architected? We attended the AWS Resilience Day at the Titanic Hotel. We were sitting in the same room where the ill-fated Titanic was designed and drawn! We discuss what we learned. Including the tools and strategies that help software engineers build resilience that were not available for the Titanic engineers. And we talk about the fact that it isn't just one thing that leads to disaster for ships or workloads. 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…
S
Serverless Craic from The Serverless Edge
Send us a text Bringing mapping to your org. We are doing a wee series on Wardley Mapping, with some practical items. The last two episodes were: 'Wardley Mapping 101' and 'Can Wardley Maps Predict the Future?'. So I thought it would be good to answer a common question: 'That's a cool technique, but how would I do that in my work?'. If you follow Simon Wardley, on Twitter, and you've started experimenting with Wardley Mapping, we tell you how you to bring Wardley Mapping to your place of work. We talk about using the Northstar exercise to facilitate mapping. And about finding like-minded people to sit and practice with. There is a way of talking about mapping. You're better to start with the outcomes. And then see if people are interested to get back into the map, as a way of sensemaking complicated areas. It's great to make sense of something and share that thinking with peers. And once you get into that language, you open up a common way of thinking and the idea of evolution to access things you want to talk about it. 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…
S
Serverless Craic from The Serverless Edge
Send us a text Can Wardley Maps predict the future, is our topic this week. In our last episode, we talked about Wardley Mapping. We did a 101 last time, explaining the basics. One of the things that we say is that Wardley Mapping is a superpower that helps you predict the future. What do we mean by that? It's like a fortune teller. But it doesn't tell you when exactly something's going to happen. It's the state of mind that it puts you in. We run through a couple of examples, to demonstrate how we've done it in the past. Conversational Programming Generative AI Well-Architected Serverless CDK (Cloud Development Kit) If you have good situational awareness, you can wait until the appropriate time. You don't have to go off and waste energy, cycles and money trying custom build something. Wait three months and you'll get what you're trying to achieve. When you map this stuff out, you can start to think about how your sensing engine can get intel on whether these things are going to happen or not. There are lots of different ways you can do that. Like following Twitter feeds and looking at blogs. And looking at who they're hiring and following the industry experts. They're points of information that can help you see how things will evolve. To predict the way things are going to go. There are multiple levels of maturity in your map and how you think it's going move and where the evolution is going to happen. Wardley Mapping can be used to predict the future but it's not going to give you an exact date. What it can do is give you an example of this is what it will look like if it happens. So you prepare yourself for when it does. And then when the press release comes out, you're like, boom, we're ready. We saw that coming. So it's the no 'surprise approach' to building situational awareness. 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 a text Wardley Mapping is a core part of our book: 'The Value Flywheel Effect'. And it's a topic that people always ask about it. It's a difficult thing to learn. We've spent many years thinking about it, stumbling around, and then practicing. So we figured we would do a quick series on Wardley Mapping. We have spent almost 10 years mapping, give or take. For me, it has been an absolute game-changer. One thing that's come along recently is the Wardley Mapping canvas by Ben Mosior @hiredthought . It's a nice canvas with six steps on how to map. Before I started using the canvas, I used to find that maps could get big and go off in 60 different directions. Purpose and scope are the first two steps. And then the third one is users . The fourth one is user needs. And then the fifth step is the value chain . It can be difficult to keep things abstract. And not go too deep. But it is good to be as abstract and high-level as possible, even just to start to get something down. Once you have the value chain of the user, a need, and a couple of dependencies, that's when you then bring it across to the map. And I would usually put them in the middle of the map. Drop them all into Product, to get you started. So you've got them all in a vertical line on your map and canvas. You start moving different components from left to right. And you might work out that one of the dependencies is Commodity or Custom. And you can see how that interaction goes. That's when you start to add in dependencies because you've got more room in the map. This is where the conversation really starts to kick into gear. And this is where people start to challenge each other's context and think about where that component belongs or what's missing from the map. So it makes for a very collaborative exercise. If you are planning a mapping session, you need to be a good facilitator. If a participant feels something is in the wrong place. Don't say no, you're wrong. It's in the right place. You want the individual to explain why they think so. If it is something that's blatantly just them for raising the challenge. The last thing you want is an unsafe environment where nobody wants to speak. It doesn't need to be too fancy. You might map for an hour. And if you're facilitating, five or 10 minutes off the hour, you take a couple of notes, If someone says we should move that component from x to y that's an observation, You're not committing to do it but just taking a few observations. Always just keep it simple. So here are a couple of really good links. We talked about Ben Mosier @hiredthought . He's got a brilliant site called LearnWardleyMapping.com . Ben created the Wardley Mapping Canvas, which is on Creative Commons Open Source. Simon's also got a couple of links. There's a site on GitHub called Awesome Wardley Maps. It is by John Grant on List.WardleyMaps.com . Simon's original book is on medium.com/wardleymaps . Simon's content is great but deep. 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 a text ServerlessDays Belfast was on the 28th of February. It's a volunteer, community, and not-for-profit event. We had a bunch of sponsors: AWS, Bazaarvoice, EverQuote, G-P, Instil and LibertyIT. Our organizers are me, Gillian Armstrong, Garth Gilmour, Peter Farrell, Julie Sherlock, and Treasa Anderson. We had 12 speakers, and over 260 attendees from over 40 companies. But most excitingly we had it at the Game of Thrones Studios Tour. The theme was 'The Reality and Fantasy of Serverless, Building Serverless Teams and Making it Real'. Phil Le-Brun, who is the Director of the Enterprise Strategy Team for AWS launched the event. And give us a perspective of what he sees when he is speaking to the leaders of the industry. IT Revolution was very generous to sponsor and provide 250 of 'The Value Flyweel Effect' books. Julian Wood gave the Keynote. Even though he works for AWS as a Serverless Developer Advocate, he gave his opinion on where he sees the industry. I thought that paired really nicely with Mattie Wilson from Instil. He gave a brilliant talk on an engineering team going through the journey from a cloud application to a serverless application. Sheen Brisals from The LEGO Group, as ever, gave an absolutely brilliant talk about Lego's journey. Going Serverless to EDA and the team topologies of an event-driven organisation. Sheen is an absolute master. Jonah Andersson did a talk on the .NET stack. And Conall Bennett and Roger Moore did a talk on CME Group's move to a Google tech stack. Craig McCarter talked about large-scale serverless. And I took comfort from hearing about a team that's doing something financially significant at a massive scale. And they're pushing those limits. I really enjoyed the talk by Anna Carlin and Emma Patton from Aflac Northern Ireland. They called their talk: 'A rookie journey of discovery and learning'. So they came in as grads and basically built a serverless system. And Chintan Parmar's Dunelm story was really interesting about Dunelm's e-commerce site because it's quite an unknown story. Most people had no idea that they had a whole big serverless ecommerce site. Ben Ellerby from Aleios closed out with his Serverless Staircase Framework. I've been a fan of Ben's for many years. He's an AWS Hero. He's brilliant and very experienced. And he's worked on a lot of serverless projects. That is what his company does. So he's got lots of war stories from doing this with real customers. 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 a text We've been talking about AWS re:Invent over the last few episodes. But one thing that we haven't talked about is Serverless Espresso. Serverless Espresso is a pop up coffee shop that allows you to order coffee from your phone. In the Expo Hall at the AWS Summit, they have a Barista setup. And you walk up to a QR code with a screen in the background. So you scan the QR code and enter in your email address. And up pops a menu. If you select an americano, espresso or other type of coffee, it kicks off an event driven flow. It uses an event driven service under the hood and pops up in the screen as a number. And then the Barista takes the number makes your coffee and gives it to you. But what's happening in the background is a whole load of orchestration and choreography run events. And as they've been using it as a way to explain serverless event driven architecture. Event driven architecture can be hard for people to conceptually wrap their heads around. So making it real through ordering coffee. And showing how to tie a coffee process and an event driven coffee ordering system makes it real. It stitches together a lot of stuff that we've been advocating for, in a way that makes sense. By using AWS Step Functions, EventBridge, Lambda, API Gateway, S3, DynamoDB and Cognito. There are two myths in this space that AWS are trying to dispel. We first started talking about event driven architecture 13 years ago. We had the idea of doing something but back then it was really difficult, because we didn't have a lot of support. So we had hard problems to solve technically, because the foundations weren't there. That is the first myth of being a hard thing to do. The second myth is that people think of serverless as just writing code and functions. It's actually more like an event driven architecture. It's events firing off activity and not a call stack. So it's a lot easier to build full event of architecture than it would have been years ago. The technical challenge is not as bad as you think it is. What I like about Serverless Espresso is the simple interactions. You order, it goes to the barista who makes the coffee, and he gives it back to you. There's one interaction. Normally when ordering a coffee, you talk to a waiter, the waiter talks to the barista, and the barista talks to someone about milk etc. There can be six or seven people in that flow. It causes confusion. In a company, if a business process is owned by six or seven teams, even across two or three departments, it gets messy. If a single team builds for the customer directly and there's no one else, it's usually pretty clean. Serverless Espresso Lab is good, because the opinions are out there and you add on your bit, which is your business process flow. It goes back to our book The Value Flywheel Effect. And the first phase of the value flywheel which is clarity of purpose. Who is the customer and what is the business flow that we're trying to build? And let's have a good debate on how we are going to do that. When you get to the technical side, that opinion is already there. And you can focus on getting the orchestration correct. Because you know that a lot of that underlying stuff is pretty much solved apart from making it behave. Look at the Serverless Espresso Lab on 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 a text AWS, What's New? We are post AWS re:Invent. To sum up, it was about the next generation of cloud focused on delivering value quickly by removing barriers to business adoption and enablement. On Day 1 SiliconAngle published an article called " AWS chief Adam Selipsky hints at the next-gen cloud ". He looks at classic cloud versus next-gen cloud. Classic cloud is infrastructure as a service and the platform of the cloud. And next-gen is looking at ISVs and true cloud. It's about using the cloud to power you business journey. Which is exactly what we talk about in The Value Flywheel Effect ! AWS are market leading for low level cloud primitives. If you want compute, get it from AWS. It has been this way for the last 15 years. But next generation cloud is about business capability. When you do Wardley mapping correctly, cloud primitives are pushed to the right to become commodities. You then look for the business capability you need. That's exactly what the value flywheel effect is. AWS are consolidating core primitives and opening up the solution space to help customers do interesting things with them. There has been a lot of criticism of AWS in previous years with regards to their developer experience. Code catalyst is a big move from AWS to try to make that more seamless. It stitches together a number of things that have evolved over the last while. It's an accelerator for teams coming on to the cloud or into serverless. And it is frictionless developer experience. In our book, it's the next best action phase of the value flywheel. Well architected featured heavily at AWS re:Invent. AWS are continuing to develop well architected and build it into things. Security also featured with verified permissions. It's out in pilot at the moment but it has potential to make a big impact on managing fine grained permissions and doing identity authorization properly, especially if you have a custom app. Most companies of a certain scale have their own custom built version of this. But you need to acknowledge that you are ahead of the curve. And have the courage to delete your custom built solution. There's a bunch of step function stuff out. I particularly like SnapStart which gives you the ability to drop large java applications into lambda. And performance time is through the roof. You can draw up an average Spring Boot application into lambda and you will get similar performance but it's way cheaper to run. It's addressing the myths around cold starts and using lambda for high performance workloads. It's also interesting from the perspective of having large framework oriented services and leveraging those for femoral compute. At AWS re:Invent, the message I was hearing loud and clear is that enterprises and large companies have moved to the Cloud but need help doing the next piece. They need help creating their value flywheel. They've done the move and now need to go to the next stage of modernization or next-gen. So that is good news for our book 'the Value Flywheel Effect'. There's definitely a lot of demand for more advice and guidance. The ecosystem has never been better for applying the value fly 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 a text AWS reInvent announcements In this episode we are talking about what we would like to see at AWS re:Invent. What would you like to see? Serverless Services An increase to the enhancement and evolution of service development capabilities and the ecosystem in general. So more serverless services coming online for items that aren't serverless and iterating to be more serverless. There's a bunch of things that people are almost afraid of like observability, deployment patterns and some of the frameworks. API Gateways In service development, Private API gateways are interesting, but they could be more developer friendly, in terms of setting up, naming and managing. We are seeing more enhancements around eventing capability like SNS filtering, SQS and X ray. These are things that make the serverless experience more rich and all encompassing. Developer Enablement You need to think about developer enablement and time to value. Can you get a developer up and running with a productive IDE in the cloud? And can they start delivering value rapidly? We're seeing steps around Cloud IDE starting to emerge. I want to see what AWS does around their Cloud9 offering. Well Architected Over the last year, we've seen good announcements on well architected capabilities, systems and services. I want to see a continued evolution of that. And more well architected thinking and characteristics baked into everything. All the way from developer advocates to patterns and code samples. Some of the basic primitives are moving up a level to something more like a pattern. It's about fast feedback and dare I say the value flywheel. Can the pipeline's tell us how well architected the chains that we made are. And can our IDE tell us how well architected we are? Stitching that together in a compelling way with fast feedback for the developers would raise the bar on what developers deliver into production. That's effectively platform heuristics. I remember back in the IBM mainframe days, it was a mature platform. And you knew it so well, that they started to bake in heuristics. When you start to analyse your code there would be a heuristics to say this might be wrong. Here's what you need to do to fix it. We're starting to see some of these elements emerge already with Security Hub, Reliability Hub and Fault Injection Simulator. It's about stitching those together like factory mode for workloads in your accounts. Tell me we're not well architected, and tell me how to fix it. Sustainability More fine grained analysis of carbon scores would be useful when teams are designing and building their workloads. And getting faster feedback on a particular service and how much it is going to cost you in carbon. What's the wacky stuff you would like to see? I'd love to see work on APA management and API gateways . Factory mode for your accounts. How well architected are you would be really good. Instead of us having to do the reviews and do it manually. The gateways are due an uplift or enhancement. What about documentation ? And how you consume information about services. We are seeing an explosion of services on the console. Is there going to be a cut down console just for 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…
S
Serverless Craic from The Serverless Edge
Send us a text It began with the forging of the Great Maps and Simon Wardley We've been talking this week about Wardley mapping. Where did you first hear about Wardley Mapping? I first heard Simon Wardley talking at cloud conferences about early cloud. I remember an open source conference and a 20 minute video. When he presented it came across as common sense. Like, why would you do anything else? The bigger question is why were we looking for this type of stuff? Or why did it resonate with us? I think we were at a certain point in our careers. We had been engineers for a while. And we thought there's got to be a bigger picture here that we're not quite grasping. Simon Wardley started writing his book in 2016. I went to Lean Agile Scotland in October 2016. And he did the talk in person. I had seen his talk a couple of times, but it didn't really click until I sat and watched it in real life. Remember, there was a time when we said we need to stop using PowerPoint! We need to get people into rooms to have conversations and working sessions. I refined and improved my ability to do Wardley Maps through teaching. There were people who hadn't experienced mapping. There's another important step. You move from doing it yourself to doing it in a group environment. When you are looking at a map you are figuring it out. When you do it in a group environment, the group will ask about this and that. And that's when it really starts to click. For me, the two big things are: 1. Start with a customer need. I remember a team were stuck for six months because they didn't know who the customer was. 2. The four phases of evolution or access (Genesis, Custom Built, Product, Commodity). Get your head around that concept. One of the other pitfalls we fell into was mapping too much detail. We went too low level. And then someone came along and zoomed us out, by saying 'you don't need those five components. Here's just one!'. Another important lesson is that senior people just want to hear what you are going to do. They don't want to know how you figured it out. If they say why are you doing that? You can go through the map in your head and say that you've thought about it. If you say this is what we are going to do and here's the outcome, you don't need to show them all your work. When we started mapping there wasn't much about apart from the odd presentation. Now there's lots of material out there. The community is growing. You can google and look up YouTube. And there's online conferences as well like Map Camp. For resources look at Simon Wardley on Twitter @swardley and his pinned tweet. Simon has a book: ' Wardley mapping '. He is on Medium at ' wardleymaps '. There's a whole bunch of stuff including free articles. They're fairly meaty but they're good. John Grant keeps a list of maps on GitHub, which is list.wardleymaps.com . Ben from @hiredthought is also at learnwardleymapping.com . And of course, our book, ' 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…
S
Serverless Craic from The Serverless Edge
Send us a text What is Engineering Excellence? Few companies say they don't want good engineering. But they don't define what good looks like. And secondly,engineers are expected to write lots of code. For me, engineering excellence is not writing loads of code. It's about getting into code reliability, feedback loops and how well engineering is functioning. And how your team is performing and meeting bigger goals. I love to say 'slow is smooth and smooth is fast'. So how do we set ourselves up for that? At the beginning, I like to go slowly to look at our process. To define engineering excellence, we use Dan Pink's motivation factors of autonomy, mastery, and purpose. We translate those motivation factors to technical excellence, autonomy, and customer focus. Well architected is better defined than engineering excellence. But I find that a lot of people haven't heard the term well architected and they think you've just made it up! If you want to move fast, you've got to be empowered and know what good architecture looks like. When you have guidance or patterns that are implemented in a well architected fashion, that sets you up for rapid delivery, moving with speed, and in an engineering excellence way. It's fast flow aimed to facilitate you moving fast, getting things out quicker and being more competitive. Teams are rapidly delivering product value multiple times a day. And they have a trail of evidence that they're going the right way because of these practices. They have dashboards, logs, alarms, alerts and the run books and the playbooks. And the key business indicators (KPIs) at their fingertips. So any stakeholder can challenge them on what they are doing, how they are operating or what they are deploying. If you arrive in an area that isn't well architected, you've got to spend three months trying to understand what went on before or trying to understand the decision making. Or you've got 12 months of technical debt that should have been taken on board before you moved there. That very difficult from a personal perspective. There's a whole bunch of advantages. One is a problem prevention culture. But I don't think it exists in a lot of organisations. It hasn't really cut through. They're still on the feature, factory, server mindset. Deliver, deliver deliver. Feature, feature feature. And then they have a tipping point where everything grinds to a halt for months or maybe years. And it may never recover. But if you have a continuous improvement mindset and you are investing in fraud prevention, well architected, engineering excellence and continuous learning. And you are enabling and applying this to your teams, you get ahead of problems before they become problems. From a problem prevention perspective, do you want to spend all your time babysitting a non well architected workload and dealing with all of that? You want your teams moving, adding value and moving on to the next thing. That's not possible if your build lacks quality, is always down or if you're having to constantly upgrade. With well architected and engineering excellence, we can build things that run and increase in value. And there's less work over the long term, while your teams move on to what the business needs. I don't think a lot of orgs think in th 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…
S
Serverless Craic from The Serverless Edge
Send us a text 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…
S
Serverless Craic from The Serverless Edge
Send us a text 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 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…
S
Serverless Craic from The Serverless Edge
Send us a text 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 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…
S
Serverless Craic from The Serverless Edge
Send us a text 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. 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…
S
Serverless Craic from The Serverless Edge
Send us a text 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 tra 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…
S
Serverless Craic from The Serverless Edge
Send us a text 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 pushin 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…
S
Serverless Craic from The Serverless Edge
Send us a text AWS Serverless Services with Paul Swail from Serverless First 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 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…
S
Serverless Craic from The Serverless Edge
Send us a text 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 phas 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…
S
Serverless Craic from The Serverless Edge
Send us a text 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 act 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…
S
Serverless Craic from The Serverless Edge
Send us a text 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 compan 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…
S
Serverless Craic from The Serverless Edge
Send us a text 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, 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…
S
Serverless Craic from The Serverless Edge
Send us a text 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 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…
S
Serverless Craic from The Serverless Edge
Send us a text 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 r 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…
S
Serverless Craic from The Serverless Edge
Send us a text 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 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…
S
Serverless Craic from The Serverless Edge
Send us a text 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: 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…
S
Serverless Craic from The Serverless Edge
Send us a text 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 Elevat or' I love his concept of an architect riding the elevator to talk to the executive in the penthouse, go 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…
به Player FM خوش آمدید!
Player FM در سراسر وب را برای یافتن پادکست های با کیفیت اسکن می کند تا همین الان لذت ببرید. این بهترین برنامه ی پادکست است که در اندروید، آیفون و وب کار می کند. ثبت نام کنید تا اشتراک های شما در بین دستگاه های مختلف همگام سازی شود.
Daily Deals
Daily Deals
Daily Deals
Player FM - برنامه پادکست
با برنامه Player FM !
با برنامه Player FM !
))
