#179 Adrian Colyer from developer to living under constant jet lag and back

Transcript

⚠ The following transcript was automatically generated.
❤ Help us out, Submit a pull-request to correct potential mistakes

Adrian Colyer 0:00
Just try and learn one new thing every day, write it down. That's it. And then just let that compound you know, over the weeks, the months, the years, it's amazing what that will do for you. Versus just not having that consistency of one small thing means you're always looking you're always thinking you're always learning the little discipline of modular no write it down. That's what that's what literally the morning paper blog was for me for the longest time, it was my journal of learning. And I think that habit if you're going to do one thing will really pay dividends for you.

Tim Bourguignon 0:44
Hello, and welcome to developer's journey, the podcast, bringing you the making of stories of successful software developers. To help you on your upcoming journey. I'm your host, Tim bourguignon. On this episode 179, I receive Adrian call you at we began his technical career in classic transaction processing and messaging before discovering languages and compilers. And going on to lead the open source aspect J project. He didn't work for SpringSource, VMware Pivotal, before becoming a venture partner with excellent London, where he now helps on the other side, find and build great tech companies out of Europe and Israel. Adrian, welcome to their journey.

Adrian Colyer 1:29
Thank you, Tim. It's a real pleasure to be here.

Tim Bourguignon 1:30
But before we come to your story, I want to thank the terrific listeners who support the show every month, you are keeping the dev journey lights up. If you would like to join this fine crew, and helped me spend more time on finding phenomenal guests, then editing audio tracks, please go to our website, Dev journey dot info, and click on the Support me on Patreon button. Even the smallest contributions are giant steps toward a sustainable dev journey. journey. Thank you. And now back to today's guest. So as you know, the show exists to help listeners understand what your story look like, and imagine how to shape their own future. So as always, let's go back to your beginnings. Where would you place the start of your deftly?

Adrian Colyer 2:20
Yeah, that's I guess the very beginning of my journey would be as a young I think just teenager getting what was then a new and exciting ZX Spectrum as they think as a birthday present, not a Christmas present. And I'm trying to figure out what I could do with it. And I do remember discovering that you could just about programming this thing and writing a tiny little adventure game was I got past Hallo world. That very much impressed my family members. But I thought it was horrible on the inside. The biggest words nested IF statement you could ever think of that happens pretty much my first foray into programming.

Tim Bourguignon 2:57
So right away, you went into programming with this?

Adrian Colyer 3:00
Yeah, I mean, the I mean, you get the computer and you don't have the cassette player, because it was cassette tapes there, right to look to load programs, and so that we didn't have any games at that point in time. So yeah, there wasn't much else you could do. And just making a computer prints and text. I think that was an advantage for us. That was cool and exciting. And so if you get a computer now and you can't produce like a professional grade, you know, like iOS app, then you've maybe you feel a bit disappointed. But printing Hello world, or your name was really great back then. So ya know, that's how it all began. And then, you know, getting the magazines where you used to see like, programs. So program source, you actually when I started, it was typing in machine code, if you're not even assembler, you typed in the hexadecimal values and tried to get it to run and debugging that if you made a mistake wasn't much fun. But

Tim Bourguignon 3:46
I believe so. Just before we move on, have you watched the Bandersnatch series on Netflix, which was a recursive story or a choose your own adventure story about somebody programming? ZX Spectrum? Oh, no, I haven't seen no, you haven't actually go and check it out. And there is in there an Easter egg at some point that the character is listening to to music in the bus. And if you input this music in Zedek spectrum, it's actually a program. We went out of their way to really make it.

Adrian Colyer 4:16
Yes, yeah, I can still hear that really distinctive loading sound. It used to look like it was a slow sound and a fast sound and very strong early memories of working with computers in the most basic way.

Tim Bourguignon 4:29
Did you have the realization back then, this is going to be your life,

Adrian Colyer 4:32
I don't know, like instantly, but then maybe like two to three years in and I was starting to really enjoy playing around. And I think I knew that. Like I really thought it was just amazing that you could write two things and operating system and to write a compiler. They just seem like so beyond anything I could imagine. I wanted to know how to do that. And that's kind of what led me to think like, well, after school, maybe I want to go study computer science, which was just sort of starting to become a course that you could study properly then and so I thought that was an early ambition. And I achieved one of the two. I've never yet written an operating system. But I did get to write a compiler. So,

Tim Bourguignon 5:07
wow, you're you're really early with this. You mean in high school, you were already thinking about OS and compilers. But

Adrian Colyer 5:14
remember, those are the bits of the most obvious to you on that basic computer, right? You can see a language Oh, how do you make a programming language? And then you've got this operating system you're interacting with? So in a sense, I mean, I did that. I was like, How'd you make a sprite move around the screen stuff that everybody did back then? But yeah, I was really interested in kind of the machine itself and how it was working for sure.

Tim Bourguignon 5:33
Wow. Okay. So obviously, you went into computer science and scratch that edge? Or how did that pan out? Yeah,

