#50 - Riding the Architect Elevator to the Cloud - Gregor Hohpe

Episode Introduction [00:02:17]

Henry Suryawirawan: [00:02:17] Hello to all my listeners out there. Super excited to be back here again with another episode of the Tech Lead Journal podcast. I’m your host, Henry Suryawirawan, and I’m so happy to announce that Tech Lead Journal podcast has reached its 50th episode! Wow! It is personally a great milestone for me and what a great one year journey it has been. I’m so thankful for all of you, my listeners who listen and support this podcast, especially those of you who have been there since the beginning. And I couldn’t have made it without any of you.

Also special thanks to all of the amazing guests that I have on the show, and especially for sharing your story, valuable wisdom, and knowledge. Last, but not least thank you to all of my patrons who have continuously supported my journey and for giving me the extra energy and motivation to produce high quality content. I’m so grateful to every one of you, and I hope we can continue this journey for more episodes to come.

Special mention to those of you who help me to promote this podcast on the social media platform, either by following, liking and resharing some of the contents. All of you help me a lot in reaching out to more listeners, and I can’t thank you enough for that. Speaking of which, if you haven’t please subscribe to Tech Lead Journal on your favorite podcast apps and also follow our social media channels on LinkedIn, Twitter, and Instagram. You can also make some contribution to the show by subscribing as a patron at techleadjournal.dev/patron and help me to continue producing great content every week.

To celebrate the 50th episode, I am extremely happy to share my conversation with Gregor Hohpe. Gregor is currently an Enterprise Strategist at AWS and the author of many popular books, such as Enterprise Integration Patterns, Software Architect Elevator, and Cloud Strategy. In this episode, we started our conversation by discussing about the role of a software architect. There are a lot of different opinions about software architect role, and Gregor explained the fundamental skills required from a software architect, and the reason why there’s the latest resurgence of the role within the industry. He also explained about his software architect elevator concept, and then described what a good architecture should look like and how to deal with trade-offs by using the analogy of financial options.

In the second half of the conversation, we then discussed in-depth about the cloud and the reasons why adopting cloud requires a lifestyle change in order to benefit from it the most. Gregor also described why organizations need a good viable cloud strategy, and debunked the concern of many organizations on cloud vendor lock-in. He also gave his tips on how organizations should approach building an in-house cloud platform and how to change the organization structure to embrace the cloud better. Towards the end, you do not want to miss our insightful discussion on the Gregor’s law of excessive complexity.

I really enjoyed my conversation with Gregor, learning about software architecture and the cloud. And even though I’ve been working with the cloud for a while, there are still a lot of things to learn from Gregor throughout this conversation. And I’m sure that you will enjoy this episode as well. Consider helping the show by leaving it a rating, review or comment on your podcast app or leave us some comments on our social media channels. Those reviews and comments are one of the best ways to help me get this podcast to reach more listeners. And hopefully they can also benefit from all the contents in this podcast. So let’s get this episode started right away.

Introduction [00:05:51]

Henry Suryawirawan: [00:05:51] Hey, everyone. Welcome back to another new episode of the Tech Lead Journal. Today, I’m very excited to have a guest with me. He is a very famous guy in the tech scene all over the world. He has an illustrious career as well. So he has been a chief architect at Allianz Technology, Technical Director at Google and also worked with GovTech Singapore as a Smart Nation Fellow. Currently, he’s working at AWS as Enterprise Strategist. He is Gregor Hohpe. He also wrote a lot of books. Few of the popular ones are like " Enterprise Integration Patterns", “Cloud Strategy”, the recent one, and “Software Architect Elevator”. So today we are going to discuss a lot about Cloud Strategy and a little bit about Software Architect Elevator. So Gregor, really, really pleased to have a conversation with you today. Looking forward to learning from you.

Gregor Hohpe: [00:06:38] Thank you. Thank you for having me. I’m looking forward to the session as well. I know we’ve been trying to make this happen for a little while, so I’m even more excited to actually be on the show now.

Career Journey [00:06:48]

Henry Suryawirawan: [00:06:48] Thanks for that. So maybe Gregor, in the beginning, can you introduce yourself to those people who may not be familiar with you yet? Maybe sharing your highlights, turning points in your career?

Gregor Hohpe: [00:06:57] Sure. My name is Gregor. I would say I have probably seen IT from every possible angle you can imagine. I co-founded a startup back in the old days before everything was a unicorn. I have worked a lot of time in consulting and professional services. Yeah, I was a Silicon Valley software engineer. I worked in large company IT. Right now, I work for a cloud provider, and I work in public sector. So I would say I’ve always been curious and I’ve always been keen to see things from a different perspective. It’s also forced me to learn a lot of things. As you mentioned, I like to write about the things I learn. So the books I wrote are mostly about the role of architects, and I run the website called architectelevator.com. And I think we’ll talk a little bit more about what we think an architect might be or should be, and how that all relates to cloud architecture and cloud strategies.

Software Architect Role [00:07:48]

Henry Suryawirawan: [00:07:49] Speaking about software architects I think in the last few years or so, software architect, in terms of the name of the role, has become one position whereby people will be a little bit skeptical, so to speak, right? When someone introduced themselves as a software architect, we would then hesitate and see the person, is this a real person that will be useful to deal with? Because of the connotation of architect means like an ivory tower kind of architect, whereby they wrote documents, and also just give orders and directions without actually having a low level, practical hands-on experience. So in your point of view, then what is the role of software architects?

Gregor Hohpe: [00:08:23] Yeah, this has been really interesting. We often say that in our field, things swing in the pendulum. It used to be like the architects make all the decisions and other people just fill in the blanks. Then there was a time where we really thought we don’t need architects. Mostly driven by the internet and the popular frameworks basically made all the architecture decisions for us, we felt for a while. It says we just use Spring and we use HTTP, and there is our architecture. Recently, we’ve seen a huge resurgence. I’m an author, so I will know a lot of fellow authors. They write about architecture, whether it’s microservices architectures, whether it’s event-driven architectures, whether it’s cloud architectures. We have architecture events, so suddenly architecture is back everywhere. I think part of the reason is that the software we build is enormously powerful, but it’s also admittedly fairly complex, right? Everything these days is distributed and horizontally scalable, and restartable and resilient, and anti-fragile, whatever label you want to put on it. It’s just fantastic. But it’s also complex. So architecture helps us deal with this complexity.

What we’ve also come to terms with, I think, is that having architecture is one thing, doing architecture is another thing, and having architects is the third. And the simple answer is you always have an architecture. You can’t choose. If you write three lines of code, the thing is going to have some architecture, no choice. Most people have also realized that doing architecture consciously is a worthwhile exercise because if you don’t do it, you usually end up with a big ball of mud kind of architecture, right? You get the giant spaghetti default. But the third part is like, well, do you have architects to do the architecture or not? I found that we have a much more open mindset. Some people still prefer to have a dedicated architecture team. Sometimes you have architects embedded in the software teams, and sometimes the architecture is done by everybody. And I really liked that. So I think we debunked this discussion of associating doing good architecture with having these ivory tower type architects. And I think that’s been very healthy for the dialogue.

