Scott Berkun on His Year Without Pants

Back in 2010, Scott Berkun had a ‘wonderful and a horrible’ idea. He thought he’d go get a job as project leader at WordPress. This is his story from BoS USA 2013…
Why was it a horrible idea? Scott had quit his job as a project manager at Microsoft nearly a decade before and spent his time as a writer. He wasn’t even certain that his project management skills still worked.

Why was it a wonderful idea? WordPress uses some of the most innovative working practises on the planet to manage a distributed team. Scott couldn’t resist the chance to experience this first hand and learn something about the future of work. And he shared what he learned – about tools and about what great management should do – with the BoS audience.

Find Scott’s talk video, transcript, and more from Scott below.

Find out more about BoS

Get details about our next conference, subscribe to our newsletter, and watch more of the great BoS Talks you hear so much about.

Video

Transcript

Scott Berkun: Good morning.

Audience: Good morning.

Scott Berkun: How you doing? I have a series of tales and stories for you of unusual work practices. Are you ready? OK. So, I’ve had two careers so far in my life. My first career was managing teams of developers. I worked at Microsoft. How many of you have heard of a company called Microsoft?

A little company. I worked in ’91 through ‘5. I was a project manager for there for a while, and I quit my job in software, in about 2003, to write books. And I’ve done that for about a decade. I’ve written five books, and I feel very fortunate in this day and age to be someone who’s basically a professional expert. I get to write books and talk about ideas in those books, and I’ve been really happy that . . . to live this sort of life.

But one fear I’ve had throughout this second career is the risks of being an expert. We have expert experts, people who are on television, and people who give lectures, and people who consult, who give advice to other people on things that they no longer do themselves. And there’s certains risks about that. You can certainly learn things from someone who hasn’t actually written software or managed a team or started a company in a while, but there has to be some limit on, or some expiration date, on that expertise.

So, as I’ve had this career for about a decade, I knew that at some point I should probably challenge myself and find out how much of what I actually think I know do I really know. And how much of the advice that I’ve been giving to people for this decade would I actually practice, if I had to go and manage a real team, at a real company, on a specific project, and to give up the abstraction that is consulting and book writing, where we can theorize and pick the examples that fit our theories, instead of have to do the . . . the daily work of actually trying to build something. I didn’t know that would happen, but in the back of my mind, I was looking for it.

Matt Mullenweg is the founder of WordPress.

• How many of you are familiar with WordPress?
• How many of you like WordPress?
• How many of you hate WordPress?

OK, good to know. I won’t be looking at you guys very often through this talk.

Matt Mullenweg read some of my books, and we exchanged some mail, so we knew each other, and he started a company called WordPress.com in about 2005, and as that company got bigger, he felt that it could no longer sustain having everyone work directly for him, which is commonly what goes on at many companies. Everyone works for the founder.

He had about fifty or sixty people in the company, and he realized that he needed to do something to solve some problems he had noticed, and he thought he should divide the company up into teams, and he he asked me if I would like to be one of the leads for those teams. For the first time in the company history, they would have teams, which meant they’d have leaders, and would I wanna be one. And I thought that this was a wonderful and a horrible idea, at the same time. It was wonderful, because this notion I had in the back of my mind, I could finally satisfy it, but notions in the back of your mind are perfect. You can polish them and make them really shiny. Oh, it would be great someday. I’m such a great guy, ’cause someday I’ll go and do this. To put that into the present was actually terrifying.

You guys may know that writers are very twisted people. Writers are twisted people. We will do just about anything, if we think it can make for a good book. So, I thought that, even if the worst happened, which was possible, that I’d get hired, it wouldn’t work out, I didn’t really know very much anymore, and I got fired in the first month or I quit, or my team mutinied, at least I could possibly write a book about it. So, before I got hired, I asked Matt, I said, “Hey, is it OK if I write a book about it? That’d be my condition to being hired,” and he said, “Yes.”

So, that’s the story that I’m going to tell you is about this year working for a company that has some very unusual practices. Some of these practices will be shocking to you, and you won’t believe that they are true, and I didn’t believe them, either. And some of what I’m going to talk about for the next . . . probably, half hour, I’m going to save a lot of time for Q and A. Having talked about this book, it generates a lot of questions, so I’m going to save a lot of time for Q and A.

Before I talk about these unusual practices, there are a couple of facts you need to know about WordPress. So, WordPress, the open source project, was started in 2003. As I mentioned just a second ago, it was doing well enough there were certain things that Matt Mullenweg wanted to protect and to enable for WordPress. We created a company called Automatic, which runs WordPress.com the service. He created [inaudible] that in 2005. WordPress, all inclusive, powers about twenty percent of the entire internet. That’s a staggering number. The reason why we don’t hear that number often is because WordPress has it’s roots. It’s an open source project. They don’t do PR; they don’t do marketing. You will never see a WordPress Superbowl ad at half-time. Like, that will never happen. WordPress.com, where I worked, this is the free hosting, basically, for WordPress, it gets about four billion pages a month. A few weeks ago, it passed Yahoo to be the number 8th most trafficked website in the U.S. Now, I tell you these things, not to brag about WordPress. I don’t work there anymore. I worked there for about eighteen months, from 2010 through the late 2012.

The book’s called A Year Without Pants, ’cause I thought that was a better title than Eighteen Months Without Pants.

But the reason why I show you these facts is just to set the stage for the practices I’m gonna to talk about, because this is not some jokey start-up company. You have a culture now that really loves to talk about these cute, young start-up companies and the weird things they do. You’ll see it on 60 Minutes or Fast Company magazine, about some new start up that has some cute, little name, and they do something weird or cute, like they always stand on one foot, or they always, they always talk in Klingon or something, and we all laugh and joke about it; it’s ha-ha-ha, but the business that they’re running isn’t really all that important yet. These numbers mean that there are thousands of businesses that depend on WordPress or at least depend on WordPress.com to run their businesses.

