The CTO Show

Okay, welcome. Welcome to The CTO Show on Cloudflare TV. I'm John Graham-Cumming, Cloudflare's CTO, and I'm very happy to have with me today Justin Cormack, who is CTO of Docker.

Hi, Justin. Hi, John. Good to see you. Yes, good to see you as well, even if it's a Zoom call and not what I would prefer, which is a coffee or a beer or something.

But I guess people couldn't listen in our conversation if it was a coffee or a beer.

So we'll go with technology today. You know, on this show, we spend time talking about what it means to be CTO.

And the reason I started this series was that I've seen the CTO role mean many different things in different companies.

And I think it's perhaps one of the most ill-defined roles, depending on the company.

So I'm going to start with my standard questions I'm trying to ask everybody, which is, what does the CTO of Docker do every day?

Can you tell us what that's all about?

Yeah. So yeah, it is a very varied role. And I kind of feel that when I was about to become CTO, I kind of looked and discovered all these varied things.

And I was kind of, oh, OK, this is less well-defined than I kind of assumed. And so the first thing, I guess, is that I kind of see my role as, I mean, we have a team of people around that.

And so particularly, we have a VP of engineering, and we have a VP of product as well, who I work with very closely.

So I know that some people kind of view the CTO role as taking in one of those two parts.

And we have those roles split out.

So those are some things that I don't specifically own. But I do work very closely with those people, because it's kind of difficult to do the role without that.

So my role, I kind of think, is it's a strictly technology and strategy role in terms of guiding the organization in those directions and particularly helping around product teams and product around making that work well with technology directions we want to go in, what's the art of the possible and the strategic in those areas.

So I do spend a lot of time with our, even though we have a director of product, I spend a lot of time working with the product team on what's the options available to do here, what could we do, what strategically long term is a good idea to do, what kind of thing, what are the possibilities, what are the things that they might not have thought of, and those kinds of things.

And then I work with engineers to help them, again, just expand their ideas of what's possible, give architectural guidance across the organization as a whole, help people with questions and things there.

And again, make sure that the product people and the engineering people are talking to each other and understanding each other and working together well.

So I do feel I'm kind of between product and engineering quite a lot in those ways.

Do you write any code? Not much at the moment.

I try and do a little prototypes and demos and those kinds of things, but I'm not there writing a lot of code.

I think that's part of the thing about this kind of stage that Docker's in as well, because we've been around for a while, but we're a weird historical situation.

We're kind of reformed series A startup. So we have areas that we've been working on for a long time and we have stable products, but we're still re-exploring our monetization space and what our scape is, because we spent a bunch of years working on enterprise products that we eventually sold off to Mirantis.

And we're working back on the developer tooling space again, which was really the origin of Docker, but we have a bunch of things we built in that space over time.

And we're just trying to explore and extend them into new areas rather than trying to write in a kind of normal series A startup at this stage, I guess we would have less existing stuff and be building more new stuff.

So I guess Docker is a weird company from the point of view of having a strange history like that.

Let's talk a little bit about history, because you didn't join Docker as CTO and it's a bit like me, right?

I joined Cloudflare as a programmer, writing stuff and ended up being the CTO.

Just talk a little bit about your history, because you've been at Docker for a while now.

Yeah. So I was coming up to six years in a few months, I think. So, yeah, I started off...

I was working for Unikernel Systems, which was a startup we did that was acquired by Docker.

And I was an engineer. I worked on Docker Desktop. Originally, I worked a lot in our open source products, you know, Docker Engine.

I'm a maintainer of Docker Engine and so on.

So I kind of went through that side of the business originally.

I've always been an IC at Docker on that track.

I have done management and other roles in the past, but I always stayed on the IC track at Docker.

And I became CTO when it was February this year, so a few months back.

I'd kind of been working, you know, kind of closer to that role over time.

I'd always... For a long time, I'd been, you know, the most senior engineer at Docker.

I'd been involved in a lot of kind of strategic work separately.

I've been, you know, involved in a lot of the things that as CTO I've been involved in, like, you know, over the years, like, you know, looking at strategic acquisitions, looking at, you know, other strategic things from that point of view.

But, you know, obviously, I mean, I think that, you know, I kind of...

It was a kind of interesting kind of path into that role. I think we're unusual, aren't we, in doing that kind of transition from engineer to CTO in the same company?

I think so. Although, I mean, it's interesting because some of the very small companies, they kind of decide to have a CTO when there are only three people, which I actually think is kind of a crazy idea because you don't actually know whether that person you're calling CTO right at the beginning is actually the right person to be CTO longer term.

And I think it's better to sort of grow people into those things.

And it sounds like, you know, you're a little bit like me in the sense that you would have had past management experience and stopped doing that and went back into a technical role and then sort of went back again towards management, you know, within Docker and within Cloudflare.