Adrian Colyer 5:40
exactly. Yeah, no, I went and did Computer Science at the University of Southampton in England chosen a because they had a computer science course that included the things I was interested in and be because the campus was green, you know, decisions that ended up in essence in a whole bunch of things down the line. And it really enjoyed it. I mean, that that was still like, if you wanted to program you had to go into into the lab where the special computers were that you could use and you didn't have like your own computer back in your dorm room or anything. So I guess you got good separation, you got some thinking time away from the keyboard?

Tim Bourguignon 6:15
Did you have some thinking time when you can do something when you build something? Did you have time?

Adrian Colyer 6:21
Do you have thinking time then as well? Yeah, everything was was slow and painstakingly down. But it did. It exposed you nicely to the lower level of kind of nuts and bolts of what was going on so as to be grateful for that

Tim Bourguignon 6:33
I came to studying way later than that. And I never experienced really this this long time loop until I put my finger into optimization. And then I wrote some optimization algorithm. We used to take something like five to 10 minutes to to compute and complete an OK solution. And that was really annoying. I'm coming from this world where you read refresh and you have is in there No, you cannot eat

Adrian Colyer 6:59
that that like super tight, immediate feedback loop visit as part of the developer experience is huge, isn't it? It's really important.

Tim Bourguignon 7:05
It is it is. So how was your transition from university after this computer science degree. So

Adrian Colyer 7:10
when I was graduating was actually a bit of a depression and a downtime and there weren't there weren't that many kind of roles and jobs around. And I ended up getting a contract offer from a company called IBM who have actually have a big big development laboratory and physical Herzliya, which is which is near Southampton, so wasn't too far. And I remember to get time Well, I probably got more chances sort of still being in work within a year or so on a contract that I have as a permanent employee because a lot of companies were trying to cut costs by shedding their most recent employees. I'm not sure how sound that thinking was because now I look back at everybody cuts their contractors to because that's even easier. But at the time, I thought like that I like took the contract with IBM. And that was kind of weird because you go to see them and it's terrible what they do, but they just offered me you have a job. You know, when you start you'll find out what it is. But I took the plunge and that that took me into this world of classic kind of transaction processing messaging and some of those sort of lower level systems programming. So Headley was the home of what's called kicks in Europe or CIC s, for example, and IBM MQ and some of those sounds like classic middleware products of that era.

Tim Bourguignon 8:23
Stay with us. We'll be right back.

Tim Bourguignon 8:25
Hello imposters, if you work in tech want to work in tech or are tech curious in any way you'll want to listen to this. We've launched a community of professionals who come together to share information and advice about jobs, roles, careers and the journeys we all take throughout our lives as the designers, builders, fixers investigators, explainers and protectors of the world's technology. We call it the impostor syndrome network. And all are welcome. So find the imposter syndrome network podcast wherever you listen to find podcasts, and look for the isn community on your favorite social platform hashtag impostor network.

Tim Bourguignon 9:07
That was just to to to place it on the timeline. Something like mid 90s to

Adrian Colyer 9:11
kind of early 90s mid 90s here. Yeah. Okay.

Tim Bourguignon 9:15
Wow. So so the almost a classical IBM for me?

Adrian Colyer 9:18
Yes. It was actually, just after I joined again, there, they started doing the first really public large scale redundancies of that wave of downsizing, but I managed to survive. So, okay, how

Tim Bourguignon 9:30
long do you say it? I

Adrian Colyer 9:31
mean, I was there for I think almost 10 years. So quite a long time. And one of the things about a company of that size is you can actually have especially early in your career, a lot of very different experiences whilst moving around the the one company so I did a lot of different things in that time, but I was there about sort of 10 years I mean, that was still the era when a lot of people like inside I was like this is my job for life. You know, I joined I worked for IBM I'll retire from my job IBM and that actually became one of my fears that I might be one of those people. Glad to say that wasn't me in the end, but

Tim Bourguignon 10:10
I don't know. You shouldn't be glad for that. But you said you had many roles. I wore many hats. Did you choose to change hats? Or did it evolve? Yes,

Adrian Colyer 10:22
sometimes I chose, you know, sometimes earlier on kind of kind of you get moved, I guess I used to say like that key things I really remember at that time, I was super lucky, I got working with a team of very who are working on kicks, I'm a really large scale transaction processor. Super, super important, you know, back then, as you still is today. And I was working with a bunch of really smart guys who took me under their wings. That was like, just as the anointed Steve Powell Johnson Hall, who was Tony Hoare, his nephew. They were doing like sort of really deep, thoughtful design with formal methods and refinement. So that was a really great school and they learned a lot. But then I think the thing that Phil made me move around internally, and maybe it's one of the like, the constant threads through my journey is I was always interested in what's new, what's coming up and to play with it. And to keep learning basically, to find out like my concerns, like it's like, there are people who know way more than I do, how do I find out what they know? How do I learn from them. And so that sort of always had me like, I was one of the first people within the site, playing with Java. Some of the listeners might remember the brown O'Reilly Java in a nutshell book, that was how like the Bible and all of Java in about 150 pages, or whatever it was at the time. And that was everything. And it was great. I wrote the very first programs on that was one of the very first people in Hursley to build any kind of web interface onto an application. You know, that was like a radical thought at the time, you know, now, obviously, it's how we do nearly everything. But then that was one of the first and so that often helped me make moves and get pulled into new areas that I enjoy this. And