So, this is the list of really unusual practices that go on in company culture. And I was told about these things before I was hired, and part of what made me interested in working there was to figure out if these things were true, if they were good or bad, if I could effectively lead a team, given these challenges.

• So, first, no one uses email. Let me say that again, no one, no one uses email. You may wonder how anything gets done. I’ll show you screen shots and pictures. There were no restrictions on what I could write about in the book, so I’ll show you some of the stuff from action, our daily working practices. No one uses email. You get . . . everyone got an email account, but almost no one used them. Ninety percent of the email I sent or received while I worked there was to people outside the company.
• Everyone works remotely, and this is one of the jokey reasons for the title of the book, A Year Without Pants. There used to be a joke, a running joke in team meetings, half-way through we’d go, “Hey, who’s wearing pants today? Ha-ha-ha-ha,” ’cause no one could see each other. We spent a lot of time in chat rooms together or talking to each other in audio, without actually looking at each other.
• There are very few rules and there’s this fundamental notion that every employee that’s hired is an adult. That if you’re hired, that means you’re talented, and that means you’re smart, and that means you’re good at getting things done on your own. You shouldn’t need much structure. You shouldn’t need a manager to tell you what to do today. You shouldn’t need that.

So, there’s this very strong culture in the company, when I was hired, that’s resistant to the notion of teams or hierarchy of any kind, which presented extreme challenges for me coming in, specifically with the job titles of “Team Leader.” I’ll talk more about that as we go along.

• There’s a bunch of other things which are now becoming more popular. They use what’s called “continuous deployment,” which means it’s not big schedules, if you’re a developer or designer, and you’re doing some work, and you get it done. You can just launch it. You don’t need to go through some hierarchical process or bureaucratic process to launch new work. So, new work is launching everyday. Bugs are being fixed every hour. It’s done independently. Everyone’s working on their own. There’s no gates in your way, in terms of getting work out the door.
• They have an open vacation policy. And this list actually goes on much longer, but you can get a sense for how unusual these choices are. By most theories about management and teamwork, this stuff shouldn’t work. We don’t have a lot of experience with larger companies or larger organizations running these mission critical kinds of systems where this stuff would work.

One theory I wanted to explore is about questioning the need for management at all. WordPress.com represents that, since their culture is inherently non-management centric. There’s a poll that Gallup did, Gallup the polling service did earlier this year, and they asked workers, American workers, professional workers, how engaged they were at work. It was an unusual kind of survey. It’s self reporting. Individuals would decide for themselves their answers. How engaged are you at work? And seventy percent of the people that responded said that they were not engaged. Seventy percent. That’s almost three out of four. Of this number, almost thirty percent said that they were actively disengaged; they were actively disengaged. Think about an actively disengaged Air Traffic Control engineer, an actively disengaged brain surgeon. That’s disturbing. And we all know, in our daily experience in life, all the people that we deal with that aren’t really paying attention in their jobs: a waiter, or someone at a counter, at a desk, or we call someone for phone support. We all kinda know this, but it’s kinda staggering to see this as an actual number.

Of course, I am dubious of all surveys of any kind. It’s worth noting that, of course, the people who have time to take a survey are probably more likely to be disengaged at work. Right. So, I sure that there’s probably margins of error here, but I think the general implication of this is sound. And I don’t look at this as an indictment of the individual workers. I look at this as a challenge or a questioning of management. All of these people have managers, managers who are failing to match the worker to the work in a way they’re engaged by.

In my life, I’ve had lots of unpleasant jobs or jobs that are not particularly interesting. Mowing lawns or being a waiter at a lousy restaurant, or doing telemarketing or direct mail. In some of those experiences, I felt engaged, depending on who I was working with and who I was working for, and how the person I worked for treated me. So, look at this number as a serious question about management and a call to action to think about what is it that management does, especially when managing people who are talented or craftsmen, or makers, which everyone in the software industry, most of the positions inside the software industry, fit to that profile.

The other statistic I want to offer, before I show you some of these screen shots of how we actually worked on a daily basis. I knew I had to explore something about the question of remote work. It’s a thing that Automatic and WordPress.com are known for, being one of the largest fully-distributed companies that we have.

When I was hired, I was employee number fifty-eight; by the time I left there were about one-hundred and ten, and now there are about two-oh-five, somewhere in that range. So, they’re known for being one of the largest distributed companies that we had. I knew I had to ask this question about, “What does remote work mean?” and “What implications does it have?” So, the data around this, there’s lots of different sources you can find, but most of it says that remote work is on the climb. About twenty percent of all professional work is done remotely. If you add to that the organizations and companies, there’s some major Fortune 500 ones that fall into this category, that allow at least remote work one day a week, a few days a month, as a partial benefit, it’s about twenty percent. And, of course, this includes all of the remote work that we take for granted, remote work that’s done over the phone.

About a hundred years ago, not even a hundred years ago, fifty years ago, any time you had a phone conversation with someone about work, that’s a kind of remote work. You were interacting with someone who’s not in the same physical place as you are. And, if you use that definition of remote work, it actually means there’s a longer history of this kind of thing than we usually consider.

And then other things fell out of all these big questions. What other traditions do we have about work that we don’t need anymore or maybe we never needed? We have this assumption about nine-to-five working hours. It’s based on what? We all know that the nine-to-five working day forces people to commute. That guarantees them a half-hour or an hour every day of stress, of uncomfort, of negative experience, before the even get to their jobs. Why do we need that? Why do we need that? Why do we have to show up at the same time? It’s a good question. What about dress codes? We assume that dress codes make us better workers, but I’ve never seen a study or research that said wearing a tie or wearing a dress makes people perform better. So, there’s lots of these questions that I wanted to go and explore, because in this environment where none of these things were true, we should be able to find out something about the absence of these things we assume to be necessary.

So, this is the mystery. This one slide explains most of the mystery around how they get around not having email. And I’ll walk you through this, and I’ll show you some more specific examples.