Henry Suryawirawan: [00:10:36] So in terms of software architect role, I think one of the things recently, especially in the startup and all these Agile, they always say do the minimum as you can. But I like when you said that there’s always an architecture in your system, no matter whether you plan it properly, do it consciously or not, there will always be an architecture. So what do you think is the importance of a role of software architect? Can you explain to us, why do you think a software architect role is probably still required?

Gregor Hohpe: [00:11:02] I often highlight that it’s not about developers having to become architects, and architects somehow being a more senior developer role. I see them as different roles, each of which is valuable in its own. What I see the architects doing is a couple of things. The one thing is that the architects generally see the system in a larger scope. A nice quote is from the book about architecting complex, real-life systems, like oil drilling platforms and stuff like that, where it really describes the world of the architect very nicely as saying, well, in the end, you’re really responsible for your part of the system. But at the same time, you are accountable for the whole part around it for the system as a whole. That’s why architects need to look more left and right, and they can’t just work based on requirements. Architects have to what I call as work based on non-requirements. The tested assumptions, those things that nobody spelled out. Neither things that weren’t actually written down anywhere, and I think those are the key inputs for a successful architect.

Software Architect Elevator [00:12:07]

Henry Suryawirawan: [00:12:07] And you have this term called Software Architect Elevator. Is that somehow related to what you just mentioned? So architects should work based on the non mentioned or non-specified requirements. Can you maybe share a little bit more about the concept of software architect elevator?

Gregor Hohpe: [00:12:23] Yes. And that’s the name of my book and my website. So it’s something that’s close to my heart, obviously. We’ve just said, the architects need to have a wider scope. They need to see the system as a whole, and they need to not just work off the requirements sheet, but basically fill in the blanks. Now, how are you going to do that? The way you do this is you look at your system from different levels of abstraction. You see it in the business context, in the strategic context, or you take the elevator down to the engine room to see a system in a very technical context. And what you find, especially in larger organizations is these different layers, these different contexts, they’re actually shockingly separate from each other. There’s some people doing the financial planning. There’s other people doing the strategy. There’s other people doing mergers and acquisitions, go to market entry, and there’s somebody down there configuring Helm charts. In between, it’s a big, giant void. That is exactly what I call the architect elevator, like someone who can move across these different layers, and make sure they’re connected.

Now in an ideal state, an organization would be very level, very well connected. I would call this like a bungalow, basically, where everything is easy to get to. But I find even in startup companies, later stage or mid-stage startup, different people need to focus on different things. It’s inevitable. Not everybody can do everything. And then very quickly, the little bungalow turns into a multi-storey home, and then shortly after, it turns into a skyscraper, right? And the thing just keeps growing. You can’t just flatten it back down because the different functions of course are important. So the next best thing you can do is somebody ride the elevator between the different levels. And I feel that architects are well equipped to be the ones who ride that elevator, which is aptly called the architect elevator.

Henry Suryawirawan: [00:14:12] I laughed when you said that someone is tweaking Helm charts. Sometimes as an engineer, we probably don’t actually realize when we tweaked, for example, Helm charts, what does it mean in terms of business impact, or in terms of purpose for the whole organization or the systems overall. So, I really laughed when you said that. I think software architects in this case is very important because you will then have a translation end-to-end. From the business point of view until the engineering point of view.

An Architect Stands on 3 Legs [00:14:37]

Henry Suryawirawan: [00:14:37] You have this thing in the book, mentioning about an architect actually stands on three legs. So what are these three legs? Can you explain a little bit further on each of the leg?

Gregor Hohpe: [00:14:48] Yeah, connecting the different levels, let me just say that the reason it’s so important is because if the connection isn’t there, the greatest technical solution in the end is not going to have the impact that it should have. It’s like if you’re drilling the two tunnels and they don’t meet each other, drilling faster is not going to help. So that’s why this connection is so important. Now, of course, this places a lot of requirements on the role of an architect. We have to go through these different levels. We have to connect all these things. There’re many different things that we need to do. So how do you come back and bring this into something tangible? And I said, in the end, to be a successful architect, you need to have three elements. Those are the three legs that you stand on. Of course you need to have the skill. You need to know your things. You find some architects up in the penthouse who just spew out some jargon, “Right, we need to leverage the serverless cloud. IOT is something edge, right? Blah, blah, blah.” That doesn’t help anything. It gets the executives excited, but there’s no elevator there. So you need to have a skill. You need to know what you’re doing, and what you’re talking about. We were just chatting before the recording, right? I’m just now tinkering with some AWS products. So I have the anchor in the engine room.

Now, the second part, of course, is you apply the skill to have an impact. Again, otherwise it’s just sort of like research, kind of playing around prototyping. That’s good for very small things, but that doesn’t make a business. So you need to forge the connection between having the technical skill, and bringing this to have an impact. This is about aligning, understanding strategies. Exactly like the elevator.

But there’s a third important part. That’s why the stool has three legs because with two legs, it’s a little difficult to sit on. And the third one is really the leadership. I took the inspiration there from other professions, like let’s say, you’re a very highly skilled lawyer or a very highly skilled doctor and medical staff. What do you become? You become like the chief doctor, like the chief lawyer, to some extent, but you remain a lawyer and a doctor. And also as an architect, you remain an architect. But the way you grow - your impact - is by advancing the field. You start lecturing, you start maybe more researching, finding new things, describing things in better ways, building more skill set, and in the end, elevating the practice as a whole. And that’s the leadership as the third leg.

Now, the nice thing about this is all of this is a two-way street. Once you have the skill, there’s so many skills you could acquire, it’s hard to figure out which skill you should really pursue, right? It’s like a kid in the candy store. So looking for the impact helps you prioritize. What should I learn? I should learn the things that have an impact. And also having the leadership, mentoring other people, gives great feedback because you learn: what’s maybe most confusing or people ask this proverbial sort of naive questions, which really get you thinking. So it’s not just your personal progression, but it’s also a two-way street. You always get things back along this journey.

Henry Suryawirawan: [00:17:49] I really like your explanation that it’s a two-way street, right? It’s not just one thing that we can just go dive deep, study hard, and we become a great architect. But you always need to show impact, first of all, and also do some kind of leadership thing, the mentoring, or advancing the field. I really liked that. Do research and talk about it, so that other people can also adopt your ways of thinking.

Good Architecture [00:18:08]

Henry Suryawirawan: [00:18:08] Speaking about architecture, I think it’s kind of like abstract in a way. We all know these days about microservice, event driven and all that. But what is actually a good architecture? Because I think it’s very hard to define. Sometimes we are clueless. Okay I have a system. I have requirement. But what is good enough architecture for my requirement?

Gregor Hohpe: [00:18:27] Yes. Good question. And the old definition is sort of you have the non-functional requirements, and the idea would be that an architect just sort of makes sure the non-functional requirements are met, and then the developers make sure the functional requirements are met. I think that’s a very naive definition. It’s a good starting point. But what it doesn’t account for at all is uncertainty. Like all these requirements thinking assumes you know what you need. “Right, here’s the list of requirements. Just make it so everything will be fine.” The dimension that’s totally missing is the dimension of evolution and uncertainty. And I think that’s where a good architecture really shines.

