The Financial Architecture of Software with Ian Miell

Transcript

Introduction [00:29]

Thomas Betts: Hello and welcome to the InfoQ podcast. Today I’m speaking with Ian Miell. Ian has been an engineer for about 30 years. Most recently is a cloud-native consultant and now CTO with Container Solutions. Ian is writing a new book, Follow the Money: Understanding the Financial Architecture of Software, and that’s what we’ll be talking about today. Ian, welcome to the InfoQ podcast.

Ian Miell: Hi, thank you for having me.

Beyond Conway’s Law: Introducing Financial Architecture [00:50]

Thomas Betts: Listeners to the podcast will be familiar with me saying that every software problem is fundamentally a communication problem. We like to talk about the socio-technical factors that influence software, things like Conway’s Law and how the structure of the organization and the communication paths actually drive software architecture. Your book seems to take it one step further. Can you dive in and say if we follow the money past Conway’s Law, where does that lead?

Ian Miell: I cheekily titled a conference talk I did recently, Going Beyond Conway’s Law and it feels a bit hubristic to do that given Conway’s legendary status in the industry. It seems that if you mention Conway’s Law, you automatically win any argument in software engineering. As you say, Conway’s Law states something like the communication structures of your organization constrain the architecture of your system that the organization builds. I didn’t directly want to attack Conway’s Law, but I came to it through consulting and I noticed that when I was consulting with organizations around usually building platforms for their teams, I ended up analyzing them in terms of what I now call money flows.

And this led me to think that Conway’s Law stops at the communication structures, it stops at the communication paths. And I thought to myself, well why do we stop there? What determines those communication paths? And that led me to thinking about how the material aspects of the world ultimately determine the software we build and specifically the decisions we make at a grand scale about the software that we build.

And so that was my idea and I developed that over a few years with some blog posts and some conference talks and it seemed that people were really interested in it, particularly people more closer to my age and my end of the career path. But it seemed that this was an area that engineers were not well-equipped to analyze and that led me to think that my original training was in history, which is a study that is systems thinking to its core.

In the study of history you analyze things in terms of economic and fundamental forces which shape. It is somewhat random acts of individuals, but these acts are also constrained by these forces in the same way that communication paths constrain the architecture of software. And so I built up these ideas over time and then had a couple of false starts trying to write a book on it. Finally, I think enough time had passed. I went to a publisher, O’Reilly, and they were really keen on the book and that’s how I got to where I am today.

Applying a Financial Lens to Architecture [03:26]

Thomas Betts: You said history taught you about systems thinking and I think more architects are learning systems thinking as an idea. And when I started studying this, the first thing that I was taught is draw a context diagram. You come into a new problem, a new situation, stop before you start getting too far into the details and draw the context. Where does that system sit? What are the outside forces at play? And sometimes that’s the user who’s interacting hands on the keyboard or touching their phone or the support team that also has to support it. What I think you’re talking about with Follow the Money is you have to look at where that software system sits inside the context of a company and that there’s all these aspects of what funds the company and what funds the software and how’s the software make money for the company if that’s what it’s supposed to do. Is that the same thing that we can take this context diagram idea and look at it from a financial lens?

Ian Miell: Absolutely. I consult with Container Solutions with companies that are struggling to shift the way they work or struggling to build a centralized platform. They would often come to us with specific questions like, “Should we use Istio or not?” Or, “Which distribution of Kubernetes might be best for us?” They would ask us to come in and do an evaluation of their context. I always start by asking, “Who are your customers? How many customers do you have? Do you have some really big customers or are they lots of small customers?” And they look at me like, “You’re a techie, we want you to give us the technical answer. What is the right thing to do?” And of course there is no right or wrong answer necessarily in tech questions. There is what is an appropriate tool for the context? Maybe Kubernetes isn’t the right tool at all for you. That happens more often than you might think.

I start by asking those really high level questions and then I’ll ask them to draw, not show me, draw an org chart. And that in itself is very revealing of context. And then I ask them to tell me, “So how do you get an idea to production?” The last part of that is a very common thing, but the first two are less common and it really helps to have that three layer understanding of the business before you start talking tech because you might be discussing why they haven’t made a decision about a service mesh and then you realize that the management of the team doesn’t really care about getting an answer to that question because the way they’re funded is not related to getting that done and that’s because ultimately their funding comes from a part of the business that isn’t directly related to the customer. These explanations can really sway through the business and allows you to see behind the curtain and what’s going on. And the corollary of that is successful businesses are very well aligned with their funding models.