These three tools, IRC, Skype and P2. P2 is basically, it’s a theme. It’s a WordPress theme. WordPress has hundreds of themes that change how it works and behaves. P2 is a theme that was made inside WordPress.com. It’s available for free, but it’s sort of a work flowey kind of blog theme. IRC, Skype and P2. About eighty to ninety percent of the communication I had with my team or in the company were done with these three tools. IRC is one of the oldest chat room, chat programs in history. How many of you have used IRC? Many of you. It’s like ancient.

When I got hired there, I thought for sure they’d have all of these fancy, high-tech video conferencing tools that they stole from the NSA or NASA or something, and it’d be all, you know, this amazingly, amazing technology. All three of these tools are free and, in most cases, in at least the cases on the left, they’re off the shelf. There’s nothing customized, or funky, or special done about them, and I found that really surprising.

IRC was the hallway. So, IRC, one of the few rules; it wasn’t even a rule, it was sort of an implication. It was implied that you were supposed to do this. Whenever you were working from any time zone in the world, you were supposed to be in IRC, ’cause IRC was the hallway. IRC was were you could go, just like your physical hallway, to ask a question, to find a coworker, to have maybe an informal meeting, to talk about social things. You could just go in there and ask a question, and whoever was online would answer. And sometimes there would be meetings held in IRC. People would create a different chat room for that meeting. It was very informal, very fluid.

One very interesting thing, and something that terrified me when I was hired, is that everything in IRC was public. So, any employee could go into any chat room, and all the chat rooms were logged. All of it was recorded. So, you could go back a month later. They were very proud of this. I questioned, at first, why that was even necessary, why that would even be a good thing. But I was told that everything was archived, so you could go back a month later and you could say, “Hey, why’d we make that decision?” And you could go back, you could search through it and find exactly the conversation, and see what was said, and that would have value. Of course, I don’t think I ever saw anyone actually do that, but like most engineers, it was sort of one of these features that everyone was so excited about the potential of, that we never actually got around to using.

Skype was equal, but a one-on-one conversation, so if ever I had feedback to give to someone on my team that was a little bit sensitive, I’d give it to them there. Skype was private. Skype was logged, but personal. It wasn’t searchable. It wasn’t shared. Sometimes we’d have team meetings in Skype. Sometimes we’d have team meetings in IRC. There were very few rules about which tools were used.

I mentioned before about treating employees like adults. The implication was you decide which tool you want to use. And, when the teams were formed, it was implied your team together will decide which tools you want to use. So, some teams use IRC, some teams use Skype, some teams use Skype video, some teams tried Google Hangouts. There was lots of experimentation, across the company, on which tools to use.

The last thing is all the way on the right, which is this P2 theme, this WordPress theme. This theme was probably the largest receptacle for all the stuff you would imagine, all the stuff that goes on in email in most organizations. If I had a proposal, I had some thing I was working on, I had a mock-up of some thing I thought should be designed, I’d post it there. And then everyone on the team would come and, just in the same way done on an email thread, people would reply. Same thing. At first, I thought this was really strange. I was very concerned that, since the blogs were also public to the company, so anyone on any other team could come by and comment on the stuff that we were working on. I had a lot of fear about trying to maintain control for the creative direction of the stuff that we were working on. But that rarely, that rarely became an issue. So, you can imagine, in the same way that an email thread would have this (inaudible) all reply, all reply, all the blog just had the same thing, except it’s manifested on a blog instead.

I was really surprised to learn two things. One, this had some major advantages that I would never have guessed. The primary one being that email empowers the sender. If I had all of your email addresses, I could send you an email every five minutes with updates on my book. It would drive you crazy, but I could do it, ’cause I have your email address. Blogs work the other way. Blogs empower the reader. No one can force you to read a blog. So, the way the company works is you pick which ones you want to follow. You pick which team blogs you want to follow, which project blogs you want to follow. If that blog becomes annoying, you don’t follow it anymore. It’s up to you. It’s empowering of the reader instead.

So, you can see, this is an example of a conversation. We were trying to figure out which bugs to fix on a particular day. It’s a transcript of our conversation. One of the things I was really shocked by, even on my first day working there, was that everybody at the company writes well. Everybody. On the first day, I had to get some accounts set up, I had to, you know, make this thing work or this server work, so I had to talk with different people, and everybody wrote really well and communicated really well. It was a key thing about how the company functioned and why they could work remotely, why they could work in this distributed fashion. They all communicated really well. And that’s one of those things to me that’s a platitude. Every company says, “We’re a great communicators. We’re all really talented,” and we know that’s not true. We know that on email, we know that people skim, and they read the first line and guess at the rest. Like, we know we deal with these, these situations were people don’t write really well, but everybody there does.

I have theories as to how they achieve that, but I noticed the effects of it. For most of our project management things that we needed to do as a team, we did them on the blog. This is an example of us actually coming up with a list of bugs to fix and how we managed the triaging of those bugs, and discussions around which ways to go. It was all very simple, no special plug-ins or fancy methods.

People ask me all the time, when I talk about working there . . . I wrote, one of my books is about project management. I know a lot about software development methods and methodologies. People ask me, “What did you use? Was it Agile, was it SCRUM, was it Agile Light, was it SCRUM +, was it 6-Sigma Light, was it 6-Sigma Light, plus Agile SCRUM? Which was it? How did it work?” And my answer is, “We didn’t use any of those things. We didn’t talk about working that way.”

I mean, even if I thought one of those methods would have been appropriate, I probably wouldn’t have used that language. There was a very strong anti-methodology, anti-corporate bias in the culture, and I was coming into the company as this former Microsoft person at an open source company. I had a lot of things I was trying, a lot of traps I was trying to avoid. So, you can see here, we just worked in a very simple fashion. As a team lead, I’d make a list of stuff I thought needed to be done. Developers would come by and grab them. When they got them done, they’d strike them through.