Yeah, I think my career has been that kind of mix of changing roles over time.

I've kind of moved into management and away from technical work and then kind of oscillated back to deciding, you know, that I fancy doing some technical work again and getting hands on again and then going back again.

So it's like I've always felt that it's something that you should be able to move between.

And I think I'm also sort of I'm a person who likes to know what's going on and I'm always engaged with the business side of things as well.

So I find I kind of find it I always get this thing that I want to I want to know what's going on and where we're going.

And in the end, that kind of leads you to wanting to, you know, direct where we're going because you get you get, you know, because you're opinionated and you care about it and you know about it and you spend time thinking about it and you want to move into those kinds of roles.

But but I'm also, you know, I am a you know, I do like coding and I do like solving solving those problems as well.

So I think being able to go back and forth between those things in different roles and over time is is good.

And I think I mean, management management is something that, you know, I learned a lot from doing it.

And I think it's a it's a valuable thing to do.

But I think that, you know, I think I mean, a doctor, I definitely decided I want to stay on this kind of icy track rather than move to a management track.

And I kind of felt like I'd done my learning from management to some extent. So are you managing people today or are you?

No, I'm not. I'm not at the moment. And I think, you know, at some point, I think we may end up with an office of the CTO and managing some people doing that.

But there's not an event at the moment. The, you know, the engineering board reports into VP of engineering and I'm not doing management.

So I think that's again, you know, those those roles are definitely blurred in different companies.

And I mean, doctors had three CTOs, I guess. So we've kind of done all the options in a way.

We started off with the founder, CTO Solomon, and then we had a we had we had an external CTO who was kind of much more a VP of engineering type person in terms of his previous roles.

And then there's me who's come from, you know, more as I see track coming up from that side of things.

So I guess we've we've we've we've had all the had different structures over time as we've grown and done different things.

I think that's an interesting point, though, right, about, you know, Docker has been through a couple of different lives.

But in general, in companies that are growing, if you fix a title on somebody, it's not necessarily the case that that's the right person for that job.

And things are going to change over time.

I know that at Cloudflare, we we kind of resisted having job titles that were especially the big titles for a long time until it was like, OK, this makes sense, because otherwise, you know, is that the right person to be in that role?

Do we know what the role is exactly? And is it going to change over time?

Because the other thing I mean, my role has changed enormously over time within Cloudflare.

And I assume, you know, you having been an IC now to the CTO must have seen enormous amount of change within Docker as well.

Yeah, absolutely. Totally. I mean, we there's been a huge amount of change.

And and I think that the kinds of the kinds of role that are needed have definitely changed in that time.

And I think that and, you know, we have had we have had different people doing those roles and it has changed.

And I think that it will continue to change. And, yeah, I can see that.

I can see that. You need you definitely need this flexibility, I think. I think it's interesting that you just didn't didn't have titles and that's that's one way of doing it up to a point.

But I think you also start, you know, you still need to examine yourself and say, am I am I am I am I doing the right thing?

Has this all changed?

Am I still the right person? Should I be doing something else? And and those kinds of things, I think it's, you know, it's important to introspect as you do these things and and work out, you know, you know, how.

How you scale yourself, how you scale the role, how you're delegating it, whether these things changing and, you know, I'm still new to the role, still trying to work a lot of those things out in terms of what what should I be spending more time on and less time on?

And, you know, some of it's, you know, some of it's the circumstances we've been in over the few over the last few months.

But, you know, looking ahead, what's it what's it going to look like in six months?

Because, you know, it's going to be, you know, it's going to be different again.

You know, we are you know, we're a startup and and we are, you know, we're scaling and we're we don't want to be we don't want to be solving the same problems in six months.

We want to move on to something else.

It's interesting, though, you said the thing about figuring out the role yourself because, you know, you've you know, you've been in the role since February.

I've been in the role for a number of years and, you know, I hate to break it for you, but I don't think that gets any better.

I think the figuring out what you should be doing is the constant thing.

I suspect it's the same thing for anybody in a C level role in a company is the responsibility you have every day is not just people who work for you, but it's like, what am I doing today and is it valuable?

And that that for me is actually the toughest thing about this role is that sort of sense of I have to reexamine myself and my job every day.

What am I doing? Yeah, no, completely. And it's it's definitely I mean, I think that the I think that that was a big change going into that role from I.C.

because, as I said, I was doing some of I was doing some of the pieces, but there was a change from there was definitely a noticeable change at the point of, OK, I'm responsible for these things now and I've got to make those decisions about what's valuable because, you know, there's no one else to make those decisions about what's the most valuable thing now.

I mean, obviously, there's a there's a team I'm working with, but, you know, there's a there's a fundamental kind of responsibility shift at that point where you're you're you're driving those things rather than making those things.

And you've kind of got to you've got to, you know, take that take those responsibilities on yourself.