Power, Patronage, and the Role of Money in Software [06:15]

The other side of it is that the sources of money, and I’m using the term money quite crudely, when I talk about money it’s about any form of power, but ultimately it comes back to money. We all get paid to go to work, they stop paying us we’re probably going to stop working for them. Money is at the root of it if you like, but there’s other forms of power and what I call patronage. I don’t think of things necessarily in terms of the customer. Customer can be a patron, obviously if you have a SaaS business with 1,000 customers, they’re all patrons of the business. Your patron might be government or it might be VC or it might be a particular manager who holds a big budget who can wield power that way.

I’m not sure exactly what your question was, but in answer to the question about context gathering, it’s everything when you’re consulting because you don’t have the knowledge of the context that the person you’re talking to does and you have to gather that context really fast. Those three lenses allow me to get as much context as I need to be able to dig deeper into the tech.

Accounting and Budget Ownership [07:24]

Thomas Betts: I think the idea you’re getting to is a lot of technical people I know love to get in and solve the problem. You walk in and especially if someone prompts you with, help me use Kubernetes. Yes, I can help you use Kubernetes, but better step back is, should we be using Kubernetes, and what are the constraints that we might not even realize are going to prevent us from using Kubernetes or a service mesh or whatever technology successfully, and does something else exist? Does the company already have another license or if I need to buy that software because we’re doing a buy versus build trade off.

I think people understand those, but I think what they don’t realize is when we’re talking about buy versus build, sometimes it’s a different type of money, the accounting is different. Whether it’s I’m going to go and spend $100,000 to get this off the shelf versus I’m going to pay someone $100,000 for a year to build this software. Those are different types of money. That’s a hard concept to get across to people when they’re saying just create software.

Ian Miell: And there’s so many strands I can pick up on from what you just said. The accounting thing is, who owns the budget is a fascinating question. With platforms, I start the book with a story about a very successful engineer, I call her Jan. She becomes a leader of a small group of engineers and she builds a platform in her spare time with those engineers, like a Kubernetes platform. And she does it within a central IT function and she builds it and she takes it, she shows it to her manager and the manager’s like, “Well, this doesn’t help me hit my goals for the year. This doesn’t help me get a promotion, this doesn’t help me get a pay rise”. And she’s nonplussed like. “I’m trying to deliver faster, cheaper, better. That’s what the company is, we’re supposed to be agile. I’m trying to help the whole business”.

And it might sound naive, but a lot of people think this way. I certainly did. Where you’re thinking, well, I’m doing what’s good for the company, but the system is not structured in that way. It’s not designed to be run that way because people are complicated and their interactions are complicated, so you silo things and you have different budgets and so on, and the end result is that you are slaving away at the central IT function, trying to make the business better as a whole, but it’s not accounted for. The savings that you make don’t show up on a spreadsheet anywhere unless you start taking metrics and persuading people those metrics work, but that’s more around the improving the situation side.

Engineers as Mini-Entrepreneurs and the Limits of Influence [10:00]

Engineers are trained to solve specific problems, usually on their own, in a way that means that they don’t have to depend on others. They’re basically mini entrepreneurs who take tools and their own intelligence and then they make solutions to problems. And that’s great when you are a young engineer because you can just do that, solve problems quicker, faster, better, and show your manager how productive you are. When it comes to making those changes more broadly across business units it becomes a very different game. And so the engineer is not really well-equipped to understand that, and this is why I think so many engineers complain. They complain they don’t understand what’s going on and actually we don’t understand because we don’t sit down with the leaders, we don’t have time or they don’t have time to sit down with the leaders and the CFOs and say, “How are you thinking about this and so what’s going on?”

We had one client who built over three years, in fact, they built a platform and they did a really great job under difficult circumstances. They built a central Kubernetes platform and they invested over years very patiently and eventually they had people using it and they came to the point where they decided, we are now as a business, we are a platform company, we’re a SaaS company. And suddenly there was all sorts of trouble. We had a conversation with their CFO, CEO and the head of engineering and it turned out that the CFO, and to a lesser extent the CEO, thought that what they’d built was a thing. They thought, we’ve built the thing and now we have the thing, so why are we still spending money on the thing? And that was because accounting saw it as an intangible asset that they’d built and that was going to be depreciated over five years.