Sometimes we’d have questions for each other. We’d comment on them. If I didn’t get a response from someone on one of my questions, I’d find them on Skype. If they were online, I’d say, “Hey, can you get to that?” Then they would, and whenever the whole list on the blog got too messy, ’cause it got . . . there were too many threads, I would go through and find all the things that hadn’t been done, and create a new post, with a new list of remaining work. Super simple.

The reason why this could work, in many organizations and places with complex processes, even places that actually need complex processes . . . this is just, this seems like, this is too ad-hoc, there’s too many things that could go wrong. But the reason this could work is ’cause every employee was empowered. They didn’t have to answer; they didn’t have to explain. They were free to fix these bugs and to move on, and to make decisions on their own. Same thing was true for design work. I have a, I have a design background. A lot of the work that we did was design related, and we would post mock-ups for things on the blog. We would discuss them. If ever we had work that was really complicated and, of course, I should back up for a second.

The blog is asynchronous, so I might have posted something and no one would respond to it until the next morning, depending on when my teammates, where in the world they were when they got to it. Skype is completely synchronous, so that means you have to be talking to each other at the same time. Most of the work we would do, design-wise or about engineering choices, was done asynchronously. If ever we had something that we weren’t communicating well, asynchronously, I would call for a meeting, we’d arrange a time, and we’d get into a virtual chat or we’d get a virtual whiteboard up and we could simulate being in a whiteboard together. We’d have our discussion and we’d talk through the different things that we were disagreeing about, come to a decision, and then we’d go back to working on the blog. And some of the things we had to do were complex engineering challenges that required flow charting or more elaborate thinking of how all the pieces needed to fit together. And I was afraid coming in that we’d lose the ability to put stuff up on the wall, in the physical hallway, where we could all look at it together. But for most cases, we found a way to replicate those things online.

I don’t think that the fidelity of doing this stuff completely remotely was quite as good, but whenever things went wrong, we had problems or issues, or something bad happened, I’m convinced it was ne . . . the remote work thing was never the prob . . . almost never the primary reason something went wrong. We were always, we were almost always able to replicate enough, enough of the essence of what goes on in conversations, in person conversations, online.

So, this picture, to bring this back around, this picture . . . there’s a bunch of really interesting things going on in it. And it looks like it’s a picture of three young men in a crappy basement apartment, with bad lighting and funky couches, sitting and doing work together. What this actually is a picture of . . . this was my team. This is about a month into my hiring with the company. Our team got together for one of the first times in physical space and, of course, what happens when a bunch of remote workers are actually in the same room working together. They work through the computer together. So, we’re sitting there Skyping and IM’ing each other, you know, and we’re two feet across from each other, which I think is kind of funny. But what’s even funnier is to think of all of the offices and all the work that’s done in regular workplaces, where most of the interaction between workers is done through computers.

Think about what percentage of time the average knowledge worker, who has a laptop or computer at their desk spends, at work, interacting with coworkers purely through their computers. It’s probably like fifty percent, forty percent, sixty percent. It’s a lot. In some places it’s probably more. I know, back before I left Microsoft and working as an author and visiting places, I’ve been in conference rooms where everyone has a laptop up and, other than the person speaking, everybody’s just on their computer.

There’s this question that we really should be asking. If most of your interaction with a coworker is purely through a screen, why does it matter where you are? It doesn’t. That screen could be anywhere. The screen could be anywhere. Sure, for the other percentage of your time, where you’re doing stuff physically in the same place, where you’re paying attention and making eye contact and doing all that stuff, sure, maybe, but for that thirty or forty or fifty percent, it doesn’t matter at all.

Sometimes we would end up meeting, a subset of the team . . . oh, I should say that the teams were formed as an experiment, so Matt Mullenweg is the founder, Toni Schneider is the CEO. They wanted to create teams to solve some problems they thought were developing, but this was all an experiment. They didn’t know if it would work. They didn’t know the right way to build a team. They didn’t know the right way to manage that kind of work or to enable it to work well, but they did tell every team that you were free to meet in physical space together a few times a year. And our team was one of the first to do it.

This was actually our first meet, in Athens, Greece. We chose Athens, Greece, because they were all from different parts of the world. Mike Adams was from California, Andy Peatling, in the middle, was from Ireland, Bo Levens [sp] was from Australia. So, when you have people distributed across the globe and you’re trying to meet up, you have some wide range from where you pick. And, also, Matt Mullenweg said, “Hey!” We asked him where we should go, and he said, “Well, Greece is great this time of year.” So, we quickly went and bought tickets, before he changed his mind. Got to act fast! You guys know this, once you’re given an opportunity, you run with it, so you don’t look back, “Oh, I already bought the tickets. Too late.”

So, one of the experiments was how do you do this. What happens when you meet in physical space? What’s the best way to use that time? And the book follows through my experience on all these different dimensions of experimentation. And the stories, I’m telling you, I’m not an advocate for everyone to be remote workers or for everyone to avoid email. I think it’s a mistake to have those kinds of blanket recommendations. I think it’s part of the problem with expertise, with expert experts is that we come up with these models or these theories, then we, “This is the way for the future and everyone should do this.” And I think that’s wrong, I think that’s flawed. We all know it’s kind of flawed.

So, the lesson from all this and the lesson from the book that I hope comes through is about the value of being willing to try.

For Matt and Toni, the notion of teams ran against the company culture, but they were willing to try, and they empowered every employee to help try, help with the experiment. They hired me as an additional experiment. Would it help if it was someone who had management experience from outside the company? Would that work better than the other teams? Would that work worse? They didn’t know, so they tried.

So, a lot of these things imply experiments. And so we had did other experiments. Sometimes it had just work out that me and one other person on the team would end up in the same place and time. These are because we were traveling for other reasons or maybe we . . . it was something that we definitely wanted to do in person, so we would meet up together and we’d work, just like you normal workers work. We’d work at a whiteboard and we’d work on paper.