Tim Bourguignon 11:53
this, this need for searching, learning, experiencing, finding new is what drove you out of IBM? No,

Adrian Colyer 11:59
not quite so. So that's how I got it. I gotta tell you the story of how I eventually came to leave IBM. So So I was working in in kicks at the time sort of bounced around, I was backing kicks. And there was this thing called Enterprise javabeans EJBs that was just brand new and coming out. And one of the things I was working on was a project to figure out how could that programming interface be supported in this mainframe transaction processing monitor. And so I was really interested in this boundary between the programming model and the middleware. And there's a lot that goes with a lot of chance things that happen as you hear this story. So one of the challenges was like, I've been in a part of IBM prior to that call, a s&t, Applied Science and Technology was the name of the group. And that was a core group, their job was to find interesting things that were going on in IBM Research, and to work as a kind of bridge with customers doing early deployments and sort of customer kind of evaluations and use cases of that technology and see what might be interesting. That led me to write a short paper that I submitted to a conference called xe, I think it was called from research to reward challenges in technology transfer, something like that doesn't really matter. It got me to xe, where I was presenting a short, short story on this paper, and nothing really maths about that, other than I was at this conference. And at this conference, there was another gentleman who also had a paper he was brilliant, he was called Gregor exile is went on to be a huge influence on me. And I forget the exact title, but it was like Aspect Oriented programming with aspect J or something like that was the title of the talk. And literally, it was aspects when you're programming that sounds kind of cool. I'm interested to know what that is. And so I went along to hear the talk. That was the entire extent of the connection time, but it's one of those things, you know, you hear this technical idea, and it instantly clicked with me. And I think the reason it clicked is that, at the core, this Aspect Oriented Programming idea was about separation of concerns. It's about how you can have modularity and things that typically might spread all through your codebase. Well, you know, one of those things that were spreading all through my code bases was like the transaction, demarcation logic, and other kind of middleware concerns or all aspects, they really fit with this, they might solve that problem. I just came back to Herzliya and I started exploring, and I got a bit hooked like this is really exciting. You know, hey, this is cool, early language. And I remember at one point, going to my manager in IBM, and I think my pitch was basically so so I sweat J come out of Xerox PARC, the Palo Alto Research Center, super famous site that a ton of cool stuff over the years. I said, this team at Parc that have got this brilliant idea. And they don't know what to do with it. You know, this sounds kind of historically kind of familiar. I think I've got something I can do with it. We can do this kind of middleware thing. It's going to be interesting. And that was enough though, with hindsight again, I was really lucky here, but they backed me and said, Yeah, okay, why don't you try to do some kind of proof of concept and see if this can work. One thing led to another I got to know they the folks in the park team really well to Greg Zaius was the professor leading that team but it was Jim Hogan in who's brilliant lead and Mick Kerstin and Eric Hillsdale and And from Bob Kane and I think Mises Berg would give them all credit. Yeah, really super strong team. And I was lucky to get to know them a little bit. And they finally decided, within park itself, this project has sort of gone as far as we can take it, we want to open source it very well, that open source itself is kind of a new and emerging and radical thing at the time. And they did, they decided for one thing another to open source it to the Eclipse Foundation, which was also brand new back then, all these things that sound long in the tooth now, but it was brand new and exciting. And they proposed to me that I lead the project, because they were they wanted a non a nonparty lead. Well, that was super daunting, I can tell you really super daunting. But you know, I was active in the community, we've done this internal project, I really wanted it to work. And so I took that on. And you know, sort of Jim and a few of the others came and we did some pair programming, that was a massive learning experience. For me the first kind of encounter with open source with actually with proper true test driven development. And the way that Jim thought about code was brilliant to be exposed to that process. But also, I mean, technically really scary. And you wrote a compiler was I'd always wanted to write one, but like, Hey, here's the code for a compiler go Have at it, you know, and one of the things I early had to do is this was job five by then which for readers who are blessed enough to be young enough to remember this, that was the version of Java that introduced the generic type system. And so I had to go figure out how all this generic typing would map into the language and build a component support for it. And so that was a ton of fun. And we built the first ever, I think, outside of the eclipse team, Eclipse plugin, which was the one for aspect J, etc. So like a fun time, you know, I had a little team working with me inside of IBM, Andy Clement, who still leads the aspect J project to this date, brilliant engineer. So we've worked together on that. And as the lead of the aspect J project, I started to go out and speak at conferences, which wasn't something that classic kind of developer ibm personality did back then, maybe it still don't do as much today. But they got me out on this conference circuits host all these other people, and eventually to being invited to give you know, keynotes and panels and that sort of thing, telling the story about the Victorian programming and what it was and how it worked. Which led me to meet chalkboard rod Johnson, who's kind of with some of the listeners, again, may know was essentially the father of spring in the Spring framework. And he was out there are the same conferences, the same panels telling the story of spring. And so we get talking. And this kind of fun thing I think happened for both of us, definitely for me is that I found sort of the one other person who was thinking the same way as I was about the way that applications and middleware should connect together and sort of be set. So you know, spring had like, inversion of control with a framework called using, you're not so coupled to it. And it had these portable abstractions. And that was like a very fledgling kind of AOP like abstraction, but you put like that aspect ideas into the mix. And suddenly, you've got all the pieces like, well, this is really cool. And I remember looking at the comps for I was like, yeah, that, that sounds really good. But kind of I can't make spring work with aspect j, because aspects didn't have constructors of a kind that like heat spring wanted at the time. And so I'm going back to the hotel room, like right, download the Spring framework source code, dive into it, figure out what spring is doing, figure out how actually to make spring instantiate and aspect J aspect? Bingo got it. That was that was the the origin of the ability within the Spring framework to instantiate a, an object via a factory method. So obviously, that would be totally fine. But if that was the thing that was missing that I needed for us, but Jay and I did it made it work, not in the perfect way. But I showed Rob and it's right here it is it works. And it is really cool. So we started this good conversation and sort of Subsequently, he told me that he'd been very impressed that like, someone that understood the code enough to make a change over knife. So that was fun. We got talking. And eventually Rob was like, Look, I'm gonna make a company around around this Spring framework, it's really taking off. Do you want to join and I was really, really, really hard decision for me at the time for quite some time, like, well, here's your like, comparatively well paid and safe for IBM, and there's big company all this resource. And, you know, why would I leave to this tiny, risky small thing and a few things were going on? Like one was like, Well, I don't want to have the regret of never having tried these things have been a good idea from Alaska cameras regret that. But the thing that really, I mean, I really one is to try the excitement of this journey. But of course, you're worried about your family, first child, should I kind of risk this contribution? I thought, the thing that made it fun was when I realized, like, what's the worst that can happen? And sort of realizing that well, the worst that can happen is basically that this startup doesn't work out. And I could go back to IBM or similar, and they probably employ me in a heartbeat. So So actually, it's not nearly as risky as I felt it was and I took the plunge and just asking myself that question like, what's the worst that can happen? It was it was a key moment. And then I'm in this completely different world now, like I've gone from 300,000. I don't know how many employees IBM has to this tiny startup. And I remember thinking about before I move, like, how is it going to be possible as this time, I think there were 10 people issued SpringSource, at the time I joined is could interface to anyone back then how was it possible, there's this tiny group of people that we could compete with a huge company that the size of IBM, and the total awakening within just a very small matter of time, and it flipped, and it was like, how on earth can a company like IBM possibly hoped to compete, but the speed at which we can move and the tight feedback loops that we've got with our users, and you know, really coming to enjoy that. And so that was a huge shift. And that's a series of steps that eventually led to me to leave leaving IBM and sort of beginning this kind of new chapter in open source and startup world.

