Loving Legacy

HUMAN SOFTWARE: How We Treat Each Other At Work

Fri, 28 Nov 2025 09:00:00 +0100

In this special episode I say hello after two years in silence, and I share what has been going on in the meantime.

I wrote a book. It's a novel. It's about how we treat each other at work, it's about families, friends, ambition, disappointment, mental health and the impact of 24/7/365 software culture and globalisation and AI on our workplace.

In this short episode I introduce you to the reasons behind writing the book and tease a continuation of this podcast.

You can find out more about the book on the Human Software Website.

If you'd like to hear more about the Rands Leadership Slack you can go here.

My blog called Surviving Software is still right here and you can also find me active on LinkedIn.

That One Script You Wrote is Now a Platform

Tue, 28 Nov 2023 09:00:00 +0100

What is a platform? How does one appear and what do you do with it when you have one?

Exploring the line between planned organisational change and operational overhead. Overview of the state of platforms and introduction to Team Topologies concepts around Team API, Thinnest Viable Platform and Conway's Law.

Review of the talk I gave at the DevOops meetup in Amsterdam, November 22nd 2023.

Slides are here:

https://speakerdeck.com/bownie/that-one-script-you-wrote-is-now-a-platform

Youtube is here:

https://www.youtube.com/watch?v=vxf8LPTr6tc

More resources here:

https://richardwbown.com/that-one-script-you-wrote-is-a-now-a-platform/

The QUEST for Better Software: Happier Teams and Happier Customers

Mon, 03 Jul 2023 09:00:00 +0100

To kick off a new season, I start with a deep dive into the QUEST framework-which-isn't-a-framework. QUEST is a mnemonic that helps you remember essential software delivery tasks. This previews my upcoming "We Are Developers" conference talk in Berlin 2023.

In this episode, I take a view on the Agile Manifesto, the 5 Ideals from the Unicorn Project as well as John Romero's 10 Programming Principles and rewrite them, group them and then provide you with a way to remember how to apply them (and what they mean) every single day whether in your team, for your teams, or your customer.

NOTES

The Agile Manifesto

https://agilemanifesto.org/

The Five Ideals from the Unicorn Project

https://itrevolution.com/articles/five-ideals-of-devops/

https://richardwbown.com/software-engineering-happiness-the-five-ideals/

Scope: ensure that the team can work on a context over which they have complete control. See Team Topologies, see SOLID principles, see DDD.

Flow: Work in small batches with complete mastery of our domain.

Agility: Make our context better every day. Improve our experience.

Freedom: to experiment, to try without fear.

Delivery: provide solutions to customers with minimal possible overhead.

John Romero’s 10 Programming Principles

https://www.youtube.com/watch?v=IzqdZAYcwfY

https://github.com/anttiviljami/romero-programming-principles

https://richardwbown.com/john-romeros-ten-principles-for-building-great-software/

Kent Beck’s Presentation about Refactoring and Cost of Upfront Design:

https://www.infoq.com/presentations/refactoring-cleaning-code/

It’s a great talk and worth watching. Because it exposes the social side of software development.

QUOTES

Avoiding Legacy? DDD, Collaborative Architecture and Product Thinking with Nico Krijnen

Sun, 30 Apr 2023 09:00:00 +0100

Do you hate legacy or do you love it? Do you accept it or do you want to stamp it out? This time I talk to Nico Krijnen (Lumunis) about the opportunities we have in our legacy codebases to understand our business better, the strategic use of new technologies to make important product improvements, the importance of collaboration and visualisation to create a shared vision of software architecture and our product no matter what state the codebase or architecture.

We discuss the meaning of legacy, what it is and when it appears, how to fix it, how to avoid it and how to prosper as a business while replacing it. We also talk about what you can do in your pipelines to avoid legacy automatically, the importance of visualisation, context mapping in DDD and C4 diagrams.

In a fascinating and wide-ranging discussion, we talk about what it takes to make great software in the age of microservices.

NOTES

The DDD NL meetup:

https://www.meetup.com/domain-driven-design-nederland/

Nico's workshops at DDD Europe:

Full-day workshop on June 6:

https://dddeurope.academy/applied-eventstorming/

2h hands-on at the main conference:

https://2023.dddeurope.com/program/playing-with-domain-models-in-code/

Automating architecture validation for Java and .NET:

https://www.archunit.org/

https://archunitnet.readthedocs.io/en/latest/

With an example of using it for a layered or onion architecture from one of Nico's workshops:

https://github.com/nkrijnen/workshop-apeldoorn-jug-2022-11/blob/main/part-01/src/test/kotlin/eu/luminis/workshop/smallsteps/ArchitectureTest.kt

Nico's speaker profile & linkedin:

https://sessionize.com/nico-krijnen/

https://www.linkedin.com/in/nicokrijnen/

And an overview of some of the courses Nico gives through Luminis:

https://www.luminis.eu/expert/nico-krijnen/

QUOTES

[01:41] "it seems that in our industry, only seniors and architects, et cetera, are getting in touch with domain-driven design at some point and I think that's a waste" [NK]

[02:10] "so one of the things I really wanted to do is trying to lower that learning curve [for DDD]" [NK]

[04:03] "you need to have ways to create sort of a shared mental model of the stuff you're working on" [NK]

[05:02] "We had a chat the other night about, how we feel about Legacy. I said, I love it and you said, I hate it. How does the legacy fit into to your daily work?" [RB]

[06:20] "legacy can have a lot of bit different meanings, but typically it means something that's not, at least how I see it, is it's a code base or a product that's not easy to work with anymore." [NK]

[06:38] " I like to go fast. I like to, to build stuff and, and be excited about those things and not feel dragged down by, a big stone that you're dragging along." [NK]

[06:47] "that's why I hate it [..] but to be honest, all our industry is full of it" [NK]

[07:03] "a lot of teams do not have the discipline to then go fast, but also go quality" [NK]

[07:45] "So typically when you meet a legacy system, first of all, what, what are the smells of its legacy? And secondly, what would you start to think about doing to improve that situation?" [RB]

[08:59] "we got someone in and they started working fully automated regression test, so deploys to production could be done, [in] half an hour. So that's different from a week, right? " [NK]

[11:16] "Cause it's a system that's making money, right? This legacy system is the place where, where you, where your business runs on." [NK]

[11:55] "So, I still hate working with legacy, right?I refuse to accept it. I think that's more than mindset, right? So I refuse to accept it as legacy." [NK]

[12:50] "You can transform that into a modulith like, which is, uh, what you call it nowadays." [NK]

[14:09] "So that's also why I think why I'm talking at conferences and spreading this knowledge because I think it's important to help the industry to realize this and also to find ways to get [legacy] under control" [NK]

[14:23] "We're building more and more software and, if we're not doing it the right way, we're just building, a lot more legacy. And I don't want to be there!" [NK]

[15:06] "I think the ease with which organizations now adopt Kubernetes and under underestimate the complexity, [is] quite scary, to be honest." [NK]

[16:46] "I think in a lot of cases people underestimate the value of just sticking with the stuff that you know and can handle" [NK]

[17:34] "Because I think a big portion of legacy is that people don't understand how the system works or what it's supposed to do, or at least do, or pieces of it." [NK]

[17:49] "I think that's where domain driven design, again, has a good role to play, is that it helps you to understand a domain. It helps you to understand the problem space." [NK]

[18:24] "it's good to use some experimental technology to do something that nobody else has ever done because it's gonna put you in a space where nobody is and where you can solve problems that nobody else can solve." [NK]

[19:56] "I would try to take the Frankenstein out of it, not accept that it's a lost cause." [NK]

[21:00] "[Legacy] is usually the point where people don't understand how a system works anymore" [NK]

[22:25] "In the workshop you encounter something that's called an Arc Unit, which allows you in your pipeline check or you compile time or test time, check that the architecture that you have in mind is not violated" [NK]

[24:08] " I think is always super important to have at least one visual in your, in your project" [NK]