But we always had this discipline about making sure that the remote view of the work was always up to date. So, you can see here that we are, once we’re done with our the meeting, we’re translating all of the stuff we’ve decided or all the ideas we’ve come up with, we’re making sure that’s reflected back on the blog, so all of the people that weren’t there would know something of what went on that they didn’t experience.

Sometimes that would be shorthand. We would just say, “Hey, Mike and I talked about the foobee doobee feature and we realized we’re going to go with Plan A instead of Plan B.” If someone cared about that thing happening, they could comment on the thread and ask to learn more. We didn’t always have to have . . . spend a lot of time making sure it was copied, but we had to put some flag up to let people who are working remotely, which is the majority of the people on the team, know that things have changed.

And this is the primary thing that any of you who work with remote workers . . . this is the primary reason why having a team that’s centrally located with one remote worker usually fails. Because that one remote worker is usually on an island, and the only thing that remote worker can ever know or use to the their work is what they see online. So, if all the stuff going is in person and no one’s putting that stuff on line, they’re lost, and many of those remote workers have to try and become like Sherlock Holmes, where they are constantly tracking down and chasing, “Hey, what’d you guys talk about today? Was there anything new? What’s going on?” They become like investigative reporters, trying to make sure that they’re not missing stuff. That’s usually why that fails. That’s not to say that remote workers can’t always work. I’m not saying that, but usually why it fails is a lack of respect, for making sure that remote worker has what they need to be successful.

Over the course of my year working at the company, we tried all different flavors and all different variations. In some cases, it’d be two people together, with half the team somewhere else. Sometimes, it would be most of the team together, with one person who stayed at home. Sometimes I was the person at home, and the rest of the team met up together. This is us at a team meet up with . . . doing a video conference, with Matt Mullenweg, the founder of the company. So, over the course of a year-and-a-half, I experienced just about every variable, every flavor of remote work that I think exists.

We were always experimenting and trying different things, and that one trick with of making sure that remote work is up to date is probably the most important thing I learned from making all those different kinds of experiences work.

The last thing that I wanna say, before I open the floor for questions, is there was a particular challenge that, once I agreed to take the job, I realized that I had, and this gets back to thinking about what a manager is, if you have a culture that is very young, very anti-corporate, founded on chaos and autonomy, what does management mean? What does a team mean in that situation? It . . . does it mean anything at all? Can it function at all?

And, coming into the company, I had to figure this out, because this was going to be my job. I wanted to do well in this job. I wanted to take it seriously, so I tried to come up with an answer to this question. What could I offer my team, if I was not a WordPress expert? I’m not really a developer. I’m not an open source guy. My entire team, each one of them, have expertise that I didn’t have. I couldn’t be better than them at their own skill set, so what could I do? And I came up with an answer, and the answer were these two things: clarity and trust, that my job and my hypothesis that the thing that I could provide and the thing that could add value was providing clarity.

Why are we doing this? Why are we not doing that? What’s the best use of our time? What’s our best possible goal? Why are we going to work on this? Clarity around those things, that with four people, five people trying to work together, odds are there’s going to be a lack of clarity. Everyone’s going to be working on their own thing. It’s not going to line up to make a sum that’s greater than the parts. I could provide that.

The second thing was trust. By trust I mean, the only way I could effectively lead a team was if I had their trust, and I could figure out a way to earn their trust. I didn’t know how to do that. So, I came up with a solution, and my solution . . . well, I shouldn’t say solution . . . I came up with a potential solution. My solution was very simple. May solution was to be the scribe.

So, we’d have our team meeting in IRC and people’d be typing, and we’d have our conversation, and I would just follow along, and once the conversation was over, I would post up some notes on the blog. And I’d try to be concise and clear and post them. And then, they saw the notes that I wrote, and they said, “Whoa, OK. You know, this Scott guy can write sentences.” Well, that’s good. That’s better than nothing. They could trust me to write sentences. [Audience laughter]

You gotta start somewhere. I knew that I had to be patient. If I came in, which I had every tendency to do, ’cause I had all this ambition to show how much I have learned and how good I am at being a leader. I came in, I wanted to change everything. I wanted to make plans for everything. But I had no trust, so if I had tried to do that, I would have failed before I started. So, I bet on patience. I was the scribe. I posted notes. And, little by little, instead of posting notes, I made a suggestion. And I picked my suggestions carefully. I picked the ones that I knew were right, the ones that I knew were good suggestions. And then they’d go, “Oh, Scott makes good suggestions about which work to do first or how to go about thinking about this problem. OK, that’s good.”

And then, little by little, over the course of two months, three months, I was naturally the person who led the conversations, that made decisions about what things we would do and about what the goals were, and about what bugs we’d fix and what bugs we wouldn’t, et cetera. But I had to earn those things. And I think that’s a great philosophy for thinking about management and leadership in any situation. In any situation.

Part of the flaw of management and part of why that seventy percent number, I think, exists is we have that notion of managers and leaders as executives, as being the center of everything. That they are the lords. They are the people who make everything go, and they must be in the middle of all things, and this environment made that impossible. But I think that it also verifies the fact that maybe managers and executives aren’t important in the way that they think they are. There’s something very different, a very different value that they add.

The last thing I want to leave you with are these two notions, these two numbers, these two statistics. I think this engagement problem is going to stay with us. One of the lectures this morning talked about millennials and the different needs at work. I think they’re going to be more demanding of engagement than previous generations, so I think this number is going to get higher. Even if it doesn’t, seventy percent is a staggering number. Seventy percent, you think of the workforce, is a ridiculous number. So, we have to ask this question about what should managers be doing differently about how they structure and think about work.

And this twenty percent number, I mentioned before about screens. Anything you’re doing through a screen, with some other person through a screen, that can be done anywhere. And as technology gets better, as more things that are done through screens, this number is going to rise. And the sooner we figure out how to take advantage of that, how to use that as an asset, the better . . . the better we’ll be.

So, I’d like to thank you for listening to me, and we have about twenty minutes for Q & A.