Tim Bourguignon 20:56
Wow, just for the sake of it. Do you think you could have gone back to IBM, if SpringSource hadn't worked out? I mean, from a mindset perspective,

Adrian Colyer 21:05
for from a mindset perspective, yeah, I, I don't know about that. I think you find if I'd have wanted to, I'd like to believe that they would have hired me, you know, maybe not, maybe they were glad to be shot on me. But I still had a number of good friends and colleagues there. And you know, probably, I could have just a safety blanket. Would it be what I wanted to do? Probably not. But once you've tasted kind of the excitement of freedom, the fast moving, then that's addictive? And can you want to be in that world? For

Tim Bourguignon 21:32
sure, indeed, very much. So. When you started with SpringSource, did you start as an individual contributor?

Adrian Colyer 21:39
Like, I mean, the company was tiny, it was flat ready? Right. So So that's all there is, I think my first title was chief scientist, because SpringSource had a CTO, the absolutely brilliant Yogen, hurler, who basically is like spring in physical embodiment. And I came in as chief scientist, and we brought aspect J kind of into the spring, kind of fold. And so we were merging the Spring framework and aspect J, and I was still leading the ASP J open source project and sort of also then contributing to the kind of the spring strategy and direction. But that was another big scary thing, right? So that now suddenly, like, springs, resources, tiny, we were out doing trainings with customers in big enterprises, teaching them how to build these enterprise apps. And I'm like, Well, I've got to learn some of this stuff really quick, I've got to become a spring expert overnight, you know, I came in this different route. But so I felt I felt exposed for a while learning that and coming up to speed, but I'm a great fan and sort of really always have loved being in close with other developers, with customers kind of on that to the technical engagement level. And we got a lot of that, and gradually, sort of my role sort of came to be right, I'm sort of like a front person for a lot of what spring was doing, because I was fortunate to be confident, you know, speaking in public by that stage, with all the aspects a background and able to, I guess, one of the one of the things I think I've been able to do is we will tell you is to synthesize complex ideas and put them across more simply, that's one of the skills that I've honed, and, you know, I was able to use that to help tell the spring story and a narrative. And so gradually, like, we saw a yoga and wanted to focus just on the core Spring framework, and do a brilliant job of that. I mean, Brian, we're all very, super glad that he did. But spring was growing a portfolio of projects, and you know, more and more things, and actually other open source projects beyond spring as well in time. And so I sort of stepped into the CTO role to look after that overarching set of things and also to, to begin, like the that first mini step in towards like an executive slash C suite role of actually, you know, how are we raising money? And how are you? What are we doing here? What was the business plan that goes alongside the technology plan? And then maybe the question that we spent more hours on than anything else fundamentally was, hey, we've got this wildly successful open source project for many years donations of open source projects. Now, how do we make money off the back of it? You know, I'm wrestling with those issues.