[24:53] "try to write the minimal amount that you can, right, that you need, but that you are sure that you can keep up to date over time" [NK]

[27:43] "the real value of that kind of high level diagram is not so much having an up-to date version of it. Is it It is drawing it together with the people working on it." [NK]

[29:11] "giving context , about a system, what I think is really useful to draw a context map like from DDD, which essentially is like the high level context overview of, a system, but then more focused on the communication patterns between systems and especially also between teams" [NK]

[30:24] "a high level C4 diagram and a context map" [NK]

[31:05] "The temptation is always for everybody to prove their worth on any project" [RB]

[31:50] "we don't want to get the impression [of domain driven design] that it means you start to do a lot of design upfront." [NK]

The Business of Legacy - Making Software Change Successful

Thu, 13 Apr 2023 12:00:00 +0100

We are bombarded with the need for business change - which means systems change. At the same time, we need to be faster, safer and more secure than ever. How can you learn to make software delivery effortless, and how can you use the best knowledge on the planet to help you?

In this episode, I introduce the best books on software and IT change in business and how I would deliver effortless change dependent on context. If you want to know where to start tackling legacy systems change, start here.

NOTES

Check out this link for the map of the Books I mention in the podcast:

https://richardwbown.com/how-does-ability-to-innovate-impact-bottom-line/

Domain Driven Design by Eric Evans (the blue book)
Test Driven Development by Example by Kent Beck
Out of the Crisis by W. Edwards Deming
The Phoenix Project and the Unicorn Project by Gene Kim et al
Team Topologies by Matthew Skelton and Manuel Pais
The Goal by Eli Goldratt
Crossing the Chasm by Geoffrey A Moore
Working Effectively with Legacy Code by Michael Feathers
Obviously Awesome by April Dunford
Accelerate by Nicole Forsgren, Jez Humble and Gene Kim
The Value Flywheel Effect by David Anderson et al
The DevOps Handbook by Gene Kim, Jez Humble, Patrick Debois, John Willis and Nicole Forsgren

QUOTES

[01:18] "So what is the secret glue that holds successful tech companies together and lets them succeed with it and software delivery where others fail?" [RB]

[01:55] "From what I can see, there is no secret to success in software change for your business. You need to be clear, consistent, pragmatic" [RB]

[02:22] "These are some of the lessons already distilled from the biggest and the best companies on the planet" [RB]

[02:37] "This, how quickly can your systems react and anticipate to changing market conditions? " [RB]

[03:47] "Almost anyone can manage IT and software delivery but the best always ask what appear to be on the surface, the most obscure, unrelated, or perhaps downright stupid questions." [RB]

[04:24] " it helps if you have a decent, wide base of technical knowledge before you start asking the questions" [RB]

[05:11] "So find the rough spots. Be an ear to those who are upset or disaffected or annoyed by how things are going now, and use their knowledge to inform your opinion" [RB]

[06:10] "At that point, no matter what the size or the shape of the system or the solution you're proposing, you'll be in a position to potentially deliver something that might make a difference to the business." [RB]

[06:43] "Ensuring that you have listened and understood is a priority. Then show how change can work for everyone and finally, show the results." [RB]

[07:10] "Therefore, it is not your change, it is the business' change, it is everybody's change" [RB]

[08:05] "I've put together a map of the best books that I feel contribute to this area, and I've also created a suggested path, which will help you navigate" [RB]

[09:41] "You can't afford to ignore product development as part of software development these days" [RB]

[10:59] "software deployment in a real life situation is always inevitably going to involve a legacy system or is going to involve a legacy decision that you've made on a previous deployment." [RB]

Interview with Jonathan Hall - Talking DevOps, Go and Continuous Delivery in Reverse

Thu, 30 Mar 2023 07:00:00 +0100

I talk to Jonathan Hall about all things DevOps from small companies to large companies and where the customer fits in the often technical story of our code development and deployment.

How do you bring junior devs up to speed responsibly? How do we as an industry think of DevOps tooling and how much is too much? How and when should you automate?

We also talk about his love for Golang and how it makes life simpler for junior and senior devs alike - how he got into DevOps and what that means to him both from a development and operations perspective.

Finally we also cover Continuous Delivery and how to implement more easily, in reverse.

NOTES

Tiny DevOps Podcast: https://jhall.io/tinydevops/

Cup o' Go Podcast: https://cupogo.dev/

Adventures in DevOps Podcast: https://topenddevs.com/podcasts/adventures-in-devops

Boldy Go Youtube Channel: https://www.youtube.com/channel/UC79XhRzbR3YSnm3ODqgZ6EQ

Best Book to Learn Go: https://boldlygo.tech/posts/2023-02-24-best-book-to-learn-go-in-2023/

Three Ways of DevOps: https://itrevolution.com/articles/the-three-ways-principles-underpinning-devops/

QUOTES

[02:41] "it was shortly after I joined that company that we had a Black Friday incident." [JH]

[03:02] "It turns out the problem was an execute bit had not been set on a little shell script." [JH]

[03:27] "how do we, how do we live a sane life. In a world where those mistakes are bound to happen" [JH]

[04:31] "any person who comes to realization, um, about themselves vis-a-vis software realizes that you have to limit mistakes as much as possible" [RB]

[05:45] "I was frequently frustrated by the, uh, The lack of streamlining they had around deployments" [JH]

[07:21] " So that's kind of how I realized. Tiny, in the sense of like small headcount, small teams is kind of where I wanted to focus." [JH]

[07:49] " if you're employee number 10, You have, you know, in theory, a 10% influence on how things are done. If you're employee number 1000, you have a 0.1% influence on how things are done. It's just a big difference that way." [JH]

[09:26] "I often say that the hardest part of our job isn't the technology, it's the people." [JH]

[11:24] "infinity sign with the different steps is one or the three ways of DevOps, and the customer doesn't really take a center seat in any of those, which is unfortunate." [JH]

[12:25] "one of the common things I see is people automating stuff before they even know what it's supposed to be doing" [JH]

[14:09] " I think that there's a natural human tendency to seek the easy answers." [JH]

[15:02] "The unfortunate truth is that life isn't that simple. Life isn't as simple." [JH]

[16:45] "since I tend to work more often with smaller, younger companies, one common piece of advice I often give them is to hire one senior instead of two juniors" [JH]

[17:33] "how many junior developers have you worked with who understood how Git works? That's an essential skill that is not being taught properly." [JH]

[18:19] "the less code you have, the safer your company is in the long run, the less expensive developers you need to maintain that code" [JH]

[18:55] "all these sorts of things you kind of pick up on the job, but that's 80% of the job really" [JH]

[20:54] "Dockers written and go" [JH]

[21:17] "So there's like 10 or 12 different ways to do loops in Pearl and go you have one and only one." [JH]

[26:15] "I've been making sort of an effort of educating people on the idea of implementing continuous delivery in reverse" [JH]

[27:29] "The problem with that approach is that nobody ever gets there, or almost nobody ever gets there." [JH]

[28:00] "Every time you push to either to master or to your staging branch or whatever you have there, get that automatic build and deploy working. Then after you have that in place, Start working backwards" [JH]

[29:27] "This makes the bottleneck more obvious. It makes the changes safer. It does introduce pain, but that pain can be a good thing if you use it to drive the right change." [JH]

[30:19] "Ask the question of Why can't you do that yet? Don't just stop there. " [JH]

[31:47] "10 years ago, it was, it was almost blasphemous to say that you could do 10 deploys in a day" [JH]

[32:11] " I'm encouraged by the, the way the conversation has changed over the last 10, 15 years." [JH]

Emergent Architectures and Beating the Monolith

Tue, 14 Mar 2023 09:00:00 +0100

What does it mean to support, extend or even replace a monolith and should we even try? This time I explore the landscape as it is now - when we feel under pressure to "do microservices" yet we have something that works but is perhaps too much of a monolith for us to work with effectively.

This quote from the end of the episode perhaps sums it up:

"Emergent architecture is used for understanding and extending complex systems, which have arrived at their state through an unknown path."

NOTES

https://richardwbown.com/build-now-vs-build-later-upfront-design-vs-implementation-costs/

https://richardwbown.com/beating-the-monolith-understanding-modern-software-delivery/

https://www.bol.com/nl/nl/f/domain-driven-design/9200000002151217/

https://richardwbown.com/defining-the-bounded-context-is-the-key-to-flow/

https://thenewstack.io/what-we-can-learn-from-twitters-outages/

QUOTES

01:25 - "emergent architecture is a smart way to say we built something and once we had a plan, but now we have to change it" [RB]

01:52 - "Documentation is of use in order for software archeologists to discover the business motivations for why we're built that way in the first place" [RB]

02:22 - "This is the very definition of the sunk cost fallacy. Those that have invested so much financially, emotionally, and reputationally, that they must double down on that approach until it's either universally accepted or until it's dead in the water. This approach, I call the "Abyss of Obsession", and it's a social construct" [RB]

03:19 - "it's important to dream big. We're all capable of it, and software is the perfect scaffolding for these dreams" [RB]

04:46 - "If you've ever tried to reverse engineer a system, then you will know that a complex system is exactly that, often intractable" [RB]

05:39 - "what you see from typical software projects is that either zero sum or significant upfront planning or design is made" [RB]

06:46 - "I call this cost to first 'gotcha'. The moment where we think, oh no, we forgot this fundamental thing" [RB]

08:07 - "Do not let our ideas become code." [RB]

09:41 - "Emergent architecture means that things change. We can be resilient to change, not just with how we build our applications physically, but also by expecting things to need to change." [RB]

10:30 - "This is why a legacy system is really every system we ever build" [RB]

11:03 - "I believe that just like a good domain model, we already have enough or perhaps too many words to describe the patterns that we see in enterprise systems and architecture." [RB]

12:02 - "Emergent architecture is used for understanding and extending complex systems, which have arrived at their state through an unknown path." [RB]

Dani Grant from Jam talking about Building Better Bug Reporting

Mon, 06 Mar 2023 09:00:00 +0100

I talk to Dani Grant, the CEO and co-founder of Jam about their browser-based bug reporting solution and how it improves the bug-fixing experience for all those involved in reporting, triage and development. We discuss what challenges that Jam has faced in growing their product to 15k users with a small team of just 7 people and what the future might look like.

We talk about Jira, enterprise bug tracking and continuous engineering improvement when it comes to technical debt. We talk about working as a start-up and the challenges it brings when it comes to legacy architectural decisions as well as ways of improving code quality.

LINKS

JAM website

A link I like about MongoDB:) MongoDB is Web Scale

QUOTES

[01:23] "What we found holding us back is all of the miscommunication and back and forth. Bugs and fixes with engineers." [DG]

[02:11] "A screenshot is such a low-fidelity way to communicate something happening on the web" [DG]

[02:41] "with Jam, We try to get all of the relevant information for a developer all packaged into one link so they have all the information they need to debug right away, no back and forth needed. So it's one click to screenshot or record a video or instant replay, a bug that just happened and we grab a crop screenshot that you take plus the full screen. So all the contact you may have missed, um, plus console logs, fully inspectable network requests, and all the specs of the device and the browser and the operating system and even what your network speed was." [DG]

[04:36] "the first thing we wanted to do was just validate that this was not only a problem that we experienced as product managers at CloudFlare, but that this was a problem people experienced industry-wide" [DG]

[05:51] "we were really inspired. The story of Foursquare, the CEO bought himself a Learn PHP book, taught himself PHP to build the first version, and so we, we loved that story and, and wanted to emulate that." [DG]

[06:31] "we were very excited about the new technologies we could use to solve this problem. So we chose things like Kubernetes and GraphQL, and let me tell you that a couple years later, if there's ever any issue in our product, it is caused by one of the not boring technologies that we chose, like Kubernetes or GraphQL." [DG]

[08:08] "Boring old SQL comes to the rescue again" [RB]

[09:27] "Small team of seven. One thing we learned at CloudFlare is when something is important and you want it to go faster, it's actually better to have fewer people on it." [DG]

[10:51] "to be honest, the product managers, the support team members and the QA testers who are reporting bugs to engineers are just as frustrated. It's a communication problem, so it really has to be solved on both ends." [DG]

[12:36] "actually what we're seeing is that a lot of teams are sending jam to their customers and saying, we can't reproduce the bug you just reported. Please log it with this tool and then we'll be able to action it" [DG]

[18:07] "there's a lot of focus on engineering teams about how to, how to improve productivity, and there's a lot of talk about tooling. There's a lot of talk about collaboration with other teams. These things are awesome but I think that the bug reporting process has huge inefficiencies" [DG]

[20:02] "we realized we needed to build something that would improve the Jira experience from the inside out" [DG]

[24:00] "we feel like we're just getting started. There's so much to be done and I'm really excited about the future." [DG]

Observability Engineering and Customer Needs with Stephen Townsend

Tue, 14 Feb 2023 12:00:00 +0100

Not all engineers are equally invested in understanding what our software is actually doing - should they be and why? Is building a successful software product more than just a technical exercise in observability? How do we get more insights into the business direction of our product? Can we only truly test performance in production and what does that look like?

I talk to Stephen Townsend from Squared Up and the Slight Reliability podcast, all about SLOs and SREs and observability platforms and patterns and trying to predict what our customers want in the future.

This was a really in-depth and wide-ranging discussion and a lot of fun to put together. Hope you enjoy!

NOTES

How To Draw An Owl Meme

Sooner, Safer, Happier - Jonathan Smart

Observability Engineering - Charity Majors et al

Accelerate - Nicole Forsgren et al

Slight Reliability with Joey Hendricks (performance testing in production)

QUOTES

[03:19] "I've just come from a massive enterprise before and there was a massive disconnection between the day-to-day work or what's, what's on the minds of the people in those engineering teams versus the actual customers and the business." [ST]

[13:55] "It's a measure of how well you can understand and explain any state that your system can get into no matter how novel or bizarre" [ST quoting "Observability Engineering"]

[14:30] "now we're serverless and containers and all these ephemeral objects and well, they're being scattered everywhere. It's just hard to know what's happening" [ST]

[18:13] "investment in the customer experience for some is greater than for others" [RB]

[23:08] "Hey we are making technology changes. How does it change these other things?" [ST]

[25:37] "it's very weird to come from an engineering background and be talking about all these business objectives and things, but it's great" [ST]

[27:46] "if you're doing software observability, it needs to be thoughtful and continual. Like it can't be. We've set it up, we are done." [ST]

[34:33] "The most successful companies are doing that right now, and they're doing, they're following the best practices that we read about in all these great books, accelerate, et cetera, and DevOps handbook" [RB]

Continuous Delivery, Platforms as Product and Value Stream Mapping

Tue, 24 Jan 2023 12:00:00 +0100

I talk to Jacob Lafors about his company, Verifa, as well as their approach to engagements around platform engineering, CI/CD and how he provides a value stream mapping service to clients. We talk about developer platforms and turning the developer experience into an internal product.

NOTES

The blog where inspiration for this podcast episode came from:

https://verifa.io/blog/unlock-your-continuous-delivery-potential-vsm/

Team Topologies:

https://teamtopologies.com/

DORA Metrics:

https://cloud.google.com/blog/products/devops-sre/using-the-four-keys-to-measure-your-devops-performance

Getting Naked:

https://www.amazon.com/Getting-Naked-Business-Shedding-Sabotage/dp/0787976393

CodeScene:

https://codescene.com/

https://codescene.com/blog/author/adam-tornhill

QUOTES

[07:20] “How do we build a process that helps bring value to the company?” [JL]

[10:04] “[CI/CD setup] It's really gonna depend on who you have in your team, your team size, the organization that you're part of as well” [JL]

[12:18] “The social technical side of software development is really coming to the fore now. I think it's not a moment too soon” [RB]

