Hello, everyone! Thank you for the fantastic response to the last session of the Turing Distinguished Leader Series. In this episode, we conversed with Lance Willett, Chief Product and Technology Officer of Tumblr. Lance is a tech leader motivated to build and lead strong and productive teams, drive strategy, and produce business results — all while understanding diverse consumer behaviors. Organizational transformation, cross-group collaboration, product strategy, and operational excellence are his key areas of focus.
We are very excited to host this episode of the Turing Distinguished Leader Series. Today, we have the Chief Product and Technology Officer of Tumblr with us, Lance Willett. Lance, why don’t you introduce yourself to our readers?
Thank you for having me. I am a designer and a developer. I started building websites, and that led me to WordPress. This was the starting point of my tech career. But going from an environment where I was working on one or two client sites at a time to launching a theme that anyone in the world could download. That was a pretty big step change for me. This change helped me sharpen my skills. Rather than solving one problem, I’m now solving big-picture problems.
I got into Automattic, the owner of WordPress.com. For those that aren’t familiar, it’s the for-profit side of the equation.
So there’s wordpress.org, which is a downloadable, free and open-source software. And we also have the SAS version, a hosted version of WordPress, the product I have been working on since then. And we share a co-founder, Matt Mullenweg. He is a co-founder of WordPress. And since then, we’ve grown many different products WooCommerce for E-commerce and stores, and my other current project, Tumblr.
Tumblr is more of a social media blogging platform. But there’s a thread that is open-source software; web publishing at scale. And I think of it as a tool for anyone from any background, country, language, gender, or financial background to be able to get their story out.
So it could be a website, it could be a store to sell things, or it could be more for fun. I really enjoy working on all of that.
That is fantastic. I understand you currently live in Tucson, and you’re leading an incredible tech team globally. How did you make that happen? Something like that would have been tough to do a few years ago. So how did you make it happen?
This is a great topic, especially now that we’ve been forced to do this right with a pandemic. Before 2020, we would go out and evangelize. Matt has a whole podcast and blog around this called distributed.blog.
And we were making a very pointed effort to talk to folks of any tech company to say: “Hey, this is the right way to work, and we can get into the details.”
For me, the roots of it are in open-source software. And so this is the story of WordPress and how we started Automattic right before I joined. I was probably employee number 45 or 50. And now the entire organization is about almost 2000 people. So it’s a large organization now.
And the roots in the open-source movement were the tool. It wasn’t necessarily about who you were or what you looked like. We often knew each other by our IRC handle, GitHub, or whatever tool we used to collaborate and contribute. I would know people’s usernames before I even knew their real names or where they lived. And so, my introduction to this world was downloading tools that I needed.
So at one point, I needed a gallery, for example, WordPress or a free PHP gallery, because I was on a lean budget.
I found the open-source tool, and I downloaded it, but pretty soon, I also wanted to contribute to it.
I would submit my change or my request and then poke around a little bit. So then you develop a relationship, and it’s often over distance. You don’t necessarily meet up unless you know who someone is and you’re in the same physical location.
I mentioned that because this is how our company was formed. We didn’t necessarily think: “Oh, I’ll move to San Francisco, or I’ll move to New York.”
When we joined as employees, we lived where we already were. And so from day one, we built Automattic to mimic that open-source [setup] with intelligent, dedicated people from anywhere who care about the same problem or the same solution, but not necessarily people who had all the same background. It was more about what they were interested in doing.
So that’s how we’ve been able to establish the company. We emphasized people’s contributions and what skills they could bring to the team rather than focusing on Bay Area or Ivy League.
Sounds great! Any advice you would have for companies thinking about going remote?
Yes, it’s imperative to talk about this. In our case, we relied on travel when we were able to get together. So we weren’t 100% isolated. We had these periods when we would come together and then take that back to our home office.
One misconception to get out of the way is that it’s [remote work] 100% one person in a private room. It’s not really like that. We shifted from needing to be in a central day-to-day [office space], but we would still get together.
I would recommend companies [who are exploring to shift between those two modes] to think about their key habits. They should go back to the first principles of communication and documentation.
How do you share things? Do you rely on an all-hands meeting in the lunchroom on a Friday? Or a wiki? In our case, we have a blogging tool where someone could write a memo and everyone else could see it.
Talking about cross-cultural [setups], if you have teams whose native language isn’t English, all of this comes into play for communicating clearly. [It’s always better] if they have something they can read at their own pace versus having to understand on the video chat and respond very quickly. It’s all about inclusivity.
At Automattic, we have an all-hands; we call it a town hall, where the CEO talks to the entire company. We do captions, but we also do a full transcript.
And it benefits you not just at that moment but also later. So it doesn’t just help someone who wasn’t present, but it benefits the ‘future us’ when we need to remember a decision or when we need to refresh our memory.
So again, [it’s about] going back to the first principles around how you communicate things. How much are you writing down?
There are things like hiring and onboarding [that you need to consider.] When someone switches from an individual track to a manager track, how do you enable them in this environment? And then, how do you figure out key relationships like partnerships and investors? How do you solve all the business processes?
And I think that there are creative ways to do it. So very recently, GitLab went public, and their IPO is a monumental thing to talk about because they’re also a fully-distributed company.
Absolutely! I would love to dig a little bit deeper into hiring and onboarding. How are hiring and onboarding different in a remote-first environment?
So I have a different answer now than pre-pandemic. Pre pandemic, when travel was allowed, we frequently tried to get a new person to meet other people quickly.
Now, because we don’t have that right now, we have to be creative.
You can’t just take a playbook from Google or GitLab or even from Automattic and just directly apply. You have to tailor it to your situation.
The other thing around hiring and onboarding is [adding] a little bit of structure. So in our case, we have different mechanisms that weave together an onboarding experience for the new employee. This includes going back to documentation. We have a field guide, which is basically like a boot camp. We also have a habit where every new employee goes through two weeks of customer support.
So on Tumblr, before someone can start, they have to do this. Even a C suite executive has to do this. And I believe that has a good impact later because employees understand their customer’s pain points and know where they can look for answers in the organization.
After that, we structure things into the team lead or manager, the HR team, mentors, and buddies. So we have this combination of a team approach where the team lead might have some onboarding [activities]. The HR team may run them through the perks and the learning and development opportunities available. And then we have a mentor or buddy, and that’s usually someone not on their team. And so the mentor might be someone like me who’s been with the company longer and can then provide some direct guidance. The buddy is a little bit different. The buddy is usually someone who’s in a similar situation.
So just to give an example, say six people join the same day, we’re going to put them into a culture cohort. And they get to go through some of those exercises together. Then there’ll be someone like me checking in once a week over the first six weeks to see if they have any questions.
The other important thing is making the person feel welcome. So even if you can’t shake their hand or give them a hug or high five, maybe send a care package that they get in the mail.
That was great. Have you seen any difference in managing a globally distributed team versus a distributed team in the same city, country, or culture?
Many of the issues are the same, right? We’re dealing with human beings, software, and bugs. So let’s talk about what the differences might be.
One is that when you have a kickoff, it’s usually really nice to do that together. So I think that’s harder to do when you’re not on-site. So one of the tactics or techniques we take on this is to share the insights coming out of those interactions very quickly and openly.
So [assuming] one person was on-site, in London to meet the client. [We say:] “Well, can you please share a quick report that helps other people get up to speed quickly?”
For us [it’s about] a little bit of over-communication. For Automattic, communication is oxygen.
And what we mean by that is, the more that we communicate, the healthier the organism. And so part of that oxygen is anyone outside the organization, right from customer support salespeople, maybe even the CEO, who see things that the rest of us don’t see. They have a habit of sharing things very frequently and transparently.
And so the habit of writing that down and sharing [things] openly is really important for this distributed setup because then it’s available to you when you choose to consume it.
And another thing I want to mention is the intentionality around time zones and cultural backgrounds. You might want to design a charter or something like an operating system that says: “Here are some of the agreements that we have. When we have a conflict, we’re going to use these tools. When we have a goal-setting exercise, here’s how we do that. When we’re doing yearly planning, here’s how we do that.”
And the principle for me is that the more transparent, accessible, and editable those expectations are, the easier it is for you, as someone who’s not physically there, to know what’s needed from you and when to do it.
That sounds fantastic. What about personal bonds? How do you build bonds in a distributed remote setting?
I love this topic because I think it’s underappreciated.
So I can share some tips and techniques that have worked well for me.
So one thing that I do right away is I start a small file as the manager. And as I’m talking to them, I just take notes. It seems simple. But what’s interesting about it is that it compounds, and I get a complete picture of the person over time.
And if I’m going into a one-on-one, I can have that in front of me and say: “Oh yeah, they like coffee. We should talk about the latest decaf trends.” And what happens there is you rather than just having a purely transactional communication; you start to develop these other relationships, which to me are very important.
And it also impacts our business because you might find out something about someone on the team that has a direct value to the thing you’re approaching. For example, you might realize that they have a cousin or a parent in the industry you’re targeting. And so, if you don’t take time to explore the person, you lose out on that opportunity.
We also do DJ [activities], where someone plays some music, and people can put it on, and they might have their video on, and they’re listening and interacting and maybe suggesting songs.
But the point is that you want to have a variety of things, right? Some people hate having the video on one more hour at the end of their day. They’re not going to come to that. They might rather just play a video game. But at the end of the day, I think it’s about making those personal connections in any way that you can. And then reminding people that if you’re the manager, you care about them and pay attention to those details.
Great! So you’re leading a lot of different functions. You’re leading product management, data science, design, engineering. Do you see similar principles that can be applied to all the different functions? For example, I’m interested in engineering versus non-engineering for hiring and management.
Do you deploy any different techniques, or do you think they usually cut across pretty well for all types of things?
There are some differences around technical topics [regarding] how you might manage a technical team, especially if the people on the team are highly focused on a particular tool or environment ecosystem, where you have to almost be like an evangelist.
Or you have to write engaging blog posts for the external world for that particular sector. That’s different, right? It’s a different mindset.
But one of the exciting things we do around, specifically for engineering management, is we talk about the developer experience.
We ask things like: “So how do you, as an individual engineer, approach your work? Do you have the right tools? Do you have the right learning opportunities? Do you have mentors?”
Sometimes you just want to talk to someone who has done it before. And so we try to set up those relationships very consciously, and they take different forms. But one form that we have really developed over the years is DevX or Developer Experience.
Now, it’s a program the size of our company. It’s a whole separate team, a whole separate part of the organization, and they get involved from hiring, onboarding, and ongoing work.
And one example of this might be removing friction from deploying code. So [it’s about] interviewing people about the continuous integration, test environment, or even the IDE and tools on their machine. [It’s about] going down to a very granular level.
And just doing a survey or chats or interviews and asking: “What are the pain points for you across the organization?” And then saying: “Okay, we need to improve there.”
So I mentioned subversion earlier. Well, we’ve been adopting Git for many years. And one of the pain points for new developers, as they join, is that they grew up only on Git.
They don’t know about mercurial or subversion or CVS and all the other things we had before. And so the developer experience for those new employees is different than someone who’s using the tools for ten years.
So that’s something that that team pays attention to. Team members may relay that back to someone like me to say: “We’ve talked to 40 percent of Tumblr engineers, and they really don’t like this thing.” And that way, we can make changes.
This tactic pays off when we want to switch people between teams. So that’s where I think the broader view and consistency come into play for engineering management specifically.
How do you broadly think about growing people or upskilling people in a remote environment?
So it goes back to what I said about paying attention to their personal details. In the same way, you pay attention to their career plan, career ambition, or skills they want to learn.
At Tumblr, we design a PPM or a Personal Professional Mission. It’s a structured document that talks about what would be really exciting [for an employee] in five years and looks for milestones, challenges, and opportunities on the job.
We also have Hack Weeks during the year when people can come out of their lane and do other things.
And by the way, that’s one way we discover new leaders and managers. We have them run a team during the tech week. And I always talk to them [the employees] afterward and ask: “How did that go?” And people sometimes say: “Wow, that was like herding cats. I never want to do that again. Please do not assign that to me.” Other people say: “Wow, I like the responsibility, and I enjoyed the ability to have an opinion be decisive.”
So we structure the career conversation with HR, team lead, and a mentor. We also have coaching programs. And one thing that’s unique about Automattic’s coaching program is it’s open to all employees. So even though it’s executive coaching, it’s available to everyone.
One thing I did early in my career that was very effective was in that coaching environment; I learned how to be a self-coach. I learned how to take someone’s advice and expand on it in my way. We also encourage coaching and team switching.
I don’t think it depends on the remote versus co-located setup other than the fact that you have to be a little bit more intentional and structured when it’s the former because you don’t naturally run into each other. So you might invite each other into a one-on-one. In our case, we have this Slack integration called Donut. It helps build connections organically throughout the company. It replicates a little bit of that [in-office] serendipity.
What general tools have you found useful to keep the team successful in a remote-first environment? And then secondly, what do you think about synchronous versus asynchronous modes of communication?
On the tool side, some of them are pretty simple. For example, we use Google products like Google Calendar, Google Docs. One habit here is if we’re in a meeting and working on something together, we would have a Google Doc shared for everyone. And [the team] is commenting and co-creating the document through the meeting. And by using that tool for its purpose, which is to gather information, gather comments, remove errors, condense down to the meaning, you can use it to its best effect.
We also use Mural. We have a habit that we call Future Specter, where we describe an ideal state in the future, and we work our way back. You have each person putting post-it notes on the wall if it’s physical, and Mural makes it really easy.
We also use P2. What P2 does for us is each team or project has a hub where they can post goals and plans. And you can also mention people by name in conversations, but the reason we’re using P2 rather than Slack is that it’s effective in a couple of ways.
One: We own the content as P2 belongs to its WordPress, and so it’s open. So we can download it, and it’s not tied to some other company.
Two: It’s written communication rather than only verbal. So you can capture it and search it and tag it and archive it.
Three: It really encourages this asynchronous habit.
So let’s think of synchronous versus asynchronous. Synchronous is about meetings, asynchronous defaults to writing, where you can consume [information] on your own schedule or own format.
There’s real-time versus deep work. And you mentioned that sometimes we need these chunks of time to get our mind focused on something. So I think especially on creative coding or writing or design it’s very, very important.
There’s a famous essay by Paul Graham from Y Combinator where he talks about ‘Maker versus Manager.’ It changed my life when I read that because it talked about how managers have 15-minute slots on their calendars all day long because they’re going into many different contexts.
And a maker just has one slot of four hours. Everything is off, and they’re just in the zone, doing their thing. So in an asynchronous environment, we want much more of those deep chunks of time, and we want fewer of those interrupted times because it’s just hard to get things done that way.
There’s another key point here, which is burnout. In my experience, asynchronous creates a much more calm and deliberate approach versus the need to be always on 24/7 answering your phone.
Lastly, something very important about this written versus meetings [setup] is that if you aren’t extroverted or willing to be up at 1:00 AM, [asynchronous communication] is more inclusive because it levels the playing field when it comes to access to that information.
And I think GitLab is one of the most transparent organizations in this case. They recorded their meetings and posted them. They had everything documented on their website. That’s very admirable. And I think it’s hard to do, but it’s great. But the principle behind it is if you need access to information to get your job done. You shouldn’t have to go through a hierarchical chain or be asked for a meeting [for the same.] You should be able to just literally search for it.
So I think this is an important topic. I also think that leaders need to role model this. We can’t just tell people: “Hey, be flexible.” We have to set up the structures and the culture and the deliberate approach that we do in our work as well.
I have this joke with my teammates. If I ping them and it’s [the message] not urgent, and they say sorry because they’re replying an hour later, I make them put $1 into my Sorry Jar. You don’t have to apologize when it’s asynchronous. I expect you to answer when you are next available. And if I want to override that, I will tell you that this is urgent or SOS or 911. If I don’t say that, the reply could come tomorrow, and that’s fine.
And what happens here is you get this sense of thoughtfulness and really read what someone is saying. One of the things I experienced on the frantic, real-time side is I’m so eager to get to the answer that I’m not even reading what the person is saying; I’m already commenting.
That’s great! What have been some of the pleasant surprises that you have encountered as the perks of working remotely?
One thing is that it’s not just ‘work from home.’ I see this a lot on Twitter and other social media where people struggled because they didn’t have a good home office setup, especially before the pandemic.
And so one of the things that surprised me is the flexibility to create my environment and [its impact] on productivity. I can work in an environment of my choice, which could be the couch or the backyard. We have teammates who are nomads, who go month to month different places. People have RVs and just camp out and go places.
Another thing that’s been amazing is these companies attract people who are open and curious about other cultures and other ways of working, which I think is avant-garde for some people even today. And so, we’re constantly evolving. I believe we are at the forefront of the future of work. So, I don’t know what’s next, but I’m excited to see what the future holds.
This was great. Thank you for sharing these insights with us, Lance.
Please watch the complete interview here:
The post Turing Distinguished Leader Series: Lance Willett, Chief Product and Technology Officer, Tumblr appeared first on ReadWrite.