Audience: Scott, you just have one of the best BOS presentations ever. Thank you very much. Seriously, awesome. I have somewhat of a logistical question with the team . . . remote work. What your kind of thesis is here would make lawyers kind of squirm, when you talk about intellectual property. Were you having your developers kind of VP’ing into a central location and all the code resided there, or did you have different servers at each of their locations so they could build and test?

Scott Berkun: Both. There’s a central . . . well, there’s a couple of things here. First, it’s an open source company, so their concerns about that stuff, generally, are not very high. I mentioned before, WordPress, free open source. WordPress.com is a business. It takes that open source code base, modifies it a little bit and does some special things to it. Some of those modifications go back into the open source code base. So, there’s an overlapping relationship between the two, but in general, the spirit of the company is open source. Not a lot of concern about intellectual property. A lot of the work that my team did was released back into the open source. It wasn’t always released back in to WordPress itself, but it was put back into a repro that uses a plug-in and et cetera.

In general, developers have what were call “sandboxes,” so they had a repository that was local to work on the pieces that they were working on, but the core repository was on a central server. Centralized. Yeah, sure. You get a book for asking the question.

Audience: Hey, Scott. We… internally, we have gotten away from using a lot of email, as well, as you have, but we spend a lot of our times managing expectations with clients, which we can’t avoid email in that situation. Do you have any tips for how we can migrate the conversations we have internally around that external facing conversation.

Scott Berkun: That’s a good question. I don’t know that I have particular advice, but I should say I mentioned that there are teams. When the company divided teams, there were ten or eleven teams. They all had different functions. None of them were particularly exotic in their charters. One team was the support team. They managed all the support and customer support requests. Another team was the theme team. They built themes for using on WordPress.com. Another team was the mobile devices team. Then there were two teams that fall into the challenge that you’re talking about. It was the VIP team. So, there’s a premier class of customers that used WordPress.com’s architecture for hosting their stuff. The New York Times, TED Blogs, Dow Jones, they host all their stuff on WordPress.com’s server. So, the VIP team had to work differently. To interact with their clients, they had to use email. All of that stuff though, they had . . . they worked in a much more traditional way. If you want, I can put you in touch with the lead of that team, and you can ask him how they managed that trade-off.

My team was fairly sequestered. We worked on WordPress.com, we had no obligations to clients, so we never had to deal with that challenge personally. I could make up an answer, but I’d be better off getting your business card and pointing you at the person who actually does this all the time.

Audience: So, hi. So, two questions we’re struggling with. One is how to plan office space, when you have a lot of remote workers that are part time. We still need lab space and conference room space, and how to get that mix right. I don’t know if you have any advice. And the other question, real quick, is Microsoft Link, choosing to make an investment in a commercial tool like that, versus the free options, if you could offer advice.

Scott Berkun: I have no experience planning offices. I think that some companies now, they are doing . . . they’re coming up with a percentage. So, they know if they’ve got one hundred employees, they’re going to build out offices for seventy percent of that. Seventy percent of their employees are going to come in on any given day. And there’s different models. There’s open space models where a large open space and private rooms. There’s plenty of plans you can find. That’s another thing. I’m sure it wouldn’t be hard for me to point you at resources and show you different theories and different equations that people use. I’m not an expert on them and, off the top of my head, I couldn’t give them to you.

I’m glad that you asked about other tools. So, one thing I suggested, I mentioned briefly that people communicated really well, but it goes further than that. The reason why these light-weight tools worked, the reason why nothing fancy was needed was because of the teams, because of how collaborative people on the teams were. So, there’s this theory that’s implied. I couldn’t give you a research sum- . . . I haven’t any research on this. This is purely an opinion, but the stronger the team is, the better the team is at communicating with each other, the less sophisticated the tools are . . . the tools that you need.

There’s all these stories throughout history of great things done with people who had small resources, but they had clearer goals, they collaborated better, they communicated better, which minimized the need for trying to solve all these problems technologically. Some of this comes just out of the open source community. To work on an open source project means that you’re working with volunteers. It means that the people who you are partnering with can leave any time, and you treat people differently, if you know that they can leave at any time. You’re going to treat them better. You’re going to treat them so they want to stick around. And so, a company that built out of an open source community has some of that culture just absorbed into it, that you treat people well, you communicate well, you look out for them.

So, a shocking experience I had, and I don’t know what I expected, but a shocking experience that I had is on my first day, I went to the IRC in one of the big chat rooms and everyone was there. And I had some random question about WordPress that I needed to figure out, and I asked the question and like four said, “Hey, I can help you. I can help you.” And I was like, “Whoa! Why are people so friendly here?” [Audience laughter]

“What are they . . . what’s going on?” And it took me a while to acclimate, that’s just, that’s how you treat your coworkers. It’s not some cultish thing, where you’re yelled at to do it. It’s just . . . that’s just . . . that’s just your coworkers. Someone’s in chat, says “I need help,” and you help them. And you feel good about it and they feel good about being helped. So, what is that? That’s culture.

So, a lot of the book and a lot of the way I think about this stuff now is focused on culture. What is that? Culture trumps technology all the time. So, my answer about Link. I actually don’t know much about these different tools, but I wouldn’t worry too much about the tools, I’d worry much more about culture.

Audience: Hi, Scott. My company has got two offices. One in New York; one in London. I found it interesting when you said that it’s really hard to have one remote worker, because they’re basically an island, and we’ve basically got two islands. And I was wondering, what are your thoughts on, you know, what are the practices of remote working that can help, not remote workers, but just two separate offices in different time zones, to stay connected as much as possible.

Scott Berkun: Are the two teams working on the same project? Or is it more of a service company and you’re . . .

Audience: So, our development team is actually in London, but then we have two commercial teams, Sales and Marketing Operation in London, and Sales and Marketing Operation in New York. And there’s . . . there has to be a lot of cooperation between then, although they kind of operate independently.

Scott Berkun: What’s the problem that you’re having?