Once we explained that, “No, no, this isn’t buying a warehouse and then you spend a little bit of money making sure that no one breaks in, this is like you are continuously building something that will continuously generate profits, it requires continuous investment”. The accountant immediately understood that, said, “Okay, so I’ll have to think about how to represent that in the accounts”. And the CEO was stuck between these two worlds and was pleased that they were starting to talk to each other. But most of us don’t want to talk to those people and understand their point of view, but it’s vital.

CapEx vs OpEx and Project-Based Funding Pitfalls [12:16]

Thomas Betts: I worked at an organization and was brought in to finish this project and we got really close to the deadline and someone realized that as soon as we released it and delivered it, we were all getting laid off because the money only paid for the project even if we were over budget. They’re like, “Okay, it’s over budget but it can go over budget and still comes out of the same thing”. They had no funding model for any single person to stick around, and we weren’t consultants we were hired as employees. What does everyone do after that? They had no idea what we were supposed to do because that bucket of money stopped. There was no operating costs.

Ian Miell: Exactly. We were talking about CapEx and OpEx and everyone talks about CapEx and OpEx, it’s the first subject that comes up and this is why because it’s so fundamental. There are two ways to think of projects, CapEx and OpEx or activities within a business, CapEx and OpEx, and you’re just thrown in one camp or the other, but actually the real world is messier and understanding that distinction and how it will affect the way things are built, it’s very common.

Challenges of Shared Software Investment [13:24]

Thomas Betts: I worked at a contractor that would build products for a customer and because all of their funding model was based on multimillion dollar contracts, anything we built internally that we could use across projects, well, who paid for that software? The company didn’t want to invest in building software that could be shared because then this customer got it for free. “Why don’t we charge that customer?” “Well, you charge that customer, they don’t want anyone else to use it, it’s their stuff”. And so we never were able to build, as you described the story of a platform, we had to build everything from scratch for every single customer. And you’re seeing that if you’re down in the trenches, we could scale this so much better if we could just write this one thing one time that everyone can use and customize. And it’s never quite that simple.

Ian Miell: It’s so interesting, isn’t it? Because a lot of CEOs are CFOs originally, and the reason for that is that the CFO really understands how the business works, so oftentimes they find it easy to step into that role because the gap is smaller. But engineers are little CEOs as well. And when you’re running a software project, you have to think of things in terms of trade-offs. Do we pay down this technical debt now or do we defer it to bring the project in and then do the next thing? You’re a little entrepreneur as well. And so my call to engineers, particularly younger ones, is really try and understand these other concepts because if you understand both the CFO’s side and the operational side, then you’re in a position really to manage the company or the business for the better in the long run.

Software Engineering is Problem Solving, not just Coding [15:07]

Thomas Betts: I think especially with AI becoming a tool that helps developers write code faster, it’s pointing out that as an engineer I didn’t hire you to write code, I hired you to solve problems. And sometimes as a software engineer, you produce code, that’s the way to solve a problem. But you also should recognize sometimes the right answer is to not write code. Can we fix the process a little bit? Oh yes, that’s a different option. And having that engineer mindset versus the developer mindset of, my job is to write code, I’ll write as much code as possible and then my value is in the code that I produced versus I have solved the problems. And sometimes that problem solving means you have to look a little bit wider.

Ian Miell: I get frustrated, I think many people do. And I understand when I have a code base, I want to make sure all the tabs are correctly aligned before I do anything else that might take time, or I wanted to make sure the naming paths are consistent. But you get larger scale problems where engineers say, “No, we have to fix this now because it’s a huge thing”. And you say, “Well, I get it, but that’s going to take us a month and in that month people are going to be looking at me as the leader of this team and saying, ‘What have you delivered?’ And I can try and explain to them what I’ve done, but it’s not going to apply”.

I once worked in third line support for a online gambling backend system, so if it was down they were losing money and so there was a lot of pressure on us to deliver and they paid us a lot of money to support those systems. We had seven engineers and several million pounds worth of projects, so it was a very profitable part of the company. And so they left us alone because the support money ticked up and there were never any really huge problems. We used to write bits of software to improve the system just because we were frustrated with dealing with the same problems all the time.

The guy who managed our team, he used to say, “I love you guys because you hide stuff from me. You’re building stuff and I don’t have to justify that building to anyone because you’re already justified with the money is in the money’s out”. And that was much easier on a yearly budget cycle because those guys were paying for our services every year so we knew for the next 12 months we didn’t have to think about profit and loss. We just had our work to do and as long as that work didn’t interfere with anything else or cause any problems, then we were free to do whatever we liked, so we as engineers could then go and fix the big problems we saw were happening. It’s a tremendously satisfying role, but now I see how rare that was.

