MARK KILBY is an Agile coach who for over two decades has cultivated more distributed, dispersed, and virtual teams than colocated teams. Currently, Mark serves as an Agile coach with Sonatype, a distributed Agile software development company focusing on automation of software supply chains. Previously, Mark led Agile transformations, from startups to Fortune 500 companies. In his spare time, Mark also cultivates communities, such as Agile Orlando, Agile Florida, VirtualTeamTalk.com, and the Agile Alliance Community Group Support initiative.
Subscribe to the Collaboration Superpowers Podcast on iTunes or Stitcher!
His tips for working remotely:
- Host regular retrospectives.
- Be visible to your remote colleagues.
- Spend time getting to know your colleagues. Get together face-to-face if possible.
- Be transparent – let your team know both the good and the bad.
- Always have multiple communication channels.
- Make it easy to move from asynchronous to live conversations.
- If remote colleagues are calling into an in-person meeting, assign them a remote buddy to help out if something goes wrong with the connection.
- Have a plan B for when something goes wrong with your tech.
Podcast production by Podcast Monster
Graphic design by Alfred Boland
Original transcript
Lisette: Great. And we’re live. Welcome everybody to this Hangout on Air. My name is Lisette and I’m interviewing people and companies that are working remotely and doing great things remotely together. And today I’m excited because I’m joined by Mark Kilby. And it says, Mark, that you’re an Agile software mentor. You’re also the founder of Agile Lean Coffee Orlando and an author of a number of publications. I was looking on LinkedIn and there are so many that I can’t even list them in the introduction. So Mark, welcome, I’m excited to talk to you. Why don’t you give us a little bit of information about who you are?
Mark: Thank you, Lisette. I’m thrilled to be here. So a little bit of background on me: over 20 years in software, most of that time dealing with distributed teams. And in the last 11 years, serving in the role of either Agile coach or Agile mentor. So as an Agile coach, you’re typically working with teams, showing them better ways to develop software, work together, collaborate. And so there’s any number of things you end up doing. There’s training. There’s facilitation. There’s sitting side-by-side and showing them how to do some of these new processes that Agile requires of you. So what’s really unique about that is it’s really a lot of face-to-face. But as I said, a lot of my past work, over 10 years or so, has been mostly with distributed teams, and that’s why I’m excited to be here today to talk to you about that.
Lisette: Before we go into the distributed teams part, I’d like you to describe a bit for people what exactly is Agile. It’s very well known in the software world and it’s just starting to branch out into the other fields.
Mark: The Agile movement started in the early to mid 1990s and became popular in 2001 with something called the Agile manifesto. So folks can go to agilemanifesto.org and read about that. But essentially, what Agile is, it is a way of collaboratively working with the business to develop the right product at the right time. So rather than your business stakeholders writing out “here’s all the requirements that I have. See you in six months to a year.” It’s really working with them on a weekly, sometimes daily basis to develop a piece of a solution, have them take a look at it, see if they’re on the right track, and just continually work with the business to make sure you’re building the right thing that’s really going to be useful. So think of the number of times you opened up a certain software package and maybe you’ve gone to the menus. You go what is all this other stuff in here? So that is the stuff that the Agile teams would not develop. They would only focus on those items that would be truly useful to the end-users.
Lisette: So the minimum viable product as soon as possible.
Mark: I was trying to stay away from the buzzwords.
Lisette: Oh sorry, I don’t even know the buzzwords because it’s not my cup of tea.
Mark: That’s okay.
Lisette: But I got one.
Mark: Yeah, you did. You hit one.
Lisette: Okay, great. And tell me then about the distributed teams that you’re working with. What does that look like? And do you work distributed also?
Mark: My current company, Sonatype, we develop a suite of products for managing open-source software components. So we can pull down and manage different software components, and we can also tell you what security issues you might have if you don’t have the latest version. We can also tell you what kind of licensing issues because there are all kinds of different software licenses that could get you into trouble if you don’t realize that certain licenses might say if you use this, you might have to make all of your source code available. For some companies, that could be a problem. So it’s helping to understand what all these different pieces you’re pulling together are. So it’s a lot like the car manufacturers who track all their different components. And if something goes wrong, they can do a recall. They can tell you exactly what components were in there, what issues there might be. So it helps you track that, as we like to say, build materials within your software. So that team is really distributed worldwide. We all work out of our houses. We’re a completely distributed company. And this is the first time I’ve been in a pure virtual organization. But my past history has been in many different distribute teams. I used to be a coach for Rally Software which was a SaaS tool for managing Agile projects. And many times, we have packets of people in different locations using the tool. We’d have to train them on how to use the tool as well as the different Agile techniques. And so over the years, I started developing a few different techniques to help these people really be collaborative even though they weren’t face-to-face.
Lisette: Okay, so you started really specializing in the distributed part of working together with teams.
Mark: Out of necessity, yeah.
Lisette: Right. So you’re thrown into this situation. Do you have something that you do at the beginning of a project with each virtual team, like some sort of team agreement that you make or we’re going to communicate like this? Or do you let the teams more self-organize? Is there something that you do in the beginning to tune your team really is what I’m asking?
Mark: Usually, I’m coming on site as helping an existing team. Sometimes it would be starting up a new team. So if it’s starting up a new team, there are some great resources out there already to do that. So there’s the book Liftoff by Diana Larsen and Esther Derby. While it’s geared towards software teams, it really could be for any kind of team. So in that book they talk about how do you identify what are the key agreements? Why is the team together? What sort of resources do they have available to them that they can pull in? And what are some other groups they need to communicate with? So it’s setting all that context for the team up front. Many teams have that set up when I come onboard.
Lisette: Okay. And I can see how it would be useful for any team, whether you’re virtual or not, that you would have these sort of agreements in place. But it seems to become critical when you’re on a virtual team to have those kind of things in place.
Mark: Yeah. So what I’ll typically do is if they have some of those agreements in place or maybe they’re not working well, we’ll talk about some things they can add on to it. For instance, with virtual teams I always make sure they have multiple communication channels. So if they have video, they have audio, but maybe also chat because if your video and audio go down, how are you going to know to coordinate and get back together? So for our teams, we have a screen share. We have audio, sometimes video and chat going – which can be a lot to handle, but think about when you’re in room full of people and you’re facilitating. You’re managing those multiple channels as well. So it’s just a different type of management and it takes some getting used to, but it’s really managing that same number of channels you would face-to-face.
Lisette: Right. It’s all in a different form. I like that you used the analogy that it’s the same as facilitating a meeting in person, it’s just that you have different things to deal with. You hit on something interesting that’s virtual management. I’m reading a lot more about virtual management and virtual leadership. What is the difference, do you think, for you? How does one manage a team virtually rather than in person?
Mark: For that one, at least with software teams, but I think it’s true for any virtual team. You’ve got to be tech savvy enough that you can use the different technologies and maybe even have your plan B for when those technologies fail, so you can still stay in touch with teams, still keep communicating with them – whether it’s in a meeting or just some ad hoc conversations. The other part of it is I think it’s even more critical that you really get to know the team members, that you really get to understand what’s important to them, why they’re there, and do they understand the purpose of the team? I actually talked a little bit about this at the Agile 2014 Conference. It’s what’s in it for them to be part of it. I talked about what’s in it for you. What’s in it for the team? And then the third part is do they understand what’s in it for others for this team to exist. Do they really understand what the big goal is? And I think as a virtual manager, you’ve got to work pretty darn hard to do that – as opposed to being in an office where you can have those casual conversations with folks to just check in with them on that.
Lisette: So there’s this need for not over-communication but lots of different kinds of communication, perhaps.
Mark: Yes. Over-communication is probably not a bad idea. Actually, with our teams right now, we talk about that all the time. It’s okay to over-communicate. It’s okay to repeat something in a daily Scrum call that’s in email. As a matter of fact, it’s even encouraged just to make sure everyone is aware of something that’s come up that maybe the team needs to be aware of.
Lisette: And how do you communicate with your virtual team? What tools do you guys use? Or is it different based on the project?
Mark: Right now, we all tend to use the Atlassian suite. So we have JIRA Agile. We have HipChat. And in HipChat, you can have multiple rooms and we take advantage of that. So each team has a room. Our user experience folks have a room. Some of our sales people, our customer support people have a room. We bounce around between the rooms. Anyone in the company might be in multiple rooms at one time. We also have what we like to call our lounge. So the lounge is where people can bring up anything. Yesterday, it was a conversation on somebody’s latest crop of hot peppers they grew. Things like that happen in the lounge. And that’s sort of our team-building area. It is open season, whatever, within reason. People can bring up in the lounge and share things.
Lisette: Okay. So then it encourages people to hang out casually, which is of course an important part – something that’s missing from virtual teams, the water cooler time.
Mark: So that’s the hangout area. Along with that we have Google apps as well for collaborative document creation, and also GitHub. So what’s interesting about these different tools is it took me a while to get used to this. I can watch the thread of conversation go through the different tools, and then pop up on a phone conversation, and then back through the tools again. But you’ll still see that thread of conversation.
Lisette: And it sounds like things are pretty transparent in your company. People are going back and forth between chat rooms, and maybe everybody can see the marketing chat if they wanted to or some of the other rooms if they wanted to. So are there any issues with that? To me, it seems like it would be better, but I’m just curious if that’s brought anything up of just too much transparency, things people shouldn’t know.
Mark: Not everything is in the chat rooms, but I’ll say the majority of things. Just about, actually all the engineering team has that kind of transparency. That’s critical for an Agile organization to really have that transparency and let folks know the good with the bad. So that way, as an organization we can look at, okay, what do we need about this? Is it just this team? Does it impact outside the team? Do we need to respond to it quickly? So that kind of transparency is very helpful. If you haven’t come from that kind of organization, it can be a bit uncomfortable. But with an Agile team, we’re used to that. We’re comfortable sharing the good with the bad in those different channels.
Lisette: Interesting. So it’s just a matter of getting used to it, maybe for some people just making the switch into a different team. So then I should ask it sounds like that’s working well – this sharing information, talking with each other. What else works really well on your virtual team? You say your team members are doing it because this is how it’s set up. So they’re distributed by default.
Mark: They’re distributed by, yeah. So it was interesting, with most of the Agile gurus out there, they’ll say teams need to be co-located. I agree, a co-located team is much more effective. But I think what’s unique about the teams I have now is they’ve got that background in open-source software development. So they’re used to being online. They’re used to having those conversations, even debates, in those online forums in multiple ways, so all kind of, keep tabs on the conversations. If I see a debate going on, I’ll encourage them, hey, you might want to get on the phone. You might want to have a higher bandwidth connection to resolve this. Rather go back and forth multiple times in an electronic board. But I think because of that open-source background, they’re very comfortable moving from that synchronous to kind of asynchronous, online to live conversations.
Lisette: Right. So the communication is rather smooth. I’ve heard this before that with the open-source background, this is how people are used to communicating or they have to. With the team members, what’s in it for the team? I assume that they’re working on a project that they really enjoy, that this is not just a job for most people.
Mark: Right, they really enjoy the work. I think for many of us, it’s being able to make a difference in some of the not so pleasant things of online life. I mean there are all kinds of security threats, hackers, and part of our work is to really defend against that. That’s primarily what one of our tools does, is to help prevent some of those issues. As an example, a lot of our customers knew about heart bleed before heart bleed was public. I’ll put it that way.
Lisette: Okay.
Mark: I think that’s important. But another key element is what I like to call… It’s not work-life balance but more work-life blend. So because we work out of our houses, people are comfortable having things in the background happen there. So nobody is upset if somebody’s kid pops up in the background and says hi or a family member walks past because we know the context of where we’re working. But also, everyone on the team is very good about checking in and checking out. So you’ll see messages throughout the day, hey, I’ll be out for three hours. I’ve got to take the car for maintenance. I’ll be back on tonight to make up the time. And nobody worries about checking on it because we’ll see activity in GitHub, in other systems. You can see they were online, they were working.
Lisette: So then you have gone to a more results-based. You’re seeing what the results actually are rather than are they working between 8:00am and 5:00pm.
Mark: Yeah. So we have some core hours for meetings, but other than that, there could be people that start work at 6:00am East Coast time and you might have work going on until 8 or 9 o’clock West Coast time just depending on who is up and plugged in and working.
Lisette: Okay. So it sounds like things go pretty smoothly. What do you struggle with?
Mark: All is not rainbows. There are some challenges. Sometimes communications can get a little challenging, especially around topics… We get some very smart people, and sometimes they have some very strong opinions about what technologies to use, what approach to use. Sometimes those debates can get a little more challenging. And we’re still working through what’s the best way to get through some of those debates. If we had more face-to-face opportunities, I would probably have certain facilitation techniques that I would use. Right now I’m trying to adapt some of those to those situations to help the team through some of that storming as it were.
Lisette: Okay.
Mark: So that’s definitely one area. Sometimes with the multiple communications channels, we still find that not everyone gets the message at the same time. So we have that challenge as well. So it’s not like walking into the team room and saying, hey, this is important because that message might go through on a chat channel that drips away. It might go through an email and not everybody checks their email the same way. So that’s where we have to over-communicate some messages just to make sure that everyone on the team got it.
Lisette: And do you have personality issues in that sense? I’m starting to get echo again. Are you there?
Mark: No I’m not.
Lisette: Interesting. I’m going to unplug the microphone. Give me one second.
Mark: Okay.
Lisette: Okay, how about this? Still getting it. For me this is better. I want to make sure the sound is okay.
Mark: Okay, I’ll get on a headset if you need me.
Lisette: Okay, this one seems good. I’m curious about personality issues. When on a virtual case, it’s important to [technical malfunction. Voice echoing back – [18:37].
Mark: You’re breaking up a little bit. I’ll just let you know.
Lisette: Sorry?
Mark: You’re breaking up just a little bit for me.
Lisette: Oh boy, okay pardon me.
Mark: Let’s switch to headsets.
Lisette: This brings up a good point that having a back up in times when you need it.
Mark: Absolutely. Yeah, so as part of that online life you always have to have a backup system.
Lisette: Yeah, case in point actually. Before the call, you told me about a facilitation technique you use for your virtual meeting, for your virtual attendance, which is having a remote buddy. So not only having a software but also having a remote buddy. I love it.
Mark: So I refer to it as The Buddy System because most people are familiar with that. Whether you’ve been in scouts or elementary school, there’s always that introduction of a buddy system. We do the same thing for mixed facilitation meetings. So if I’m with a group of people co-located and we have some remote folks, I’ll ask members of the team there in the room who can be a buddy to one of the remote people so that they have somebody directly they can reach out to. So that takes some of the load off the facilitator, and at the same time, there are always two people looking out for that remote person: the overall facilitator and their buddy. So it’s part of that. I ask the buddy to make sure they have a direct chat channel to that person so that if anything happens, the remote person can send him a note and say, hey, I can’t break in and the audio channel or the call dropped. I’ll be right back on. Or I’ve got a question. Can you ask it for me?
Lisette: Okay, that makes sense. I really like that [inaudible – 00:20:48]. So we’ve talked a bit about the benefits for your team and we’ve talked a bit about the challenges and some of the tools. I’d like to go more into the personality aspect and also the productivity aspect of it. So let’s talk about productivity. You said that you have ways of knowing whether people are working because they’re checking in code. It sounds like we’re having more sound issues. Is that true?
Mark: No, it’s just my headset. It’s not working. If we’re still having issues, I can switch to ear buds.
Lisette: So productivity: how do you know people are working? You’re saying they’re checking in code, but is all code-based? Or are there other things that you use as well?
Mark: There’s code, there’s documentation. The automated test are also coding. It’s not some of the writing of test plans as this test code. With the different requirements, what we call Agile user stories, it’s using multiple team members working together, usually two or three people working on a story. So those two or three people know when one’s falling behind and might need some help. So the teams really bid about checking in with each other in the situations. So if somebody is stuck on a task for a while in our daily stand-up calls, somebody will ask, hey, is there something you need? Do you need somebody else jump in and help you? So we always get a sense day-to-day is everyone moving forward because we’re working even smaller sub-teams to get those stories done.
Lisette: I know a lot of people say that Agile and virtual working can’t really work together. But it seems to me that Agile is the primary model for how virtual work should be done, this task-based, short sprint cycles, checking in often, over-communicating, really having well-defined work, doing retrospectives in lessons learned. It all just sounds like virtual teams have to work Agile or it wouldn’t work.
Mark: Well, yes and no. In 2001 when the Agile manifesto came out, the technology wasn’t quite there yet. Now, with high-speed network connections, it’s easy to upload videos – whether it’s Skype or Google Hangout. I think it’s a lot easier for distributed teams to collaborate now. And the important part is a lot of the same techniques for collaboration, I believe, translate into the virtual. So the principles are the same. Just some of the techniques might need to be a little bit different. So those are some things I’ve been collecting. I’m going to start blogging on that soon both on the Sonatype blog site and my own blog site, just to start sharing things like The Buddy System. The Buddy System is completely technology independent. It’s just saying, hey, can you help out? And you make sure this person with us in the meeting is really all we’re dealing.
Lisette: Just another nugget that stand out.
Mark: Yeah. There are quite a few. I’m looking up on my bookshelf here. I think it’s further up, so I’m not going to reach way up and get that. But the book Agile Retrospectives by Diana Larsen and Esther Derby, that book has several activities that in a sense require face-to-face interaction. But as I started looking at the exercises, I started coming up with ways for distributed teams to use these techniques. I think I shared with you before some of that wiki page where we had captured how to do distributed retrospectives. A few head coaches got together at the Agile 2014 conference. We shared some notes on some different things people had tried. And actually, many of those exercises out of that book can be done in a distributed setting where everyone is collaboratively working through what they see over a two-week iteration or a longer release cycle. What insights do they get out of that? And what decisions do they want to make as far as what kind of improvement moving forward? Because the Agile team is always looking to improve their process. They’re not waiting to be on the project. They’re taking a break essentially every two weeks, spending about an hour or two after every two weeks to look at how’s the process working course. And what do we want to change to make better for us and for our customers?
Lisette: So what do you think the resistance is to working in this way? I mean let’s start with Agile before we even go to the virtual teams because it just sounds like this seems so clearly the right way to work. Why is there a resistance?
Mark: The resistance, I think primarily was because the technology wasn’t there at all the last few years. Another is people value the face-to-face connections. So I’m not sure how it is there in Europe, but here in U.S., there have been many co-working sites that have popped up, and a lot of that is from remote workers that are really seeking at making connections. For me, as you mentioned before, it’s the Lean Coffee. So getting together every week or so with other people to share ideas and how they’re working or through some of the things we did at Agile Orlando with some of the evening presentations we have, working with speakers or just getting together with other remote workers and say, hey, how are you doing this in an Agile context? So there’s still a need for human contact. I think that’s where all the resistance is too. If you’re used to being face-to-face, there is an adjustment period to being an all-virtual organization. I’ve gotten to know my co-workers. I know their interest. I know that who plays Mario Kart. I know who grows hot peppers. I know who has kids and who has cats. So we still have those connections and we’ll joke around. For instance, another one of my techniques is we have a pretty efficient daily stand-up on our teams. They usually run anywhere from five to maybe eight minutes. And that’s for one team, that’s about five people, and another one that’s eight people. So we have pretty quick scrums. But I always encourage people that you jump a little bit early or hang out afterwards. And so the ones that jump early, we socialize a little bit, how are things there? How is the weather? That kind of thing. And afterwards, we’ll do two different things. During the scrum, anyone can say along with here’s what I’m working on. Here’s what’s next. Here’s what’s blocking me. Another thing they can add is, hey, I have a post-scrum topic. And they might say I need the whole team or certain people. And so after everyone kind of makes their rounds on what they’re working on, we sit around for post-scrum and that person can go through their topics and say hey, I’m struggling with this issue. Who can help out? And so that’s the opportunity for the team to live, kind of help that person to work through whatever issue it is they’re dealing with. And we also socialize a little bit with them too.
Lisette: So it sounds like one of the real struggles in teams – and I do hear this a lot – is how do we humanize the virtual experience. You’re right. In Europe, it’s exactly the same. There are co-working spaces popping up all over the place. Clearly the need for in-contact, being with humans is important. Otherwise, people wouldn’t go to a coffee shop to get work done. They’re there because they need the people to be around. So it sounds like then the challenge is then humanizing the office and having these informal conversations. It’s very useful. And I’ve heard one person actually say that sometimes the virtual experience can be more human because we’re seeing so much of somebody’s personal life behind them on the screen.
Mark: You’re seeing my life behind me right now.
Lisette: Exactly. So I could probably guess that somebody is a fan of Mickey Mouse and there are a lot of books. You can infer a lot of information.
Mark: And I think it’s important too. And that’s why I was talking about that work-life blend. So it’s not shutting all that off. It’s really letting people see, hey, this is part of my life also. And I think that’s important to share in virtual teams. So it’s mostly the socialization, working a little bit more as well as the background also kind of be there a little bit more.
Lisette: And has that ever been a problem? This extra personalization, has that ever come back to bite you or anybody on your team? Just out of curiosity.
Mark: I would say for those who work in a distributed environment, they’re used to that kind of blending. And it’s my experience that most of them actually like that blending because they like to know about their co-workers. They like to know who the person is. It’s not that they’re just some kind of robots sitting in front of the screen. We really want to know who’s at the other end of that line. The ones that they are not basically… Well, let’s say all business. But just to try to keep that work-life separation. Those ones I find that struggle with distributed teams or the hybrid distributed teams and are very bothered by all the noise in the background. So that’s a problem. Also, I think it’s important that on the life side of the work-life blend, it’s letting family members and others know, hey, for a certain kind of calls I do need a little quiet time. But my wife and I have an agreement note that if the door is closed, that means the other person really shouldn’t come bursting in there. With kids, it’s a little different.
Lisette: Right. So have you ever had somebody on your team that’s just not cut out for… or the remote working, they just can’t do it?
Mark: On the current team, no. On past teams, yes. If they’re not used to going to networking events like local user groups or co-working, the isolation can really get to you at times. I wouldn’t be surprised if some of them got into a state of depression. I’ve seen people quietly faded away. They show up for the calls and then they will just eventually drop and might quit and might join another team or something like that. But I find the ones that are willing to share a little bit of the personal side of themselves and really make an effort to get to know their team members, it helps. And it doesn’t mean introverts fail. I am TJ, so I’ve got a strong introverted side, but I do enjoy connecting with people on a one-on-one basis. That’s another reason I like virtual.
Lisette: Right. It’s not so overwhelming and completely overstimulating to be in interaction with people. And you can turn it off when you’re in your own. I’m also the same. I’m a highly sensitive person. I’m extroverted but I’m highly sensitive. So the interaction is overstimulating for me sometimes, and I find that working in this virtual setting can really help that aspect of my personality. So I’m assuming that this must be the case for others as well. Software developers are stereotypically introverted. So it seems to lend this lifestyle, lends itself stereotypically. There are all kinds of loopholes in personality types and every stereotype.
Mark: With many software developers, it requires a lot of deep concentration. And there are times when you’ve got to be heads down. You’ve got to have your blinders on, maybe your headphones on, your favorite music, and just go on a way at it. And that’s cool but with those in the team they’ve got to realize they’ve got to cope with error, they’ve got to reconnect. I’ll say that the folks I have right now, they’re awesome at that. They’re really great about not only coming up for error but listening for their team members to see when team members might need help.
Lisette: I guess I have two more topics on my list. Then jump in if there were any questions that I haven’t asked you that you would like to have been asked or something that you’re dying to tell. But my last two topics are on building trust in the team members, because I think that’s important. That’s a baseline in a virtual team. And the other one is just curious about cultural differences on your team. So those are two pretty different questions but I’ll just put them out there. Maybe we’ll start with the trust question, if there are issues in building trust? What do you think what really works for building trust on a team?
Mark: My friend Christopher Avery has a great approach. He talks about trusting just right. It’s really about making those small trust deposits to the rest of the team. So on an Agile team, it’s about making commitments on a daily basis, and that’s what part of that stand-up is. So while the team has user stories they’re working on, individual team members are saying hey, I’m going to take on this task. I think I can get it done tomorrow. There is the commitment. We get to tomorrow, hey, I had some issues, but I think I can get this done, and then making sure you meet that commitment. So it’s 1 – keeping to visibility, again, on what each other is doing, what commitments they’re making to the rest of the team, and also letting the team know, hey, I’m having problems with the commitment. Here’s how I’m going to reconnect, or reaching out for help. So I think all those elements is key, whether it’s virtual or co-located team. It’s just keeping those commitments visible and keeping people informed on here’s how I’m helping the rest of the team.
Lisette: So there’s being visible, of course, working out loud with your work, making sure that everybody knows what’s going on, and then also being reliable – following through on what you say you’re going to do.
Mark: Absolutely.
Lisette: And those two things, I think you’re right. Sorry, I interrupted. I didn’t hear the last thing you said.
Mark: I say it’s making those daily deposits into the trust account.
Lisette: I like that analogy, the daily deposits, because it is all the little things. It’s not just one thing where you walk into the office one day and everybody trusts you. It’s a hundred things that came up until that point, until that day. It’s the littlest did you do what you said you were going to do.
Mark: Right. So you can make a hundred deposits throughout the week, but if you blow it on something big, then people will start to question you and you’re starting over again and you’re having to re-deposit.
Lisette: Right. It can take six months to build up and just a day to lose all your hard-earned deposits.
Mark: Yeah. I think trust is like the stock market will be a sturdy analogy.
Lisette: Right, run away! And are all of your team members in the U.S.? Are you working across time zones?
Mark: Right now we have three Agile teams, a fourth team that’s shifting to Agile. On one team we have team members from Cologne, Germany to Austin, Texas. So that’s several time zones there. Another team going from U.S. Canadian East Coast to the West Coast. And then a third team going from Eastern Europe all the way to the West Coast.
Lisette: Okay, that’s starting to get pretty far there. We’re starting to get like 11 hours difference, 10 hours difference.
Mark: Right. And then another team is a little more closer. It’s two to three time zones. So we try to keep them close together. But due to some of the expertise of some of the team members, we have one team that is separated out quite a bit, but they have some unique skills on one product.
Lisette: I haven’t heard anybody say that time zones are no issue for me. So I’m assuming time zones are also an issue for the team. Is it just a matter of dealing with them? Do you have any special tips for that?
Mark: Well, that’s where that work-life blend comes in. So we do have some core hours that we specify for, hey, these hours we will typically schedule meetings and we try to be pretty stringent on that not to schedule outside that time. As I said before, our team members are very good about checking in and out. Like I said, I’ll look at HipChat and the fellow in Germany sometimes seem at the end at 6:00am East Coast time. And I see him work and work and then right after one of the scrum, he’ll say, okay, out for three hours. He’s off to play volleyball. Then he’ll check in as soon as he’s back. He says, okay, I’m back online. So having that flexibility and everyone pays attention to these core hours. The time zone difference really doesn’t make that big of a difference. As a matter of fact, with two of our teams, they work on the same product. The team boundaries are actually very flexible. So they’ll review each other’s work. They’ll help each other out. So it’s not just the members of this team. So the time zone overlap is even less of an issue because there are others who are familiar with the code, familiar with the work, that can help you out at different times of the day.
Lisette: So if you get it right, you can really have 24/7 operation in some sense. I mean where one thing leads to another thing.
Mark: Yeah. We’re not really trying to do the follow the sun kind of approach that some companies had done. Our culture within our engineering group is very flexible about letting people maintain that work-life blend. That’s one of the reasons why people sign on, is because they value that.
Lisette: Right. It sounds like you’ve done it right. I’ve worked in a company that did something similar. Everybody kept their Skype status accurate. So we didn’t use HipChat but we used Skype. It was a very small company. But everybody knew where each other were at all times. It was simply in the Skype status and you need to check there if you needed somebody. And it worked. It totally worked.
Mark: You knew when to get a hold of them.
Lisette: So you’ve got talent all over the world. How do you find them?
Mark: Right now we’re a fairly small company. I think engineering, we are probably just over 35-40 in engineering, somewhere in that range. So at that size, a lot of our folks have been pulled in through connections, through networking. So people we know, people they’ve worked with on other open-source projects or previous jobs, so there’s a lot of that connection. But we’re getting to the size now that it’s extended beyond that. So in the previous recruiting, through networking, there has always been some sort of prior relationship. So there’s always been pre-established trust, I’ll put it that way. Now we’re getting to a point where we’re getting new people in that maybe we haven’t worked with before. So as part of that, all we’ve been doing is making sure more of the team gets to interview the new person in and are any red flags. So basically, if there are a couple of thumbs down, then we don’t proceed with that candidate. So we use that same collaborative approach in our interviewing process.
Lisette: It really strikes me as you say that in the beginning, people are bringing in their friends and people that they’re worked with before. And I think that must be an incredibly powerful way to build the team. You know these people are ready. You’ve worked with them before. You know and like them. You probably know a lot about them. And if you just bring in your favorite people, then it’s got to be magic in some sense or it can be.
Mark: And you know that they do good work, so you know great things are going to happen, and it does.
Lisette: Right. So then it starts getting scary. I’ll be curious about your journey now that the company is growing and you’re hiring outside of this network. I’d be really curious to check in with you and ask about what’s been the difference in the team members. And does it matter? If everybody is interviewing and you’re sure about this person, then maybe it goes really well. But once you start hiring outside the network, then what are the differences? That would be a curious thing to explore.
Mark: We’re doing some slow-grow. So we might hire two, three people a quarter at most. So we’re not having any tremendous growth right now. Certainly we see as a new person gets added onto the team, we go back to that forming, storming, norming process again. And then the team does go back to performing. So I can track the team’s progress over time. Tools like JIRA… You can see the ups and downs of how the team performs. And I can usually tell. I can look at it and say, oh yeah, that was the time everybody was out on summer vacation, or this is when so and so joined and they were trying to help that person get up to speed. So you can see that in some of the trends of how the team has been working.
Lisette: Super interesting. I mean I’m an analytics nut, so I’d love to be able to map those trends and just see… You get some idea of what you can expect. That’s what I like about Scrum, that there’s a velocity, that there’s a realistic velocity of what people can do because I’m thinking I really need to do it myself. I look at my task list and I think there is just no possible way that that’s all going to happen this week, yet I still keep it on my desk with the hope that maybe I’ll be uber-productive [laughs].
Mark: That’s where you’ve got to take off just the stuff you know you’re absolutely going to get done.
Lisette: Right, great. I think those are all the questions. I mean I can go on and on. But I realize that we’re going to the top of the hour now and I know you have other meetings today. But one last question is if people want to learn more about what you do and know more about who you are, what’s the best way to contact you?
Mark: As I mentioned, I’ll be blogging more on some of these virtual techniques, especially the facilitation side. So they can go to markkilby.com or they can go to Sonatype and the Sonatype blog will have some posts more about how we work as an Agile team at Sonatype as well.
Lisette: Oh great. So people can get the first-hand stories of what you guys are doing and experimenting with. Very valuable, I’d love to put that in the liner notes for this interview, for sure. Great, thank you so much, Mark. I learned a number of new things today. I’m really looking forward to writing this up and really digging in. If I have follow-up questions, I’ll definitely be sure to contact you.
Mark: Absolutely.
Lisette: So thanks so much. And for everybody listening, thank you again for sitting through on another Hangout on Air with remote interviews. Until next time, be powerful.