Tim Bourguignon 24:04
Do you make it not so intuitive so that you can sell some consulting? Or do you want to very interesting even so people can can ramp up with it, but you cannot sell on an offense back?

Adrian Colyer 24:15
Exactly. I mean, that that was always that is one of the things I dislike about some of the models that have been used is that if your monetization depends in a way on you, sort of not delivering such a brilliant open source product, that never feels great. So yeah, you're always looking for things that don't have those kinds of compromises in them. Of course, I mean, like as a service wasn't the thing that there was no cloud, there's none of that existed back then. So it was pioneering just to do something in the open and, you know, to, to help move the industry away from like, until that very point. Everything has been standards, body driven. I mean, again, it's hard to imagine now but the like, like SQL is for databases, so things like you know, JTE had an AV from before but those standards that vendors would get Together, they've agreed, and then we would all just use them. And that's how it was. And spring was a real mold breaker and say, actually, you know, we can come up with our own, you know, frameworks, programming models, and we can do a better job because we're in this super tight feedback loop. And we're working with the community. And that was a really big change.

Tim Bourguignon 25:16
And do you still lead the aspect of a project?

Adrian Colyer 25:19
Although no, so Andy Clement had worked with me at IBM, eventually, there was a gap. It took me several years, but I managed to hire him eventually out of out of IBM in to join me in SpringSource. And he gradually took over the day to day leadership of that project, and still does it to this day, and just put out another release earlier this year. Even amazing that he's still on that journey. So yeah, so so I don't need that project anymore. In fact, I, I think Andy would not want one of my pull requests at this point in time.

Tim Bourguignon 25:51
Okay, looking forward, and then you're gonna have to help me, you then work for VMware, and then the fourth people in my mind, people who was acquired by VMware afterwards. So yeah, how's it going?

Adrian Colyer 26:03
Okay. Yes, it's super complicated. Companies. So the short story is SpringSource was acquired by VMware 2009, which I mean, that's a whole other story. But Palmer, it's who was then the CEO of VMware, and it just a brilliant person to work under and learn from had this super, I mean, it was a very visionary and out there kind of viewpoint for the CEO of VMware at the time, like, the developers were increasingly super important, and were a big influence on what underlying technology stacks were being chosen and would be chosen in the future. And therefore, if a company like VMware didn't have some kind of interaction at sway and influence over a developer community, you're always at risk of getting kind of disrupted and moved out. And so he's, he's so so this is the very beginnings of like, Cloud is emerging, right? And there are going to be cloud platforms and VMware strategy and like, well, we know we need developers. And so Paul had this really strong vision and principles way to do that, which basically acquire SpringSource. Because one of the one of the assets, we sort of quotes hide as much as you can have it, you know, but we are a community of millions of spring developers that sort of, you know, we're following and using it, and so. So they acquired SpringSource, and then sort of SpringSource became a division inside of VMware. And eventually, we got the dreaded V prefix and was V fabric for a while in there. And sort of, I kept the the CTO role as kind of the CTO for what had been fabric and became upstream SpringSource, sorry, became the fabric. And we did a few acquisitions in the data area and other stuff. So the portfolio was growing. And I was working a little bit with the executive leadership team at VMware on sort of strategy, etc, as it related to those parts of the stack. And that led to sort of one time, this this realization, and again, I think a lot of credit to Palmer, it's that sort of like, we can see this huge changes happening, where we're sort of Cloud Platform as a Service. And you know, that the way that it's going to happen, and at the same time, we've got this huge business in vSphere. And you know, this is driving and going really well and going gangbusters. And can we do both of those justice under one roof, you know, maybe we can't, you know, you know how it is when you've got one hugely successful product that really consumes all the resources and drives everything a company does. And it's super hard to to get a new thing off the ground in that context, because however great you do with a new thing, you've only moved like the very least significant digit of the revenue of the beat. So that's a hard environment. So okay, can we put we spin this out? What would that look like? And so, I was tasked along with it with a wonderful gentleman called Scott Yara kind of we put our heads together there, Scott came from the data side and had been the founder of green plum, which had been acquired by EMC. And actually, green plum had also themselves acquired a smooth, agile development shop called Pivotal Labs. That's it. So you've got Pivotal Labs inside of green plum inside of EMC, and you've got all of the sort of SpringSource stuff as the fabric at VMware and Scott and I kind of put our heads together and came up with like, a technical thesis for households like the Cloud Foundry plus the spring stuff, plus kind of some of this data platform could come together and make a cohesive whole and many other people were involved in the eventual spin out the became pivotal. And that was my small part. So so we spun pivotal out of VMware and pour it became the CEO of pivotal. And these assets from EMC came across. And as part of this are important, same on day three to rob me who have been the founder of Pivotal Labs. You're like, Rob, we really like your name. Can we steal that? And so that's how the whole thing became called pivotal. It came from Pivotal Labs. And one of the things in that thesis was like, the spring was really successful because we had the development of the platform itself. And we were working at a tight feedback loop with the people who were building apps on top of spring and that was the open source thing of a training and consultancy everything that we did, made it work. Look at the pot. That thesis was a lot, you know, we've got this fledgling cloud platform Cloud Foundry. And there's this group kind of Pivotal Labs that's weirdly sat here inside of EMC that's building lots of these kinds of apps that would naturally run on a platform like that. It for its clients, can we recreate some of that feedback loop? Right. So we can we can we put this Pivotal Labs magic on top of Cloud Foundry, and eventually actually, a lot of the building of the Cloud Foundry platform itself took place with inside of what had been Pivotal Labs and the rock news tutelage. And eventually, of course, he went on to become the CEO at Pivotal. So Pivotal, was always like, part owned by VMware, partly owned by EMC had some other external investors, etc. And then, obviously, like the spin out successfully, once it became a big company did really well, some very, some great deals and customer success stories. But yes, is it the story kind of ends a bit strangely, because as you alluded to pivotal was later, you know, after my time, folded back into VMware, so we kind of went full circle. And maybe VMware was again, feeling this need to, to get tied to the cloud and cloud platforms and of stasis, having a Kubernetes unit was brand new, etc, at that point in time. And so, so yeah, Pivotal, Pivotal, went back in again, but my part was only taking it out.