Architecture Modernization and Organizational Buy-In [17:38]

Thomas Betts: And I think you can hear those success stories when it’s fully contained. If I spend a couple of weeks of my time cleaning house over here in this area of the code or writing scripts, and the bigger picture is just the software keeps working that unit of software. I think we’re seeing more people struggle with large architecture modernization projects, like companies that developed software a decade ago and it’s starting to show its age and we need to modernize the platform.

One of the big challenges is always getting full buy-in through everyone that needs to accept that. That we need to spend a few years maybe doing this modernization work and in that time we can’t be adding lots of new feature requests from the customers. We have to slow down on what we’re adding, but the people who value we’ve added new features, we’ve responded to customers, they’re not selling the platform underneath, the system is being changed. They just want it to keep working and they want to keep adding stuff, they want to keep making their customers happy. How can we improve those communication lines between the technical people and the non-technical decision makers, and how do we have to start talking about the money better?

Ian Miell: This is such a big topic. In fact, you’re talking about some of the customers that we’ve got right now. We have customers who, a very common pattern is, they’re a 20, 30-year-old company who built their software in the three tier software engineering world, but typically sold B2B. In fact the one I talked about earlier with the accountant that was one of those companies. They had a product, they called it a product, but it was actually 20 different code bases deployed in 20 different environments with 20 different levels of age and their own histories in their own deployment context and everything else. And they saw that the writing was on the wall and they needed to become a SaaS company and their customers were telling them, “We just want to pay you a monthly subscription and you give us a product. We’re tired of these projects that take forever to build”.

And people underestimate how hard it is, really underestimate how hard it is to move. The common fallacy is, we’ll change the technology and everything else will follow. And it’s just not true. One of the key drivers for me writing this book was I was tired of reading all these books. I won’t name them, but reading all these books describing the perfect state of the world and not telling you how to get from A to B. I don’t profess to know exactly how to get from A to B, but I do know that it’s hard, it’s messy and you’ve got to use a lot of tricks and some of it’s quite painful.

Leadership Challenges in Moving from Projects to Products [20:38]

Your question, how do you get from A to B, sometimes the people you’ve hired are not suited to that new world, they don’t get it. Very often the leadership is not prepared for the difficult decisions they’re going to have to make. The leadership says, “We want to go from project-based profit to product-based profit”, so the line goes up massively and everyone’s happy. But products are really hard. You used to have the discipline of the customer telling you what they wanted very loudly, very clearly with a bag of money at the end of it. And that was very easy to focus everyone’s mind on that.

And then you move from that to a product roadmap that’s fuzzily related to what the customers want and then your biggest customers then phone the CEO up and say, “Where’s this thing that we were promised last year?” And you say, “Well, the roadmap shifted and it’s because of user feedback and duh, duh, duh”. And they’re going, “I am not interested. I pay you a lot of money every month, give me what I want”.

Those shifts are really hard. I call it missionary work in my job, like the core people who build the platform, and it should be a small core team building that platform in a small considered way, need to spread that knowledge and understanding of how the platform works gradually through the system, this is the missionary work, and find out which teams are going to be responsive to and not. But there is no formula for this because each context is different. Each business has its own set of constraints, pressures, historical patterns, habits, behaviors, culture.

That’s another frustration I had actually, like with Conway’s law, people stop at culture. They say, “The culture is wrong”. And I’m like, “Well, so what do I do? How do I change the culture?” And I say that the culture is determined ultimately by the money, the way the money goes around the business. And if that doesn’t change, your culture is very unlikely to change. And that actually raised back to my history degree because there’s a joke that all historians are Marxists, all historians think in terms of material flows through the world. They’re materialists. They don’t think it’s ideas that change the world, they think it’s oil or technological developments or bond markets. I think that the base from the material world determines the superstructure culture. We shouldn’t be looking at culture, we should be looking at how things are funded, rewarded, incentivized, et cetera.

Thomas Betts: I remember the catch-phrase five, maybe 10 years ago now was, data is the new oil. And the companies that have the data and we’re mining the data and that’s going to be the valuable thing that people spend money on and we’re going to sell the data or we’re going to harvest data or we’re going to feed the data to the AI. And that’s that same idea, like you said, the oil leads to what gets funded.

Buzzwords and Superficial Change: Agile and DevOps [23:36]