Audience: The problem can be it’s, it can be really hard sometimes to coordinate properly on Marketing activities. Sometimes we find out the teams are duplicating efforts, because they’re working on similar things. The development team and the product managers in London tend to have a better relationship with the sales people and account managers who are in London, because they just walk across the road and speak to each other, and it can be much harder for the guys for the guys in New York feel that they don’t have as good a relationship and don’t get as much updated product information as the guys in London do. Those kind of things.

Scott Berkun: Yeah, you know, there could be a lot of things to try. I couldn’t tell you what would fix it. Generally, in any organizational problems, if the two people in charge of the two different groups don’t like each other, that bleeds down. That just filters down. If the two people in charge of the two groups get along really well, that bleeds down, too. That would be the first thing I’d think of. Those peop . . . are they on the same page, those two, the leads of those two offices?

If they’re not talking much or they disagree, or they’re fighting for resources, it’s gonna be hard to do anything that’s gonna fix that. And if that’s broken, I would think about . . . or you can’t fix that, then I’d think about, how often does someone from one office get to visit the other?

I mentioned that, even though this company is known as the remote working company, they believe you should get together, periodically. There’s intangible things you will get, and you’ll think about your relationship differently if, periodically, you’re in the same place.

I didn’t mention it, but the other thing, once a year the entire company gets together, the whole company, in the same place. It’s optional to come, you’re not required. Some people choose to work at the company, so they don’t have to travel. That’s part of why they took the job, or for family reasons. But the company gets together once a year for a week, and it’s the big meet up. And that’s usually a great opportunity for any sorts of issues between teams or groups to be discussed, for those two leads to go out and have some beers and sort out their differences, so they can go back and return to their offices, and things will be better.

Audience: So, I wanted to ask you about, quite famously, Yahoo have kind of ripped remote working off the table. And the reason for having done so, according to leaked documents and intrigue, is that they did an analysis about how much people are actually working when they’re at home. And (inaudible) once you get through it, (inaudible) was like, this is just not happening and took that off the table.

So, I was wondering, you know, what around accountability there is for . . . I mean, obviously, the best answer is hire good people who are motivated, but you know how do you catch that and what do you do there?

And then a slightly second point would be about Legacy, so ’cause people are, I imagine, are ebbing and flowing. Are there some sort kind of coordination issues around making sure that you’re not losing kind of brain power or thought, or you know, keeping the business’s core knowledge base kind of up to date, when lots of people are ebbing and flowing in and out.

Scott Berkun: OK. The Yahoo thing is fascinating to me, because we are so . . . it’s like we’re so easily shaken about ideas. Yahoo’s a failing company. They stopped doing something, we go “Oh, my God, well shouldn’t we all stop doing it.” It’s like if you had a dying animal that stopped breathing. We’d go, we should all stop breathing now. The dying animal stopped breathing; therefore, everybody should stop.

Yahoo’s not doing well. Yahoo’s had a horrible decade. Five years ago, whatever it was, four years ago, and they were going to be acquired by Microsoft three years ago. Everybody, their best talent left. That’s what, at any company, when you’re struggling that much and you’re flailing, a lot of your top talent goes away. So, Merissa Mayer inherited a very difficult challenge.

So, I read everything that happened in that whole situation. It’s her trying to recover her company. I can totally understand her choices. The day that . . . I remember reading some of it . . . all of her data that she referred to was about employees at Yahoo.

I’m sure that remote work is a privilege. The copy room in your office, where you can steal staplers and paper clips, that’s also a privilege. Any benefit you have as an employee can be abused. And when you’re in a company that’s falling apart and you don’t have the best people anymore, things are abused. And it would make sense for the leader of that company to take them away.

The other thing I should say is about hiring the best people. It’s the one thing on that long list of about unique work practices that wasn’t on there, that I want to make sure I tell you about, ’cause I think it’s fascinating. It’s that Automatic and WordPress.com, they hire by trial. So, the way you get hired by company is by trial. So, the way you get hired by the company is by a trial project.

Once you work your way through the network and you get referred to be interviewed, they say, “Hey, you wanna work here. Great. Here’s a project. We’re gonna take a real project from our list of stuff to give to you.”

If you’re a designer, you’re a programmer, maybe you’re a writer, whatever it is that your job would be . . . “Here. We’ll give you access to IRC rooms and some of P2s and stuff. Go do it.”

And a lot of people get that and they go, “Oh, I start now? Where’s my list of like ten things to do . . . and the . . . ?” They expect there to be more structure. They go into the IRC chat room and they’re like, “Well, what do I do now?” They get freaked out by not having direction, and they bail on the project.

They bail on the hiring trial.

Some people get further along, they figured out how to work, and they’re going to work remotely. And they do a good job on the trial project, but they’ve realize they don’t like working remotely. So, they bail, too. So, the hiring process actually filters out a lot of the problems that we would assume might be true with remote workers, which is exactly what a hiring process should do in any organization.

Hire by trial sounds really strange, but I think that’s part of the problem, that our hiring processes in most organizations are incredibly broken. We hire by this meta-language, in the abstract. We talk about all this, “Oh, what would you do this and what would you do then?”

But we know in the real world, it’s not a good way to hire people. If you had a wedding or a party and you wanted a cake, and you went to the baker, you wouldn’t say, “Tell me about your strengths and weaknesses as a baker?” We wouldn’t say something like, you know, “Tell me about a cake that went wrong and what you learned from the broken cake?” That’s ridiculous. You would say, “Make me a cake. Make me a cupcake; make me a cookie. Give me a sample of what you do.” But we don’t do that.

So, they do hire by trial, which I think is brilliant. It’s expensive. It takes more time, and it’s a low hit rate, but that’s exactly what you’d hope a hiring process does. The fact that it exposes candidates to the culture and exposes them to coworkers, gives them a very clear . . . it gives them the real experience of working at the company. So, before they sit . . . before they even offer them the job, they’ve already been in the company. This makes complete sense to me. I don’t know why it’s not more popular.