And as you say, think about what's what's valuable, what what you're getting done and what the things you could have got done instead are and whether they were would have been better.

Yeah. How much of your time is you mentioned architectural staff internally working in engineering, working in product?

How much of your time is spent on what I think of as like external activities, major customers, major partners, all that kind of stuff?

It's it's a fair amount.

We I spent a fair amount with partners. I I work a lot with the CNCF.

I'm on the CNCF Technical Oversight Committee, which means I spend quite a lot of time looking at upcoming cloud native projects and which is really interesting because it keeps me in touch with where things are going in the in the broader industry and what's relevant to us.

And, yeah, I spend a lot of time with partners.

I mean, we we work, you know, very closely with a with a number of partners.

And, you know, I think it's and and customers, our customer, we have a lot of we have a lot of small customers now.

We're a bottom up developer led business. Largely we run not so many.

So I probably spend I used to spend a lot of time working with large enterprise customers when Docker was in enterprise sales.

It's less I spend less time on kind of that kind of sales engagement now than I used to a while back.

But we and we have lots of smaller customers instead, which is a different problem of trying to, you know, trying to follow a lot of people's opinions and data and those kinds of things, which is which is an interesting and different kind of process from the kind of big enterprise sales business that we were in before.

Right. Right. And you like me are fairly accessible on Twitter as well.

Do you find people asking you on Twitter and saying, hey, there's a problem with this Docker configuration I've got or this thing?

Can you help me? Yeah, I do. That does it does happen a fair amount.

I think people, you know, I'm visible. People know who I am.

You know, I've been around. People do ask things. I think that, you know, I think accessibility is important.

I do try and I do try and be accessible to people.

I'm, you know, I'm on, you know, on the cloud native slack and the Docker community slack and Twitter.

And, you know, I think that and, you know, I do think that the, you know, the external community is very important for us.

We were you know, we're a developer led business and we need to know where developers are wanting to go.

I mean, it does to some extent. You know, there are sometimes it's just people grumbling and complaining about, you know, but sometimes it's like real technical issues and real like this is directions we could take.

And then there's a lot of, you know, people working on projects that are related and working together.

And, you know, we've, you know, we're a we're an open source company at heart as well.

And so that kind of community is really important to us.

And we've benefited a huge amount from the contributions that we get and the work that we do in the community.

And that's really important for us. I'm curious how much of your day ends up being reading things?

Because I find that, you know, I end up obviously doing external stuff like what we're doing right now.

Right. And then, you know, talking to customers and partners.

And then I spend a lot of time doing recruiting as well. That's a pretty critical part of my job.

But I also end up reading a lot of stuff like internal wiki pages, external stuff about new technologies.

Obviously, sometimes long emails about stuff.

I feel to me like a huge part of my job is reading and writing things, which seems very 19th century, but turns out to be very important.

Yeah, you mentioned reading first, and I was thinking, yes, and writing, actually, as you said that, because I think that one of the I mean, yeah, I definitely do a lot of reading and writing.

I do think that writing is one of the most effective things for remote working, and it just works really well.

I think we're definitely trying to have a very much a written culture.

From that point of view, I think it was interesting.

We've had a bunch of people through in Docker who are brought up on the Amazon way of meetings of writing things down first.

And we're, I found it, I found it really useful way of thinking about meetings and working with meetings.

And I've, it's a little bit weird at first, when you, I mean, I've had meetings with Amazon, where I've had to write things for that I felt or felt I should write things for them, because that's the way to do it.

But also, I, it's a good way.

I'm kind of learning that culture with people who live it daily and seeing how that how they work.

And I do, I do think that it really is, you know, for remote work, one of the best things you can do, because it's so accessible for people to find things later.

Yeah. Yeah, I, so people don't know the Amazon culture is if you have a meeting, what you do is you turn up to the meeting with a memo, which outlines everything, everybody sits down and reads the memo together, or they may have read it beforehand, but they literally read it and then they can discuss what's in it.

And we have some people who are from Amazon as well. And the first few meetings I have with them, it felt very, very strange, but and it's very hard work, because you have to prepare this memo before you have a meeting.

But it's also incredibly productive in the meeting, because everyone's got the same data and information and have a discussion.

And I totally agree that only in the remote work world, the written word is so, so important, because one of the dangers in the remote work world is we replace meetings in the office just with zoom calls.

And it's absolutely exhausting to do one after another and surprisingly inefficient.

And I understand what we were chatting beforehand, that Docker has gone completely remote.

So talk us through that.

How has that affected your role, given that you can't sort of walk over to someone and have a chat about something?

Yeah, I mean, I think it's really interesting, because it's something that, you know, changed gradually over Docker's history.

I mean, when I joined, we were, we all said we're, I was, we were based in Cambridge, when we were acquired, and we said, we're not moving to San Francisco.