Thomas Betts: I want to pull that in a different direction because I think we see that in our industry every few years there’s that new catchy buzzword and people latch onto it, whether that’s agile or DevOps or team topologies, and I don’t want buzzword to sound disparaging, but I think people think it is just this. I can get out the spray can and just like I can make our company agile and all I have to do is send people to a class and they become scrum masters and then we have stand-ups and now we’re agile, and they don’t fundamentally change their behavior. We’ve heard this story in different variations.

I think DevOps is the latest iteration that, we want to do DevOps but we didn’t actually invest in changing and having a team that’s dedicated to building the platform, like you said, or having people actually talk together, talk on a regular basis and work together. We’re going to have DevOps with two different silos for dev and ops. Are you seeing the same thing when you’re talking about the money breakdown is the same thing that if the money patterns don’t change and you think, I want to make more money, but I don’t want to change how I’m doing it, you can’t actually have that 10X growth switching from a project to a product.

Ian Miell: Absolutely. My hope with this book is that people actually talk about the things that matter. If we go back to the DevOps time, and DevOps is a really complicated term. I actually know Patrick Debois who coined the term DevOps. He doesn’t want to hear about it anymore because similarly to agile, it was invented in one context and then got used in every other context. And so the original impetus and the meaning and the focus of the term has changed so much it’s unrecognizable. It’s just a different thing now.

In my mind, DevOps was originally you build it, you run it, and so from that follows lots of things. For example, you own the P&L for the thing that you maintain, you are responsible for the APIs around those things, but most businesses can’t or won’t operate like that. You ended up saying, okay, we’re going to centralize it and then we’ll have a DevOps team that’s at the center and they’ll be responsible for the DevOps bits that the teams do because they can’t run it, we need someone else to run it. And then we might have a separate DevOps team and a separate operations team. That’s a really bad pattern.

Then Google came along and said, no, we call that SRE. And SRE is not DevOps because these are not ops people, they’re dev people who happen to do operations or infrastructure operations and they think like engineers. It all got really, really complicated. But by focusing on the things that matter, if you do the same thing over and over again, if you have the same structure, you’re going to get the same results very probably, unless you have extraordinary individuals who are super motivated to overcome them. But basically you throw the dice you’re probably going to get the same result.

And my plea to everyone is, let’s stop talking about, agile is a classic one. I worked at two banks over a period of five years and I remember seeing posters saying, “Let’s be agile and remove your blockers” sort of thing. I was sitting there as a architect/engineer thinking, well, I can’t remove my blockers. I literally have no power. The system is designed to not give me that power, and ultimately there’s a good reason for that, but let’s not pretend that we’re agile. Let’s not pretend that we can be agile. Let’s try and make the best of the situation we’re in. The mistake of thinking that it’s just a lack of will on the part of the engineers or the project managers or whoever is just not helpful because it’s generally not a lack of will, it’s just a matter of incentives being determined by the situation you’re in.

Mutual Understanding Between Engineers and Financial Decision Makers [27:22]

Thomas Betts: And I think it works both ways. We’re talking for the engineers could benefit from understanding financial aspects and how the company’s finances work. The same is true the other direction, being able to communicate, here’s how the system works, here’s the thing we want to build, how do you help us change the company? And if we have to change the funding models, let’s figure that out. I liked your idea of DevOps equals you own the profit and loss. I very rarely have encountered that where it comes down to that level. It may be a few levels above, but I think it’s still pretty common to see. You’re in IT, that’s a cost center and sales is a profit center, so you can’t possibly be making money because you’re not bringing in revenue, but without the software, if the software is a product, how does that equate? You can’t have profit coming into the system, so how does that work that people need to understand?

Ian Miell: I was saying to someone earlier today talking about this, that a lot of the evils of the world are the result of mismatches between accounting concepts and reality. And the idea of a cost center and a profit center is such a crude way of looking at the world. And again, I don’t want to blame accountants because accountants can’t represent the world in its complexity and understand everything. No one can. They have to have a way of working that works for their goals and that the market and government and regulators can trust. But if they control all the conversation, then you’re going to have trouble.

Accounting Blind Spots: Valuing Knowledge and Experience [28:56]