Tim Bourguignon 31:17
Okay, thanks for the overview. And by the time you had started switching back to another kind of role, you were more involved in strategy, and then you went more into finance and helping companies grow

Adrian Colyer 31:30
isn't. So again, like another a lot of these links are like sort of a thing I didn't know was about to happen. But I was at least well enough prepared to recognize that opportunity, and go grab it. And so this is another one of those cases. So So I've been working a rookie at Pivotal partners, that leadership team looking after like the SpringSource team and Cloud Foundry. And like, I felt like that got to a good place here that in the sales motion, particularly basically customers were saying, Look, we really love spring, we went into spring, now we can see that you make your spring work great on Cloud Foundry. Wonderful. We like we're all in like, good. This is finally like after many years, Paul's vision coming true. And it started to happen. That role for me when I was in the valley, and I still lived in Europe, I live in England, a little bit outside of London, basically Winchester. And so I was basically flying forward and back to the US all the time, about one week in three I would spend on the West Coast, which when you calculate it is almost the perfect formula for living with constant jetlag. And, and at the same time, I was also training really hard, I used to love racing bikes, and I was preparing to do a race called the Race Across America with a four man team, which is like a 3000 mile nonstop bike race, guess what my body really didn't like, all that jetlag, and all that hard training man who knew, and so I ended up with a heart complication, a result of that, which is all fine now, but it kind of stopped me not quite dead in my tracks, but could easily have been literally dead in my tracks. And so that was a bit of a wake up call, like, probably need to stop this, like, Well, okay, I can't do that role I've been doing without, you know, a lot of physical presence in the US. That's kind of a requirement I felt to succeed in that particular. So maybe this is the right time for me to take a step back from Pivotal, what am I going to do? So I'm in this frame of mind, and I got approached by XL in London, who wants some help with due diligence on a on an investment that they're looking at making. And so, you know, I had a somewhat tenuous relationship to them previously, and they've looked at an investment in SpringSource, as you know, years before, but it's not like I was in close contact with some areas. So for some reason, or other sort of some group, they found me as a person that can probably really help them look at this investment. And I did due diligence with it. And I really enjoyed that conversation with the founder, the founder was reflecting back how much they enjoyed talking to me. It kind of it clicked with him as Kevin come early, and Bruce golden the excel at the time. And eventually they came to me and said, Look, why don't you come and be what's called an EIR, which is like an executive in residence XL for a while, you know, come through this for six months or something, not something I'd really considered at all. What can I do? I thought, well, you know, like, I feel like the startup scene in London in Europe has really moved on from when I was involved with it, like many years prior in the early days of spring, except and this is like a pretty good vantage point, actually, to sit for a while and take the polls while I figure out what I want to do next. Kind of like yeah, why not? So you know, I spoke I spoke to the partners and you know, off, I went up to the XL offices, and then sort of that you find out like, well, what isn't EIR? Oh, really? And it sort of is what you make of it is sort of the answer in my book and so ended up getting involved and I think a key thing that helped me was going through my network managed to help source a couple of deals for the for the fun that sort of they might not otherwise have got into. There's nothing like sort of sourcing a deal to make you well liked inside inside a venture firm. And so that was great. I found I was really enjoying it in as much as if you can imagine somebody's doing something interesting and new somewhere around Europe and Israel from from a London farm perspective. And basically in that role, you can talk to them, ask them, whatever you like about it, they'll happily tell you, you can meet all these cool entrepreneurs and find out the stories. And so I was quite enjoying that side of it. And after six months, this is we actually, you know, like, we quite liked working with you, you seem to like working with us, why don't we make this permanent. And so I became what's called a venture partner, which is also I use his private informants like a hanger on to the investment team, but permanent rather than temporary, which EIR is see, there are many different kinds of Venture Partners, I should say, so that they're not all like hangers onto the investment team. But as I say, like, you know, what, I could go and want to become in my career and investor now and sort of that would have been a path. And I consciously chose not to do that I was like, this is working, because our backgrounds are different, you know, I'm coming at it from a very technology oriented lens that I bring a viewpoint and a set of skills that are different to going out and our investor would bring, and we complement each other. And that's why it works. So I don't think it makes sense for me to try and become a not so good version of what you're already doing. Why don't we rest on those different complementary activities. So I decided not to, not to be a Czech writer, but to enjoy this kind of venture partner role, which I have no regrets about, really happy with that. And also, I do that efficiently, like three days a week for Excel. And I've done various other things with those other two days, and also advising of other startups and things in the early days, and using that to still get my kind of hands on fix. You know, that's one of the big fears right now I'm making this transition, you know, sort of like, well, I will I just, I'm seven years in now. Can't believe it. Will I like gradually lose touch? Yeah, well, I sort of, I just feel like, I mean, sure that I'm Adrian, I'm the guy that used to be, you know, and how long can you tell that story before it was thin, and you've lost currency. And so I use his other two days to do a variety of things. And that was sort of part of my thinking as well, like I want. I don't know, my core identity. I'm a technologist. And I still feel that way. And I think it always will. I didn't and don't want to lose that. So