Previously, Docker had insisted that most of the people who it acquired moved to San Francisco.

And we were the first people who kind of collectively said, we're staying.

And, and that was part of the agreement. And it was. And so we were the first substantial office outside San Francisco, but Docker had always had some remote people.

But they've been kind of scattered, and they've been forced to, you know, they've been kind of forced to fit in.

But over time, we ended up with a lot more offices in different places.

So we were more distributed. So we we had a, for a long time, we've had a large Paris office, because Docker being originally French had a very strong culture.

And we was, we found it quite easy to hire people in France, because people have heard of Docker, the great French success story.

And we had, you know, an office in Canada, and a couple of other ones in the US.

So we become much more distributed and a little bit more remote.

But then, with COVID, we just started, you know, we really just, and just a little bit before that, as well, I think we just started hiring people, just without regard to location.

And we, we just got rid of our San Francisco office, the one opposite your office in San Francisco.

Yes, it was right opposite the counter office. Yes, we just, we just got rid of that before, like a week before the pandemic, pretty much.

And then during the pandemic, we just let our other leases roll off.

And so we're gonna, we're office and, you know, we, we'd hired, but we'd hired more people who were just remote, you know, in across the US and Europe before that.

And it just seemed kind of a logical extension of that gradual process of getting more distributed and more remote.

That was just accelerated a bit by, by the pandemic. And how do you get people collaborating well in that environment?

I mean, obviously, you say writing is important.

Are you doing something to help people figure out how to communicate?

Yeah, I mean, I think that writing, writing is important.

And writing is very important.

And that's extremely important. And, and I think that kind of writing culture had been there, we'd already started a few, some of the things to do with remote meetings before the pandemic, again, we were, we'd encourage people to take meetings from their desks rather than from meeting rooms, so that everyone was on equal footing, even if they weren't in the same office.

And so some of those cultural things around, you know, not being, you know, not being asymmetric between a bunch of people in an office and someone who's remote or people who are split between two offices.

We, we used to have a lot of kind of local meeting, meetings across, you know, sort of similar time, like, Cambridge and Paris, we used to meet on a try to localize teams around time zones.

So most teams are pretty uniform in time zone.

So not more than a few hours difference, there's a few exceptions, we have, you know, we have some, some people, some teams have a few people who are further apart in time zone, but generally, we try to keep the work in time zone, because we found that then sort of things like standups and collaboration in Slack, and things work much more smoothly.

We, we, we did have a time when we had some really significantly split teams, and it was much harder.

Yeah. But what about your role?

Because you I mean, you must have to cross time zones all the time as a CTO. Yeah, you manage that.

I mean, I used to, I used to travel to the US a lot. Like, I used to go to SF for kind of two weeks every couple of months, usually.

And so and, and visit our other offices often as well.

So I used to, I used to kind of compensate, I think, by traveling, and I've had to not do that, which is interesting.

So I think that, you know, I think you have to consciously, you know, spare, you know, spend time with people, you know, outside your time zone, and it is, and, you know, spend time making sure that you, you communicate with them and get to know, you know, get to know them personally, and, you know, have a relationship where you, you know, each other and have that familiarity you often get from visiting.

I mean, that's a very good point. Actually, I really noticed this because I've been based in Europe, and then I'd go visit our office in San Francisco.

And it was enough to meet somebody one time and have a coffee with them or something that the, the electronic relationship later was way better.

Having had that initial kind of get to know you kind of thing.

That's the thing I would love to get back to traveling to do just to build those initial connections.

And I find that a lot harder to do electronically.

Yeah, I think it takes, I think it takes a lot longer.

I think you can, I think, as you say, a coffee and a little bit of time, sometimes it was enough.

Now, I think you have to, you have to spend more time doing kind of smaller things.

I mean, I think that, you know, getting to know people a little bit more gradually is easier, because it doesn't have that kind of immediacy that it does in person.

So I think it takes is kind of, I think you have to do it over a longer period of time to get to know people.

And, and some people, you know, and there are some people who just don't like Zoom at all.

And that's much harder. You know, I think you have to be sensitive to how people, how people like to work online.

It's different there. You know, I do work with some people who just really just prefer, you know, Slack to Zoom by a huge margin, and you have to, you know, and you do it.

And we're going to run out of time talking about how we don't like Zoom.

So we're actually going to get paid for Zoom by running out of time on it.

But I agree. I, so I do final interviews on people, and I do all of them as audio calls, just to save myself from yet another video call every day.

It's just, I just find it so, so tiring. Listen, Justin, thank you so much for being on.

30 Minutes always flies by on this show. It's lovely to talk to you.

Good luck in the new role as CTO of Docker. And, you know, we'll be in touch. Maybe have you back on again when you've settled in.

Cheers. Excellent. Thank you.