A Leanpub Frontmatter Podcast Interview with Gregor Hohpe, Author of 37 Things One Architect Knows About IT Transformation: A Chief Architect's Journey
Gregor Hohpe is the author of the Leanpub book 37 Things One Architect Knows About IT Transformation: A Chief Architect's Journey. In this interview, Leanpub co-founder Len Epp talks with Gregor about his background, his education in Germany, his time at Stanford, the impact of our current political moment on the tech sector, what it's like working at Google, why insurance is interesting, his book, and at the end, they talk a little bit about his experience as a self-published author.
This interview was recorded on February 12, 2018.
The full audio for the interview is here. You can subscribe to the Frontmatter podcast in iTunes or add the podcast URL directly.
This interview has been edited for conciseness and clarity.
A Leanpub Frontmatter Podcast Interview with Gregor Hohpe, Author of 37 Things One Architect Knows About IT Transformation: A Chief Architect's Journey
Len: Hi, I'm Len Epp from Leanpub, and in this Leanpub Frontmatter Podcast, I'll be interviewing Gregor Hohpe.
Gregor is a former Chief IT architect at Allianz SE, a giant German financial services company based in Munich, and he is currently Technical Director, Office of the CTO at Google in Singapore.
Gregor is a popular conference speaker, and well known as co-author of the Addison-Wesley book, Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions.
Gregor is the author of the Leanpub book 37 Things One Architect Knows About IT Transformation: A Chief Architect's Journey. His book is based on his two decades of varied experience, from software engineer to author, to Chief Architect of a large, multinational company, and is intended to help IT architects understand how to meet the many challenges of orchestrating IT transformation in the enterprise.
You can follow Gregor on Twitter @ghohpe, and check out his website at eaipatterns.com.
In this interview, we're going to talk about Gregor's professional interests and background, his books, and a little bit about writing and self-publishing.
So thank you Gregor, for being on the Frontmatter Podcast.
Gregor: It's my total pleasure, I'm happy to be here.
Len: I should say that Gregor is talking to us from Singapore. I want to thank you for taking time out of your morning to speak to me.
I usually like to start these interviews by asking people for their origin story, and I know you've got a lot of experience in a lot of different areas. I was wondering if you could talk a little bit about where you grew up and how you first became interested in computers, and made your way into computer science?
Gregor: Tn my case, that's actually a fair amount of time ago. When I started, I always liked to build stuff. Mostly construction kits - physical things. Somehow that was just my natural inclination. And our school had a single computer. It was those days when the first computer appeared.
I used to say, one of the reasons I liked it was because it was easier to fix problems. If stuff broke, with software you could fix it, and run it over - versus the mechanical stuff that oftentimes actually physically broke. That was very frustrating if you didn't have the right parts. So I was drawn to computers as a way of experimentation.
I also did a lot of electronics. Again, this being a while ago - it was very simple electronics. I remember having a electronic kit that had a single logic gate. One logic gate that was basically electronic kit. But at the same time, I learned quite a lot. Even as simple as it was, by thinking about stuff in components, in pieces, like the electronics do.
So it was a little bit mechanics, a little bit electronics. And the school had this magical computer which you could start playing with and do stuff. I think that was what what motivated me.
Len: Education works a little bit differently in Germany than it does in North America. As I understand it, students can get separated into streams early on. I wanted to ask you if you had an experience with that?
Gregor: Correct. I went through that. What happens is that after elementary school, you do four years of schooling. After that, there's three tracks that you can take. And to be honest, you're about 10 years old - so your parents largely decide for you, with you, with the teacher. Then you enter one of these three tracks. One track is meant more for the vocational kind of career path. Later, you will do an apprenticeship. And then the other tracks are meant if you're bound more for university.
It's an interesting concept. The way I always looked at it, is that there's two interpretation of equal opportunity. The one is, everybody gets the same kind of education. That's equal opportunity of a sorts. But the other one is also - you give people the kind of education that matches a little bit. The interest and development at the time. Germany seems to follow the latter one. Where you have a slightly different path, relatively early on.
Len: And what if you find yourself to be in what you believe to be the wrong path? I've always been curious about this. Can you correct that?
Gregor: Correct. There is an upgrade path, from the middle track, if you wish, to the university track - you can actually upgrade. It does happen. There's late bloomers. There are folks who'll change their interest. So there's an upgrade path. You basically do an additional three years at the end, and you come out basically as if you had taken that track.
Len: I guess the only answers to this can probably be anecdotal, but what happens if, let's say, a kid disagrees with their parents about which track they should be going into? It would be pretty hard to live together if you disagreed.
Gregor: Yeah, so what rather happens is actually that once you turn 18 years old, you're legally authorized to decide your own schooling. So if somebody was signed up for the extensive track, which would take you right there, you'd be like 18, 19 years old when you would finish.
Some kids just quit and say to their parents, "Today I turn 18 years old, and I never wanted to go to high school" - this is still high school - "or for high school that long. So that's enough for me, thank you very much." That does happen. It usually puts a little wrinkle in the parental child relationship though.
Len: Did you study computer science at university in Germany?
Gregor: Yes, so for me, by the time I had finished high school, at that time, finally computers became a little bit more affordable. There was the Apple II. There was the Vic 20. A lot of folks in my generation grew up with these kind of things. So by that time, it had become relatively obvious that I would go into computer science.
When I was little, I was always aiming to be a mechanical engineer, because that seemed to be sort of the most creative technical path for me. But then by the time I exited high school, it was relatively clear that computer science was the one I would want to do.
I was largely self-taught. What I wasn't quite prepared for was the science part of the computer science. So when we started university, there was actually a lot of theory behind it. Compiler theory and computability theory and all these kind of things. In hindsight, as so often, it was probably good for me. It gave me a good foundation.
But it was a little bit of a shocker for many of us who joined university, because in the first semester, there was essentially no programming. It was all the theoretical foundations of computer science. I guess it is called "computer science" in the end. So, I would say that's fair enough.
Len: I have a question that I often ask of people on this podcast. It's become kind of an unofficial theme. It is: if you were starting out now to pursue a similar career to the one you've pursued, would you study computer science formally at university?
Gregor: I certainly would. How do people say it - before you can do things, or before you're allowed to do things wrong, you first have to learn to do them right. Often you hear these stories where people just break all the rules, and sort of seem to freelance and ad lib everything.
Often artists, let's say architects etc., they seem a little bit crazy and ignore all formalities. But most of the time, you find out that first they learned how to do this properly, if you can even use that word - Picasso is a great example. Like, "Wow, I could paint this kind of things." No, he was properly well-trained, what we consider a normal painter, even though that's a difficult term to use. And then people progress into becoming more creative or becoming more unique. So my personal opinion is, it's always good to have a proper foundation, and then you can play on top of that.
Len: That's a really great answer, thanks for that. I haven't quite put those things together in my mind with computer science before. But yes, coming at things from the perspective of - let's say teaching English literature in university, which I have a little bit of experience with - often you can get students who want to jump ahead and start being very creative, rather than constructing formal arguments and marshaling evidence for them.
I do remember having to say to people, "Of course experimentation is great, but before you get there, you have to prove to me that you can do the conventional things." There's time for the creativity, but that time is not until you've proven that you've got the foundation you need, in order to even understand how you're being creative in the first place.
This might seem a little bit random, but I've heard from German friends that the conventions around attending classes can be a little informal in German universities. Does that accord with your experience? Where people kind of walk in and out of lectures?
Gregor: Yes. But I believe Stanford in the end has a similar thing. I mean, you are responsible for getting something out of your schooling. I would say the big difference is that the German education is free. So for a lot of people, the pressure seems to be lower. And people are just like, "Well, if I don't make it this semester, I make it the next one," right? If you do that at Stanford, either your scholarship will run out, or your parents will have a very serious word with you, because the extra quarter is going to cost them a nice dime.
I think there's a little bit more drive behind really getting something out of the time you spent there. Because there's some folks in Germany, I think, who misinterpret the freedom to attend class or not attend class, if they like. So basically, it's the same rule, but I would say it has slightly different dynamics around it.
In Stanford also - I mean, being in the middle of Silicon Valley, we had a class on entrepreneurship. And some of our guest speakers were like - Steve Jobs came to class, Scott McNealy from Sun came to class. Jim Clark of Silicon Graphics. Those were the biggest names of those days - Reed Hastings, still very famous for Netflix. Those were the folks who came to our class and gave guest lectures. So you want to be there.
Len: That sounds really exciting. And you were there at a very exciting time in the early- to mid-90s. I wanted to ask if you could express a little bit of what it was like to be studying computer science at Stanford at that time? I mean, this would've been around the time when the internet would've been burgeoning - coming to public consciousness.
Gregor: Actually those were the days when I got the Mosaic browser. And we had internet in our dorm room. So we were definitely right there when this was happening.
To be honest, I was probably a little bit overwhelmed by the whole thing. I had a scholarship for one year, for three quarters. And the computer science topic - I used it mostly to broaden my range. So there was artificial intelligence, there was a lot of robotics.
I spent quite a bit of time, I felt, completing my computer science portfolio. And also taking entrepreneurship classes. There was a lot of what was called "engineering management" there. That's probably where you could feel the most that something was happening.
But to me, having come out of the German village, if you will - I was a little bit overwhelmed and I probably didn't grok 100% what was really going to happen over the next 10, 15 years.
I thought, "Oh this is all kind of exciting." But funnily I looked at it mostly from a technical side. "Oh, there's a browser, I can look up some documents," right? And we had some ideas about, "Ooh, could we start a company out of it?" But then we're just like - we don't really know where this thing is going to go." And then many of us actually took regular jobs. Of course the guys who didn't, some of them became extremely successful. But it was very interesting times. For me it was new, but it was also a little bit confusing - embarrassingly, I have to say. I didn't quite get it at the time.
Len: And when you left Stanford, did you move into a job at a conventional company? I know you got involved with a startup at some point as well.
Gregor: Ironically, I was just a tiny bit ahead of the curve for the startup machinery to really get into gear. It's hard to believe - at that time, the visa situation was relatively difficult. It wasn't so much that it was difficult to get an H1B visa, but many companies were't actually used to it that much. And then with a small startup company, because an H1B visa is tied to the employer - that was a relatively risky thing.
So I actually ended up going into consulting. Which probably, from a pure financial point of view, wasn't the cleverest choice, because of the crazy upside that the startups bring. But I always liked having the theoretical foundation for my computer science, and I also always liked seeing the software in people's hands. And people being able to use and get value out of what I did. At that time, because the internet was just sort of getting started, consulting seemed the best way to do so. You would build solutions for customers. AndI stayed in consulting actually many, many years - because I enjoyed that aspect.
Len: You write in your book about the kind of parallel universe that you exist in when you're a consultant. I wanted to ask you a little bit about that.
There's a parallel universe and career pathways that you write about. But you also write about the fact that - one of the criticisms that people can have of consulting is that the consultant is not tied to results, often. They come in and do something and leave. Or rather than build something, just give advice. I wanted to ask you about how your opinion about that has evolved over time?
Gregor: That's always a slippery slope. The strength of the consultant, of course, is that they see many different companies. So, take one customer trying to undertake a certain system implementation etc. - the consultant's strength is they're often seeing the typical mistakes. They're seeing what can go wrong. And that is the expertise they bring. That model only functions if the consultant has access to different client environments.
It can also be an advantage that the consultant isn't bogged down in the internal processes. In the book, I refer to it as the parallel universe - it's that you have a separate career track. You don't need to get promoted in the organization of your customers. And often, interestingly, that makes you a more trusted resource, because in some organizations, there's some in-fighting, there's some competition.
So when somebody suggests to do something, all the other people have the feeling that, "Maybe they're just pushing the agenda? Maybe they will take the credit for it?" Being a consultant makes you immune from this, and often puts you in a better position to be a trusted adviser.
The slippery slope is, of course, a lot of consultants do give you clever advice, then they move on. And if it doesn't work, they tell you it was an implementation issue.
I think this is the professional ethics you need to bring with you as a consultant, to make sure that you have a actual trusted relationship and a vested interest to really advise your client. I think if you do that well, you can combine the two things. You can bring the strength, but still be tight enough, close enough with your customers to really see things through to completion.
Len: You also worked on a contract for the state government of California, if I understand it correctly. I was wondering if you could talk a little bit about what that experience is like, as perhaps contrasted from corporate consulting. What's it like working for a government?
Gregor: Yes, basically I went from Stanford, Silicon Valley to doing work for the government. Which sounds maybe like a little bit of an unnatural choice. Again, it was a sequence of events. It was early in my career. And telco was the hardest thing at the time. Which is funny, because now often working for a telco company is very competitive and very difficult, because the digital companies basically took 90% off the value chain, if you wish?
Back then, telco was very hot and I wanted to work in telco. They didn't have a position for me in the consulting company. They had a quite charismatic vice president, who I'm still in touch with today, who said, "Well, why don't you come to Sacramento and we do some really interesting work for the government." I'm like, "Mmm, isn't that an oxymoron - doing interesting work for the government?"
It turned out to be actually true. The State of California is a very large organization. At the time, it was the sixth, seventh largest economy in the world, considered as a state of its own. So like the size of France.
Big money was flowing through there in state income taxes. Because they were a state agency, they had a lot of rules and regulations around how they could spend money. And one way to deal with that, was to offer a contract that was purely around benefit achieved. So we as a consulting company, as a provider, would only get paid if the software we produce saves the state money, or brings additional revenue. Basically, if it becomes a more efficient organization.
In an ironic sense, you could almost say we did something that was agile, in the sense, that agile software development is very value-driven, looking to optimize the value the client achieves. In some sense, maybe there was a very early, if a little bit commercial, interpretation of that.
It turned out to be actually super interesting work. We built large custom systems. We had a lot of freedom. Because in the end, the customer had to trust us that this would actually create value. And we had to trust ourselves that it would. So ironically, yes - the days working for the state government in California, was some of the most interesting software development I did throughout my career.
Len: And you did work for a start-up for a period of time, I recall from your book. It was exercise equipment?
Gregor: Yes. That part in Stanford did work out. Of course, people come together and people are like, "Well why don't we do something," right? "Why don't we start a company?" The idea was to - I was never much of a gym person. I liked outdoor sports. I'd always felt like a hamster if I went to a gym. And of course, Californians, always being a bit progressive on the exercise routine side - the idea was born: how about if we make this hamster exercise model more interesting using technology?
So the idea was that you would be on a treadmill or on a bicycle, and you would have a video stream. And the video stream would interact with the exercise machine. So we filmed a hike up the half dome, or biking around San Francisco. And when there was a hill, your bike would actually become harder. We could electronically control the resistance in the bike, or the treadmill would actually lift up if there was an uphill.
I built this electronic integration, and I still have to say - a good test for your product is always: do you have fun using your own product? And I have to say, in this case, "Yes." It was actually a lot of fun using your own product. Seeing this video. Seeing the hill come up, and as soon as the hill hits, the treadmill lifts up and you have to make it to the end of the slope. So it was in fact actually quite engaging.
Len: And how did it end up, the business?
Gregor: There were two challenges. It went on for quite a while. I ran out of my student work visa, so that was, for me, the defining moment to go do something more stable. Because I needed this H1B visa.
There were two challenges though. The first one was, we didn't really understand that industry. Which sometimes can help. So some healthy naivety can help. But in our case, we were too small to learn as we went.
And the biggest technical problem was - and it's going to sound funny - there wasn't any broadband internet. People had dial-up modems on telephone lines. And this multimedia content that we used, the only distribution channel for that was DVDs and CD-ROMs, actually. Many years later, Netflix started mailing DVDs in the mail, because even then there wasn't enough broadband.
So the idea of this streaming video content - that wasn't technically feasible. It was a distribution model with CD-ROMs, and scaling that out became quite difficult. The company lived on for quite a while. Got acquired. This happens quite a bit.
In the end, I think the idea was sound. We had a lot of fun. We didn't get rich. I think it was still a fantastic thing to do.
Len: I know you eventually ended up at Google. I want to ask you about that. You got there at an interesting time, shortly after it IPO'd, I believe.
But before we talk about that, you moved abroad to study. You've worked in many different countries - Germany, the United States, Japan and now Singapore. And we're at an interesting time with respect to discussions around immigration and visas and things like that. The discourse in the United States is distinct. There's Brexit happening in the UK.
I've interviewed a few people from the UK on this podcast, and asked them about their experience of that and how they think the current discussion might be affecting the mood in the tech sector. I wanted to ask you about - I'm going to be really general - about what's going on? Because it is hard to kind of contain entire discourses like around Brexit or what's happening in the United States.
Gregor: Yeah, and it's definitely affected the mood. I have some friends who actually packed up and left the US and moved to Mexico, I would say half out of protest and half out of all their personal conviction. It definitely hits a nerve with people, which isn't surprising. And it also - even from a sort of - I almost want to say, nuisance level. I mean it has impacted a lot of events that we go to. Like academic events or developer conferences.
Because people start wondering. It's like, "Well, if I'm hosting an event in the US," which often the natural destination for high tech kind of things, "how the visa policy's going to change? I'm going to have attendees who are not going to be able to go there." So even at a tactical level, and at a mood level - people definitely notice, and people are aware of it, and generally people are not happy about it.
To me it's an interesting dynamic that's going on there. I reflected quite a bit on this. So on the one hand, of course - the internet, even by name - the "inter" net. It knows no borders. This is a global phenomenon, and it's grown - largely because it is a global phenomenon.
If you look at Google or Facebook, these are global products. There isn't a Facebook Japan or there isn't a Google search - there'slanguage variations etc., but the product is basically a global product. And if you're in the business of information sharing and search etc., that is the natural thing to do. You want to see us as much as you can.
At the same time, we have to be conscious that all the technology that we build has increased the social divide. It's a huge uplift for folks like us. We have the Stanford degrees, we work for the Googles etc. All this rapid movement in the industry and in the technology, that is a huge booster for us. And we have to be conscious that it's not necessarily the same booster for everyone.
Now at some point, that leads to backlash. With people saying, like, "Hold on. This is the stuff that makes my job go away, that threatens my livelihood, etc." There's not only upside about it. For the Silicon Valley engineers, it's like, well, any new thing that comes out basically increases your stock options. So everything is great from that perspective. But this isn't universally true.
I think there is a reason, there is tension. Of course, most of us are not happy with the election results and the Brexit. And we think many of these kind of undertones are dangerous and very short-sighted.
At the same time, I think we have to look in the mirror a little bit, and see that there is a dynamic that made this happen. It wasn't - and I say this bluntly - it wasn't the case that one day everybody just became stupid, and decided this thing we really don't like.
There's a certain dynamic behind it. I think it's good to look at it from both sides. Personally I of course hope that we get things to be back in balance a little bit. And as I said, the technology and the things that it enables, really is the basis for more global integration. So countries splitting up, is of course going totally the wrong direction. It's a dangerous direction at the end of the day.
Len: It's interesting you bring up the divides that are happening in our society over time, and then linking that with technology and the emergence of this sort of globalist internet.
It led me to think, while you were talking, about an interesting remark that the President made, with respect to technology, about a 400 pound guy in his basement.
I found the President saying that to be so striking. Because in the world that I live in, I understand what computers are, and what technology is. But to a lot of people, there's something that sets tech and tech companies apart from other companies. So the same person that might not get at all bothered by some kind of anti-competitive activity undertaken by, say, something like Walmart, which people still see as not a tech company, although it's changing it's own image and approach around that - but there's something about [tech] that people get excited [about] in a special way. Sometimes negatively, sometimes positively.
There are people who are on the other side of the digital divide, simply just not really understanding what's going on, and the tech world is this figure of fascination. And to some extent, dismay, and something that people associate with things that are keeping them back.
What do you think about that? Do you think there's something special in people's imaginations about the tech sector that sets it apart?
Gregor: That's certainly a broad, a little bit touchy subject. I think the idea or the concept and the concern about the digital divide has been around for a long time. Actually I just remembered - I took a public speaking class back in Stanford. This must've been '93 or '94. And the topic I chose was actually around the digital divide, at that time. Because the internet was coming, and we were the Stanford students. We realized at university we have access to all this. But even we at home, and nobody else, basically, had.
And the history tells - whenever there's movement in the system, whenever there's innovation; this can be on the technical side, or can also be that a political system gets loosened up - the spread widens.
The post-Soviet Union is probably the best example. It was kind of a stable system for a long time. Suddenly things really loosen up, things get moving, and immediately you'll find some folks who will benefit from this hugely. And then you have exactly the vice versa. So I think the dynamics of it are known.
Now the worst thing you can do, of course, is fuel the divide. The worst thing you can do is demonize or mystify the thing that's going on. Because in the end, you're just exploiting people's skepticism, or sometimes their lack of knowledge about it.
I'm definitely not a fan of actively fueling this, or spreading any kind of stereotypes. I think in the end, you should do rather the opposite. The best way - luckily in this case, it's not machinery or a political system so much changing. It's actually a relatively accessible technology.
I think that's one thing that even with cloud computing and a lot of things, like the Raspberry Pi's etc. - the entry level into programming and into technology from a financial perspective, has become extremely low. You can get a cloud shell and start programming in a browser for basically next to nothing. You can get a Raspberry Pi for like $35. So in the end, that part is definitely positive.
What's probably missing is, for people to have the trigger, the access to the education. Maybe motivation also, for people to take advantage of this. But I would say, interestingly, that the hard barriers to access this technology have actually decreased enormously. You to have to have like 10 million dollars to buy a computer. Now for a few dollars, you can do that. With a little bit of luck and a little bit of wishing, maybe this helps compensate that. But I think it won't fix itself. Folks have to actively try to bring the gap down.
Len: And you moved on from consulting to Google in 2005. I was wondering if you could talk a little bit about what that experience was like, suddenly joining this giant and rapidly growing company at such an exciting time?
Gregor: It wasn't quite as giant at the time. It was in its amazing growth phase.
What happened to me is what happens to most consultants: the travel burden. You're always on the road. The US is a very large country. I was on the West Coast, and had weekly trips to Chicago, weekly trips to Atlanta. Ultimately that wears a lot. So the time came when I'm like, "I like working with customers, but I'm a computer scientist, I'm not a flight attendant in the end." I needed to find something where I wasn't going to the airport every week.
And Google actually called me in the end. A lot of Google recruiting was done through referrals. I had the luck that some of my buddies had already arrived there. They referred me, and I joined there as a software engineer, doing large-scale Java refactoring. Adwords frontend, a large Java application. It was definitely a major shift.
I would say, in my career, I've rebooted quite a bit. I mean, start-up to consulting is a big change. Consulting to an internet giant is a big change. And there's a few more big changes. So these days, we might call that a "pivot" - that might be the fashionable word for it? For me it was more like - let me do something completely different.
Google was amazing. I mean it always has been. It was much, much smaller. I don't remember exactly. It was a few thousand folks at the time, maybe two, three thousand people?
Again, the interesting thing is - as these things happen, if you look back now, we're like 80, 85 thousand people. You're like, "Wow, what was it like when it was 2,000 people?" But when you were there when it was 2,000 people, it's just 2000 people. We didn't know it was going to be 85,000 people.
It's like the internet a little bit. We didn't think anything too special about it. We had work to do. We did fun stuff. It was search and ads, largely - maps was coming around. YouTube wasn't there in the beginning. Android wasn't there in the beginning. So it was - I don't want to say, "humble," but it was a smaller kind of operation with very focused engineers.
I think the one thing that hasn't changed, is really the quality of the engineers. Google has always been able to attract really good people. And it was fun working alongside those folks.
Len: You mentioned that your experience working for the Government of California was unique in the sense that you only got paid if you delivered. As I understand it, Google has something that might be described as similar to that, where you're being measured, and you always have to be delivering. And this can be one of the things that makes it exciting to work there. Is that a correct characterization?
Gregor: That's correct, but it's a very fine line to walk. I would say Google is the kind of culture where people have an extreme degree of freedom to achieve the goals they have set. Which sounds very natural. That's what you like to do. You give people something they should be doing, they should be achieving. Then how they get there - you leave this out, you leave this up to them.
A lot of traditional organizations don't do this though. They regulate what kind of chair you can sit on, and what can be on your desk, and what you're wearing, and when you come to work, and when you have a meeting. They tend to regulate a lot of the ingredients, if you wish, whereas Google leaves you a lot of flexibility. So you can have your dog at work and skateboarding shorts. The usual Google image.
What I would warn people off, is that sometimes when people see that image of the digital giants, they think it's like a summer camp, it's all like loosey-goosey, and people are there with their dogs and shorts and skateboards. That is not actually the case. It's a very successful business. Facebook and Amazon's just alike. In the end, they are result-driven - as they should be. But they do give you an enormous amount of freedom in how you get there.
I would say if there's trusted leadership, and if there's the right role models in the organization, this actually works quite well. It puts a little bit of discipline on us as engineers, because everybody knows there's breakfast and lunch and dinner and laundry and oil changes and whatever on site. If you don't pay attention, you might be spending 24 hours there. But in the end, that is not the intention.
The intention is to give you all the things you need to be comfortable, so you can focus on your work. And you decide how much of that you do. Because in the end, it's only the outcome that's measured. You're not measured by how many hours you spend at work. If you have a great idea, and you get it done in the morning, and you feel like, "That was a good day," you're free to go home.
Len: Speaking of places that aren't summer camp, you moved on from Google to Allianz, which is a giant - I'm not saying this as a negative remark about Allianz, I'm saying it as a mark of respect for what they do - a giant global insurance company. What led you to make that decision, to go from somewhere like Google, to move from Tokyo, I gather, to Munich, and to work for this insurance company?
Gregor: Yeah so a large insurance company is not summer camp. People wear suits and ties. All my co-workers asked me when I joined, "How come you don't have to wear a tie?" And my answer was, "Well how come you do?" It's like, "Well everybody does." And I'm just like, "Well that doesn't mean you have to." So there was definitely a little bit of a cultural challenge.
So yes, a very different environment. Larger. 145,000 people. Very globally diverse. A very interesting business. People always think insurance is a little bit boring. You need to get car insurance, because otherwise you can't get your registration. In the end, though, insurance covers anything from travel insurance, to accident insurance for your day of skiing, right down to -
I always say, whenever something really bad is in the news, Allianz pays at least a part of it. Whether this is Malaysia 370, the Costa Concordia, or anything else dramatic happens. A flood, landslide - anything. The large insurance company's always right there.
In those cases it's not so much about paying, it's also a lot about crisis management. For the large corporate customers, insurance companies actually engage in very different ways. They do things like safety inspections.
Let's say you want to insure your power station. Some highly qualified engineers from the insurance company will come and look at your turbines and all the other set-up and say, "Does this meet our standards? Because if it doesn't, we're not going to insure this, or we're going to up your premium."
Likewise, if something goes wrong, they don't need a check for $500. The large companies - they need crisis management, they need safety management, they need rehabilitation management. So in the end, insurance is actually a lot more interesting than what people see from the classic of home owner or car insurance.
In my case though, it was a little bit of a personal change. I worked with Google in Mountain View, in the mothership, and then in Tokyo for over four years actually, doing super interesting stuff in mobile ads.
And then, for partly personal reasons, I was looking to come back to Germany. I had been on the road, if you wish, for almost 20 years. I went to Stanford with a suitcase or two. And I basically hadn't gone back. So there was an inclination for me to come back to Europe, be closer to my parents. And then I also thought -
For me, it's always the kind of place I want to live. And the kind of place I want to work depends a lot on which country I'm in. I think different environments just make different kind of companies more favorable. Like if I was in Silicon Valley, I probably would not work for a large insurance company. I would work in a high tech environment.
But if you go back to Germany, I think some of these large organizations are actually very interesting to work for.
A few things came together, and there I was, ultimately becoming the chief architect of a large insurance corporation. And similar to the government kind of projects, the things we did there were actually extremely interesting.
Len: You've written about some of the interesting challenges that the insurance industry is facing now, and some of the exciting ways going forward. It must've been really fascinating to be working for an insurance company at around this time - when ride sharing is becoming a thing, car sharing is becoming a thing.
You also wrote somewhere about the internet of things. I was wondering if I could just pick your brain a little bit about that? What are the particular challenges that the insurance companies are aware of themselves facing with the internet of things?
Gregor: You're absolutely right. Insurance has become even more interesting, because of digital disruption, as we call it - which is a lot of the premise of the book.
The rules of the game are just fundamentally changing. I often joked inside that Allianz is 127 years old. I said, "Well, we had 127 years to basically find all products that don't depend on technology." So you can be pretty sure e did a pretty good job, 127 years. We found all of those."
By the same logic, that means that any new product that comes along is going to be technology-driven. It's going to be technology-enabled. The whole drive-as-you-go. This is all sensors in the car. So this is one main factor. The technology, and especially the IOT, brings new kind of applications.
I often say, insurance insure things. So knowing more about these things, is a great thing to do. This is where IOT comes in.
As so often, the technology doesn't just appear overnight. It's often a matter of price point. I mentioned before, large insurance companies will insure things like train engines and drilling platforms and power stations. Those things had IOT for almost decades. Because it's very expensive equipment. It's often safety critical. It's very expensive if there's downtime, if a turbine breaks. Getting that repaired is a major ordeal. So those things always happen - heavily instrumented, analyzed - everybody looks at, does this thing make a funny noise? Does the bearing do anything? So it's always been there.
What has happened, is that the price point comes down dramatically. And the thing that it's leant to in the insurance industry is a very interesting one.
Traditionally we think of insurance companies like the ones who pay out when something bad happens. Now of course, if you think about it, that's not a happy day for either party. Because something bad happened to you, and the insurance company has to pay. So this is actually in some sense, the worst-case scenario.
So there's a lot of shift to, what we call in the insurance company, claim prevention versus claim handling. Wouldn't it be much nicer if this bad thing hadn't happened, because you wouldn't have to deal with it? And we as insurance company wouldn't be paying out either. So we're both happier than otherwise.
A lot of the IOT, a lot of the metrics are just about that. They're about understanding what's going on. Making your car break before it hits the car in front of you.
Likewise, in the health sector - you're having sensors, you're having early warning signals if something is not 100% right in your body. The same with heavy machinery. If this turbine is starting to vibrate in an odd sense, right - there is a sensor that tells you that. That way, a lot of predictive analytics can happen, and you can catch things that could've been a bad case scenario, before they actually happen.
In the end, it's a very interesting use of technology, and a big business driver for insurance. Because claim avoidance is of course a good thing for them as well. Yhis is one of the examples where technology is making major inroads into the insurance business.
Len: It's a slightly selfish question, but I have a particular interest in watching the self-driving car technology evolve. And a minor claim to fame I have, very minor, is that a few years ago, I had a letter published in The Economist, in which I predicted, unoriginally, that one thing the car industry is not prepared for is the ending of personal car ownership.
I've read that this is something that insurance companies are also looking ahead towards. What happens if people don't own their cars anymore?
Do you have any particular thoughts about that? Because what you're describing - very interestingly - is a business that cannibalizes itself naturally, because it wants to make things safer; which one could then conclude, it means people will need less insurance. Or the insurance will get cheaper.
Gregor: There's a couple of facets to this. The self-driving cars have two major aspects. The one is, it could be a really great enabler for car sharing and less car ownership. Because in the end, the biggest disruption in car sharing we've seen, was that you can pick up the car pretty much anywhere and leave it anywhere.
I often use this example where gradual changes in technology and the business model ultimately reach a tipping point.
So, car rentals must have been around for almost as long as the car has been around. But a car rental never fundamentally changed the model. You have to book it in advance, you have to go somewhere where there's the car rental company. They like you to bring it back to the same place. So it behaves kind of like your own car, except you own it for like a week or a couple of days, instead of a couple of years.
Now, car sharing - even though it seems like a increment, it's kind of doing the same thing. You just use your phone to unlock it. It has reached the tipping point, because now the car is anywhere you want. You can rent it one way, you just leave it wherever you went. It took the friction out.
I think the self-driving cars are going to make another push. Because now the car can come to your house, for example. It can go very slowly out of the parking garage, and meet you where you are, kind of thing. I think it's another big enabler of the car sharing part.
That's definitely factor number one. And that will reduce car ownership. And the insurance companies are extremely aware of that.
The second part with a self-driving car, is of course, who is the liable party? If the car's driving by itself, should my insurance premium go up after my car causes an accident? Or is this, rather, corporate insurance? Would Tesla - to use the example - want to have a corporate insurance contract with Allianz, and just say, "I insure my cars. I insure my engineering, my software, because the people who are inside actually have relatively little to do with what my car does. So it wouldn't be quite fair to charge them the premium based on age or gender or where they live. Because that really makes no, no difference." It's very interesting dynamics at work there.
If you look at insurance as a whole, generally car insurance can be a big revenue driver. It's often not the biggest profit driver for a large insurance company. It's a fairly competitive market. The margins are relatively thin. So in the end, they look very, very carefully, at the same time. If you're diversified and you're a large insurance corporation, that is probably not going to put you out of business.
What's really interesting is to start having these corporate relationships. How can you engage with a BMW or a Mercedes or a Tesla? Because the whole liability question fundamentally changes.
Len: You mentioned relationships. Your work at Allianz was as an enterprise architect, and ultimately chief architect. I wanted to ask if you could explain to people what those roles entail, and how relationships within the corporation you're working for are a key part of that role?
Gregor: I'm sure there's some mystery around, what does a chief architect really do? I would say in this case, and this will be true for many organizations in today's day and age is: they're in a transformation scenario. All the things we just talked about, requires the organization to work differently than they have been. Because we had 127 years, more or less selling the same products. Now there's major change in the system.
There's a transformation scenario, that of course also impacts the IT. This is different technology now. You have sensors in cars. You need to get the data. You have analytics, etc. So you can imagine that this is something very different than administering insurance policies.
A lot of the role, I would say, of the enterprise architect, and the chief architect, is to make sure that the technology, that the IT such an organization has, actually benefits the business in the best way it can.
Again, it sounds obvious. Why would you make technology that doesn't benefit the business? But then you start to realize, there's long planning cycles. There's budget cycles. There's office politics, whether you want it or not. There's vendors sometimes selling you things that they are very convinced about, but you might not be.
There's 1,000 factors that make this alignment go out of whack. And because of the large organizations, things often don't move so quickly. It can happen that a year or two goes by, with IT spending money doing a project, investing in a certain technology - when in the end, the business impact doesn't actually come out, qhere the cycle doesn't close.
In the end, I would say, in this era, one of the most essential functions of the enterprise or chief architect, is to make sure that that connection is solid.
Len: Is that importance generally recognized within today's large corporations, that weren't necessarily historically tech companies? Or is that something that you need to argue for, so that people recognize the importance of the role?
Gregor: At the board level, it definitely is. That's originally what convinced me to join a large insurance company. I was interviewing with a Chief Operating Officer. It was a board member, a fantastic guy. I often joked that the leadership sits up in the penthouse, and that doesn't just mean they're wining and dining themselves. That means they also have the best point of view. They have the foresight. So at board level, at leadership level - yes, absolutely - these organizations know what's coming their way. And they also see some of the inefficiencies they have in the systems.
They often look at banking, like retail banking, as a leading model about how financial services got disrupted. I often, when I hold a workshop, ask folks, "Who has been in a physical bank branch in the last month?" Occasionally there's somebody who lost their pin or got a mortgage or something. There's the odd case. Basically, the answer is nobody.
Retail banking is giving a more than subtle warning to the insurance companies what's going on there. So at the leadership level, yes - they will realize that. Because on the one hand, they foot the bill. They see the IT cost in the hundreds of millions or often billions of dollars. We often believe only the digital companies have money.
This is not quite true. There's a lot of very successful businesses, where there's a lot of money going around, and also a lot of money being invested. In this case, several billion Euros a year in IT. So now of course, company leadership sees where that is going, and whether that brings the expected return. They definitely do.
Also, they see the need to become faster. To actually do things that lead to quick results.
Where it gets tougher is if you have project managers who are asked to run a three-year project that was maybe planned five years ago, when the technology, the dynamics were very different. Now, it would be very difficult for them to say, "You know what? I'm just going to cancel my own project. Because look, it all doesn't make so much sense anymore." There's this divide and these differentincentive systems that make this so difficult.
You'll find some folks where you get a lot of support, and you'll find some other folks and say, "Yeah I know - you're enterprise architect, go dream on, I have a real project to deliver."
Len: You write in your book about how physical architects, who design buildings and stadiums and things like that - that you can see their personality in their work. And you say that the same goes for technology architects. I was wondering if you could describe a little bit about your style?
Gregor: Yes, so I - there's a little pet peeve of mine, that a lot of people believe this technology stuff we're doing isn't particularly creative. We're the guys with the thick glasses and the shirt coming out the back, and just typing at the computer all day. The last thing people would attribute to us is creativity. I think this is completely wrong. I think there's a lot of personality and creativity in it.
One of the most surprising conversations I once had was with a manager a long, long time ago, where I very casually made a statement, like, "If I look at a piece of code, I can tell who in my team wrote this." He was like, "Wow, like magic - how does that work?" He thought code is an emotionless, heartless kind of machine thing, that doesn't have any human element. And then it's like - wow, like seeing who wrote this, to him was eye-opening.
I would say, in architecture, that's even more so. Because basically, you're starting either with a blank sheet of paper, and you need to make something out of it; or you're starting with a lot of snippets, it's almost like a collage. And in the end, you need to make something useful out it.
My little pitch for programming, up to doing architecture, is it's actually a hugely creative exercise. I would even go as far as saying it's the folks who [don't?] like a certain amount of creativity, will probably never do really well in this. They'll never be the ones who really achieve great results. Because that is one of the key ingredients.
Coming back to the style question. For me, I would say - it's difficult to put in words, but I would say that what I'd like to do about this, is to play off the healthy tension between it being very rational, and it being a little bit of an art form. Those analogies have been played a long, long time. Is it one or the other? We need to make software development more industrialized. Or other people say, "No, it's really a craft." You can argue forever about it, I think for the simple reason, because it's both. I think that healthy tension, I would say, probably best describes my style.
Let me give you some examples. Definitely as chief architect, I was always known as the stickler for a rational reasoning. When people would say, "We need to choose technology X," I would say, "Why?" It's like, "Well, because technology Y isn't any good." "Well, how do you define good and not good?" Right? I wanted to see a very rational, "Here's what we're trying to do. Here's the three things that are important to get there. Here's the two options you looked at, and here's where A was better than B or vice versa."
I have been known to be quite a stickler - it's probably the German schooling that comes out - there can't be a logical break in the chain. Because a lot of the time what happens, is people have a preferred answer. And they reverse engineer how they got there. On that one, as chief architect, we can't tolerate it. It's like we had to know where we wanted to know, and then make sure the technology solution, the vendor solution, we map into that.
So my style, I would say, can be best described by marrying that, and make sure this is all sound. We're then taking a step back and looking at the whole picture, and seeing that there's a certain harmony.
If you went on the dangerous metaphor, maybe, of making this a painting - on one hand, I would be extremely strict on the color science. It's like making sure nothing is there by accident. But then once the gestalt of this - once the thing emerges - you switch your brain to a very different mode. You switch into maybe right hand side brain mode. And you still make sure that there's an overall balance. I would say that would best describe my style, if it can even do that. And I would say also, that's what keeps making it interesting.
Len: Speaking of keeping it interesting, you recently moved back to Google, where you're Technical Director in the office of the CTO, based in Singapore. I wanted to ask you about this latest move that you've made, and what do you do in your current role, and why did you go back to Google, and why is it in Singapore?
Gregor: Good points. So, what we talked about with the consultants, some of the slippery slopes, but also the advantages of living in the parallel universe: that is also true for IT transformation. I reflected quite a bit about this with my boss, who's the CEO of the IT division, where I drew the spectrum of, how much are you ingrained in an organization that you're trying to change? And the two extremes are - well, you're not at all, and you hand them a paper and say, "Harvard Business Review said you should be doing X, Y, Z, and good luck." And the other one is: you're fully immersed.
Both of those are difficult, because on the one hand, you have low impact, and if you're fully immersed, you often don't have the freedom to act. In the end, what you need to do to move an organization, you need to have the right ideas. You need to have some creativity. And then you need to have the ability to actually move. So, there's the scale of authenticity and the scale of actually making a change. And both end points of the curve are near zero.
So, always trying to move a little bit in the middle, where you are not just a totally normal, regular employee, but you need to be able to break and bend a few more rules - because if you are 100% bound by the system you're trying to change, it becomes like pulling yourself out of the swamp by your head. And that only works in the stories. That doesn't work in real life.
We started some of this discussion, and I felt that over the five years, I hadn't checked as much change as I could, being a full-time employee. Now, being a full-time employee had also many advantages. I could hire and mentor a team. I could build a team, I could run a team. I was their formal supervisor. I took care of their performance reviews. I made sure they get raises and rewards. There were many things that I could only do by being there. But I felt after five years, a lot of those things I had done, and that taking a step back would be the right thing to do.
It was also a time where - so, a little bit surprisingly, I was suddenly not attached to anything from the personal side. So it's like, "Oh." I was thinking to maybe make a career change, because I felt five years was a lot of things I did at Allianz, and they might want some time to digest a little bit. And suddenly, I wasn't very much tied to the location I was in. So I was saying - well, in your life, these moments become much rarer. Once you have a family and the kids are in school. And depending where you are in your career - just moving a country becomes hard and harder.
I found myself in a position where like, "If I really wanted to, I could just pack up now and get on an airplane and go somewhere else." And I said, "Well, having spent four and a half years in Asia, in Tokyo, I'll go back to Asia." I always liked Asia. It's very dynamic. There's a lot of energy here. I said, "Why not?"
I rang up my old Google buddies, and I said, "I just did five years doing IT transformation at a very large organization, and I was at Google before. I think that's a relatively rare combination, do you have something that takes advantage of that?" And in the end, that's what they did. In the office of the CTO, where basically I am advising other companies in very similar things to what I did at Allianz. So for me, it was a perfect fit. I said, "Okay, sure let's do that." I put all my winter clothes in storage, and moved to Singapore.
Len: Best wishes for this next stage in your journey. It sounds really exciting. And of course, moving to a new place brings with it a lot of interest and pleasure as well.
Moving on to the next part of your interview, I wanted to talk to you about your latest book, 37 Things One Architect Knows About IT Transformation: A Chief Architect's Journey. What what was the inspiration for writing this book? Gregor: I would say it was probably therapy, as funny as that will sound.
Transforming a large organization is hugely rewarding, but it's also extremely difficult. I alluded to some of the things. You're bound by many rules of the system you're trying to change. So basically, every day you're pushing, you're relentlessly driving for change. And as rewarding it is to see the system around people changing, and some folks who were maybe held back by the system, now really getting a new life and a new interest in their career, while that is hugely rewarding, it's also extremely tiring.
In the end, I said, "Okay, this isn't just a job. This is not something you do because there's a paycheque at the end of the month." I felt there must be something more I'm getting out of this experience. Maybe thinking a little bit selfishly as well. I said I should write about it, and I realized that there wasn't so much written about it, probably because the market size is maybe not so huge. A traditional publisher would think like, "You're not going to sell so many of these books."
The other reason being that I think most folks who do this job don't have the time, or don't take the time to write a book about it. I had started to notice that on my blog, which was originally a blog about enterprise integrations around messaging architecture. I had noticed that I started to blog a lot more about architecture and organizational kind of topics, because I blog about what's on my mind.
And I thought, "I have a few blog entries. If I edit those and make those proper and fill those out a little bit, this might be the starting point of something bigger." Since a lot of my friends were on Leanpub already at the time, they hinted me to Leanpub, saying, "This is a great place to write a book if you don't know yet exactly what it's going to be." So I took the chapters of the blog, I converted them into the rudimentary, the skeleton structure of the book. And then I had something I could keep working on. That's how largely the book came about.
Len: You made the very interesting decision to structure the book as a set of stories. You have very particular reasons for doing this. I was wondering if you could talk a little bit about that. I found that really interesting.
Gregor: Right, so generally if you had said, "Somebody's going to write a book about enterprise architecture," or even IT transformation, you would expect it to be a little bit dry. You expect this to be a technical book.
In the end, that's exactly what I didn't want to do. I wanted to convince people that - as we talked about before - it's actually quite creative, it's quite interesting. And also, to be fair, it is a complex topic. The organizational complexity, the complexity of the business environment, and the complexity of the technology, goes nowhere but up. All of these are moving faster, becoming more complex.
I felt that in the end, storytelling is the best way for our human brains to make it through that complexity. People don't read dictionaries. People read books, and books have a story line. Books are engaging somehow. This is wired into our physiology. There's this fundamental way of functioning of our brains. So I had a strong affinity to try to make this engaging, and also to make this real life.
The title is a little bit tongue-in-cheek. It's a very long title. It makes it already obvious that this is a very personal account. That's where the therapy aspect comes in.
In the end, packaging this in stories felt a very interesting format for me to write in. But also, many people have commented on it. It's like, "Oh it's not a technical book at all. I'm not so technical, but I really got a lot out of your book. I can relate to that."
That was definitely an objective that I had. I didn't want this to be a reference manual or a technical book of any sorts. I wanted this to be a story, where there are of course useful nuggets that you can take away, but that's packaged in a nice and engaging way. Len: You write about movie star architects in one of your chapters, and I was wondering if you could talk a little about that, if you recall that? Where you talk about the four personas of an enterprise architect?
Gregor: Yes, that's a metaphor I've been using for a long time. To be honest, I would have to probably scour my hard drive somewhere where, to find where I used this the very, very first time. These things just pop in your head.
People always ask, "What does an architect actually do, and what role should they take?" In the end, so often the answer is, it's a combination of things. It's not one persona. And to make this approachable, a little bit entertaining to people, I chose movie characters to give the analogy.
And the movie parts - not the movie, the book parts - quite a few things are from The Matrix. Being a little bit of a sci-fi geek etc, I watched Matrix movies with a lot of interest. When people think of an architect, they often think about the guy in The Matrix. We always remind people, "Careful, that guy is actually a computer program," right? "It's not a person. So be careful with this metaphor." But still people have this idea of this sorta grey-bearded authority. You become the chief architect by basically knowing everything and speaking in this very rational manner. That is just the way it's gotta be.
This is how it started. Some friends of mine had the analogy of the gardener, where they basically take the view that in a large enterprise, the architect doesn't actually decide everything. Stuff grows on its own, especially the weeds grow the fastest. So the architect's job is more to keep things in balance, to prune a little bit here, to do a little bit of planting. But the growing will happen all by itself.
That's where the gardener metaphor came from. I mapped that again to a movie character and said, "That's just like Edward Scissorhands, who is the most gifted gardener, who is shaping plants - that must be Edward Scissorhands, who is making all these amazing sculptures out of the neighbor's bushes." Then it took on a little bit of a life of its own, and I went down the whole spectrum of different personas, the Wizard of Oz, etc., that, in combination make up a little bit of the personality of a senior architect.
Len: Speaking of sci-fi, you actually reminded me of something I was thinking when I was reading your section about the architect elevator, where you say, "Architects can ride what I call the architect elevator. They ride the elevator up and down to move between a large enterprise's board room, and the engine room where software is being built."
That reminded me of Star Trek, in particular Scotty and Geordi's roles, and how diplomacy is actually a really important part of what they do.
Just by coincidence, I was watching recently the episode where Geordi and Scotty meet, and Geordi's really busy trying to get something done, and Scotty's kind of hovering around him, interfering with him a little bit. Scotty asks him, "How long is it going to take to solve this problem?" And Geordi goes, "At least an hour," or something like that.
Then he goes, "Well how long did you tell the Captain it would take?" And Geordi says, "An hour." And Scotty's just totally flabbergasted that he would tell the truth, because he wanted to set the Captain's expectations so that he could be surprised by Scotty's excellent performance, and also leave him wiggle room.
I'm not talking about dishonesty, but was diplomacy an important part of your role in riding that elevator from the engine room to the boardroom?
Gregor: It certainly is. And yeah, when I joke that you can learn a lot from The Matrix trilogy about daily life, the Star Trek folks will definitely make the point that you can learn yet a lot more from Star Trek.
This is certainly true. What I like is, this connection between the bridge, in their case, and the engine room. Because ultimately, both things have to be in harmony, otherwise the spaceship isn't going to do what you need it to do, or the mission is definitely not going to be successful. And that has become a little bit the metaphor of the book. The defining chapter is definitely the one on the architect elevator.
It really relates back to what we were talking about earlier, where the architect's job is to make sure that whatever IT gets built, benefits the business, and also that the business thinks and decides in a way that it can really take advantage of the technology. It's really about making that connection. And as we know in many organizations, that connection is pretty far apart.
The best quote on this I ever got is, I was telling my friend that I'm teaching a class about IT skills to senior executives. This is a fantastic program that Allianz had started, where they require all the senior executives to take IT training, basically. And her comment was, "I hope they are not too senior to understand what you're talking about." That really highlights the challenge.
The idea is that generally somebody as senior up in the organization, they are less technical. In the digital companies, that is not like that. Like a Sergey Brin or Mark Zuckerberg, they would not fall into this model. But in traditional organizations, that can happen. And that is the disconnect, the dangerous disconnect that this elevator is aiming at fixing.
Now, coming back to the diplomacy, that is a huge part of it. Because now you start moving across different levels, you need to communicate and engage appropriately at the individual levels. I don't think it's about sandbagging estimates. But it's about building the trust, the relationship that you're not just there as a pure connecting element. Because otherwise the folks in the engine room will feel, we're just taking the good ideas and selling it to management. That is not what the architect elevator is meant to be.
The architect elevator is meant to be: you bring value on both sides. You give some hints in the engine room about what might add more value, and you do likewise in the penthouse, so that you bring value. I think to build that trust, and to really highlight the fact that you're engaging at both points and bring the value, a certain amount of diplomacy and way of engaging is absolutely needed.
Len: For what I found to be very clever and entertaining reasons, your book is called, 37 Things One Architect Knows About IT Transformation. I'll leave it to listeners to buy the book, to find out why that number was chosen. It's a really good story. But if instead of 37 things, if you had just one thing that you could say to all the future or even current enterprise architects out there - what would you say to them?
Gregor: I'll answer with a chapter that actually didn't make it into the book, and tell a tiny story.
My friends challenged me a little bit and said, "It should've been 42 things." Because in The Hitchhiker's Guide To The Galaxy, the magic number 42." So, there's a whole other segment of geek subculture. I am actually writing on a few more chapters, and who knows? Maybe it'll become 37 + 5, or 42 things?
The one advice I would pull from the not-yet-written chapters, is - in today's day and age, architects really live in the first derivative. Your job is to increase the rate of change. Because the digital world is all about speed. It's how quickly you can innovate, how quickly you can iterate. And if you're trying to build a system that never has to change, ever, you probably don't need an architect. You just hammer together somehow - if it works once, there you go, you're done.
Now of course, the catch is that the premise is most likely false. Building a system that never ever has to change is extremely rare. More likely than not, your system will have to change. It will have new requirements. It will have updates to software versions that it relies on. It will scale out. It will increase in size. It might be in different markets/languages.
There's 1,000 different ways your system will change. And to me, with the mathematics background, the change in a function, in a mathematical function, that's what we call the first derivative. That defines the rate of change, and likewise I would say the rate of change in an organization really defines the need of an architect. Your job is to make things such that they can change with ease, with low friction. And that's the advice I would really want to give.
Len: The last question I always ask in these interviews is: if there were one thing about Leanpub that we could improve, or one thing we could fix, or one thing we could build for you, what would you tell us?
Gregor: That one I would have to think about. Because in the end, I'm super happy.
The idea of publishing before things are finished, we actually already followed back with the enterprise integration panels, which is like 14 years ago. I can't take credit for the idea, because that was Martin Fowler's idea. He said, "Just put all your stuff on the website."
And we're just like, "People will steal everything and read everything and never buy the book." And he says, "Well, no - that's not going to happen. It's going to make people more interested in the book. And the risk that you take for the three people who are probably going to steal it, tThat cost is minimal, compared to all the other people who you engage, and all the feedback you get."
We've always been big fans of having things published while you're writing it. Except in the old days, it was very distinct. There was a phase where we were publishing to the website. And then there was a very painful transition from that into something that started to resemble a book.
In the end, I would say the biggest accomplishment that Leanpub has brought us is, that distinction no longer exists. You can work on a book and keep publishing as you go along. But when the time comes to say like, "Now it's no longer a blog thing, now it's a book." Well, there's nothing to do. You just hit the final publish button, and there is your book and you can have it printed and many other things.
In that sense actually, I'm super duper happy. Some folks comment on Markdown being restrictive or difficult. I found this to be actually very, very easy going. I'd actually say I'm a quite happy customer.
Again, it's not about just having different tools. People need to understand that it changes the way you write the book.
Sometimes people say like, "Oh it's just another publishing platform, and there's nice articles." I think you, and your colleagues out there, are saying, "No, no, no that's not what it's about." "It's about changing the way you write the book." And I think that's the key takeaway.
In my case, it's worked extremely well for me. If I hadn't had the feedback from people while I was writing, I might have never reached the 37 things.
For me, it was very important to have it out there. To see people are willing to buy it. People giving feedback. I would say I'm a pretty happy customer. But I'll think about where I can provide some input still.
Len: Thanks for that really great answer. If you do think of anything, please let us know.
I just wanted to highlight one thing you said very well, which was, relaxing. It's one of the things that, when I'm interacting with authors, I often find myself doing, is saying, paradoxically, the hardest thing to do sometimes is to relax, if you're nervous about publishing for the first time.
Just the other day, we had two emails in a row from people totally separate from each other. One guy accidentally published his book. He just didn't understand that when he pressed "Publish," it would go up for sale. Which happens from time to time, and we're working on how to fix it so that doesn't happen.
But he got a sale. And he was like, "Oh my God, I can't believe it. We've got to put a stop to this."
And then the next email was from someone who had had done something similar, and had ten sales like right away, and said, "I can't believe it, my book's not nearly ready. But last I checked, no one had asked for refunds."
One of the things that's changed over time is, not only have authors become more comfortable with the idea of publishing early and publishing often and watching the book evolve in public, but actually readers are more familiar with the idea of in-progress publishing as well. Things are changing on that side too, where people are not shocked anymore when they purchase an unfinished book. They recognize what's going on. "Oh, the author has published this early, and I'm going to have an opportunity to watch as they publish new versions. And I'll come back to the book when I'm ready." They don't freak out when they encounter an unfinished book.
I just wanted to say that to any potential authors listening, one of the most important things you can do is just get started. The motivation and the excitement that comes from that is something that the readers share with you.
Gregor: I would say even - this is a fantastic example of where we talked about the business model and the technology alignment, which has been a little bit of our running theme.
When electronic book publishing first came out, people treated it like a print book. People would sit in a quiet chamber, writing the book. And ultimately it comes out, but it comes out just paper. This is a classic case - where people used a new technology, but still applied the old model of thinking. Meaning the business hasn't really realized the potential.
This is what the chief architect's job is - versus in your case. For me this was extremely natural, saying, "Once you publish electronically, this doesn't have to be a one-time event anymore." Because you can have updates anytime. And people would read it as it comes along. And so you changed the model. For me, it's another classic example of understanding the technology, but making the bridge to see how this can also change the business model. That's exactly what we all talk about when we talk about IT transformation.
Len: I wanted to say, Gregor, thank you very much for taking the time to have this really interesting conversation. I feel like we could keep going. But it's been about an hour and a half, so I feel like I should probably call our time.
Once again, thank you for taking the time to do this interview. Thank you for the great answers and your stories, and for being a Leanpub author.
Gregor: Thank you. It's been a huge pleasure for me, thank you very much.
Len: Thanks.