A Chat with "The Morning Paper" Author, Adrian Colyer

Transcript

Nic Jackson: On today’s show, we’ve got Adrian Colyer. Adrian currently works as a venture partner for Accel. But previously, he held CTO roles with SpringSource, VMware, and Pivotal. In addition to an incredible working career, Adrian writes a blog, The Morning Paper, something that we are massive fans of here at HashiCorp.

In my humble opinion, the work that Adrian has done with Spring has helped to shape the direction of software development and the modern software systems architecture — and I find it incredibly exciting to talk to him today. Adrian, welcome to the show.

Adrian Colyer: Thank you. It’s a real pleasure to be here.

Education and Background

Nic Jackson: We’ve got some great questions. I always like to do dig a little bit into your educational background — try and learn a little bit about what brought you to where you are right now. I have a question for you. I’m not going to ask how old you are. But I have been doing some snooping on the internet, and I did look at when you graduated. You’re actually a pretty similar age to me.

Can you talk to us about your first introduction to computing, and some early memories and things like that?

Adrian Colyer: Yes, of course. It definitely will date me. My first computer was a Christmas present. It was a ZX Spectrum, the one with the little rubber keys — for those of you that remember that. My earliest memories were, at that time, there were hobbyist magazines. Because there wasn’t really any software that came with the computer, especially — they would have listings in them that you could type in to get it to do very simple things.

I distinctly remember trying to get an animated tank to move across the screen. The very first ones, you literally typed in the assembly code — not the assembly instructions — but you typed in the hexadecimal strings. I remember being so excited to eventually get my hands on a — I think it was a BBC Electron because it had a built-in assembler. I thought that was the coolest thing. That was the beginning — doing very humble things very slowly and picking my way up from the bytes upwards.

Nic Jackson: Would that have been Sinclair User back then, the magazine?

Adrian Colyer: Quite possibly, yes.

Nic Jackson: I think I’ve got very fond memories of those days as well. From those early experiences of playing around with computing, what inspired you to study computer science?

Adrian Colyer: Even though it was simple, I graduated to basic, if you could say that. I would write these simple adventure games that were a horrific mass of nested if/else statements — and all sorts of things. But you could mold it. You could shape it. You could make it do things that back then seemed impressive — even though they were basic.

I loved that creative sense to it — being able to shape something. I got fascinated about how the whole thing worked. I remember — it sounds quite sad — the thing I was super excited about the decree course I eventually chose was that they showed you — I think it was — operating systems and compilers. Those were the only things that — beyond the pre-canned game — that I’d engaged with. That was a computer to me, the operating system and then the language. Well, if you teach me how to make those things, that’s magical — it seemed to me — and I was keen to learn about that.

Nic Jackson: I love the fact that so many people are influenced from gaming — the early influencers of computing, to then fulfill a career. Every parent out there looking at their kids and saying, “Hey, you shouldn’t be playing games. Nothing will amount of that.” I think there’s proof on the pudding that it does lead to good things.

Back onto the education — because I think a lot of the things that folks look at these days is the cost of education.

When I went to university, it was — well, it was a lot less; to the point of educational grants to — not only pay your fees — but to pay living expenses. Did you have a similar situation?

Adrian Colyer: I think I might’ve been the very last year not to be part of what in the UK was the student loan system. In other words, I could get a grant and have not just my tuition fees but basic living expenses paid. The year after me — I think a couple of years after me — that didn’t happen, and there were student loans. I was one of the last to come through it, and I did need it; I needed that financial support to be able to do it.

Nic Jackson: I think it was a wonderful thing, and I think what the question I was leading to as well is, do you think that if circumstances had changed — if you didn’t have that capability — do you think you would’ve still gone away to university?

Adrian Colyer: If I didn’t have an external source of funding, as it were? Oh, I mean, I don’t know. I mean, if you look at the scale of debt that a student leaves with, which can be on the order of £60,000. Obviously, we’re talking a while ago, so it would’ve been proportionately less. But depending on the mechanism, I would’ve felt uncomfortable about that — I would’ve thought really hard, for sure. I mean, maybe now, we’ve had many years of getting used to students repaying it, and it’s become more normative. But it’s a huge thing to leave hanging around your neck.

Nic Jackson: What do you feel about the worth of it? The benefit that you had out of that — I suppose this is the key thing?

Adrian Colyer: At the time, I would’ve been very wary of it. But looking back — of course — I’d do it every single time. It was A, great fun doing this degree, and I learned a ton. But like most of these things, it was what unlocked the next step. Without going to university and getting the degree, I wouldn’t have been able to take the next step. Then nothing that followed would have followed, probably.

Nic Jackson: Do you have any takeaways? The thing I learned in a computer science class is the same thing is a principle that I apply today?

Adrian Colyer: I think you take inspiration from a few teachers. I remember one lecturer who was brilliant. He’d done all sorts of LISP-y things, and I enjoyed his classes. Maybe you take a belief in yourself, where you’re like, “Hey, I can do these things, and I can study them.”

Some of those principles have perhaps followed through. A lot you learn later. But the belief that you can study and master things and enjoy it, etc., that was planted in me then. That’s been hugely valuable.

The IBM Years

Nic Jackson: We all know that it did lead to bigger and better things. Let’s look at the first step there. I believe your first step from leaving university was a career at IBM?

Adrian Colyer: Yeah.

Nic Jackson: How did that start? Was it a career graduate fair — or did you directly apply to the company?

Adrian Colyer: I remember when I was graduating, there was a recession. There were hardly any jobs around. So maybe there was a recruitment fair. I went to university in Southampton. There’s a big IBM Hursley research and development site just up the road employing 1,000+ people or whatever. It’s an obvious, known big employer in the area. They probably sponsored some prizes at the university. There was a connection with them as an obvious employer.

I remember at the time there were no permanent jobs anywhere, and I went to IBM solely because they offered me a four-year fixed-term contract. I thought I’ve probably got more chances of four years of work on that arrangement, at this point in time, than going in as a permanent employee and first-in-first-out — if times get tough. Obviously, I converted from a fixed-term contract to a permanent employee after a while.

AspectJ

Nic Jackson: You spent 13 years there, right, I think? I mean, I hope my mathematics is correct on that. You must’ve enjoyed it? I want to touch on one of the things which, again, I hope my research is correct was it IBM where you first started to look at AspectJ?

Adrian Colyer: Yes, it was. Absolutely. My IBM past has been like a real grounding in classic middleware time transaction processing, messaging system. That’s the time that Java first came into being, etc.

I worked on a platform called CICS, or C-I-C-S — as the Americans like to call it — as well; many things. While I was working on CICS — that was what we call now an application server, I guess. It was a mainframe application server. It did many of the things that you think of as a modern application server. You have the transactions and all the rest of it. We were thinking about the programming model of how you’d write an application ­— and how the application connected to the underlying application server.

I think — because I had that idea in my head — I went to a conference. I went to ICCE 2000. Ironically, I was presenting a paper there, which was called From Research to Reward; Challenges in Technology Transfer — or something like that; talking about how we took work out of IBM Research and tried to find places to apply it.

I was there for that reason, and there was a paper presented by somebody called Gregor Kiczales, and the title was Aspect-Oriented Programming. I literally just thought, that’s an interesting name. I don’t know what that is, but it sounds interesting — and I should go check it out.

It was one of those moments for me, where you see a new idea or a new technology, and it instantly connects with you. It says the core of an application could bind to a piece of middleware and describe its transactionality, security, persistence, logging — and all these other attributes that, back then, we were doing with horrific — I guess it was XML — in that first generation. Here’s a much more elegant way of expressing it. These Aspect things feel like they neatly encapsulate this. That was my first hook.

Eventually, I got talking to that team, who’d been running a project out of Xerox PARC. My pitch to my boss literally was, “Hey, there’s a team at Xerox PARC who’ve got this brilliant idea, and they don’t know what to do with it. Maybe we should pick it up and run with it.”

The team building AspectJ were super kind to me. They embraced me, and we collaborated together. Eventually, they decided the best way for AspectJ to go forward was to open source it. When they open sourced it, I took over the leadership of the project and took it forward from the day of open sourcing onwards. I incubated all of that during my time at IBM — and then moved on fairly shortly afterward, but that was the genesis of it.

Nic Jackson: I mean, I looked at this around the timing, as you said, starting around 2000 when you saw the paper. But specifically, I found an article which you’d written back in 2005. There was one thing that literally jumped out of the page at me — you mentioned, and you quoted Eric Evans on domain-driven design.

I looked at this, and I was like, hang on a minute. Adrian is talking about Eric Evans and domain-driven design in 2005. I remember looking at this, maybe even 2015, and thinking these were revolutionary concepts.

I found it evidently apparent that — even back in 2005 — you were deeply thinking about how systems are composed, and potentially how they interact, and how they’re decoupled. Was there a primary motivation around that? Was it based on the work that you’d done with CICS, and helped you developed something larger?

Adrian Colyer: That took me to AspectJ.  For those who don’t know — AspectJ is an aspect-oriented programming language. It’s all about really saying, look, when you build a system, there are these things. We call them cross-cutting concerns. If you were to write a design document, they’d be one chapter — one paragraph — in the design document. It would say something like, “All the services at this layer are transactional.” Blah, blah blah. This is how transactions work. In many codebases you’d have that one coherent concept in the design, and it would end up scattered across a large bit of the codebase. That’s why we called it a cross-cutting concern.

The thing you had to think deeply about in the AspectJ context — in order to build the language and grow the community — was how do we make that modular? I used to say, “How we make the code look like the design?” If it’s one conceptual thing in the design, how can it be one conceptual module in the code — and what does all that entail?

Which leads you to thinking about, well, what is a module, and how do we design our system — and all those classic Parnas papers. That’s the thread that took me into all of those places. We knew Eric Evans as a friend of the SpringSource team and his wonderful work — and very much enjoyed talking with him and working with him over the years.

Nic Jackson: I’m a big believer in domain-driven design. I think domain-driven design is the thing that a lot of people haven’t realized that they need right now. I think it’s something a lot of folks naturally will center around when they’re trying to build their teams and their organization around microservices.

But I literally find it mind-blowing that Eric Evans was able to think around those topics back when systems were a number of interconnected systems, rather than tens or hundreds of interconnected systems. It’s a brilliant, brilliant piece of work.

Adrian Colyer: It’s one of those few books that you can look at over the years and say that was a real landmark that changed things. There’s before and after Eric came in with his DDD — and that shaped the way a lot of us think.

Nic Jackson: Vernon Vaughn as well was very popular — and in my last job — we were big fans. Vernon did some great work to take things along and maybe make them a little more accessible around some of the concepts. But brilliant, brilliant work.

AspectJ and Open Source

You mentioned earlier about AspectJ and open source. Now, again, to me, open source in 2005 wasn’t a thing. That’s pretty forward-thinking. How did that come about? What were the drivers around that? How did you spot that?

Adrian Colyer: My first foray into open source was accidental. I’d attached myself to AspectJ, and PARC has some IP and some code that was internal. They wanted to find a way to give it a future and open source looked like a good solution. Now, of course, the minute I got into it, well then — that changed my world.

You’re right; it was super early, especially for the enterprise. Things we take for granted now, like the incredibly rich, fast feedback loop that you can have in developing software in a tight loop with its users, etc. — but completely revolutionary.

If you think about a classic IBM-style product development — certainly of its time — you might work on something for 18 months, two years, then you release it, and then gradually customers use it. Three years after you design something, you might possibly hear some feedback about whether it was any good. With open source, that could compress down to half an hour or something. Your ability to refine and improve and get in that feedback loop was astounding.

Nic Jackson: I think that causes you — or in some ways forces you — to reevaluate the way that you build systems. We tend to move towards a more componentized approach rather than a large contribution to a single entity. Where were the Spring influences coming from, then? Because this is obviously a major, major pivotal moment in software development.

Leaving IBM and Founding SpringSource

Adrian Colyer: Connection — the bridge to Spring. I’m working on AspectJ. I’m the project lead. Around that time, there were a set of conferences, like the ServerSide — for example — that had become a bit of a circuit for a certain subset of people.

Lots of interesting things grew out of that circuit. It would turn out often I was on the same panel — speaking at the same events as this person — Rod Johnson, who had this fledgling thing called The Spring Framework.

A very interesting thing happened. We started talking to each other. It wasn’t an obvious connection. But we both realized that we’d found — as we knew at that point in time — the one other person in the world who had a similar vision about the way enterprise applications, middleware and services that they use should be bound together.

Rod had a key part of the problem, with the dependency injection and with some of the other things that were in Spring. Frankly, Aspect had a different part of the problem — how should you do these transactions and the security and some other things? And so we were like — ah — you put all this together, and you get this nice composite that solves the collective problems.

Gradually, we got to know each other, and I took the leap, and I left IBM. It was called Interface21 at the time — but I hooked up with Rod and the team, and that was the beginning of the SpringSource journey.

Nic Jackson: Which was an incredible success because you took an open source product and not only made it very popular, and still is probably — I would say — one of the most widely used software development frameworks. But you turned a company out of this. You actually managed to make a successful business from this wonderful tool. How did that work? Was that by accident or by design?

Adrian Colyer: It was by design in the intent. The way it was realized, obviously, there’s a lot of learning on the way. Now we’re used to — like HashiCorp — companies that make really big, great businesses and are open source at the core. For the longest time — and in fact, until fairly recently — people didn’t think that was a wide-scale usable model.

The genesis of SpringSource as a commercial entity was a group of smart people contributing to the open source project and also generally doing consultancy. There were primarily consultants who were building enterprise applications and using Spring to do it — finding they loved that way so much that they were contributing back to the codebase.

Rod was leading that, and obviously, Juergen Hoeller was another super key figure. That group came together and formed this genesis of a company that began monetizing as a group through consulting, and then developed training, which is great because you can have one person teach a whole class all at once. Then through this whole journey of, well, is there developer support? Is there production support? Then gradually growing into lines of business beyond the core Spring Framework.

We had a business around Apache Tomcat. We had Hyperic and system management. Eventually, further down the line, business around Redis and around RabbitMQ. One thing that defines that 15-year period of my career is generally, “Hey, we’ve got this wildly successful open source project. Now, how do we make money out of it?” That’s the question on which many ciphers have been spilled — and there’s no simple answer.

VMWare and Cloud Foundry

Nic Jackson: I’m very pleased that you did, and I think it’s a wonderful framework. On behalf of millions, I am sure, thank you for the work that you and the team put in.

Let’s look at next steps. Because after the success of Spring Cloud and Spring, you moved onto VMware, and a little product which a few people will have heard of — which is Cloud Foundry. I think Cloud Foundry was — and is — as an important project for the way that we think about developing and interacting with the software development process.

Where do the ideas come from? Can I be a little cheeky and suggest that Cloud Foundry was trying to tame the beast that you unleashed with the microservice approach with Spring Cloud?

Adrian Colyer: Cloud Foundry precedes Spring Cloud a little bit. The credit for this — and it’s a really incredibly visionary move — really goes with Paul Moritz, who was the then CEO of VMware at the time that they acquired SpringSource.

We came in as a division of VMware at the time. For those that remember, there was a lot of like, “Are VMware crazy? Why are they doing this? This is a virtualization company. What are they doing buying an application development framework in the enterprise Java space? It doesn’t make any sense.”

But Paul had a vision that developers were going to become increasingly important, and because they were the initial contact point, they had a very large sway over what technology choices were made from then on downwards. Of course, now we call that the shift left phenomenon — or developers are the kingmakers — etc.

But Paul believed this enough that he was prepared to spend a sizeable amount of money buying a company, essentially because Spring had this amazing developer audience and interaction with it — in the belief that VMware would ultimately need something that connected to developers on down.

At the same time as that happened — incubated inside VMWare — we met Mark Lucovsky and Derek Collison within the first few days inside of VMware. They had a fledgling project called Cloud Foundry. That was like — well, we also think there’s something; what we’d now called the PaaS layer — that sits above virtualization — that should go with this application programming model. The vision was there then — of all those pieces — and it took us years to assemble, grow it, unlock it and put it all together.

The Creation of Pivotal

The creation of Pivotal was another key step in that journey. You can see that there’s this massive opportunity at the PaaS layer and the application layer. Super hard to realize that full potential inside of VMware, with all of the core products, etc. going on. Another move with Paul at the helm. We spun out the Pivotal company.

We had a wonderful guy called Scott Yara — putting our heads together; how could this fit together? Then, it was even a couple of years into the Pivotal journey — actually, when Pivotal started to try and sell Cloud Foundry — finally, everything clicked organizationally. And it clicked because the sales team were like, “The only thing that customers really want to talk to us about is Spring.” Spring — and the way we build applications — is the lead-in to this platform. Finally, after all those years, Paul’s vision had come together.

Here’s this amazingly powerful developer outreach and platform that has sway, that leads people to a run time that’s best suited to running those applications — that maybe could then run, etc., on the VMware stack. It took many years and lots of cultural alignment and shifting and jiggling to get it all to bed. Then eventually, it clicked — that was a very rewarding moment when it all came together.

Nic Jackson: Well, I think it was a wonderful success, and I think it was attributable to that triumvirate of things. You had the software development framework, the software development platform. But one of the wonderful things that Pivotal, as an organization, did was brought the process. They were leading this route of development — this automation approach, this full quality software development; testing everything — to be able to help people drive business value out of the software and systems.

Adrian Colyer: I saw so many times. The enterprise sales motion for Pivotal — in a number of cases — was: bring in the most senior folks from the company and give them a tour of the Pivotal lab. They actually see firsthand the way that people are working, and the software is being developed, and the velocity, etc. Then they go, “I want that.” And they wanted the whole thing, the platform, the process, the transformation, etc. It was very visionary for them, and that essentially was a huge factor.

Nic Jackson: One thing that you have to be congratulated on around that as well is that it was beloved by businesses and the people who were developing the software. The developers loved the process. The businesses loved the value that they got from the process. I think it was universally successful across the board there — and some wonderful thought leadership that Pivotal has injected into the industry, which is helping shape the way that we currently develop software.

Adrian Colyer: Rob Mee takes a lot of credit, obviously, for building up Pivotal Labs. We took the Pivotal name from Pivotal Labs that had been acquired earlier — and all of that piece of it came from Rob Mee and his team. They were great.

Anubhav Mishra: Props to them. I think so far, it feels like Pivotal was ideal groundbreaking at what it was doing at that time, and I appreciated it over time. I was only exposed to it super late in my own career. But I would always think that somebody should have thought about something like Cloud Foundry in my jobs — and then I found out there was a Cloud Foundry. It had already been thought through. I think that was exciting for me to know.

The Morning Paper

I want to take a pause. Talk about a few different aspects of your career — pick up on the normal flow and talk about the most famous thing that I think you’re very well known for is The Morning Paper. I’m a personal consumer of it. I know Nic reads it, and a lot of HashiCorp folks read The Morning Paper.

My question is, what prompted you to even start something like that?

Adrian Colyer: A happy accident/piece of luck. The honest confession is, I was a sucker for a listicle is how this all began. Somebody posted somewhere, something like 10 Computer Science Papers That Every Computer Programmer Must Read. It was some title like that. I must find out who wrote that.

I just was curious. I’d always enjoyed reading research. I’m like, oh, I wonder how many of those I’d read? Some of them I had. A couple of them I hadn’t. Some of them I hadn’t read recently. I was on the train when this happened to me. I live outside of London. I have about a one-hour train journey into London, which at the normal times is where my office was. I’ve been working from home for quite some time now.

I had this one-hour train journey, and I was sitting there, and I’m reading a computer science research paper, and I look around the train carriage, and my fellow passengers are reading the newspapers. In the UK, like The Times, The Telegraph, The Guardian, whatever. I very flippantly tweeted, “Oh, this is funny that my morning paper is this.” And I tweeted the link to the computer science research paper I was reading.

I thought, oh, well, that was quite fun. Let me share a couple of excerpts. I did it the next day and the next day. Somehow, I think I ended up doing five papers a week for the first two years straight — or something after that, and I took little breaks; end of term as I called it —like, over Christmas and Easter, I’d have two weeks off.

But it kept rolling. First, it was tweets. It was like, “Hey, this is the paper. Here’s a couple of thoughts.” And then I started having too many thoughts about the paper, because you’ve probably picked up, I get really excited about this stuff, and I want to share it. So I’m doing six tweets a day. A good friend who I’d worked with said, “I think Adrian should start a blog.”

It was his polite way of saying, “Stop spamming my Twitter feed,” basically. But you know, maybe he’s right. So I flipped it into a blog format, and I put my condensed excerpts. Gradually the format evolved, I weakened, and I went down to about three papers a week at one point — which is a bit more of a sustainable pace. But that is how it all started — pure chance. But obviously, once I’m into it, it continued by design.

One important thing to me — because, at this point, I’d literally just moved from Pivotal into the VC world. That’s a bit of a strange thing — as a pure technical person — oh, this is an interesting leap. I didn’t want to be the person that used to be the CTO at SpringSource. How many years can you live on that before it gets tired and you’re irrelevant, etc.?

I suddenly realized, one of the reasons I’m so enjoying this, beyond just the research, is it’s keeping me in a current technical conversation with a group of really interesting peers. It filled a hole that was created by leaving a purely technical role in my job. That’s one of the things that helped that to continue and gave me a lot of value from it.

Anubhav Mishra: Five papers a week, Adrian. That’s ridiculous. I know that I barely can make two — especially with the language that’s used in academic papers. It’s fairly complex, and it’s very verbose in many places.

It is really hard to grasp the fundamental truth of a paper — what you’re trying to get to super easily in a short period of time. I think that’s an interesting skill. How long does it take you?

Adrian Colyer: Very frequently asked question. For a post of The Morning Paper, it’s somewhere around three, three-and-a-half hours of time per post; I think something like that. Going from coming in, reading the paper for the first time, trying to distill my thoughts about it, and then write them down and get it all scheduled.

A Morning Paper post is a one-take. I just sit down and write it. They’re not extensively edited. You know what? Because I do so many, I’m prepared to live with the occasional typo and whatever — that’s OK.

When I was commuting ‘though, the pattern would typically be read the paper on the way into London in the morning, think about it during the walk to the office, and have it mulling around in the mind during the day. Then on the train on the way home, break the back of writing up my thoughts about it.

Different papers have different levels of intensity and depth that you need to get to — but that was the heart of it. That’s still — even if I’m not on a train — the gist of how I will do it. I’ll read the paper through. I’ll mark it up. I think about it. What’s the story that this paper is really telling? Why is it interesting to the audience? And then I’ll write the post.

Anubhav Mishra: That’s definitely a unique skill. I’m sure people have told you that before, but it’s not straightforward to do that.

Adrian Colyer: Well, practice helps. By the time you’ve done your first thousand or so, it does get easier.

Anubhav Mishra: How do you find these papers in the first place? Do you look through a catalog?

Adrian Colyer: There are several ways into it. A great way to start that I did as well, I mean, like the 10 Great Papers Every Programmer Should Read, you can go to, for example, the recommended reading lists of computer science courses in areas you’re interested in.

You can see, like, oh, what papers are in the courses? What do they recommend? Maybe this is — in some senses — a canon that starts to emerge, and you can start to do that. Then you start to realize, well, these are the main conferences that come around in these different areas, and maybe these are the ones that I like, and I feel a bit more affinity to.

I mark up a calendar at the start of the year of when they all are, and I go through their proceedings when they come out — and I try and remember these are the papers that look like; I’ll put them on my reading list. Then you start to learn — here’s a research group that — regardless of the conference — does super interesting work. Let me follow that group, etc.

Then there’s just like, I read a great paper. It was really interesting. Then I follow the references in the back. There are these never-ending threads that you can keep following forever. There’s such a vast expanse of knowledge out there.

The actual paper selection — and one thing I like to make sure people understand — is sometimes people have said, “It’s like winning a best paper award if you get in The Morning Paper.” It’s nice for coverage, but it’s not like winning a best paper award.

A, because I don’t have that qualified judgment to say that. But also, I follow my own interests. I pick a paper that — at that time, for whatever thing I’m researching — is the paper that connects to me or speaks to me for some reason. So, it was interesting, and it was serendipitous, but it wasn’t like I religiously read all 40 of the papers from the proceedings and selected this is the absolute very best one.

Anubhav Mishra: *I’m sure people reach out to you, and they’re like, “Hey, you should read this one and summarize this one,” and so on. I’m sure your Twitter DMs are full of folks sending you papers?”

Adrian Colyer: I have started to get some of those suggestions, and that’s just wonderful. I mean, if somebody’s already said, “Hey, I read this paper, and I loved it,” and they send me the link, I’m always very grateful for those. For sure.

Anubhav Mishra: I guess The Morning Paper; has that helped you in your career? Has that given you an edge over, other folks? It kind of touches on your point earlier — when you talked about you venturing into the VC world — and this kept you relevant. How has that helped you in the day to day job that you do today?

Adrian Colyer: It’s helped me massively, and in ways that I didn’t necessarily foresee, but I recognize the patterns and then reinforce them. One simple thing is obviously many startups have very technical co-founders. Quite often, I’ve read, or I’ve written about something that’s close-ish to what they’re doing. Maybe they’ve heard of The Morning Paper. We can build a rapport very quickly.

It’s perhaps unsurprising, but a founder really loves it if they talk to somebody at an investment firm that actually deeply understands what they do. Now, I don’t get the ultimate intricacies of every company I meet, but I can have a meaningful conversation with a technical founder down to a good level. So, it’s great for building rapport and for understanding what they’re doing.

The interesting thing is, I can never predict in advance which papers are going to later come up and be useful. It’s not like I’m particularly choosing papers because I think, oh, that’ll be great in some conversation with a founder down the line. But so many of them often are. Again, it’s about having this wide — for this role — broad-brush approach over everything, and then allowing luck to do its thing.

Life as a Venture Partner

Anubhav Mishra: Talking more about the VC role, and which is you today. What is it like being a partner who is a computer nerd at a VC firm? How does that work?

Adrian Colyer: My role is what’s called a venture partner, which I informally describe as a hanger-on to the investment team. Well, first off, I started as an EIR, which is like a temporary view to come and see what’s what. I thought, hey, this is actually a super interesting vantage point.

The fund I work with out of London — we invest in companies out of Europe and Israel. If somebody’s doing something really interesting in Europe and Israel — starting a business, got some great technology going — I can talk to them. They tell me all about it, and they answer any questions I have. I mean, how fantastic is that? All the people that you get to meet, the conversations you have, and the things you get to learn.

That side of it is absolutely brilliant; that you’ve got that connection. Then I realized I can try and be an out-and-out investor. I can go down that path and try and become a senior partner, and I can be responsible for writing the big cheques, etc. I thought, probably I’ll be not quite as good at the more CEO traditional background investors that are in the London firm.

Likewise, they have — to me — an incredible understanding of technology, given that they haven’t worked in a deeply technical role. Some of them have — but certainly so many years. They’re never going to be as technical and have that breadth that I have on that front.

I’m not going to go to McKinsey and be a consultant — or go to Harvard, or that kind of thing. Why don’t we be complementary? That’s how it settled inside of Accel — and it works really well. I work alongside the partners. I help with sourcing. I help with diligence. I sit on boards. I help grow companies.

But I’m not trying to be the out-and-out investor, and I think that helped them because they then understood where I fit in. It definitely helped me to say, “That’s not me, and I’m comfortable with this member-of-the-team, but I don’t have to be the front person on every deal.” That’s how it’s been structured.

Future Technology Trends

Anubhav Mishra: That’s very well-balanced, at least from what you’ve explained. You do end up researching a lot of future trends and where the industry is going. I’m sure you’re asked this question a lot of times. In your perspective, where do you feel the industry is trending towards?

Adrian Colyer: Accel does this thing it calls the prepared mind, which is the famous quote, “Fortune favors the prepared mind.” We look at an area, and we’ll try and form a thesis about what a winning hand might look like. Then we’ll search the companies with the hope that if we encounter a company or some founders in that space, we can be smart enough to move quickly and decisively. That’s the theory there. We do that work as a team through a whole range of things — and you certainly do get to see some of the themes coming through.

Now, do we look at big five-year horizon things? Perhaps not quite that extreme. But we certainly do thematic stuff. For example, a team have recently been looking again at a bunch of developer-focused and developer-led companies and looking at some of that.

Been looking in — again, because actually, I’ve been building some of these — I still am hands-on am writing code, which is another aspect of the role I really enjoy. Some of the stuff around building robust, solid, mature data pipelines and operating them, etc. There’s a real hole here that doesn’t seem to be filled. We’ve been looking at some of that.

We did the obvious. We’ve been going back a few years looking at stuff — what’s happening with AI and machine learning and what things do we like, do we not like, etc.? Not an Accel thing — but it really caught my eye in the news recently — IBM saying, “Here’s our roadmap to our 1,000 qubit quantum computer,” for example.

That’s not really for Accel yet, but wow. What can you do with 1,000 cubits? Look at that trend; they’re doubling Moore’s Law. That’s cool, and it’s going to be a real leftfield thing that intersects with us at some point.

Anubhav Mishra: What’s surprising to me is that you’re still hands-on-keyboard. I’m sure it surprises a lot of people who are viewing this, as well?

Adrian Colyer: It wasn’t really planned. Accel, at the time, had an internal system that was just terrible. Everybody was complaining about it, and I knew a thing or two about building these web app things. I quickly built a little better front end on top of the old existing system. It’s grown, and now it’s called Sourcery. It’s Accel’s internal platform for doing top-of-the-funnel sourcing. Can you find some signal in the data that helps the very top of the funnel say, “Hey, maybe here are some companies that you ought to be looking at?”

It does that, and it streamlines all the processes and practices, etc. Oddly enough, I probably do as much if not more actual real coding — certainly code that goes into production — than I did when I was wearing the CTO hat of Pivotal, for example, because you don’t get to write much of the product in those kind of roles.

Nic Jackson: This highlights that we were talking to a person who absolutely loves what he does. I’m guessing that there has not been many second thoughts in all of the steps throughout your career and to where you’re at today?

Adrian Colyer: I’ve chased what interests me, what fascinates me, and I think where I felt I could keep learning. I just follow that and see where it takes me.

Learn One New Thing Every Day

Anubhav Mishra: I guess we could keep going on and on and asking Adrian all kinds of other questions because it’s so interesting. But I think I could conclude with a last question that Nic and I like asking folks that are on this program, For all the folks that are watching, what is one piece of advice you would want to give which would help them to propel them to become the next Adrian?

Adrian Colyer: Great question. I’m a great believer in the iterative process and little feedback loops, etc. I think if there’s one thing — and in essence, The Morning Paper is an example of this — try and learn one new thing every day. It can be a small thing. It doesn’t matter. Maybe write it down so that you get a little bit more like, oh, I did it. What was the thing for the day? And if it really feels good, maybe share it.

All you’re looking for is to get that compound interest thing going. It doesn’t have to be much, but it’s the regular and little and often — and this habit of am I learning? Am I growing? Did I write it down? Have I got the evidence? If you do that every weekday — whatever — for a year, you’ve got 250 little improvements, little new things you’ve learned, and just keep it compounding.

It doesn’t matter what it is, whatever — a habit — you come down in the morning, you have your coffee, you read or learn something, and you write down what you learned. Done. Simple as that. But just let it compound.

Anubhav Mishra: All right. I’m going to take out my diary right now and start writing today. The snowball effect. Hopefully, it works out well for everyone. Really appreciate you, Adrian, for your time and having you. It was a pleasure and privilege to have you on the show. I know Nic, and I enjoyed our conversation with you — thanks so much.

Adrian Colyer: Brilliant. Great chatting with you.