[13:02] (TT and Conway’s Law) “the way those technical decisions are made are so heavily influenced by the way the organizations and the teams around us are structured as well” [JL]

[13:20] “ And I think where that, that, that, that is going is, is more on the, the, the idea of platform engineering now” [JL]

[16:41] “and the reason why I don't get so annoyed when I hear these buzzwords because I think there's more to it than that.” [JL]

[18:09] “ if a platform team does extra work to cater for two people, it means that, or two personas, it means that those two personas have less work to do and that's much more scalable that one central team does the upfront work.” [JL]

[18:37] “you don't need to know Kubernetes. You can see the, the resources and you know, you can see one is green and one is red” [JL]

[21:00] On IDPs and product thinking: “getting that product mindset is, it's not difficult if you, if you've been building products before” [JL]

[24:03] “ the problem we're solving is that we don't want the teams to have to manage and maintain all their own Kubernetes clusters” [JL]

[24:49] “usually the bigger the company and the bigger the teams the general level of competence that you can assume does go down a little bit.” [JL]

[26:15] VALUE STREAM MAPPING

[26:34] “If I was brought in to build some kind of internal developer platform, the first thing I would go and do is to go and run, uh, value stream mapping workshops with the, with the different software teams.” [JL]

[28:00] “So what do you do? Do you, do you create a branch? Do you start hacking, coding? What about when you get to, to use version control? and how's your merging process?” [JL]

[31:37] “if you're scared of losing your, your work or your contract or whatever because of what you're say and what you do, then, then, then you're not, you're not getting naked.” [JL]

[32:52] “I was kind of going through a funk at the time where I was like, continuous delivery is seen as a, again, as a hammer.” [RB]

[33:27] re: Continuous Delivery “there is no endgame and time is finite” [JL]

[34:07] “But I feel like for the justification value streams are very good because they produce this data for you.” [JL]

[34:51] “the DORA metrics are good. I wouldn't bother creating my own metrics just for the sake of having my own metrics” [JL]

[35:39] “I would know that if, if our business is very volatile and maybe we're quite young and you know, we need the product market fit and these sorts of things, then I would know that our key goals would be for changeability and, and adaptability and so on.” [JL]

[37:45] “You know, me and me and Bob over there, we got together and drew a value stream but didn't really help us.” [JL]

[37:57 ] “it's not just the diagram that's the value, it's the process of creating it, the process of getting people to talk, the process of, you know, that involvement with the team.” [JL]

[39:10] “Well if your code doesn't change, then, then why are you cleaning up all these code smells?” [JL]

[40:57] “the DORA metrics aren't goals. I mean they don't tell you what to do.” [JL]

QUEST: Do We Still Need Agile in 2023?

Sat, 07 Jan 2023 15:00:00 +0100

It's 2023 and just like any year, your timeline is awash with good intentions and lists of things that you can do this year. You might even be writing a list - but what is the good of a list if you never look at it and it's too big to comprehend in the first place?

I use this episode to relaunch this channel as "Lovin' Legacy" - because I love legacy code and I'm not afraid to say it - and also to poke at the lists that the Agile Manifesto, John Romero and Gene Kim (and others) have made for us.

Can we make sense out of the true core of software development - can we focus on just a few things?

I hope we can.

I unpack or at least uncover my own acronym called QUEST, which is all about making the software and team sing from the same hymn sheet. Let's start 2023 together with a bang. Hope you like this episode and the rebrand - let me know in the comments!

NOTES

The Agile Manifesto

https://agilemanifesto.org/

John Romero's 10 Programming Principles:

https://www.youtube.com/watch?v=IzqdZAYcwfY

Gene Kim's Five Ideals:

https://richardwbown.com/software-engineering-happiness-the-five-ideals/

How Does Legacy and Tech Debt appear?

Thu, 08 Dec 2022 08:00:00 +0100

Legacy and tech debt are a fact of life in all software. So how can we identify the major causes and try to limit them in our development process?

This time I discuss the major causes of tech debt and put forward a way to deal with them at various levels in your organisation. Writing software is an intensely human activity and we'll deal with the factors that making writing perfect software next-to-impossible. For at least us humans.

NOTES

https://richardwbown.com/team-topologies/

https://richardwbown.com/ddd-refactoring-and-legacy-code/

Join my workshop on January 17th 2023:

https://richardwbown.com/embracing-legacy-and-tech-debt

The Power of Test Driven Development (TDD)

Fri, 25 Nov 2022 09:00:00 +0100

Before I read the book by Kent Beck I was just thinking - pesky tests what are they good for apart from getting in the way? What’s so good about Test Driven Development?

But writing tests isn’t what test-driven development is about. It's actually about designing your code in a way that matches your expectations. It's a powerful technique that, when understood, will transform the way you write code and design software.

NOTES

Kent Beck - Test Driven Development By Example:

https://www.amazon.com/Test-Driven-Development-Kent-Beck/dp/0321146530

Github template repository:

https://docs.github.com/en/repositories/creating-and-managing-repositories/creating-a-template-repository

QUOTES

00:54 - "Because TDD is not about driving development through testing. It's about designing and architecting your application. Through writing tests." [RB]

02:12 - " I find myself going backwards and forwards, making sure I understood every single step and what it meant in that first section." [RB]

03:26 - "And so you carry on writing some more code. And eventually the whole thing becomes a great big ball of string. Lots of code and no tests." [RB]

04:06 - "It's more of a tool for a structured approach to design in the first place. " [RB]

05:07 - "Writing a test helps show that it works. In fact, the word test is really wrong here. It's more of a proof than it is a test." [RB]

06:06 - "Writing code in TDD can initially feel slow and labored but in only a short time, you'll start to notice the benefit." [RB]

06:36 - "This is almost like the reverse Conway maneuver to Goldratt's theory of constraints." [RB]

08:02 - "Whatever we do, there has to be a low barrier to entry for testing." [RB]

08:42 - "And this is the true power of TDD, rather than agonizing over design and architecture and advance" [RB]

09:12 - "TDD is an absolute no brainer" [RB]

Legacy Code: Sunk Cost or Opportunity?

Fri, 18 Nov 2022 09:00:00 +0100

Why do we love to build new code when we have plenty of good software that already works? Is the platform language or framework legacy? Is it because we want to learn a new skill? Is it because we are just bored of supporting the old software?

I aim to persuade you that before you decide to rewrite even part of your application in a new language or framework, you can profit by making your existing code and existing deployments better and your organisation stronger.

In this episode I equate Legacy and Tech Debt - they're the same thing at different scales - and I see them both as an immediate problem. As soon as you've written something you've incurred it. As soon as you've deployed it, you've incurred more. The attitude your engineering organisation takes to your codebase and your supporting systems speaks of your attitude to tech debt and legacy. If you can keep your code and your systems alive through constant attention - then you minimise the effects of the debt, and you minimise the chances that something becomes legacy.

This was originally presented just this week at the ctocraft conference and I'm refining it in public as I go. Please let me know what you think and if my assumptions and potential conclusions are valid.

NOTES

Link to slides:

https://richardwbown.com/wp-content/uploads/2022/11/Legacy-Code_-Sunk-Cost-or-Opportunity_.pdf

Link to ctocraft conference: https://ctocraft.com/

Link to my book list with the books mentioned: https://richardwbown.com/resources/

QUOTES

00:44 - "I equate legacy and technical debt to be the same thing at different scales " [RB]

02:02 - "Wikipedia it has 15 categories of technical debt" [RB]

02:27 - "Everything, every decision that we make incurs technical debt." [RB]

03:19 - "it's always going to be built-in and assumptions around how we actually wants our software to do stuff" [RB]

05:59 - " things only get complicated, of course, when we want to get users involved" [RB]

07:07 - "our CI and our CD tools require configuration they require metadata. And a lot of the time we perhaps underestimate the amount of time that we have to spend in configuring these tools to be able to deliver what we want" [RB]