You might know my famous slogan about architecture sells options. Options are a great way to deal with uncertainty. The analogy comes from the financial markets, an option is the ability to execute a trade–like, you buy or sell a stock –in the future at defined terms. So you can buy an option, maybe to buy one share of Amazon stock for $4,000 one year from now, and then when the year comes, the decision whether to exercise the option or not becomes very simple. Because if that time the stock is higher, you buy it for 4,000 based on the option, you have money in the bank. If the stock is lower on the market than the option, you let the option expire. You don’t take it. Now, what we learned from this is that decisions become much easier in the future. It’s a great way to deal with uncertainty, if you travel into the future. Well, there’s no more uncertainty. You can look at reality at that time. So if you can defer the decision, that is a really great thing. And this is what we call options.

Probably the best technical example that we have is horizontal scaling, like elastic infrastructure, horizontal scaling, like how much hardware do you need for your application? It’s always been a guessing game because there’s a lot of uncertainty. And of course, for internet facing and mobile apps, et cetera, the uncertainty is even higher. As an architect, I can sell you an option, make it microservices architecture, you make it horizontally scalable. You run it on top of an elastic runtime. In the future, making the decision is very easy. You need a bit more hardware, you go deploy the hardware, and you need less, you actually shut down some service. So this is an option that as an architect, I could give you that allows you to defer a decision. In this case, the decision about hardware sizing, and that takes a lot of the uncertainty out of the game. And that is a great value. Taking uncertainty out is highly valuable. I used to work for an insurance company. We made 11 billion euros operating profit a year by dealing with people’s uncertainty. So if architecture takes uncertainty out of the equation, that is worth real money.

Trade-offs [00:21:09]

Henry Suryawirawan: [00:21:09] Then how about trade-offs? Because as we all know in IT, or most of the things in the world, you can’t achieve everything. There will be always trade off, either like for example, scalability versus performance, security and all that. So how does an architect deal with this kind of trade-offs? At the end of the day, with all these differing options and also trade-offs, how do you actually communicate that, so that everyone in the team, everyone in the company, actually adheres to the decision, and hence properly implements that?

Gregor Hohpe: [00:21:36] Yes, and recall that I said the architects, they sell options, right? We don’t donate the options. And this is where the trade-offs come in. With our horizontal scaling example, that option is great, but it has a cost. The cost is slightly more complex application architecture. You need to replicate your state or externalize your state. You need to have automation to spool up new instances. Now, these days that’s probably common to many developers, but if you write a little hello world for yourself for the weekend, probably you don’t make it horizontally scalable. So there is a cost. The cost comes in a number of different forms, right? There’s a little bit of effort, but that’s actually relatively easy to deal with. The larger cost is complexity. Something that includes more options invariably is more complex. So as we find out later, complexity is not a very good thing because complexity slows it down, and the world we live in slowing down isn’t a very good thing to do.

The last thing, the way you buy these options or you trade these options is in order to gain one option, you need to give up other options. So let’s say you want the option that each team programs in their own favorite language. Right, it’s a great option to have. Some people like Go, the other ones doing this Scala, and people on the JVM. Right, it’s a really nice option to have. But you enable this option by locking something else down. You say okay, I have APIs, it’s HTTP or HTTPS. It’s JSON payloads or protobufs, whatever you want to be. You lock some things in to gain that option. So it’s really an options marketplace. Like you’re trading, you’re giving up some to gain other options. Now the question is, of course, well, when is it worth buying the new option versus when is it not worth having the option? The important part here is that the architect generally cannot make that decision on their own. They can offer the option up for sale, but the value of the option depends on many factors. One of the key factors is the amount of uncertainty. So if things are highly uncertain, I’m launching a new mobile app. I don’t know whether this will have one user or 1 million users. I deal with a huge amount of uncertainty. So the horizontal scaling option is almost a given. Like the value is so high because uncertainty is so high. From a little hello world or a photo app for my own family. You know it’s like three people. I probably don’t need a lot of options.

So the options marketplace consists of the architect offering things up for sale, they’re not free. But then you need to work with the business and the context to understand whether that option is actually worth buying or not, and what the cost has been. You said like how do you get people to understand that? I think the best way is to really make these decisions very consciously, and to be very open about the trade-offs. It doesn’t help anybody who says, oh, of course it has to be a container. Of course it has to be in Kubernetes. Of course it has to be X, Y, Z. Of course we need a service mesh because how couldn’t you? And of course it has to be serverless. It’s like all are given. No, it’s never a given, right? These are all important decisions that have trade-offs. You gain some options, you lose some other options. Making those trade-offs transparent to a wide audience is probably the most helpful thing you could be doing. And of course, that looks very much like the elevator. The people higher up on the higher floors understand the ramifications of the decisions you’re making.

Henry Suryawirawan: [00:25:02] Speaking about explaining this, having an open, conscious decision and also transparent, reminds me of architect decision log or something like that, whereby you actually put down all the thought process that you have, and also outlines why a certain architecture is decided at that point in time. Maybe so that people also understand all these different options that we thought about, and why we chose a particular options versus the others?

Gregor Hohpe: [00:25:25] Yeah. Mike Nygard coined the term of the ADR, the Architecture Decision Record. I like that a lot. The key thing is to express the decisions so that the trade-offs that are being made are meaningful for a wide audience. It can’t be some cryptic kind of, we decided to flip this arcane bit number XYZ at somewhere deep in the infrastructure. That’s not an ADR that’s going to do a lot of good. It’s got to be meaningful, and the trade-offs gotta be communicated. But I like ADRs a lot.

Cloud Definition [00:25:55]

Henry Suryawirawan: [00:25:55] The next thing that we want to talk about is a specific thing about cloud architecture, which is a big topic these days, because so many cloud providers, so many cloud products, and so many people wanting to go into the cloud. So you wrote this book “Cloud Strategy”. I read it, and I love it a lot because there are a lot of humours as well inside the book, I have to say. So, when we talk about cloud strategy, right? I mean, almost these days, everyone is familiar with the cloud, but what is the definition of cloud from your point of view?

Gregor Hohpe: [00:26:23] Yeah. Thanks for reading the book. And yes. I feel that books with technical depths don’t have to be boring. So I always inject a little bit of humor and in the end, reality writes the best story. So I think all the funny parts are taken from well disguised customer conversations and customer engagements. In the book and generally, I shy away from it having this one sentence definition of what cloud is. You end up with these like very academic weird things that try to put as many buzzwords in a single sentence. What I’d rather try to do is show the different aspects of cloud. And one aspect is of course, where does your stuff run? And where does your data reside? We don’t need to think too much about this. Everybody talks about on premises versus in the cloud. That is probably, I would say, the overemphasized aspect for many reasons, right? Because on-premises often also not actually your premises. It’s often outsourced run by a third party. So there are a lot of thoughts about the location, but that would be the first aspect that comes to many people’s minds.