Audience: Hi, Scott. At the beginning you said that expertise has an expiration date. If you’re not actively practicing it, there should be some limitation on when you can continue to dole out expertise. And you described that as some kind of challenge to yourself, of when you were going to take this on with WordPress and is my expertise still fresh and all that.

And I’m curious, and you’ve also written books about innovation and project management and other things that I’m sure are in your . . . you know, the kind of things your were dealing with day-to-day at WordPress. I’m curious about what kinds of things that you found that you wrote about in your books, that you found that actually may not still be true or, you know, you got it wrong in your books, if anything.

Scott Berkun: There’s nothing wrong with that. That’s part of why I wanted to do it. I have no fear of being wrong in the book. That’s part of . . . half the reason for writing it. That’s actually what I think. I think, this is what I think, and I’m hoping someone smarter comes along and goes, “Oh, yeah, well, this is not quite right.” And then I can go, “Oh, now I can write a new book.”

I have no fear. This is the whole basis for writing. This is what writing is supposed to do. You’re hoping to make progression. Anyway . . . when I wrote Making Things Happen, which is the book about project management, I knew when I wrote it, I didn’t fully agree with a lot of stuff that was in it. And by not agreeing, not that it’s flawed or broken, it’s that I wanted to capture, when I quit my job at Microsoft and had been a program manager, like a team leader person, for a long time, I wanted to document everything that I had learned in those ten . . . not everything . . . I wanted a distillation of the best stuff that I had learned and captured from my brain then.

Even then, I would probably never have used all the stuff actually on a project. That book is very heavy weight. It’s very . . . operating systems and the kind of planning you need for that kind of stuff. So, even when I wrote it, I realized there’s probably a lighter weight book I could write, about managing smaller projects and smaller teams, and working in a more agile way. That’s definitely true.

I think there’s something that runs through all of my work, which is just about Occam’s razor. I’m a huge believer in Occam’s razor. If you need this complicated system and this complicated theory, you’re probably wrong, so you need simplicity. There has to be simplicity. That’s something that runs through all my work, and that’s what I came up with as my plan for this job, was clarity and trust. Those are two very simple words. They’re five letter, six letter words.

I’m actually hope . . . I’m a little bit lazy . . . I’m actually hoping that people read this book and they’ll tell me all the things that I got wrong, but that hasn’t happened yet. The book has only been out for a couple of weeks, so that hasn’t happened yet.

Audience: Hi, Scott. So, I work at a company were about fifty percent of our man hours are done remotely. One of the common nuances that we have, and I’m curious as to how you guys address this, is that some things which seem minor turn into kind of big deals, because we can’t properly convey emotions through the wire. So, how do you guys do that and what are some examples of experiences at WordPress?

Scott Berkun: Well, so, just be clear. I don’t work there anymore. I worked there from 2010 to 2013, so I’m not an employee anymore. I just want to make sure that’s fully clear.

This is the complaint. I mentioned before, I had no restrictions about what I could write about, and one of my biggest critiques was that the culture was not one of . . . it was hard to get good . . . there wasn’t a lot of debate. There was some debate, but it was rare that you would get really good, deep feedback about stuff.

And I wanted to chalk it up to remote work, but I think it had more to do with the culture itself. It just, it was something that the leaders didn’t do, and Matt and Toni didn’t do much. There weren’t many good examples in the company of giving . . . of critiquing work, without being an asshole about it.

But about emotion, the only emotion that came through vividly all the time was humor, and I think humor creates space for other emotions, that if I can make you laugh, even if it’s just smiley face, smiley face, I know I’ve connected with you.

Humor is the most fun, you could argue, emotional connection. When you make someone laugh, there’s something honest and genuine about that, even if you’re remote. Humor was huge, the number of running jokes and sarcasm, and there’s a ton of it. And I think make . . . create the room for the other emotions. They follow from that.

Maybe time for one more. Oh, we’re at zero.

Audience: My question is about international culture because we have a large development team in India, and what I can say, as far as, you know, the cultural biases that can be brought into those discussions, and it looked like you had an international team there, so how did the cultural biases factor into that.

Scott Berkun: I think that the hiring processes they used minimizes a lot of these concerns, because if there’s some mismatch culturally, they’ll know it before they’re hired, and either they’ll get . . . they’ll feel OK acclimating, or they’ll find it off-putting and they won’t go all the . . . they won’t finish. So, some of the hiring candidates we had on our team, that happened, where they were OK, they were pretty good technically, they were OK on communication skill, but they just, they didn’t fit with the way the company worked, in terms of how to pick work and being aggressive.

And so, there’s something . . . the other thing I should say is everything, almost everything I showed you was written. Written communication is the most important form and, in written communication, issues of international, issues of language and whatnot are minimized. It’s much easier to write in English, if English is your second language, than it is to speak in it. So, I think that was an advantage of the fact that it was all text.

It also meant that people had time to respond. One of the advantages of text is that people had time to think about their text before they reply, so I think that also minimizes people’s fears about cultural sensitivity or the likelihood that they’re going to make those kind of mistakes.

Well, thank you guys for listening, and I’ll see you guys at lunch. Thank you. Thanks.

Find out more about BoS

Get details about our next conference, subscribe to our newsletter, and watch more of the great BoS Talks you hear so much about.

Scott Berkun.

Scott Berkun is a bestselling author, explainer and popular speaker on creativity, leading projects, culture, business and many other subjects. 

He’s the author of eight books, including How Design Makes The World, The Myths of Innovation, Confessions of a Public Speaker, and The Year Without Pants. 

Born and raised in Queens, NYC, he studied philosophy, computer science and design at CMU. His first career focused on UX Design. At Microsoft he worked on Internet Explorer 1.0 to 5.0, Windows, MSN and later led an engineering team at WordPress.com (2010-2012) responsible for Jetpack, Publicize and other features used by millions of people.   

More From Scott.