07:19 - "Even with this simple pipeline, it becomes complex very soon" [RB]

08:26 - "We want those teams to be able to work in that best possible way" [RB]

08:59 - "And this is the essence of cognitive load. How can we take the stress away from the team so they can really perform at their best and provide a service, which our customers will love." [RB]

09:24 - "Technical debt is what you feel the next time you want to make a change" [RB quoting Ward Cunningham]

10:17 - "Something goes into production means we have legacy immediately." [RB]

11:30 - "Legacy is also everywhere. In the enterprise, in the scale-up or in the startup and every major or minor decision we make" [RB]

12:55 - "So often it's simpler for us to just ignore it. We put our heads in the sand" [RB]

14:31 - "you must have a realistic plan to get to a new technology or get to a new application" [RB]

16:25 - "if legacy is immediate, then engineers should always be invested in supporting business value. So how can we make that feeling happen?" [RB]

17:07 - "everything that we do on a daily basis means value for customers. How can we achieve that feeling?" [RB]

Does Continuous Delivery Have an Image Problem?

Fri, 11 Nov 2022 09:00:00 +0100

Sparked by a short Twitter exchange, this time I investigate why a lot of CD implementations (that I've come across) often appear to be half-complete or just fail to achieve CD. What are the root drivers behind achieving CD and why do so many implementations fall short? Is it just ME?

It's a hard subject and one that I've debated with quite a few people. This episode is an exploration of a few themes and perhaps can offer some insights or perhaps is still a work in progress. I certainly have a few more avenues to explore around where the application stops and the CD implementation begins - plus should you design your CD implementation with that in mind.

Really interested to hear your thoughts.

SHOW NOTES

My book list including links to 'Accelerate', 'Continuous Delivery' and Domain Driven Design

https://richardwbown.com/resources/

The original tweet:

https://twitter.com/BryanFinster/status/1587589240321626113

Original post with my quote and Bryan’s discussion of it:

https://riseandfallofdevops.com/5-minute-devops-cd-is-pointless-5c906d0fd164

Bryan discusses many things including “Engineer for Release” on the No Nonsense Podcast:

https://richardwbown.com/bryan-finster-continuous-delivery-no-nonsense-podcast/

QUOTES

02:19 - "in my experience over 25 years working in software on it, I've rarely seen an organization successfully deploy a consistent CD implementation across the whole org." [RB]

02:52 - "continuous delivery is often seen as a holy grail for a firm's digital transformation" [RB]

04:42 - "the organization types should be Westrum generative. That it should be a nurturing, encouraging high cooperation organization" [RB]

05:16 - "So my point is most orgs don't support the concept of CD because they don't change. " [RB]

06:02 - "Because as every good book on the subject says without fail, there is no one size fits all solution for any of this. Plus it takes a lot of work on the journey is really, never complete. " [RB]

07:16 - "Most organizations are not software delivery centered organizations. There's just something that they have to do" [RB]

09:36 - "Pride gets in the way when it comes to building software, but also CD pipelines." [RB]

11:10 - "CD typically is created by a few heroes who understand that complex domain." [RB]

12:34 - "Similarly for CD, perhaps that's too lofty a goal to aim for directly. If we look at this huge program of work that we take on when we start to implement CD." [RB]

14:07 - " where does. the application stop and where to CD begin. But that's a, that's a topic for another time I believe." [RB]

15:47 - "engineering for release, which I really love. This is the concept that you're building your release mechanism even before you've built the first line of code." [RB]

16:01 - "Before you even write a test or a single line of code, you write your pipeline" [RB]

Is Legacy Scary? Or Is Building A New Software Product Scarier?

Fri, 28 Oct 2022 09:00:00 +0100

What is legacy? What does it have to do with building new software? Why does it annoy us as software developers? Why does it worry us as business owners or product managers? Why do we ignore it as forward-lookers? What’s so great about technology anyway that makes us do this?

What exactly is legacy? I believe that legacy software is not always the evil, boring thing that we believe it to be - and that before you decide on building a new software platform or product you should go through a process to define and refine your legacy and decide if building new is right for you.

In this episode, I introduce some concepts about categorising and understanding your legacy systems.

[[OR LeTS ReTIRE tHE MoNOLIth!!]]

QUOTES

01:09 - Step one for me is categorize your legacy under understanding the landscape. [RB]

01:15 - If you have a system which is just not being used anymore, it's not legacy, that's just obsolete. [RB]

02:23 - your company could be bearing its head in the sand and building something new to avoid looking at the real legacy problem. I call that ostrich legacy [RB]

02:52 - This isn't a simple exercise. It is a strategic one to help you understand where you want to go with your business [RB]

03:32 - The amount of investment or sunk cost made in a software product often puts us off from continuing to support it [RB]

04:00 - This is the sunk cost fallacy fallacy. You had an idea that replacing what you had would somehow be a magical solution to all of your ongoing support and staffing issues. [RB]

04:27 - But let's look at some of the other lies that we tell ourselves about new products. [RB]

04:52 - We will finally be able to retire the monolith, and that is the real hum dinger. [RB]

06:21 - We have heard good things about Kubernetes. We have been told that we need to cut costs. [RB]

07:12 - There is a hidden complexity in bringing something to market. and this is the 80 20 rule [RB]

07:46 - So rather than thinking about the sunk cost fallacy, think about the cost of ignoring legacy [RB]

08:28 - It's a good idea to revisit your legacy categories and your landscape and try and work out how much it will change through the introduction of your new products or service [RB]

09:35 - Take the time to continuously refine your picture of what makes up your product landscape and don't be afraid to make changes [RB]

10:33 - Let's see how Elon Musk get on with his attempts to make Twitter a better platform. If you look at how that product has evolved, perhaps there are a few legacy products and systems there that he might want to think about. [RB]

A Manifesto for Better Software Delivery

Fri, 07 Oct 2022 09:00:00 +0100

An increasing number of businesses are now actually (at least partially) also software businesses. Energy companies, financial giants, insurers, and retailers – all of them have significant in-house developer populations numbering in the thousands or tens of thousands. These companies commission, buy and even build their own software. And these are not small or insignificant efforts. They are huge in many ways, interconnected through corporate IT as global IT infrastructure. It is hard to run and support all of this software using existing techniques.

Tools and techniques are often fighting against what it means to be a software developer and provide little real value to the business either. It's time to reevaluate. It's time to take a new approach to how tools and techniques are applied in the industry when it comes to software delivery.

SHOW NOTES

https://richardwbown.com/a-manifesto-for-better-software-delivery/

Global IT budget : https://www.zdnet.com/article/cloud-computing-security-or-more-developers-heres-where-the-tech-budget-is-being-spent-next/

QUOTES

00:44 "Building running and supporting software is hard. It's complicated for individuals and software companies alike" [RB]

00:55 "An increasing number of businesses are now actually at least partially, also software businesses" [RB]

01:33 "Everyone on the boards of these companies should be aware that building and delivering software is a difficult creative and fundamentally human process that they are undertaking." [RB]

01:48 " Existing accepted techniques of project management have evolved when dealing with more predictable, externally managed vendor-run projects. " [RB]

02:27 "The current patterns of agile lean and DevOps are definitely not new." [RB]

02:49 "We talk sprints and time boxes, like we know what they mean."

02:53 "The tools market alone is worth hundreds of billions of dollars annually" [RB]

03:32 "Crazily most of these expensive tools like JIRA, Azure DevOps, github, gitlab, et cetera duplicate or replicate each other's features." [RB]

04:05 "It's therefore insane to just buy a load of tools and think "job done"" [RB]

04:36 "let's ensure that the whole organization understands, that when it comes to building software, all bets are off" [RB]

05:09 "Get the tools out of the way. And back to being what they should be ,solutions to relieve us of the complicated manual processes and not self-justifying parts of the process themselves" [RB]

Making Software More Sustainable with Tom Kennes

Sun, 02 Oct 2022 09:00:00 +0100

I talk to Tom Kennes, sustainable cloud consultant and ambassador for the Sustainable Digital Infrastructure Alliance (SDIA). We discuss how IT and software delivery can be more sustainable and what happens when Ronaldo uses Instagram. We also talked about the impact of programming language choice on carbon footprint, the amount of energy used when watching Netflix and how to right-size your cloud infrastructure. Lots to dive into for the techies with tools that are available to measure the impact of the software you build and deliver. The emphasis is very much on making small changes that add up to a big difference, so there are some really practical tips here for individuals and organisations.

SHOW NOTES

How to join the SDIA:

https://SDIA.io/join

More on the the SDIA: https://sdialliance.org/

The Cloud Carbon Footprint Calculator: https://www.cloudcarbonfootprint.org/.

The most efficient programming languages:

https://cryptomode.com/c-is-the-most-energy-efficient-and-fastest-programming-language-study-finds/

AWS and Software Power Measurement

https://medium.com/teads-engineering/estimating-aws-ec2-instances-power-consumption-c9745e347959

Scaphandre: https://github.com/hubblo-org/scaphandre

RAPL: https://blog.chih.me/read-cpu-power-with-RAPL.html

Solar-powered website: https://solar.lowtechmagazine.com/

Instagram footprint for Ronaldo - actually a lot larger than Tom stated: https://www.gosports.com.my/news/high-energy-one-ronaldo-instagram-post-consumes-as-much-power-as-ten-households/

1 hour of Netflix - newer research suggests lower numbers than Tom stated: https://www.carbonbrief.org/factcheck-what-is-the-carbon-footprint-of-streaming-video-on-netflix/.

- Carbon Innumeracy. People tend to underestimate the amount of CO2 from a gallon of gasoline a lot: Amir, G. Carbon innumeracy. PLOS ONE 2018, 13, e0196282. https://www.researchgate.net/publication/324932129_Carbon_innumeracy/link/5aebc7ea0f7e9b01d3e0652f/download

QUOTES

2:05: "I think sustainability is, overall the best thing you can do. Anything that's more sustainable will, in the end benefit society." [TK]

4:05 "First you think cloud is a good thing, (and) cloud is a good thing. Then you notice that there are some, oddities in there. They notice that why aren't we tackling those things?" [TK]

4:33 "he real question here is how can we incentivize companies to start reporting on their digital footprint?" [TK]

4:49 "cloud is the least welcome environment where you can measure these things" [TK]

5:11 "sustainable IT attempts to enable companies and developers to start reporting on their GHG emissions, their carbon footprint, their energy consumption" [TK]

5:25 "if you can enable developers to incorporate their footprint in their decision making, you are enabling such a large workforce to do more green, to do better in that context" [TK]

7:30 "the easiest thing you can do, which also saves you money in the end, is just right-sizing your cloud basically." [TK]

8:27 "There's quite a famous kind of league table of programming languages and showing how green they are in comparison or how much energy they use." [RB]

9:11 "python has a energy consumption as 80 times that of C#" [TK]

12:41 "[The SDIA is] one of the biggest nonprofits in the European Union that focus on sustainable IT" [TK]

13:09 "in the end it's about showing that you care for the environment, which it's something that investors are looking more and more for" [TK]

15:36 "there is this one tool which focuses on performance monitoring counters . Which basically directly come from a CPU and say how much energy a CPU is using. " [TK]

16:33 "You can deploy it on your Kubernetes cluster that exposes metrics to Prometheus that you can use from there. They also have some other tools as well that they use to even calculate embodied carbon" [TK]

18:03 "It really brings this quite abstract idea of the sustainable IT into an everyday life of engineer developer." [TK]

18:39 "if you look at the total energy consumed by IT we are somewhere at six, seven, 8% of the total energy consumption" [TK]

19:17 "if we were to change our ways, we can actually solve quite a big part of this puzzle next to, of course, supplying the tools to make other sectors as, as well more sustainable" [TK]

19:57 "there have been predictions that put an hour of Netflix equal to 30 kilometers of driving on an electric vehicle" [TK]

20:34 "Ronaldo, when he posts a picture it's often seen by about 300 million people. The overhead in terms of energy consumption that is implied there is about equal to the yearly consumption of one Amsterdam household." [TK]

21:30 "So it's incredible how little we actually know about our daily life carbon footprint, or emissions" [TK]

Putting the Product back in the MVP

Wed, 07 Sep 2022 09:00:00 +0100

When was the last time you did a Minimal Viable Product that was actually minimal? How often do we get it right and truly focus on delivering something of value to the customer?

On this week's podcast, I riff on the idea of how to get a true MVP, not only past the idea stage, but into production no matter what type of company you are. By looking at the constraints that we have in play at any one time, we can determine before we get started with an MVP how it might be rolled out.

We also touch on the importance of marketing for your MVP and/or product – and ensuring that you have a customer base that wants it before you get there. How you can even use your compliance journey to road-test your idea.

Join me for this discussion and, as always, let me know your thoughts about what’s gone wrong and what's gone right with your MVPs!

SHOW NOTES

This show inspired by some systems thinking, some writing and also the theory of constraints.

https://richardwbown.com/how-the-mvp-has-lost-its-meaning/

https://en.wikipedia.org/wiki/Theory_of_constraints

https://richardwbown.com/approvals-come-first/

QUOTES

00:49: “Much is made of the MVP, the minimal viable product. But so rarely is it executed in a meaningful and valuable way.”

02:02: “Using an MVP to road-test new tech is not always a smart move.”

03:19: “architecture just means big decisions that you're probably not going to undo later.”

03:59: “There is a tension here between architecture and MVP”

06:35 - “By narrowing our proposal for our MVP. We stand a greater chance of getting it approved and rolled out in order to gather feedback”

07:28: “The reasoning behind the processes that build up around change control are all there for sensible reasons.”

08:15: “Whatever of path is open to you, your MVP won't deliver unless it has users”

08:49: “Don't leave the marketing to last or as an afterthought. And this applies not just to startups or individuals, but also to the scale-up or corporate world”

Between Product and Engineering

Tue, 23 Aug 2022 09:00:00 +0100

In this episode we explore the way that technology, tools and architecture can affect the product that you are building. As engineers do we need to think more about product side? As product marketers what can we do to understand how the technology choice informs or limits our product possibilities? How do we deliver software in an open source project vs how do we deliver software in a corporate banking environment? What are the constraints that we need to be aware of in our decisions and how the customer need informs that. How we need to enjoy what we’re building - and make sure that we continue to enjoy building it as an individual, a team or as a company.

Once again I really enjoyed recording this one and asking myself some hard questions. Perhaps you have more questions that from it? Please get in touch with me via the Software Delivery Club. I’d love to hear from you!

https://softwaredelivery.club

SHOW NOTES

Dave Farley - Modern Software Engineering (https://twitter.com/davefarley77):

https://www.amazon.com/Modern-Software-Engineering-Discipline-Development/dp/0137314914

April Dunford’s Obviously Awesome (https://twitter.com/aprildunford):

https://www.aprildunford.com/obviously-awesome

Rosegarden Linux Audio and Midi Sequencer and Notation Editor:

http://rosegardenmusic.com/resources/authors/

You can also download a compilation of my best blog posts in PDF form. I call it:

A Systems Approach to Software Product Delivery

Getting your Evenings and Weekends Back

Tue, 02 Aug 2022 13:00:00 +0100

Making software is fun. Running software can be less fun. How do you do both and not go insane? How do you make sure you're not working all the time to keep your (virtual) baby up in the air?

The same rules apply whether you're a startup, a scale-up, a corporate, an individual, an open source project contributor. You're part of your own support problem.

This time I discuss what it's like to be a coder who wants to have it all - the good times and the bad times - but wants to limit the bad times to working hours only. I hope you enjoy it as much as I made recording it.

NOTES

XKCD 242 - The Difference:

https://xkcd.com/242/

Brian Scanlan about Intercom's approach to on call.

https://www.intercom.com/blog/rapid-response-how-we-developed-an-on-call-team-at-intercom/

And he talked about this recently on Adventures in DevOps:

https://topenddevs.com/podcasts/adventures-in-devops/episodes/reducing-on-call-engineer-burnout-with-a-volunteer-management-infrastructure-devops-121

Inspiring music that helped me write this:

https://en.wikipedia.org/wiki/Milk_%26_Kisses

https://en.wikipedia.org/wiki/Reading,_Writing_and_Arithmetic

QUOTES

01:25 - How did it feel the first time you wrote something in a computer language that maybe you just learned and it worked perhaps first time

02:50 - We're in that space where creation is flowing. But at some point reality bites. Then we need to do something with this thing that we've created.

5:05 - What is happening tonight? Mummy, why can't we go out to the zoo this weekend? I know guilt right. The point I'm really laboring here is that one should be proud of your creations.

05:18 - All of our creations need us. All of these things are calling for our time.

06:48 - Some of the most successful systems on the planet have been built on a knife edge of functional validity.

07:43 - Your job is therefore to minimize that risk and ensure that you can roll back or fix forward with the least possible effort.

09:21 - Be aware of your legacy as a coder. Think carefully about how your persisted data will be managed.

Welcome to Software Delivery Club – The Reboot

Thu, 21 Jul 2022 09:00:00 +0100

Welcome to the Software Delivery Club.

Every week, we explore different aspects of the business of delivering software into production. Talking to industry experts about how they get to keep their production software running, whether you build or buy, how they cope with new features and product changes, how they keep their customers satisfied while also keeping themselves and their engineers happy, what tools like they like and which ones they don’t as well as tales from the front line when it comes to delivering and supporting production grade software.

NOTES

This is the reboot of the podcast that used to be called "Automation for the Nation". The old episodes are still relevant but now we have a new name and new purpose.

QUOTES

00:39 "Software delivery club is the new name of this podcast." [RB]

00:42 "It used to be called automation for the nation. While it's not a complete reboot in terms of content, I wanted to draw the line in the sand between what I was trying to do a few months ago and where this podcast is now." [RB]

1:35 "the true magic we're looking for, I believe is at the intersection of software development practice, product and pragmatism." [RB]

02:51 "How do you improve your product, support customers and stay reliable? Software delivery club is about that." [RB]

Thinking in Systems & Change Management

Mon, 04 Jul 2022 17:00:00 +0100

How do we manage change? Assessing urgency and what does it mean when no-one is owning a (technical) systems problem? I talk about this common problem with projects and systems and how we can resolve it, touching on Incident Management and Product Ownership.

Secondly, I spend a few minutes talking about the book “Thinking in Systems: A Primer”. This is a classic text which describes in simple terms how interactions between systems can get so complicated. Great for those who've not thought about systems interactions before and need a basis for understanding how complexity can appear very quickly.

NOTES

Brief review of "Thinking In Systems: A Primer":

https://kislayverma.com/books/book-review-thinking-in-systems-a-primer/

Resources for understanding Change Management (ITIL) and Product Ownership (Scrum)

Change Management and the IT Infrastructure Library (ITIL):

https://en.wikipedia.org/wiki/ITIL

IT Service Management:

https://en.wikipedia.org/wiki/IT_service_management

and within that, IT Incident Managment:

https://en.wikipedia.org/wiki/Incident_management_(ITSM)

What is a Product Owner?

https://www.scrum.org/resources/what-is-a-product-owner

QUOTES

"Now, when I speak to those who tell me that they have a ‘systems problem’ it’s like they’ve almost self-diagnosed. They know that they have a problem but they also seem to be able to tell me almost how I can help them fix it for them. " [RB]

"Don't assume that a change to any system will fix a given problem without causing another problem, too. Don't assume that things work like they say they're going to work" [RB]

"Incident Management is a process whereby you can get your systems back on track with respect to a situation with any given system" [RB]

"the very act of fixing systems in itself requires a system and a process" [RB]

Positioning Your Business Through Better Systems

Fri, 17 Jun 2022 15:00:00 +0100

EPISODE SUMMARY

This week I talk about how to position your business through better systems. How to understand how important you are at the core of the message to your customers and how you can build a system of positioning that will allow you to play with marketing messages and land on what works best for you and your ideal client.

What systems do you need to support your positioning and marketing efforts and how they can help you understand what's working and what isn't.

EPISODE NOTES

Inspired by lots of reading and writing to create this podcast episode but mainly in reaction to positioning books and what I've learnt from Value Based Pricing and orienting yourself to favour the client over yourself.

Building a Story Brand: https://buildingastorybrand.com/

Obviously Awesome: https://www.aprildunford.com/obviously-awesome

Jonathan Stark Value Based Pricing bootcamp: https://jonathanstark.com/vpb

The main message is "don't forget yourself" in the rush to build a business that you think is the right one. Client doesn't come first when you're the one that's in charge.

Also in the recording I call the episode "Marketing Your Business Through Better Systems" but afterwards I changed my mind - this is so much more about Positioning than it is Marketing.

QUOTES

"How can you build it so that there is a funnel of work waiting for you every time you want to dip into it?" [RB]

"Finding your customer is essential. Differentiation is the core of your message. And your story must make sense." [RB]

"This is a six point list which enables you to turn your ideas into your business." [RB]

"The systems and automations or flow from the core decisions you make these will influence your systems and processes." [RB]

"Using analysis and tools such as MailChimp, or ConvertKit, you'll be able to see open rates of your emails, you'll be able to segment your market into locations, age ranges, demographics, perhaps, you'll be able to tag user behaviours" [RB]

Systems are a Sales Opportunity (or Having The Systems Conversation)

Fri, 03 Jun 2022 09:00:00 +0100

EPISODE SUMMARY

When you first get a taste for working in a company you think you can change the world.

Eventually you realise that the world is just fine and it's you that needs to change - and sometimes this can take a long time. When you have a business and you want it to move quickly, grow and adapt, what things can you do to make sure you're maximising your opportunity?

This week I talk about the past and the future and discuss how your systems could be holding you back or limiting your success. I also discuss the Systems Conversation as a way of making sure that keep agile, keep pushing the boundaries of what is possible rather than just settling or having to make do with continuous bad news.

EPISODE NOTES

This week I was mainly riffing on new ideas so no links to share except the books that have perhaps inspired me:

QUOTES

"Systems are there to help us but they can very quickly make our businesses less agile, less able to compete." [RB]

"So make sure you have a systems conversation regularly." [RB]

"Understand what is constraining you and your business as well as what could help you." [RB]

"Without realising regularly the opportunities that your systems can afford, you're not taking full advantage of your size or scale." [RB]

"Systems are there to help you leverage. So have that conversation, even if it must be with yourself and understand what changes you need to be more effective in your next sales conversation." [RB]

How Finance Directors Drive Strategy Through Systems

Fri, 20 May 2022 12:30:00 +0100

EPISODE SUMMARY

What do Finance Directors (FDs) have to do with successful projects in organisations of all sizes? They control the purse strings, but they also control what happens and when. So can you have successful projects without FDs buying into the strategy for your business?

This week I explore this topic in brief. I also ask you to tell me what you love and what you hate about Excel and ask, is it all over your business?

EPISODE NOTES

QUOTES

"how vital it is to plan, 1, 2, 3 or possibly 5 years in advance for your systems and how pivotal a role the FD plays in that discussion" [RB]

"Excel. Like it or loathe it, it’s there in our organisations and it plays a large part in both finance and general administration processes for all of our departments" [RB]

"Systems get to end of life and need to be replaced, it’s natural to postpone these activities for as long as possible often due to BAU concerns. So work these into a strategy." [RB]

Interview with Ingrid Lill - Brand Consultant with a Pencil

Fri, 13 May 2022 17:00:00 +0100

EPISODE SUMMARY

This week I'm talking drawing with Ingrid Lill.

Ingrid is a Brand Strategist with a Pencil who use Visual Thinking techniques to help her creative and entrepreneurial clients understand who they seek to serve.

I wanted to catch up with Ingrid after she helped me out with my positioning using her visual thinking techniques to sketch my 'ideal customer' and I realised that this wasn't my ideal customer at all. I talk to her about how she got started with visual thinking and how she has grown her brand and who she works with from CEOs of software companies to non-profit groups to entrepreneurs.

We speak about her background, her methods and technology as well as how using visual techniques help when it comes to deciding on a client, product or service offering for your business.

We also talk about how this works in a group setting and niching down on products and services.

EPISODE NOTES

Some more about Ingrid.

Ingrid's template is here and here is an example storyboard

And a link to Ingrid's course Find Your Message.

Donald Miller "Building a Storybrand"

Tim Urban. Wait but why?

QUOTES

"I am the guide who is helping them with my very specific product, which I call a game changer because it's much easier to communicate if you have a specific thing that that you are offering" [IL]

"So I find that personally quite challenging coming from a creative background myself, from an engineering background, well yeah, creating stuff. I like to do new stuff" [RB]

"However, to get it to really fly, I need to be able to put a system in place which enables me to work around it on a day to day basis. I think this is something that both, how can I say, approach in the right way? Personally, I find that I can't do these things in isolation, I have to do them all kind of simultaneously. " [RB]

"If I should define my psychographic people, it's people who have too many ideas. And I help them to map them out on paper" [IL]

“My clients have to be specific about their clients” [IL]

System Mapping & Drawing Happy Pictures

Fri, 06 May 2022 09:00:00 +0100

EPISODE SUMMARY

This episode is all about drawing pictures. Visualise your systems, the inability to visualise your systems and also how to map your business using pictures.

Last week I launched my free email course Know Your Systems. Signing up takes two seconds and you'll receive 6 days of daily content on how to understand and control your systems.

EPISODE NOTES

You can subscribe to my free email course Know Your Systems.

See my blog article on Professional Associations and Systems Mapping.

See Ingrid Lill's website here.

QUOTES

"This is exactly the point of system mapping. Lots of complex information conveyed instantly" [RB]

"Purpose of the picture or diagram in systems mapping is not to be completely accurate or detailed or even up to date." [RB]

"The most important part of mapping is actually deciding what you have and how it works with other systems and generating a conversation" [RB]

"The visual medium is designed to convey a lot of information quickly. It's the fastest way of communicating research" [RB]

The Systems We Don’t See (and ones you've never heard of)

Fri, 22 Apr 2022 12:00:00 +0100

EPISODE SUMMARY

We depend on systems in our life, in our business. Sometimes we don't even know that they exist. This week I'm talking about systems that work well, and systems that sometimes don't work well, and systems that can leave us in trouble if we don't know we depend on them. I also have a pop at Microsoft Excel as well as GitHub!

I'm also celebrating the launch of my 'Own Your Systems' free email course.

EPISODE NOTES

You can subscribe to my free email course "Own Your Systems" by going here:

https://richardwbown.com/own-your-systems/

QUOTES

"Systems that are so built into our ways of working that we don't even realise they're not working, sometimes the ones that we don't miss until they're truly gone" RB

"I was lucky enough not to be a middle manager for a very long time. But when that particular role finally caught up with me, I spent a lot of time preparing reports a lot of time converting things from CSV" RB

"In my consulting business, I use online tools, which are aware of 21st century priorities and ways of working. I use tools which save me time" RB

"GitHub is a great example of a high profile system that you've probably never heard of" RB

Who is responsible? (or the Machinery of Business)

Fri, 15 Apr 2022 12:00:00 +0100

EPISODE SUMMARY

When it comes to our jobs or our companies we have some tasks that we have to do and some tasks that we want to do. But those can be the same on any given day. How do you know? How do you understand someone else's perspective at work? In this episode I'll explore the things we do and the way we do them to understand a little better how we can use the Machinery of Business - the tools we have - to help us.

EPISODE NOTES

If you'd like to create your own continuum of daily tasks then you can use this template to give you an idea of how it works.

As I mentioned in the episode, I found a couple of great Steve Jobs quotes here and here.

https://www.cnbc.com/2019/10/05/apple-ceo-steve-jobs-technology-is-nothing-heres-what-it-takes-to-achieve-great-success.html

https://quotefancy.com/quote/911560/Steve-Jobs-You-cannot-mandate-productivity-you-must-provide-the-tools-to-let-people

You can sign up for the mailing list or get in touch with me from the website.

QUOTES

The Digital Language of Systems

Fri, 08 Apr 2022 09:00:00 +0100

EPISODE SUMMARY

How can we make sure we are all "on the same page"? By speaking the same language.

In this episode I am examining the use of digital language in organisations when it comes to running projects and in our understanding of information systems. How to be more effective when it comes to communicating with stakeholders and what exactly are 'stakeholders' anyway?

I talk about buzzwords, about acronyms and how to keep the project team engaged. I hope you like it and you can also download my free guide to digital language linked below.

EPISODE NOTES

You can download my free guide to Digital Language.

QUOTES

"Technology moves quickly, new words are getting invented all the time" RB

"with information systems and software systems, we can often hear language that we don’t understand" RB

"Speaking digital language can be as daunting as speaking a foreign language." RB

"change sometimes brings commitment" RB

"Anyone who has an interest should be included, and the language you use is therefore important to gain the greatest reach" RB

Zooming Out - From Systems to Conway's Law

Fri, 01 Apr 2022 09:00:00 +0100

EPISODE SUMMARY

I look at the organisation and its impact on your systems - remember that systems are not just what you build or have built for you, it's also the people. Conway's Law and continuous learning can help us make sense of digital transformation.

EPISODE NOTES

Understand that your business needs are met not as a whole, but by individuals and departments. Those individuals and departments shape the systems they use - they create them all the time. Your IT systems and your IT systems change process had better recognise this.

QUOTES

I quote Melvin Conway: "Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure."

"the most important thing you can do before taking on a new software or IT project as an organisation is to zoom out" RB

Be More Scientist

Fri, 11 Feb 2022 09:00:00 +0100

EPISODE SUMMARY

In the last episode we jumped straight into automations and how they can sometimes make our life more difficult. This time we take a look at systems - all types of systems - and understand the human element that made them.

EPISODE NOTES

Since January 2022 I've been thinking long and hard about automation - but it was clear that automation was just a piece of what was making me think. Systems provide opportunities for automation but they can be manual or they can already be 'automatic' or built in IT. So how do we work with systems and understand those which already exist in our business?

QUOTES

" if you're troubleshooting an issue, the best way to understand is to change something, note down the difference" RB

"This applies across the board, whether we're multinational small company, an individual who's looking at their Etsy shop or looking at their WordPress installation and saying, Okay, what can I do to make this better?" RB

"They all have been put together by somebody sitting down and thinking about it, writing down an idea and maybe sharing it with a colleague or a friend" RB

"Learn to understand and explore the systems that have been created for you, they are imperfect, they were created after all by humans, so don’t expect them to work the whole time" RB

The Naming One, Early Automation and Brittle Systems

Mon, 31 Jan 2022 09:00:00 +0100

EPISODE SUMMARY

Before you get obsessed with automation it's worth thinking a little about what you're doing to your systems. Do you even need automation yet? In my first ever episode I introduce some concepts to consider in your automations.

EPISODE NOTES

This was inspired by some discussions on The Business of Authority podcast around the 'Gravitational Pull of Systems' and how it can be hard not to jump straight into configuration.

Inspired me to start the podcast and also write a short blog on Brittle Systems.

QUOTES

"the more you connect, the more that you're kind of building in your business process to that way of working" RB

"don't implement a whole system or automation around that, just to serve five people, because the amount of time you're going to spend implementing it way outweighs the amount of time you're going to spend actually doing that work" RB

"buy out of the box and use out of the box" RB

"do not automate too soon" RB