What’s more interesting to me when we talk about the cloud is it’s a change in operating model. It’s really redefining the interface you’re having with your IT. That’s why I always say cloud isn’t IT procurement. It’s not something you buy. It’s not like a CRM kind of system or like a database. It is really a lifestyle change. Because in the old times, the way you deal with the IT is: you fire a ticket, you make a request, things take some time, transparency is a little bit limited. Once you order something, you’re usually stuck with it for many years until it’s depreciated, right? That is what the interface into your IT looked like, and of course, a cloud operating model turns that completely on its head. You can have stuff whenever you want it. You can dispose of it whenever you want it. You can recreate it. It’s a highly dynamic environment.

We talked about before that the traditional definitions of architecture, they ignore uncertainty, right? They have this idea that everything is pre-defined. I think this translates extremely well into cloud. If everything is stable and static and well-known, then cloud is probably just a little bit more efficient way to run the infrastructure. Yes, maybe you will save some cost, but largely it’s same old thing in a little bit better packaging, it’s likely lower cost. However, once you assume that you don’t know everything, that you live in an uncertain world, that architecture options are valuable to you, that there’s a lot of change, a lot of uncertainty, that’s when the cloud operating model really changes the way your organization can operate. And I like that aspect of cloud computing much better.

Cloud is a Lifestyle Change [00:28:56]

Henry Suryawirawan: [00:28:56] I really love your definition about it’s really about lifestyle change for your IT. And it’s an operating model, not just procuring things, like buying software, buying hardware where traditionally we are all accustomed to. So can you explain a little bit, why do you think a lifestyle change is more a proper term rather than a procurement?

Gregor Hohpe: [00:29:16] Yeah. So the first question should probably be: why do you want or need a lifestyle change? Right? Because if it could be just simple procurement, it’ll probably make your life a lot easier. Almost every customer I talked with, the procurement part to them is relatively easy. But then in the end, they’re in the middle of a giant transformation, and the transformation of course is closely related to the lifestyle change. Now, the reason you want to have the lifestyle change is because your environment has changed, and that has to do with pace, and it has to do with uncertainty. In the old days when things were moving relatively slowly, both from the business environment, as well as from a technical environment, things were just like you can buy three different brands of servers, and that’s about that. So in terms of runtime environment, it was really, okay, you put it on VMware, and that was that. There wasn’t so much evolution, there wasn’t so much going on, and the business environment was also much more predictable.

Now that has changed a lot. If anybody needed a wake up call, of course, the pandemic did that in terms of how quickly environments can change on the business side. Where suddenly customers have to shift their whole customer interface from physical store into online ordering, whether it’s restaurants or whether it’s retail shops. Massive shifts, which of course translate into the IT infrastructure needs. Customers where it used to be sort of 90%, supporting physical in-store commerce, and maybe 10% e-commerce, and then in a matter of couple of weeks that actually flipped. So talk about scaling and scaling up and also scaling down, getting rid of the costs for the stuff that’s not needed as much anymore reacting to this. And I think that’s why you want the lifestyle change. I call this the transition from the economies of scale to the economies of speed. The economy of scale is you build something and then you get the return on investment, right? The bigger you are, and the longer you can run this thing, the better your return on investment is. So that works well if things are steady. The economies of speed are much more about learning quickly, having constant change, being able to listen, being able to course correct, being Agile, if you like that word. Those are the new ways that business runs and the cloud is a natural fit for that kind of way of running business. If you’re always moving, if you’re course correcting, if you’re changing, that’s when the benefits of the cloud really come to bear.

Henry Suryawirawan: [00:31:35] And you coined the term as like cloud thinks in first derivative, in terms of economies of scale versus economies of speed, right?

Gregor Hohpe: [00:31:43] Correct. Like when the first derivative is zero, things are in a steady state, cloud is nice, but it’s not going to really change the whole way you think about the idea. When the first derivative is not zero, if things are changing and they’re changing rapidly, that’s when the cloud operating model –the part that we said of the cloud that’s much more interesting– that’s when that really comes to bear. Sometimes, instead of return on investment, you should think about return on agility. What is my return on having the ability to react quickly if something changes. Yeah, if you want to look at it mathematically, that is really the first derivative.

Motivation for Moving to the Cloud [00:32:18]

Henry Suryawirawan: [00:32:18] And all these are really interesting to me because when I used to work with a lot of cloud customers as well. A lot of people in the IT industries, a lot of them actually, their motivation or incentives moving to the cloud is actually to save. So from traditionally managing on-prem, managing vendors, managing hardware by yourself into moving things into the cloud. Simply because of the cost benefit, there will be no more, what do you call it, capital asset, and everything now becomes operational expense. So it seems like from your explanation just now, it should not be the main motivation of why you are going to the cloud. Is that correct assumption?

Gregor Hohpe: [00:32:52] So saving costs is always good, right, especially good if you have to convince upper management of something, right? If you reduce costs, it’s always handy to have that argument. We’ve seen many customers, of course, reduce that cost with the cloud operating model. However, there’s sort of two corollaries to that. The one is the cost centric model is a very traditional IT one, which again, is based on the assumption of predictability. It’s “Dear IT, here’s my requirement. Please fulfill this requirement at the lowest possible cost.” What happens if this requirement changes? We all know in the old world, what that was called is change requests. I always say it’s change requests, have a certain sound attached to them. It’s usually called “Ka-ching” because the vendor easily makes you pay a lot of money when you have to change your mind. That’s how old IT outsourcing works. This is of course where cloud can do something very different. So what we see customers these days, they like to reduce costs but they just as much like the agility. They like the higher staff productivity: if you don’t have to manage all your infrastructure, people can actually focus on higher value things. That doesn’t mean you reduce your cost, it doesn’t mean you need to get rid of those people. But rather these people can do much more valuable things.

People are also starting to find that the cloud is much more reliable. You can fail over more easily. You can spin up more instances. You’re not going to run out of capacity as easily as you do on premises. So you can get into different availability zones. In the end, actually you have higher availability. And interestingly, slowly but steadily, folks are coming around to realizing that in the cloud, you can run more securely than you can run on premises. Right, I mean that’s probably a whole podcast on its own, but the cyber landscape has changed dramatically. The attack vectors have changed. So in the end, it is something that you need to have a lot of resources for to manage, and that’s something that the hyperscalers just simply can do better than an enterprise with their own data center. So I would say cost is still there, but the portfolio of benefits has actually broadened a lot.

The one I throw in though, and that is probably the most unexpected benefit, at least for me it was, when the first time I went to the cloud operating model, that was transparency. We don’t like to talk about it so much because which CIO wants to admit that the IT is intransparent? But yeah, go to any IT executive, and say, well, tell me like, how many servers do we have? How many of those are production versus staging? What’s the utilization? What application runs on it? Who is the owner? When was the last push of an application update? What’s the patch level? And basically, you get a three months project that basically gives you the wrong answer. So that’s what IT looks like, and there’s no shame because everybody looks equally bad. And that’s why I realized cloud actually gives you much better transparency. All these things become a simple report. Here’s all your workloads. Here’s the patch level. Here’s the last updates. So the transparency you’ll get improves significantly. And coming back to your cost question, of course, having improved transparency allows you to optimize much better. And that is also a big contributor to the cost reduction. So my favorite benefit with the cloud is actually transparency.

Henry Suryawirawan: [00:36:01] Right. So I, again, laughed when you said transparency, because again, I could relate with the story whereby we didn’t really know what is going on with our IT infrastructure. I remember one case in my previous company whereby we always ask this, “anyone knows about this system?” Maybe the guy already left. Nobody knows about it. Nobody wants to touch it, and sometimes nobody even accounted for it. So the system just runs somewhere in a corner of a room, probably. And if it’s down, some people notice about that and we need to support. So I think with the cloud, at least it gets more transparent. Even the cost itself is more granular, per minute kind of billing. And we can easily figure it out. Okay, what are the things that we have in our IT infrastructure? So I really laughed about the transparency there.

Cloud Strategy [00:36:43]

Henry Suryawirawan: [00:36:43] So speaking about all these different benefits that we have, seems like moving to the cloud is really beneficial, also if you want to run in a more agile manner. So coming back to the book title itself, “Cloud Strategy”, why do you think it’s important to have a cloud strategy? What does the strategy here mean?

Gregor Hohpe: [00:37:00] Hmm. Yeah. And first of all, going to the cloud is a big deal. There’s many tools, so many things that help you get there. But at the same time, as I said, it’s a lifestyle change. It’s also a major commitment. Often there’s a lot of money at stake. There’s longterm relationships that are being built. So I think thinking carefully about how you go to the cloud is well advised, that’s a good idea. What happens or what I see happen too much though, is that the journey to the cloud is driven by specific objectives. We want to be 80% of our workloads in the cloud by X date X, Y, Z. We want to be the market leader in this and that segment. So basically, people end up stating their aspirations, but when it comes to actually making tough decisions about how to get there, things get much more quiet. This is why the subtitle of the book is really called “a decision based approach to successful cloud migration”.

Like when people show me the strategy, the strategies they always, they look like a happy story book. “Oh, here we migrate our first workloads, and then we migrate more workloads and then we go to containers, and then we go to serverless.” And it’s like everything just becomes great, and they lived happily ever after. The enterprise reality, or even any meaningful size organization’s reality doesn’t look like this. You need to make decisions. Are you going to migrate everything at once? Or you’re going to migrate in bits and pieces? If you do bits and pieces, what’s going to come first? There’s a million decisions, right? Well, which cloud are you going to go to? What kind of workloads are going to go first? How are you going to change your operational support? Do you build up your operational support before you migrate something? Or do you do that after you migrate it? All of these are sensible ways to go about it. And your strategy is picking your path. I mean, in the end, you can have decision tree, with many nodes and plotting your paths through that decision tree. That is really the strategy. Proclaiming the end result is relatively easy. Navigating the decision tree is much, much harder.

So that’s what I’m trying to do in the book. Not tell you what to do, but to teach you how to think about your problems. You can’t copy paste your cloud migration from somebody else. Your starting point is going to be different. Your constraints are going to be different. Your needs are going to be different. Your competitive environment is going to be different. There’re many factors that want you to have your own strategy, but what I want to do is give you a building kit that makes it much easier for you to define that strategy. But it’s not a copy paste kind of exercise, and it will never be.

Building Up Cloud Strategy [00:39:36]

Henry Suryawirawan: [00:39:36] Speaking about copy paste, we all want to have best practice or best solution to certain thing, we can just replicate. But I think migration to the cloud is not easy. Simply because every company has their own situation, their own skill sets. The people also may not be aware about the cloud technology. Plus, there are so many cloud providers with their own so many products, right? There’re just insurmountable amount of things that you need to learn, and you need to also be aware of few things that are different between different clouds as well. So I think a strategy here makes sense. But how then should people start thinking about what kind of strategy that makes sense for them? Because these days, there are many big name cloud providers. There’s also a hybrid cloud model either on-prem and cloud, or multi-cloud. So there are so many different options. How should someone start with building up their strategy?

Gregor Hohpe: [00:40:25] Yeah. And you’re right. Often the strategy starts with picking the cloud provider. This is the classic IT playbook. This is like, we need a database, so I go to talk to Microsoft and IBM and Oracle, right? And I make a score chart, and I pick the database –ideally, you should pick an open source database– but it is a classic IT playbook. And what we find time again, though, is that the vendor decision is just one out of many decisions you need to make. I just recently wrote a blog post actually titled “How not to pick a cloud provider”. And it has clearly just comparing unit costs, it’s like applying the old way of thinking to the new operating model is almost guaranteed to lead to a poor result. A much better starting point is to really think about what are the business metrics I want to move? Why am I doing this? It’s not because of the tech are more interesting, or because my resume needs some boosting, right? I am doing this because I’m giving my business some capabilities that it didn’t have before. And those are capabilities that the business very much needs, like responding to uncertainty. Higher availability for the systems under high rates of change. These are all things that were very difficult to do on premises that are possible in the cloud. And then I can start tracking by those metrics. Right now, of course, there isn’t a push button, which says, improve my business metrics. No cloud provider has that. I wish. So now it comes to translating that into a path.

Now, the business is not going to be interested in each and every of your technical decisions. But what they might be interested in is the principles that you apply when you make those decisions. Let me give you a classic example. Do you want to think things through very carefully and make sort of one shot for a specific migration path? You figured it all out, you sorted out, your modernize and you’re just make it cloud native and you put it in the cloud and it’s just beautiful. It’s serverless, cloud native, uses everything as a service integrated with the operational frameworks–beautiful! But it probably took some time to get there. Or do you say, I prefer the shortest path to value. So I lift and shift the thing over somehow, maybe make some changes, maybe replace the app server with something open source, maybe replace the database. But by and large, I leave it as it is. Well, which way you’re going to go? That is a great principle to define.

That’s why I often say, do you want to have a principle of shortest path to value? And you need to be honest that the business would have said, of course, yes, we want shortest path to value because of course we want value. Then, as an architect, what you need to say is: “That is great, but keep in mind that the shortest path to value in the long run is a longer path than the straight shot.” In the book, I likened this to Pythagoras. If you can jump from bottom left to top right, from on-premises traditional monolith, all the bad things. If you can jump the diagonal all the way into cloud serverless, cloud native, that is the shortest path. But that might not be the shortest path to value. The shortest path to value is going to zigzag a little bit. So those are the trade-offs that business needs to understand, and principles that imply those trade-offs are a great way to guide your cloud migration.

Henry Suryawirawan: [00:43:36] So I really liked principle-based kind of a decision approach rather than which cloud providers should we choose. Because that is kind of natural for many people. We want to go to the cloud. Okay. Which best cloud providers should we choose? But instead, to start with the principles behind why you’re moving to the cloud? And what kind of business metrics that you want to change by enabling using the cloud? So I really love that principle based approach.

Patterns and Antipatterns [00:43:57]

Henry Suryawirawan: [00:43:57] Speaking about these principles, right? I’m sure throughout your career, you have worked with many different customers, many different people in the IT industry. Do you see some common patterns or anti-patterns that are interesting for us to learn from?

Gregor Hohpe: [00:44:10] Hmm. I said at the beginning, you know, somehow our business tends to be defined by a pendulum, that always swings back and forth. So we could see quite a few swinging pendula here, and the one that is eternal is always the multi cloud. How much do I want to be on a single cloud? And how easy do I want to make it to switch to another cloud, if I need to? On one hand, that is well advised, right? Because yeah, we talked about uncertainty. So if uncertainty forces you to change a vendor relationship, you should think about what that implies. But what we find time and again, is what is a very let’s say, “unarchitect” way of thinking is people falling into the extremes. The one extreme is like, oh, it’s just pre-defined. I go with this cloud provider because I liked their most recent event, and they gave me a nice t-shirt. That’s sort of the one extreme, and the other extreme is of course we need the over uber cloud abstraction, something rather framework. Basically, we’re going to build our own cloud on other people’s cloud. So that way we can do whatever we want. The problem is both extremes are probably equally bad.

As an architect, you’re dealing with trade-offs. It’s always a curve where the left and right end point is never the best choice. The best choice is somewhere in the middle. We see this pendulum swing back and forth. What people realize is when they want this multi cloud, uber something or other layer, their motivation isn’t actually all bad, right? They’re thinking about switching costs. Normally they call this lock-in, it’s a little bit of an odd term. For me, it’s really just switching costs. If you want to switch to something else, how much is it going to cost you? How long is it going to take you to make that switch? And then you can calculate what is the likelihood that this switch happens. Now, you can buy yourself options. You can abstract things away. You can run in containers. You can use open-source. Many, many options you can buy to reduce that switching costs. As we said, these options all come at a certain cost. Complexity or feature under utilization is probably the biggest cost that you have.

But there’s one option that I see enterprises much more dangerously neglecting. There’s this weird notion that the amount of lock-in is somehow set by the vendor. It’s somehow assumed like this vendor locks you in, because we’re like, some evil people want to take all your money or whatever you think, it’s somehow assumed that vendor does the locking in. I don’t think that is true at all. If you define lock-in as switching cost, your switching cost is dramatically determined by your organization’s velocity and agility. Like the rate of change you can handle and how quickly you can change things, that is at least as big a factor in switching costs than anything that the vendor brings into the equation. So let’s put it this way. Let’s say, you’re modern software delivery shop. Everything is CI/CD, automated testing, shift left, DevSecOps, whatever buzzwords you want to tie in, but basically you have a low friction software delivery. If you have an idea, you need to do something, you can implement and deploy this very quickly. Now, whatever reason it might be, you need to move things into a different cloud provider. Well, you take all your fully automated setups, right? You need to make some changes. Probably different IAM, different databases underneath, some different toolings. Yeah, you’re making some changes. But you have a well-oiled machine that can absorb these changes. You can test these changes. You can deploy these changes, and off you go. Now that low lock-in, if you wish with air quotes, that low switching costs is because of the way you operate.

The way I explain this is, this is the very reason that you find many startup companies not having all these tummy aches about a multi cloud strategy. The traditional businesses say, oh, well the startups don’t need a multi cloud strategy because they aren’t regulated. They don’t have anything to lose, blah, blah, blah. Bullshit, basically, right? Startup companies have a lot to lose. Fintechs are highly regulated. This is not the reason they’re not having tummy aches over multi cloud strategies. The real reason is their higher velocity, their lower friction. They have a lower cost of change. So if some change comes along, they just deal with it, and they’re not stuck for three years. They deal with it, and six weeks they’re up and running in another cloud, or maybe it’s even three weeks, and off they go. So in this pendulum that swings between this, like how much do I need to be committed to one end or the other? The part that I find is too much neglected is your own velocity. And that should be the biggest determinant of your switching costs, not whatever the vendor brings to the table.

Henry Suryawirawan: [00:48:52] Thanks for reminding us about this lock-in versus switching cost. Because you actually wrote a lot about this and discuss it online a few months back. What different levels of lock-in are there? Is it like software lock-in, vendor lock-in, hardware lock-in and all that? Thanks for reminding us actually, the lock-in is simply something that you have to consider from your own point of view. How much velocity can you do in the case that if you need to change, can you really do it fast? Versus if let’s say, you don’t have much IT skills, for example, so lock-in becomes more prominent even though probably the software or vendor part is not so difficult to move out from. So I think it’s a good reminder for all of us.

Cloud Is Not an Infrastructure Topic [00:49:29]

Henry Suryawirawan: [00:49:29] And another thing that you wrote in the book about common anti pattern or mindset difference is that cloud should not be an infrastructure topic. But all these days, people talk about cloud, it’s more about moving their infrastructure. Lift and shift like from on-prem to VMs or Kubernetes container and all that. Why do you think that it’s not an infrastructure topic then?

Gregor Hohpe: [00:49:49] Mm, Yes. And it often starts with infrastructure because that’s the classic IT model, right? You file a ticket, you get a server or VM, and then the rest is with the application teams. The reason that is no longer so is because we work in different ways. The reason we work in different ways is because the market has different demands for our applications. We need applications that can undergo a high rate of change while maintaining high reliability. In many people’s heads, they’re still back then. Back then, we do something quick and dirty, right? There’s always this perceived dichotomy between, oh, either I’m moving fast, or I do something high quality. And a couple of years ago it’s the analyst even try to make this sort-of official with these ill-advised two speed architectures. They said, oh, on the front end, you can be moving quickly because if you break something it’s not so bad, but your backend has to move very slowly because you have to be going careful. I will cite one chapter from the software architect elevator, and it’s called “Slow chaos is not order”. Just moving slowly doesn’t make things actually better. And we’ve actually found that moving faster often increases quality. That’s where all the automation, CI/CD, all these kinds of things come into play. In the end, you have higher quality, higher operational reliability at a higher rate of change.

Now, the reason that relates to infrastructure is because that way of working is no longer an infrastructure-centric point of view. I already said, right? It’s about CI/CD, about DevSecOps, about delivery pipeline and about software runtime. It’s probably also about your communications infrastructure, your service meshes. There’s a lot of stuff around it that makes this way of working possible, and that stuff isn’t infrastructure. So if you want the cloud operating model, you don’t want to look just at the infrastructure, you want to look at what I claim or what I call to be more often application centric cloud. Because that’s where you get the velocity and the agility. That’s where you get to move quickly. That is also how you reduce your switching cost. That’s how you reduce time to new feature release. That’s how you recover more quickly in case something goes wrong. So all of these benefits can not come from the infrastructure alone. They come from a nice interplay between application delivery and infrastructure.

This is probably one of the biggest shifts. I have a chapter in the book it’s called, “the cloud turns your organization sideways”. This plays exactly on this: it used to be, you have this nice infrastructure layer, then you have the middleware layer, and the application layer, and they’re all in their own layer. And it turns out, to actually operate in a modern operating model and a high-paced model, you basically need to turn this sideways 90 degrees where you work across the different layers. The folks who managed to do that, those are in the end, the ones who reap the benefits from the cloud migration. That’s we see time and again.

In-house Cloud Platform [00:52:38]

Henry Suryawirawan: [00:52:38] And another quite common that I see along with this cloud journey, since there are multiple clouds, since they have different options that people can choose in terms of products, services, and different ways of securing things, a lot of customers actually thinking about building in-house platform or in-house cloud platforms, so to speak. In one kind of abstraction layer to deal with different complexities. For example, different APIs, different products, different services. And you mentioned this in one of the chapter of the book as well. What do you think about this strategy of building in-house cloud platform?

Gregor Hohpe: [00:53:10] So I like platforms a lot, and I’m writing actually a book on platform strategy. Because I think platforms are something very powerful, and I’m also a pretty big fan of the Team Topologies book, where it talks about platform teams. The reason platforms are such a powerful concept, I mean, the cloud is a perfect example, is the platforms are something relatively stable and harmonized, but at the same time, they enable a high rate of change and a high rate of innovation. Sometimes, if I want to wake up our customers a little bit, I tell them that the cloud you’re buying is the same cloud your competitor is buying. They look sort of slightly shocked, and it’s like, yes, the principle of a cloud platform is standardization and harmonization, otherwise the thing cannot scale. But cloud computing has surely been the biggest innovation driver in the last decade and a half. So there’s something magic about platforms.

Now, the question is, how should you deal with that in-house? I’m a big fan of platform teams in-house. Actually at GovTech Singapore, I was working closely originally we were called application infrastructure team. And we didn’t like the infrastructure terms so much–for the reasons we just mentioned–so we became the engineering productivity team. And that was clearly a platform team. A couple of important things for such a platform team to succeed. A, make sure you enable. A lot of traditional IT, when they want to harmonize something or have an idea of building a platform, they’re thinking about constraining. They’re thinking about standards. You can’t use this database, but you can only use that one, and here’s the 17 quality gates you have to go through. They always think about constraining. That’s sort of the classic IT idea of application delivery being the wild west, and then infrastructure somehow having to come in, and restore law and order. Now, that model makes for great cartoon. It doesn’t make for very great IT. So platforms need to enable. That’s the first thing.

The second thing is the platforms you built can’t be cast in stone. Like successful platforms aren’t where you vision the future in five years, and you go to build that, and then four and a half years long, that future is actually in place. This is not how it works. If you look at AWS, we are a great example, right? It’s constantly evolving. It’s always taken feedback from customers. So an in-house platform also needs to take feedback. You can’t assume you’re smarter than everybody else.

The third advice I would give for in-house platforms: don’t rebuild what other platforms have already done. There’s at least three major cloud providers, maybe four or five, depending how you count. I haven’t checked our combined market cap, but it’s like somewhere 5 trillion plus. There’s a lot of smarts, and a lot of innovation, and a lot of things going in there. And that is huge value for you because all that innovation comes to you for like pennies an hour or micro pennies per API requests. It’s basically dirt cheap the way you get to consume that innovation. Don’t think that with a small in-house platform team, you are able to compete with that, and build some sort of abstraction layer that somehow magically keeps up with all the stuff that is underneath.

So if you follow those three points of advice that you enable rather than disable. That you take feedback rather than thinking you’re smarter than anybody else. And if you don’t replicate everything that is already there, I think you can have a very productive and very happy in-house platform team. Because you can make assumptions that are true in your organization that might not be true in all organizations. A platform like AWS needs to support many different enterprises and digital native businesses. So maybe you can narrow things down a little bit. That is totally fine. You can make smart defaults. You can define processes that are related to your industries. There’re many great things in there. But I highly advise you to follow the three ground rules of making an in-house platform team.

Henry Suryawirawan: [00:57:06] And also each of the cloud provider itself evolves, right? So their products change. There are new products coming out as well. How they interplay each other, I think is also something that sometimes the platform team didn’t foresee in the beginning. When they wanted to build a platform, they probably see, okay, this cloud provider provides this kind of capabilities now, but actually maybe one year after that, all things could change. You also have to maintain, or even change or refactor the kind of platform that you have built over the time, in order to keep up with the changes from the cloud providers. I think it’s also something that is very tricky to deal with.

Gregor’s Law of Excessive Complexity [00:57:39]

Henry Suryawirawan: [00:57:39] And another thing that is quite common, speaking about IT industry these days is about shiny object syndrome, or buzzwords. Then you have this law, which you call “Gregor’s Law of Excessive Complexity”. So what is the relation of complexity here and the, you know, like buzzword driven kind of development?

Gregor Hohpe: [00:57:55] Yes. And we talked about complexity a few times. I think in this whole exercise, complexity is your biggest enemy. Cause complexity slows you down. Complexity introduces errors. Complexity hurts your operational abilities in the end. Complexity is really the root of much evil. That’s why I say like, if you go back to the beginning, that’s really the options marketplace. Having options is great. Options cost you. The cost is usually complexity and finding a good balance there is probably what architects do. The reason I relate this to shiny objects and buzzwords is because being in IT these days can be like the kid in the candy store. All the stuff you have, all the different open source projects with like ridiculous names, and we have 200 services in AWS as well, like we add the other services from the other cloud providers. You just have stuff to no end.

And when you keep spewing out these kind of buzzwords, a couple of bad things actually happen. A, it doesn’t make a viable strategy. It’s just like a mishmash of like random stuff. And the other thing that it will also do is it will cause enormous complexity. You can’t just choose like a pile of random things that you think you need to have. It’s like going to the supermarket, and there’s all these great fantastic foods you can have, and you like all of them. So you pick the popcorn, and you pick the pasta sauce, and you pick the steak and you pick all this kind of stuff because you like all of them. You put them in one big pot and you cook this, and nobody’s going to want to eat that. It’s going to be like inedible. So IT strategy is like this. You can’t fall victim to the buzzwords. You need to have in mind, what am I going to cook? Get the right ingredients for what are you going to cook, and put the right pieces together. You can’t just randomly mix and match buzzwords.

The reason that relates to Gregor’s Law is it comes back to having the options. Having options is nice. But in the extreme case, you will find folks who want all the options. Oh, what if this happens? What if I need to go in another industry? Oh, what if I need to change my technology? What if I need to operate on Mars? What if the aliens invade, and I need to be prepared with my IT infrastructure? I just need to have all the options. These are the people who never want to make a decision. Their decision is to just have all options available at all time. I’ve seen this, and I coined this Gregor’s Law, and that goes as follows: excessive complexity is nature’s punishment for organizations who are unable to make decisions. Somebody who wants everything, who’s just like blinded by all the buzzwords. It has to be this, and it has to be that, and it has to be able to do this. They suffer from excessive complexity, and that in the end is what slows them down.

The weird part of it is, the ironic part is often they took this route under the idea that somehow it would reduce lock-in. Because they want to have all the options like, oh, if I have all the options, I’ve never really locked into anything. But in the end, they’re locked into their own complexity more than anything else. And that is nature’s punishments, right? That is the essence of Gregor’s Law. So go make some decisions. Make conscious decisions. Take some options, but also make some conscious decisions. That way you get the complexity down and your life would be much happier.

Henry Suryawirawan: [01:01:11] I really love that law. So excessive complexity is nature’s punishment if you are unable to make any decision. Thanks for reminding that. And I think I could relate to all this as well. Sometimes we just want all the options available, all the cool technologies out there, but actually we are like stuck in all the complexities. Like first of all, having to learn each of the technology, and also how they interplay with each other, right? And the second thing is that what are the available people to support all this complexity?

Organization Structure [01:01:37]

Henry Suryawirawan: [01:01:37] Maybe last question on this cloud strategy. How should an organization actually embark on this journey? So how do you structure your team? How do you upskill your people? How do you actually go about it in terms of organizational level?

Gregor Hohpe: [01:01:51] Yes. And it’s always a people topic. The transformation and the tech is all available more than you probably will ever need. So in the end, it’s really changing the way of working. If you don’t change the way your organization works, the cloud is going to look much more like another data center. We have very nice data centers, but no IT executive I’ve met ever needed another data center. So you should change the way your folks operate and think about it. I actually have a chapter in the book, right? Because we always talk about the five, six or seven “R"s of migrating applications. So actually define the “R"s of migrating your workforce. Because you also need to re-skill, sometimes replace, sometimes retire your workforce.

Couple of things I always say upfront. The most common concern is IT executives come to me. It’s like, yeah, I get all this cloud stuff. I really want to do it. But I don’t have the right people. It’s always like, I don’t have the right people then I can’t hire the right people because I’m a boring XYZ company. I’m not a Silicon valley hot shot. I usually pause the conversation right there, and I make people take two very important factors into account. A, if you think your people are risk averse or they don’t want to change, or they don’t like to sort of work in this new environment, you made them behave that way. When I was in kindergarten, nobody was thinking about lock-in and being risk averse and not trying things out. Your organization taught people that taking risks is not rewarded, but it might be punished. That there’s no support for experimentation, trying new things. Your organization taught them that. So now, you’re liable to unteach them that. Because if you’ve been teaching that to them for 20 years, you can’t say you have the wrong people. You have exactly the people that you taught them to be. So don’t come to me now and say, oh, I need a different kind of people. You taught them, you unteach them. That’s fundamental number one.

Fundamental number two is most of the time, you actually have the right people. The favorite story there is an old interview with Adrian Cockcroft who also works at Amazon, where somebody says (well, he was at Netflix at the time, of course a super sexy, super hot company), he says, you can do all these things because now you’re at Netflix, you have all these great people. And Adrian answered. He said, well, do you know where we hire them from? We hired a lot from your company. People of course have the blank stare. So you probably have the people. They’re just being held back by your system. Friction is high. Everything takes forever. You have 20 approval processes. You can’t get anything done. People are being slowed down. So for me, the people transformation story always starts with you taught them, you unteach them. And your base assumption should be you have the right people. Unleash their potential, and you might be positively surprised what actually can happen in your organisation.

Henry Suryawirawan: [01:04:41] Wow. So thanks again for reminding us. Because sometimes, we think that, oh, to be cloud averse, we have to have a great enough people talent, and we can’t hire them because they are first of all, maybe not many are available out there in the market, because a lot of companies are trying to recruit all of them. Speaking about getting the talents, maybe you should look inwards, try to upskill, or maybe remove all the constraints or what you said is unteach them the constraints that they know. And start to let them play with experiments in order to learn and also gain the benefits of learning along the way. So really loved that.

3 Tech Lead Wisdom [01:05:16]

Henry Suryawirawan: [01:05:16] So Gregor, it’s been a really pleasant conversation. I really loved this a lot. But since we are out of time, I only have one last question that I normally ask to all my guests, which is about the three technical leadership wisdom for you to share with all of us here so that we can learn from your wisdom.

Gregor Hohpe: [01:05:33] Yeah. It’s a great topic. Thanks for the chat. We could talk a lot more. Yeah, so I think there’s more than three wisdoms, but if I had to pick three, the first one that comes to my mind is I recently saw a blog post that’s actually from Corey Quinn, he posts a lot about cloud and AWS. And he said, you’re not the technology you work on. You’re not a server-less developer. You’re not the cloud native developer. You’re not an AWS developer. You’re not a GCP developer. This is just tech stuff that comes and goes. What you create is much beyond that. And I think being an architect is at the very essence of that. Don’t lock yourself in with the technology.

The second one relates closely what we said about buzzwords, right? I have a lot of frustration with people who spew out buzzwords. So this is sort of in the corner of Richard Feynman. I always say, if you can’t explain what you’re doing and what you’re proposing to do in plain English, you just simply don’t understand it. There’s no excuse for confusing people. I always say your IT shouldn’t look like an episode of the old Battlestar Galactica where they’re like, oh, we need to go seven quons to reach the proton something or other, they speak this cryptic language that nobody knows. Technology shouldn’t be like that. You need to make yourself understood. That way, you get buy-in for the decisions, and you best do that by shunning all the buzzwords.

And the last one comes back to Gregor’s Law. Complexity is a punishment. Complexity is your biggest enemy. So go, don’t be afraid to make some decisions. Reduce the complexities, you don’t fall victim to Gregor’s Law.

Henry Suryawirawan: [01:07:06] I really love when you said that if you can’t explain it in plain English, most likely you don’t understand it. So I think it’s also something that we need to ponder. For example, if you want to propose, let’s use Kubernetes, can you explain it in plain English without all these jargons and terms like containers, orchestration, scheduler and whatever. I think it’s really a great reminder for all of us. Before we propose something, we probably should be able to explain it in a simplified manner or plain English, so to speak. So Gregor, if people want to have more conversation with you, or find your work is there a place for them to find you online?

Gregor Hohpe: [01:07:38] Yes. My home is architectelevator.com. There’s also cloudstrategybook.com. So I’m relatively easily found. I’m quite active on LinkedIn. So that’s also a good place to interact, and I’m also equally active on Twitter. It’s G H O H P E is my handle there. Twitter is more a mix of opinions and random stuff, but I also look out, follow the people for advice on Twitter. So it’s really a community I actually like quite a bit. And always look forward to hearing back, to hear feedback. So please don’t be shy to post anything online. I’ll be happy to see and respond to that.

Henry Suryawirawan: [01:08:14] And I highly recommend the book as well, Cloud Strategy, including also the Software Architect Elevator, which is also quite insightful in terms of how do you become a great software architect. So make sure to check those books, and support Gregor in all his writing. So thanks Gregor for your time today. It’s really a wonderful conversation. So hope you good luck for whatever that you do next.

Gregor Hohpe: [01:08:34] Yep. Thank you so much. And I know what I’ll do next. I’ll write on the platform strategy books. So maybe we’ll talk again in a few months or a year, about what that came out to be. Thank you for the time. Thanks to all the listeners who are listening to the podcast.

Henry Suryawirawan: [01:08:47] Right. Looking forward to that.

– End –