Another classic one is thinking that engineers are interchangeable, that you can just replace one with another. The person I was talking to today was talking about representing the accumulation of knowledge as CapEx rather than OpEx. If you have someone working for you for 10 years in a certain position, that should be capitalized on your balance sheet somehow, but it’s not. It’s an employee, you’re paying them every year. You compare them to another employee you’re paying the same amount every year, they’re equivalent in your mind. But actually everyone knows that some of those people who have paid the same as some of those other people are much more useful, productive, helpful, they get more done than the rest of the business. And most times those people are somewhat recognized for that and somewhat rewarded, but does that reflect the value to the business? Probably not.

Thomas Betts: That’s a really good point. I hadn’t thought about the knowledge stock is the term that Diana Montalion taught me, that acquisition of knowledge over time. It’s not just I learned how to write C# and JavaScript and TypeScript, whatever else, it’s, I understand the business. I understand how our software works because I’ve been working with it for 10 years. And someone coming in brand new, even if they have 10 years of experience, they don’t have my 10 years experience. There’s no way to value that. Maybe I give that person a bonus or try and keep them around, but it still comes down to that money is coming out of the operating expense, not the capital expense. We value the building, we need to maintain the building.

The Frozen Middle [30:29]

Ian Miell: But what you’re talking about just then reminds me that as a consultant, I don’t have the context of the people in the room and oftentimes I have to say, “Look, you know your context, I can’t advise you what the right decision is to make because you’ve been in this context much more”.

But there’s this concept in consulting of the frozen middle. When you’re trying to make change, people at the top are super in favor, the people at the junior end are super in favor because they’re willing to do things new, but the people in the middle just sit there, nod, smile, and just carry on as before. And it is easy to demonize those people, those middle managers, but they know the business better than anyone. They know it from the middle, they see the bottom and they see upstairs, and they’re stuck between them and they know how to survive. They’ve survived for that long, and they survive by saying, oh yes, here’s another consultant who just doesn’t really know our context. We’ll just be nice and say yes to everything and move on. As a leader, you have to dig into those people and understand what they’re thinking and why they’re thinking it, because if you don’t their silence would crush your ambitions to change the business. That’s another very big pattern we see, and it’s because their knowledge is undervalued often.

Thomas Betts: And it’s sometimes very difficult to get through to those people, if we do things differently, you will benefit. Because they’ve got years of experience of I’ve collected my salary, everything’s been working just fine by doing basically the same thing. I don’t want to have to change. What if it doesn’t work out for me? When automation became a thing and we started writing scripts to deploy all of our servers to the cloud, the IT support people who were in charge of those machines, some of them resisted that.

We had a push to move off of Novell, this is like 20 years ago, and the manager’s like, “No, we’re definitely sticking with Novell”. I’m like, “I don’t think that’s a good long-term strategy”. But he was adamant because that’s what he knew. He didn’t know the dynamic forces and things that were going to change. And if you can accept that that’s going to be different, then you can go with it. But if you think things have to stay the same, maybe software isn’t the right career for you.

Ian Miell: I never understood that mentality because, to me, it’s like if I hire a workman and he does a really good job and saves me time and money, I’m going to hire them again. I’m going to tell my friends about them. I never optimized a project or improved something or worked myself out of job without having another one to go to. It just never happens. If you do your job well, then you end up doing your boss’s job because they give you tasks like, “I’m overworked, go to this meeting for me”, and basically you get mentored by that boss. But a lot of people fear change. I certainly did when I was younger, I was looking ahead at 30 years of stress and thinking, how am I going to do this? And I worried about what I was going to be doing. It’s human nature and human nature, it’s a big problem.

Closing Remarks [33:26]

Thomas Betts: I’ve really enjoyed the conversation, Ian. What’s the name of the book and about when do you think it’ll be coming out?

Ian Miell: Sure. It’s called Follow the Money: Understanding the Financial Architecture of Software. It’s published by O’Reilly. I’m writing it now, and it’s due to be finished the end of next year. Hopefully I’ll get it done before that, but, “Deadlines make a great noise as they whoosh by me”, as Douglas Adams said. But I’ve got a lot of people advising me with anecdotes and stories about their experiences, and some of yours will definitely be incorporated as well. I hope people enjoy it.

Thomas Betts: And if you want to connect or follow you online, what’s the best way to do that?

Ian Miell: I’m on LinkedIn. I’m also on Blue Sky, but find me on LinkedIn. Just connect with me and I’ll say hi, and I’ll respond.

Thomas Betts: Great. Well, Ian, thank you for joining me today.

Ian Miell: Thank you.

Thomas Betts: And listeners, we hope you’ll join us again soon for another episode of the InfoQ Podcast.

Mentioned: