On April 6, I hosted the 3rd session of a monthly Company Building webinar series for founders and operators of developer-focused and/or commercial open source startups. The goal of this series is to share tactical knowledge -- the nitty gritty know-hows that can make the grinding experience of company building a little easier for entrepreneurs -- from experienced operators who are still in the game. (We will announce the 4th session soon!)

This session is with Justin Cormack (CTO of Docker) on the best practices of managing and scaling a global engineering team.

To make our wide-ranging conversation more useful and digestible, I edited and condensed the session’s transcript into the following topics (jump to the section that's most relevant for you):

You can find the audio/video version of this conversation on the Interconnected Voices YouTube channel or watch it below:

Be sure to check out transcripts and audios of Session #1 with Matt Ekstrom (ArangoDB, ScyllaDB, MongoDB) on early stage sales and Session #2 with Clint Smith (Discord, Datastax, MySQL) on global company operations. Bookmark the "For Founders" tag for future content.


Justin’s Background

Kevin: Justin, I really appreciate you taking the time. I know it's late into your day in the UK, but thank you for joining us.

Justin: Thanks for having me. It's really nice to see you again. I really love your weekly emails. Interconnected is one of my favorite things to read and I always look forward to reading it. It's really, really interesting. And there aren't other people writing with the same kind of breadth and it's one of the things I really appreciate. I guess I've got a weirdly broad background too, in many ways, so it kind of resonates with me.

Kevin: Well, thank you so much for that, Justin. I appreciate you giving Interconnected a shoutout, but today it's all about you! So let's actually start with that background. I know you've been at Docker for many years, both as an engineer and now rising up to become its CTO, but I'd love to hear, first of all, your pathway into technology. And then we can dive into some of the engineering management topics that we will talk about.

Justin: So I think my route to technology was fundamentally a lot tied to my mother. She was a math teacher and always loved helping us understand things. She did computer programming a long time ago when she was younger, so she introduced us, me and my sister at an early age to computers and technology. And that's kind of where it came from, but I was never quite sure what I wanted to do. I always had broad interests, so I ended up tangentially leaning towards technology, but not jumping into it full time. I worked in finance for a while and investment management, but gradually moved more and more towards software.

I’ve always been interested in business and what’s going on there as well, so I did a few startups. I did startups in IoT, LED display, public advertising a long time ago. I ended up getting interested in Docker indirectly, because I got interested in working on unikernels, which are basically trying to encapsulate operating systems at a more developer focused level. And we did a startup, Unikernel Systems, that was acquired by Docker five and a half years ago now. So that's how I ended up at Docker.

Docker is a really fascinating place. The people are great. I always like working there. It's a really interesting thing from, you know, how do we take open source and turn it into a business? How do we take something that's got mass adoption and created a whole market, and turn it into a business, which everyone else feels they can sell off of as well? And it's been a really interesting journey through that.

So I started off working as an engineer based in Cambridge, UK, which we'll talk about the international things a little bit later on, but basically I worked on Docker desktop. That was our first project we did, which was great fun. We shipped that so it became really successful.

And I evolved through lots of different roles in Docker, working across a lot of different parts of the business. As you mentioned in the intro, I worked in security for a while. Security was always something I'd kind of worked on the edge of, but hadn't really jumped fully in. And it was really interesting to work on that. I mainly focused on product security, but really running all of the security at Docker.

Then Docker restructured at the end of 2019. We sold off the enterprise Kubernetes business to Mirantis and focused really on the roots of developers and developer needs and the initial adoption of Docker, which was all through developers. In that role, I was really the most senior engineer at Docker. By then I kind of started moving towards this sort of CTO role. At the end of the year, I spent a lot of time talking to our investors, Peter Fenton, in particular at Benchmark, and talking about the directions that were interesting and what we need to do. So that's how I ended up moving into the CTO role early this year.

Docker’s Journey Becoming A Globally Distributed Team

Kevin: That's fascinating. I want to actually start with your beginning journey into Docker then. I didn't know that you came into Docker via an acquisition and that's kind of interesting. This was back in 2015 or so, is that right?

Justin: Yeah that's right.

Kevin: So back then Docker was an American company but with some European roots, right? Its founders are French and so on. And you have always been based in the UK. What was that initial, entry way into working remotely or in this globally distributed engineering setup as a acquiree of an acquisition. Would love to hear more about that experience.

Justin: Yeah, I think it was really interesting and if you follow on from there, it's affected a lot of how Docker changed down the way in terms of international things.

So we had the advantage of being quite a big team. I think there were 10 of us at the time. So it wasn't a sort of two-person acquisition or anything, and that gave us a bit more leverage. We were quite clear from the beginning that we didn't want everybody to move to SF. For pretty much all the previous acquisitions except one, everyone had moved to SF.

So we were a sufficient nucleus that was the beginning of Docker's real international spread. It was kind of fascinating though, because I remember at the time they really weren't sure how this was going to work out. And I think we actually had in our contract that said that someone from the team should be in SF at all times. That was sort of a hedge, like you’ll be in America, but that’s not how it worked out. Until COVID, I spent a lot of time in the US. I probably spent more time than the other people. I used to travel every two or three months to the US and spent a few weeks there.

At the time Docker was still mostly SF but that has changed over the years. You mentioned Docker was initially a French company and so fairly soon after we were acquired, in maybe late 2015, or early 2016, we set up a Paris office. We've always found it easy to hire people in France because Docker has this reputation of being a French success story, which is really interesting. So we've had a lot of people in the Paris office who were initially in SF. It used to be quite French speaking on a Friday afternoon in SF: you'd hear a lot of people speaking French, that kind of thing. But now most of the French people are at the Paris office. That was the beginning of really becoming a globally distributed company.

Best Practice: Coordinating Engineers By Time Zones

Kevin: I see. So let's get into that then. It sounds like you, or your previous company was the reason why Docker became distributed, almost out of this acquisition. And now it's becoming more popular, more generally practiced, or even fashionable these days for new startup companies to just have a corporate entity somewhere but you hire from wherever. GitLab, which is a company we're both very familiar with being kind of the prototypical example of that in some ways.

How has your engineering management practice evolved since you've risen up the rank? What do you do to manage all these engineers from all time zones who may even speak different languages, but are all working from the same code base or computer language? What are some best practices you've gleaned so far?

Justin: So it's evolved a lot over this period. I think we kind of had to learn to do it, and we weren't very good at it at the start. Also there's a big change pre and post COVID. Until COVID we were just starting to become a remote work company.

Some people have always been remote at Docker, but it was a small number and we were starting to have a lot more remote working. We had the SF office and a Palo Alto office, and people were moving to whichever one was more convenient or working from home. More people even before COVID were moving away. And we were hiring people outside the offices.

But when COVID happened, we just got rid of our SF office after the Mirantis split, because we were downsizing. And then we just talked to staff about offices and working and gradually people came around to getting used to working from home. And we shifted now into a situation where we're just rolling off the last places for offices and going fully remote. So there were two transitions really, one was to distributed and one was to fully remote.

So the distributed one culturally felt a bit different because we still had offices and we still had these clusters of people always with local management. So we'd have engineering management in Paris, engineering management in Cambridge, engineering management in SF. And there'd be this kind of close knit teams generally working together.

We had times when some of our teams were very split between people mainly working across time zones and not with people in the local time zone or office, which was very weird. And we've really gravitated towards the model where we try and keep coordination within particular time zones but also ideally local offices. I think we're now more focused on the time zone as a unit rather than a place, but time zones are difficult. France to the West Coast is even worse than the UK to the West Coast - it's another hour off. And it's difficult for people to spend enough time together, to work really, really well together. It can work and open source projects often do that, but coordinated working on individual close-knit code bases and products is really hard.

So we're doubling down on that small connected team. We're moving now to teams that are very self-contained, ideally geographically localized, maybe around five engineers, a product manager and engineering manager, and UX. Those small teams are ideally in a single time zone. Really aligning them to solve particular customer problem areas.

Kevin: Got it. I mean it is kind of a wild, wild west. I don't think anybody really has this thing down as far as, “this is how you're gonna manage 100 or 200 engineers scattered across the globe.” A lot of companies are figuring it out as they go. And it sounds like the way you're approaching it now is actually using time zone as the unit. So if I understand it correctly, is it that you will intentionally cluster say a few engineers that need that close knit work or in a particular unit to be in the same time zone, so they can coordinate in a more synchronous fashion?

Justin: Yeah, absolutely. So far we've been restricted in which countries we're hiring, because we were limited by where we had companies. We're going to move to less restrictive hiring and use a global hiring company so we can hire anywhere now, but we were kind of stuck.

We were across the US and Canada. We're in the UK and France, which are an hour off, so pretty much the same time zone. I think we're going to be cautious in expanding the time zones above those areas for now, until we're larger. We already refocused Docker into 70 people now. So keeping that small, tight knit thing is important. I think it'll be a little longer before we're going to move into the Asian time zone probably, but we're going to expand the countries we hire in the existing time zones we have, which is a fairly large block of the world at the moment.

Ideal Team Size; Synchronous vs Asynchronous Work

Kevin: Totally. So to get really tactical now. Based on your experience so far, organizing what I would call engineering pods or small engineering teams along the same time zone, how many engineers have you discovered is the ideal size for a pod like this to work on something together where synchronous work again is a preferred way to approach it?

Justin: Around five engineers, plus the engineering manager, product manager, and UX. We've had larger and smaller teams before, but that seems to be kind of optimal where we're trying to aim at at the moment and see. We're really trying to get the focus where the team has all the resources it needs. We've had central functions for design before, but we've had bottlenecks with central functions and we'd like to really get every team their resources.

Kevin: And what's your opinion now on this balance between synchronous work and asynchronous work? These terms get thrown around a lot, about engineering practices, especially in open source companies. And for those of you who aren't too familiar with the jargon of it all, but if you do any programming, you will know.

Asynchronous just means somebody does it somewhere and then it can wait and somebody else can pick it up somewhere else. And you can do this without really coordination at the same time, while synchronous is the opposite, where you do want to talk through certain things and work on something together at the same time to get the results.

What's your thought on the balance between these two approaches in terms of growing an engineering practice that serves the rest of the company well?

Justin: Yeah, it's difficult because there's a lot of different kinds and forms of communication. The traditional open source model of mostly communicating through issues and pull requests is very async, with perhaps some meetings to set direction but not very often. This tends to be very different from the product-led thing, the pair programming and sprints and stand up meetings and that kind of close-knit communication. So I think there's different kinds of communication and models and they work for different things at different stages.

We are an interesting company in that we have a lot of different kinds of work we're doing and software we're working on. We have open-source work that's in the community and fits more with the very async model. And then we're running SaaS services where people are on call, which is a different sort of communication.

We're kind of unusual in the variety of things we do as a company, which makes it more interesting, but also makes our communication structures a little bit different. I will say getting people better at writing things down is incredibly valuable, whatever you're doing, and writing is in a sense async. But it’s not necessarily about what form of async communication you use, but how well you're doing it. I'm a big fan of the Amazon style writing things down before meetings. We've been moving well towards that culture. We had a bunch of people who are ex-Amazon, who helped introduce those writing cultures to us, which is really valuable.

It's interesting when you can change from presentation/slide cultures to writing cultures over time. And I think being fully remote has changed things as well, because lots of people have white boarding and synchronous meeting cultures that are actually harder to do remotely. Whereas writing is actually a culture that works very well across different scales and sizes of communication. It helps people on board as well. So it has a lot of advantages.

Kevin: Absolutely, yeah. I’m clearly, as a newsletter writer, a big fan of writing. I do think it's probably still one of the most scalable forms of communication, that could both spread out very quickly, very easily, but also get a lot of people on the same page at different points in time. Like you said, probably one of the better, asynchronous ways of communication.

Justin: There is one thing about writing that's actually interesting. It's about language. So people who speak different languages generally often prefer reading to listening, because they can read it at their own pace, but people do find writing in their non-native language more difficult. So there are some nuances around that that are interesting.

Kevin: It's interesting you mentioned that reading is better, for say non-native English speakers, because you can take your time. You don't have to listen to somebody else talk about what we're doing right now, which is a lot harder to absorb in real time. Any advice or thoughts on making writing more accessible as a tool of expression within a company and helping non-native speakers of certain languages write better?

Justin: I think a lot of it is practice. I think writing things down in their native language first often helps people. I actually had an interesting conversation with someone at Amazon about this, and Amazon does not have any English-only rule with that writing policy - you could write it in any language. That has problems potentially too, but it’s an interesting slant on it.

One thing that I've come across with open source projects is that sometimes they're divided by language. I remember the first time, I was an early user of OpenResty, which is a lower, larger plugin for Nginx and that was originally in Chinese. And I used to read the mailing list with Google translate at that time. It was interesting because it gradually transitioned to more English. The author moved to America, but there were communities then that were divided by language. We’re still seeing that some of the cloud native projects a little divided by time zone and language. These things are just difficult.

Collaboration Between Engineering Teams and Other Functions

Kevin: I want to move on to a couple more topics before we open up to Q&A. I know we already have a couple of questions in the Q&A tab here in Zoom. One thing I want to talk to you about is, of course, Docker is a very technical company. The product is very technical, but obviously engineering does not live in its own world, right? It has to work with the product team, the design team, and also the sales and even probably a marketing function as well. What are some best practices you could share with our audience in terms of modes of collaboration between your engineering teams and these other functions in the company, especially in this distributed or multi-time zone world?

Justin: Yeah, I think it's been interesting. Docker has changed a lot and these practices have changed a lot as well. We went from being in the enterprise market to developer focused.

I think the engineering team’s collaboration with sales, marketing, and product are very different. With marketing, we've had this amazing community that's built up really earlier with Docker and our products. And marketing has been around growing that community and building events like DockerCon that are amazing. We had 20,000 sign ups just in the first few days when we opened the registrations for DockerCon this year last week. We had 80,000 people last year at DockerCon. These events are what people really value and a lot of our marketing is about nurturing those communities that we've built up around the products.

The engineers love to get involved in that and people really love communicating with engineers and spending time with them, because they're the people who build these tools that they love. And so the interaction between the community and marketing has always fallen out quite naturally.

Sales has changed more in a way. We had a full, large enterprise sales force when we were in the enterprise Kubernetes and runtime business and that was very much me going to meetings and talking to banks about security and things like that, and shipping relatively slow-moving enterprise products that support the enterprise sales process, so engineers often feeling quite detached from sales. It's more difficult to involve them with that. And it's just that engineers don't like enterprise sales, because they don't like being sold to like that themselves most of the time.

Whereas now we have a tiny sales team and we're mainly bottom up SaaS. We're re-exploring what sales is like for a bottom up developer focused company. So it's a totally different relationship we have with sales now.

There was a massive disconnect with Docker, because the grassroot's adoption of Docker was people who are moving to cloud early, but we were trying to sell products to people who were trying to do on-prem and moving into cloud late. It was a kind of mismatch in the end. I think we're in a great situation now where we're really just engineers trying to sell to people like themselves. We're building products for our peers. Developer tooling companies have this amazing thing, where you are building things for yourself and can say that these people are like me. They're not necessarily exactly like me - they might be less advanced in this journey - but there's much more empathy with them, and that makes it easier.

I think from the product point of view, that also helps. I think that, yes, our products are technical. And Docker's original thing was to take something that was deeply technical and obscure - Linux namespaces and containers - and turn them into something that everyone could use. But the market and the users of Docker have changed so much in the five years I've been at Docker. I realized that now they don't understand how to use SSH anymore.

We have over 10 million people using Docker, and it's all sorts of developers at all sorts of levels of experience and technical knowledge. Most of them don't understand the inner workings of how it is. It's just magic for them. And that's very different from people who had opened pull requests to fix an issue with the Linux namespaces five years ago.

So I think it's hard for product people to work with these things, because it is deeply technical. And I spend a lot of time as CTO working with the product managers to help them understand what's possible. And I'll listen to the engineers do that, help them understand what's possible and help them interpret some of the things that they're saying in terms of what users are asking for and thinking about the possibilities.

But there are product people out there who do work and their careers are on developer focused products. User experience for command line is still a niche area, but there are people who are fascinated by it because it's just an interesting topic. It's understanding the modern world. And what developers do now, other people will be doing in the future. So it's a fascinating area to work in product and we're hiring product managers, by the way, if anyone's interested.

Kevin: Never miss the opportunity to put out a recruiting pitch, right? We're all in tech. Everybody is hiring, but yeah, I think you're right. Docker has probably done almost too good of a job back in the days to obscure all these details in the kernel space and on the Linux level of things so that people are like, I don't need to know this. I would just use Docker, right?

Justin: But that's the right attitude I think. I sense that Linux isn't necessarily something you have to use. Sometimes the Linux desktop experience was based on the Sun Workstation experience and it was kind of nice back then. I remember the first time I sat in front of the Sun Workstation. I was like, "wow, this is amazing." But it's not actually necessarily the way people want to consume Linux now. I mean, people actually want to consume Linux as a deployment platform for applications, but Docker is a kind of an API that you can do that without having to use Linux. And the kind of way that people think of, it is like, "it's a programming API, so it doesn't have to be your life." You can still use a Mac or Windows. Developers think of their life in IDEs, in pull requests, and in code. The operating system doesn't have to be a really visible thing.

One Mistake Justin Wants New Entrepreneurs to Avoid

Kevin: Absolutely. So I want to wrap up with a broader question before we go into the Q&A session. Because you've been through a lot of startups before Docker, and now you're at Docker and you're the CTO. I'd love to hear maybe one mistake that you hope all new entrepreneurs, new founders in our space can avoid when they start growing and scaling their engineering team in the early stage.

Justin: I think that one day you'll have someone who doesn't fit and doesn't work in the organization. Donnie Berkholz, our chief of product, has a great talk he did many years ago at RedMonk about assholes ruining your open source projects. It also applies very much to companies that have people who are just negative and destructive of what you're trying to achieve. Recognizing these early and fixing the problem is really important.

If you're lucky it'll happen sooner and you'll get to learn that lesson sooner, but it will eventually happen at some point. There are people who just are not the right fit for your startup at the stage it is now. You just shouldn't be working with them.

You need to set the culture soon. One of the reasons I still love working at Docker is that the culture is just really nice. People are just lovely people to work with, very modest and great at working together. And we've felt that culture for a long time and it's been there since very early on.

One of the things that as a founder you bring to the company is those attitudes of how you want people to be and how you want people to behave to each other. For eight years now we've kept very much the same culture and quite a few of the same people have been there for a lot of that period too, not all of them. The culture has stayed longer than the individuals who helped create it.

If you like what you've read, please SUBSCRIBE to the Interconnected email list. To read all previous posts, please check out the Archive section. New content will be delivered to your inbox (twice per week). Follow and interact with me on: Twitter, LinkedIn, Clubhouse (@kevinsxu).

四月六号,我主办了每月一次的 “创业公司建设” 系列webinar的第三期,受众专注于面对开发者产品和/或商业化开源创业公司的创始人和运营者。 (过几天会宣布第四场!)

这一场是与 Justin Cormack(CTO of Docker)讨论管理全球分布式远程办公的工程团队的各种最佳实践。

为了使我们两人的对话更有价值、更易消化,我把会议记录从英文翻译到中文并编辑加浓缩为以下几个话题(可以直接跳到对你最有用的话题):

本讨论的音频/视频版本可在《互联之声》 YouTube频道上找到

Justin的个人背景

Kevin: 让我们欢迎Justin上台! Justin非常感谢你能抽出时间来,我知道你在英国的时间已经很晚了,但还是感谢你能来参加我们的活动。

Justin: 谢谢你邀请我,真的很高兴再次见到你。我很喜欢收到你每周写的文章。《互联》是我最喜欢读的东西之一,我总是很期待每周读新的两期。这个周刊真的非常有趣,而且目前没有其他人写出了你这样的广度,这是我非常欣赏的事情之一。我在很多方面也有很广的个人背景,所以你的newsletter与我有很多共鸣。

Kevin: 嗯,非常感谢你Justin,很感谢给《互联》打广告,但是今天的话题是关于你!让我们先从你的背景说起吧。我知道你已经在Docker工作了很多年,是一名工程师,现在又升任为CTO,所以我很想听听你是怎么步入技术领域的。等一会儿我们可以再深入探讨一些刚才谈到的工程管理方面的话题。

Justin: 我觉得自己会走上技术的道路从根本上来说和我母亲有很大的关系。她是一个数学老师,总是喜欢教我们了解事情的来龙去脉。她很早以前年轻的时候就做过电脑编程,所以在我们还很小的时候就把电脑和技术介绍给了我和我妹妹。这也算是一种缘分吧,但我一直不太确定自己到底想做什么。我总是有广泛的兴趣,所以后来有点倾向于做技术的工作,但没有全身心地投入其中。我曾在金融行业工作过一段时间,也做过投资,但渐渐地越来越多地往软件方面发展了。

我一直对商业领域也很感兴趣, 所以后来就做了一些创业公司。 我做过与IoT、LED显示屏和广告方面有关的各种创业公司。我最终间接地对Docker产生了兴趣,因为我对unikernels产生了兴趣,这基本上是试图在更多开发者关注的层面上对操作系统进行封装。

然后我们就做了一家创业公司叫Unikernel Systems,五年半前被Docker收购了,这也是为什么我会来到Docker工作。Docker是一个非常令人着迷的地方,里面的人都很好,我一直很喜欢在这边工作。如何把开源的东西商业化并变成一门生意是一件特别有趣的事情。如何能把一个已经被大规模采用并创造出一整个新市场的东西,变成一个赚钱的业务,而且任何人也都可以拿它赚钱,这是一个非常有趣的过程。

所以我一开始是身在英国剑桥做工程师——稍后我们再讲到国际化的事情——但基本上我是做Docker桌面版的。那是我们做的第一个产品,非常有趣。最后我们推出了这个产品,它也变得非常成功。我在Docker里做过很多不同的角色,工作内容也跨越了公司业务的方方面面。就像你在介绍中提到的那样,我在安全领域工作过一段时间。安全也一直是我有接触、有工作过的东西,但没有完全投入,只是在边缘做过些事情,不过这方面的工作我很跟兴趣。我主要专注于产品安全方面,但实际上Docker整个的安全问题都涉及到了。

然后Docker在2019年底进行了重组:我们卖掉了企业级Kubernetes的业务,卖给Mirantis,接着转向于开发者的需求、以及推动Docker被采用——Docker能够得到应用还是因为开发者。在那时我是Docker最资深的工程师,所以当时就开始向这种CTO的角色发展。在年底的时候,我花了很多时间和我们的投资人交流,尤其是Benchmark的Peter Fenton,谈论各种公司业务发展的方向和我们需要做的事情。这就是我从过去到今年年初成为CTO的历程。

Docker实现全球分布式团队的历程

Kevin: 你的经历很有意思。那我们从你最初进入Docker说起吧,原先不知道你是通过收购进入Docker的。这是2015年左右的事情,对吧?

Justin: 是的,没错。

Kevin: 所以当时Docker已经是一家美国公司了,但是还有一些欧洲的基因,对吗?比如它的创始人是法国人等等,而你一直是在英国。作为一个被收购者,最初进入到远程工作或者全球分布式的工程团队中,是怎样的一种体验?我很想多听听你的这段经历。

Justin: 我觉得这真的很有趣,如果你顺着那条线往下走,就会发现它影响了很多Docker未来在国际发展上的变化。

我们当时有个优势,就是拥有一支较大的团队。当时我们大概有10个人,所以这不是那种两个人小公司的收购,这给了我们更多话语权。我们从一开始就认定,不希望有人搬到旧金山去。在之前几乎所有被收购的公司里,除了一个例外, 每个都搬到旧金山。

所以我们当时算是有一个足够大的核心,成为了Docker真正走向国际化的开始。这件事也挺有趣的,因为我记得当时他们真的不确定未来会怎么发展。而且我们其实在合同里写着,团队应该一直保持有起码一个人在旧金山的状态,算是一种对冲吧,保证会在美国,但最后结果并不是这样的。新冠疫情之前,我其实会在美国呆上很多时间,可能比其他人呆的时间更长。我曾经每隔两三个月就会去美国一趟,一去就是几个星期。

当时Docker主要还是在旧金山,但这些年逐渐地变了。你提到Docker最初是一家法国公司,所以在我们被收购后没多久就在巴黎设立了一个办公室,可能在2015年底,或者2016年初。我们一直觉得在法国雇人很容易,因为Docker经常被视作是一个法国人创业成功的典范,名声很好,这一点很有意思。我们巴黎办公室里很多人最初都是在旧金山的,以前在旧金山的周五下午,你能听到很多人说法语,但现在大部分法国人都在巴黎办公室了。这是我们真正成为一家全球分布式公司的开始。

最佳管理实践:以时区协调

Kevin: 明白了,那现在就来谈谈这个问题吧。听起来你或者你之前的公司,还有那次收购,几乎是Docker演变成个全球分布式公司的原因之一。而现在对于新的创业公司来说,全球分布的形式越来越流行,越来越普遍了,甚至很时髦。就是在某个地方注册一个公司,但是全球进行招聘。我们都非常熟悉的GitLab就是这种做法的典型例子。

不知道你升职之后的工程师管理实践是如何发展的呢?你是如何管理这些来自不同时区的工程师?毕竟他们可能说着不同的语言,但又是从同一个代码库或用同一个计算机语言来工作。到目前为止,你收集到那些最佳实践?

Justin: 嗯,管理实践在这段时间里发展了很多。我想我们有点不得不学着去做,虽然刚开始并不是很擅长。另外新冠疫情出现前后也有很大的变化,在新冠之前,我们才刚刚成为一个远程工作的公司。

有些人在Docker一直是远程工作的,但那是少数,后来我们才开始有更多的远程工作。我们有旧金山办公室和帕洛阿托办公室,所以就让大家搬到任意一个更方便的地方,或者干脆在家里工作。更多的人甚至在疫情开始之前就已经搬走了,而且我们开始在有办公室地点以外的地方雇人。

但当新冠发生时,我们与Mirantis的拆分完成后,就把旧金山的办公室费掉了,因为我们在缩减规模。然后我们就跟员工们谈起了办公室和远程工作的事,渐渐地人们也开始习惯在家工作了。我们现在的情况是慢慢把最后几个办公室地点费掉,完全实现远程办公。所以其实有两个过渡,一个是形成分布式的结构,另一个是实现完全远程办公。

分布式的结构在文化上感觉有点不同,因为我们当时仍然有办公室,仍然有在当地进行管理的集群的员工们。所以我们会有工程管理在巴黎,工程管理在剑桥,工程管理在旧金山,而且会有这种一起紧密工作的团队。

我们有段时间的团队是非常割裂的,全是跨时区工作的人,而不是大多在同一时区或办公室的人,这是非常奇怪的。所以我们现在就倾向于按照时区协调一起工作,最好大家也是在同一个地方的办公室。我认为我们现在甚至更注重把时区而不是地理位置作为单位了,但时区是很难的。法国到西海岸比英国到西海岸更糟糕——又差了一个小时。而且人们很难花足够的时间在一起,很难在一起真正地、很好地工作。当然这行得通,像开源项目就经常是这样做,但有效的协调在一个代码库里或一个产品上工作是很难得。

所以,我们现在加倍努力去组织这种同一时区的小团队。我们正在转型发展那些非常自成一体的团队,最好是地理位置上本地化的团队,可能是五个工程师左右,一个产品经理和工程经理,还有UX。这些小团队最好是在一个时区,我们也刻意的让这些团队为特定的一些客户问题去服务。

Kevin: 明白了。我想这确实是一个还在被开拓的领域,我觉得没有人真的摸索出了所有具体该怎么做的事情,能够做到 "这是你该如何去管理100或200个分散在全球各地的工程师的方法",很多公司都还是在摸索阶段。听起来你现在的做法是以时区为单位,就像你说的那样。所以,如果我理解正确的话,是不是你们会有意地把几个需要紧密工作的工程师集中起来,在同一个时区,这样他们就可以以更同步的方式协调?

Justin: 是的,是的,绝对的。目前为止我们在能够在哪些国家招聘上有些限制,因为受到了公司所在地的限制。我们接下去会转向限制性较小的招聘方式,启用一家全球招聘公司,就可以在任何地方招聘了,但是在这个方面我们还是有点卡住的。

我们现在基本在美国和加拿大各地都有人,也在英国和法国,这两个地方相差一个小时左右,所以差不多是同一个时区。我想我们现在对于扩张这几个地区以外的时区还是持比较谨慎的态度,等以后规模更大了再说。我们现在已经把Docker重组到70人,所以保持这种小规模的、紧密的联系是很重要的。我想我们离进入亚洲时区可能还有一段时间,但是会在现有的时区里扩大我们雇人的国家范围,已经包括了世界上相当大的一块区域。

最佳团队规模与结构;同步与非同步工作之间的平衡

Kevin: 那现在我们来聊聊很具体,很战术性的东西,根据你到目前为止的经验,利用时区组织我所说的工程队,小型工程团队,发现多少名工程师是最适合同步工作模式的,是比较理想的规模?

Justin: 大概五名工程师,加上工程经理、产品经理和UX。我们以前也有过更大和更小的团队,但这似乎是我们目前试图瞄准的最佳状态。我们想把重点放在给团队所有需要的资源上,我们之前有设计一种所谓的“中心职能”的模式,但对“中心职能”模式遇到了瓶颈,我们希望真正让每个团队都有自己的资源。

Kevin: 明白了,有道理。那你现在对这种“同步工作”和“非同步工作”间的平衡有什么看法?这些术语在关于工程实践的讨论中经常被用,尤其是在开源公司。对于那些不太熟悉这些术语的听众来说,如果你做过一些编程工作,就会知道。

“非同步”指的就是有人在某个地方做了某件事,然后可以等着别人在另一个地方接过来,而且可以不需要真正的同步协调。而“同步工作”则相反而已,你确实在同一时间讨论或者做某些事情,来做出成果。你对这两种方法之间的平衡有什么想法吗?怎么样才在工程实践发展方面对公司的其他部门比较好?

Justin: 嗯,这很难,因为有很多不同种类和形式的沟通。传统的开源模式主要是通过issues和pull requests进行沟通,是非常不同步的。也许会开一些会来确定大方向,但并不频繁。这往往和产品主导的东西,双人编程和sprint以及站立会议那种紧密沟通的协调方式有很大的不同。所以我觉得有不同的沟通和模式,它们在不同阶段对不同的事情有不同的作用。

我们是一家有点特别的公司,有很多不同类型的工作和软件。我们有开源,在社区里,更适合“非同步”的模式。还有SaaS服务,有人要on call随时解决问题,这又是一种不同的沟通方式。

我们作为一家公司,在做的事情种类上有点不寻常,所以变得很有趣,但也让我们的沟通结构有点不同。我想说的是,让大家更好地把事情写下来是非常有价值的,无论你在做什么,写作在某种意义上是“非同步”的。但这不一定是你用什么形式的非同步沟通,而是你在沟通时做得怎么样。我很喜欢亚马逊式的在开会前把事情写下来的方法,我们也因此一直在朝着这种文化发展。我们有一群前亚马逊的人,他们把写作文化介绍给了我们,真的很有价值。

随着时间的推移,你可以从ppt文化转变为写作文化。而且我觉得完全远程工作的形式也改变了一些东西,因为很多人用白板和同步会议的文化,其实是很难在远程情况下做到的,而写作其实是一种在不同规模和大小的沟通中都能很好地发挥作用的文化。它也能帮助大家上手,所以有很多优势。

Kevin: 绝对的,是的。当然,作为一个写博客的人,我很赞同写作的优势。我确实认为它可能还是最可扩展的沟通形式之一,既可以非常迅速、非常容易地传播出去,又可以让很多人在不同的时间点上达成共识。就像你说的,可能是最好的,“非同步”的沟通方式之一。

Justin: 关于写作,还有一点很有意思,是关于语言的。就是说不同语言的人一般来说往往更喜欢读而不是听,因为他们可以按照自己的节奏来读,但是人们确实觉得用自己的非母语写作比较困难。所以围绕着这一点有一些细微的差别,很有趣。

Kevin: 你提到对于非英语为母语的人来说,阅读比较好,这一点很有意思。因为可以慢慢来,不需要像我们现在这样听别人说话,需要实时吸收,这其实更难。你对于在公司内部让写作成为一种更简单的表达工具,帮助非母语者更好地写作,有什么建议或想法吗?

Justin: 我认为很多都是练习,先用母语把事情写下来也往往能够帮到大家。实际上,我和亚马逊的人就这个问题进行了一次有趣的对话,亚马逊的写作政策并没有任何“必须用英文”的类似规定——你可以用任何语言写,这点很有趣,但也会产生出一些问题。

我在开源项目中遇到的一件事就是,有时它们会被语言所分割。我记得我是OpenResty的早期用户,它是个底层的、较大的插件,与Ngnix结合在一起用。因为它起源于中国,当时我要读项目的listserv都要用谷歌翻译翻成英文来看。这点很有意思。现在它都逐渐过渡到更多英文,那个作者也搬到美国了,但当时有社区是以语言来划分的。而且我们现在还能看到一些云原生的项目,因为时区和语言的不同,还有一点分裂。这些东西就是很难克服。

工程团队与其他部门的合作关系

Kevin: 在我们开始问答环节之前,我想继续谈几个话题。我知道我们在Zoom的问答栏里已经有几个问题了。我想跟大家谈的一件事是,Docker是家硬核技术公司。产品的技术性很强,但工程部门并不能活在自己的世界里的,对吧?它必须与产品团队、设计团队合作,也必须与销售,甚至与市场营销团队打交道。在你的工程团队和公司的这些其他部门之间的合作模式方面,尤其是在这个分布式或多时区的世界里,你有什么最佳实践可以与我们的听众分享吗?

Justin: 嗯,我认为这很有趣。Docker已经发生了很大的变化,这些实践也发生了很大的变化,因为我们从一个企业产品公司变成了以开发者为中心。

我认为工程团队与销售、市场和产品的合作是非常不同的。在市场方面,我们已经有了一个非常棒的社区,这个社区是在Docker和我们的产品上很早就建立起来的。而市场营销一直围绕着发展这个社区在做,并举办了像DockerCon这样的活动,这些活动是非常棒的。今年的DockerCon上周开放注册了,仅头几天我们就有了2万人注册,去年总共有8万人参加DockerCon。这些活动才是人们真正看重的,我们的很多营销都是为了培养围绕产品建立的这些社区。

工程师们都很喜欢参与其中,大家很喜欢和工程师们交流,因为他们是打造这些他们喜欢的工具的人,所以社区和营销之间的互动是很自然的。

销售在某种程度上变化比较大。我们在做企业级Kubernetes和runtime业务的时候,有一支完整的大型企业级销售队伍,那时候我做的非常多的事情是去各大银行开会,谈安全之类的事情,以及推出相对缓慢的企业级产品功能,来支持弥补企业销售需要的不足。缓慢往往使工程师觉得和销售过程很疏远,让他们参与也比较困难。而且工程师不喜欢企业销售,因为他们自己很不喜欢听销售“卖东西”。

现在就很不同,我们有一个很小的销售团队,主要是推动自下而上的SaaS模式。我们重新探索了销售对于一个自下而上的、以开发者为主的公司来说是什么样的,所以现在我们和销售的关系已经完全不同了。

以前Docker有一个巨大的脱节的地方,就是最草根的对Docker的采用者都是很早转向云的人,但我们以前是想把产品卖给那些想做on-prem,很晚才转向云的人,这说到底是一种不匹配。我觉得我们现在的状况很好,我们就是工程师想把产品卖给像自己这样的人,我们在为同行打造产品。开发者工具公司真的有点神奇的特质,就是你在为自己造东西,可以说这些人和我一样。他们不一定和我完全一样——他们在这个旅途中可能还走得不太远——但我们和他们有更多的共鸣,这让打造产品变得更容易了。

我认为从产品的角度来看,这也有帮助。我觉得的确,我们的产品是技术性很深的。而Docker最初也是把一些技术性很强的、晦涩难懂的东西——Linux的namespace和容器——变成大家都能用的东西。但是在我在Docker的五年时间里,市场和Docker的用途发生了很大的变化。我记得可能是在第一年前左右,才意识到现在大家已经不懂如何使用SSH了。

我们有1000多万人在使用Docker,而且是各种经验和技术水平的开发者。他们中的大多数人都不懂Docker内部的工作原理是怎样的,这对他们来说就像魔术一样,这与五年前为了解决Linux namespace的问题而有诉求的人截然不同。

所以我认为做产品的人很难处理这些事情,因为它是深层次的技术问题。于是我作为CTO花很多时间和产品经理交流,帮助他们理解技术里什么是可能做到的。我会倾听工程师与他们交流的时候,帮助产品经理理解什么是可能的,帮助他们解读一些用户要求和思考各种可能性。

但也有产品经理在做这方面的工作,他们是在专注于开发者产品的。命令行(command line)的用户体验还是一个小众领域,但也有人对它着迷。因为这是一个非常有趣的话题,是对现代世界的理解。开发者现在做的事情,其他人将来也会做。所以这个对在产品领域工作的人来说是个很有吸引力的选择。对了,我们正在招产品经理,如果有人感兴趣的话!

Kevin: 千万不要错过各种招聘的机会,对吧?我们都是做tech的,大家都在招人。不过是的,我觉得你说的没错。Docker当年可能做得几乎太好,把内核空间和Linux层面的东西这些细节都遮掩掉了,让人们觉得我不需要知道这些,我只要会用Docker就好了,对吧?

Justin: 但我觉得这才是正确的态度。我感觉Linux不一定是你必须要用的东西,有时候Linux桌面体验是基于Sun Workstation的体验,那时候挺好的。我还记得自己第一次坐在Sun Workstation面前的时候,当时就想,"哇,这太神奇了",但实际上这并不一定是现在人们想要用Linux的方式。我的意思是,人们其实是想把Linux作为一个应用程序的部署平台来用,Docker就是这种API,让你可以不需要使用Linux就能做到这一点。而人们对它的看法是,"它是一个编程API,所以不必成为你的生活的一部分",你仍然可以使用Mac或Windows系统。开发者的生活在IDE里,pull request里,代码里。操作系统不应该是那么显眼、占空间的东西。

Justin希望每个创业者能避免的一个错误

Kevin: 在进入问答环节之前,我想用一个比较宽泛的问题来总结。因为在Docker之前,你已经经历了很多创业公司,现在你在Docker,是CTO。我很想听听,你希望我们这个领域所有的新创业者、founders在早期开始发展和扩大工程团队的时候能够避免什么错误。

Justin: 我认为,有一天你会雇到一个不适合的人,在团队中无法有效工作。Donnie Berkholz,我们的产品总监,有一个很棒的演讲,他很多年前在Redmonk举办的活动上讲的关于assholes怎么毁掉你的开源项目。这点也非常适用于公司的情况,指的是那些消极的、对你的目标有破坏性的人。尽早意识到他是谁,并解决这个问题真的很重要。

如果你幸运的话,它会很早发生,你会更早地吸取这个教训,但它最终会在某个时候发生。有些人就是不适合在你的创业公司现在的阶段里工作,你就不应该和他们合作,而你也需要尽快建立企业文化。

我仍然喜欢在Docker工作的原因之一,就是这里的文化真的很好。大家都很谦虚,很懂得如何与人合作。而且我们已经感受到这种文化很久了,从很早的时候就已经开始了。

作为一个创始人,你给公司带来的一个东西就是你对大家如何做人,如何相处的期望,并通过探讨来保持企业文化和态度。八年来,我们保持下来了非常多的文化,也留住了不少老员工,当然不是所有的人都留下了,但我们企业文化的持续,比当初创造这个文化的个人延续的更久。

如果您喜欢所读的内容,请用email订阅加入“互联”。要想读以前的文章,请查阅《互联档案》。每周两次,新的文章将会直接送达您的邮箱。请在TwitterLinkedIn、Clubhouse(@kevinsxu)上给个follow,和我交流互动!