Tim Bourguignon 36:59
you see people see you this way. Just nowadays,

Adrian Colyer 37:05
I suppose. I mean, it's strange to me, because sort of different people get to know me at very different points in my career, and let's have a very different framing. And so I think the other thing that I did during that XL time, once again, the backstory to this is purely accidental. So I'm on a train, I'm commuting into London, and I follow them for a listicle headline, right, so so that clickbait headline, and it's something like 10 computer science papers that every programmer must read or something like so, you know, I've always had this love of kind of the research computer science. Oh, I wonder if I read them all. And so I pull up the list. And there's a couple that in there that hadn't read, or whatever I certainly hadn't read for a long time. So I started reading one of them on the train. So I'm starting to train and I'm reading this computer science research paper, I look around me, and as you as a commuter train, lots of people around me reading the newspaper, right. And so it's a flippant tweet. Oh, here's my hash the morning paper, and I tweeted the title of the research paper I was reading. Well, it turned out that for the next five and a bit years, or something I did for a long time, like a research paper every single day, every single weekday, and then like just down to three a week. And it started off just as a Tweet of the paper title. And then it was like, a tweet followed up by a few kind tweet snippets about what I found interesting in the paper, and then one day like an old SpringSource colleague, Greg Gabler, forge, sitting on Twitter, I think Adrian needs to get a blog, which was a very polite way of saying stop spamming me with all these tweets. So So I started a blog called the morning paper, which is very simple. I select a computer science research paper in the morning, I read it, I think about it during the day, I'd write it up on the way home done post, it was five of those a week for quite some so actually probably event I think as a technologist, most of the people that know me, for a technical technology perspective, know me now through that rather than through whatever I used to do before, which has helped me build like, and maintain wonderful connections with a bunch of you lovely people for you to research groups and present it to people in industry, etc. It's just connecting around the shared love of like, new and emerging ideas and their application against this same kind of transfer from research into industry. And that that moment of change that I really love. And so those people probably would still identify me as a technologist first, somebody that encounters me from a Xcel kind of vantage point first, probably things have been more in that kind of venture capacity, per se, that engagement is normally different to let's say the typical experience they have with other VCs in Europe already so they frequently tell me and so you know, one of the things that's lovely their surprises like if you're a technical co founder doing this some kind of cool project and you want to share the story with to talk to people about it and to do that with somebody that understands what you're doing and can ask you intelligent questions and sort of go a level or two deeper. I mean, I'm never as expert in what they're doing as they are clearly. But just to get that kind of rapport and understanding a couple of levels down, they enjoy and I enjoy. And so they probably think of me in that regard as a technically savvy VC with a bit more technical depth than the average is maybe not that what they're taking away from that

Tim Bourguignon 40:22
makes perfect sense. And that's where we should be I think he should have some kind of a bouquet of profiles analyzing companies helping and from every vantage point

Adrian Colyer 40:32
is that we aware a number of different hats, don't we? Yeah. And so

Tim Bourguignon 40:36
in the video interview, do you still code Do you still have to say

Adrian Colyer 40:39
so? Yes, yeah. I mean, like, here's the thing. In a sense, I'm, I've done more coding at Xcel, in the last few years than I did probably in the last two or three years, when I was actually a CTO of pivotal hour at least they have code that's running live in production anyway, again, like so. So XL, and there are these really terrible, clunky internal systems. And actually, that nobody ever directly using a really old version of Salesforce that it was really cumbersome, it was really slow. Or something better, didn't know how to get something better. I was like, Well, you know, I do know a thing or two about building enterprise apps. And eventually, I just knocked off a coupe, fragile Google just to show you it could be like, so I build this tiny thing is like a side project, right? I only work three days a week. So it's like a part of my three days a week part. But you know how these things go. So gradually, the side project becomes the software that's powering the whole of the London partnership kind of day in day out is the mission critical production stuff. And so you know, I built that out solo, and then gradually hired a couple of people to start working on it with me. And now I sort of have a role helping to specify a map out like x sales, internal platforms for from a sourcing data pipelines can it sort of day to day, kind of productivity, sweet stuff. So I do still code on that I have pushed to GitHub today. So you know, so it's so humbling, honestly, like, you can get all this time you have all the all of these decades in any kind of been CTO and whatever. But you get back to the coalface of it's you and the code, and you got to make it work. And, like the things that you conceptually know, versus being able to make it work in practice, and be really smooth and simple. And like, not getting hung up forever on this and this little silly front end thing. You know, like, it's, I don't know, I think there's something good about like, still being connected with the realities of at the coalface and like, you know, programming and writing good software is not easy, and I still don't think I've mastered it, and I'm still learning and I'm still working at it. I've always had this dream that one day, you'd start this project and you do everything, right. I don't know how maybe some listeners have this kind of data on this project. Everything is going to be done, right. You know, like, and I'm going to make this like, masterpiece of software. And well, I've never yet succeeded, you know, at some point, like the thing, things crumble, and you get these little bits you're less happy with and then you know, maybe one day I'll get this perfect project, I think maybe that's that's part of the quest, there's always a better way, there's always more to learn, there's always something new, and you got to keep pushing for what that is.

Tim Bourguignon 43:15
I fear that it was, let's ride that metaphor for the for the end of the show advice, what would be the one piece of advice that he that someone should hear to be on the right tracks to make this project perfect.

Adrian Colyer 43:30
So I think that the one piece of advice that I give to people now, and it really came back to me through the morning paper, and I think it's just super powerful, and it's dead simple to do, but it's dead simple to understand is like, just try and learn one new thing every day, write it down. That's it. And then just let that compound you know, over the weeks, the months, the years, it's amazing what that will do for you. Versus just not having that consistency of one small thing means you're always looking, you're always thinking you're always learning the little discipline of mandala and write it down. And that's what that's what literally the morning paper blog was for me for the longest time it was my journal of learning. And I think that habit, if you're going to do one thing will really pay dividends for you.

Tim Bourguignon 44:19
I see the mind trick here forcing you to to view the world through this learning lens and having to in forcing you to really see is this something I could learn? Is this something that's learnable is just something you and then figuring out what you could read or write about that?

Adrian Colyer 44:35
Yeah, constant learning and improving. Yeah.

Tim Bourguignon 44:39
Awesome. That's a very good one. Thank you. Thank you very much. So where would be the best place to get in touch with you and start a discussion will continue to disagree and discussion with you. So

Adrian Colyer 44:47
I guess a couple of easy ways here on Twitter. I'm Adrienne Collier and email I'm a Collier co l EY er xl.com.

Tim Bourguignon 44:57
Okay, anything on your plate on your plates that you want to plug in? Before and before we call it today,

Adrian Colyer 45:01
I mean, I guess I guess the last thing to say is if you're in Europe and Israel and you're starting some exciting, you know, technical startup or you're building something great, you know, I'd love to hear about it and to talk to you about it.

Tim Bourguignon 45:12
Awesome. Thank you very much.

Adrian Colyer 45:16
Brilliant. Thank you, Tim. It's been a really great conversation.

Tim Bourguignon 45:18
Oh, Likewise, likewise. And this has been another episode of Deputy Attorney. We see each other next week. Bye bye. Thanks a lot for tuning in. I hope you have enjoyed this week's episode. If you liked the show, please share rate and review. It helps more listeners discover their stories. You can find the links to all the platforms to show appears on on our website, Dev journey dot info slash subscribe. Creating the show every week takes a lot of time, energy, and, of course money. Will you please help me continue bringing out those inspiring stories every week by pledging a small monthly donation, you'll find our patreon link at Dev journey dot info slash donate. And finally, don't hesitate to reach out and tell me how this week story is shaping your future. You can find me on Twitter at @timothep ti m o t h e p or per email info at Dev journey dot info. Talk to you soon.