PETER HILTON is a consultant at Signavio, working remotely from Rotterdam, the Netherlands. He works on teams that have to determine how they are going to work together. Sometimes that’s remote and sometimes that’s in the office together – it depends on the day.
Subscribe to the Collaboration Superpowers Podcast on iTunes or Stitcher!
His tips for working remotely:
- Work out loud and eliminate status reports/meetings.
- Stick to the facts online and save the complicated emotional stuff for a higher bandwidth channel like video or face-to-face.
- Spend a few days working together in the same room.
- Encourage and ask lots of questions.
- Learn to type faster (a lot of remote communication is done through typing).
- Don’t send messages faster than you receive.
- Experiment and improve continuously.
- Test your assumptions.
Podcast production by Podcast Monster
Graphic design by Alfred Boland
Original transcript
Lisette: My name is Lisette Sutherland and I’m researching people and businesses who collaborate remotely. Today, I’m interviewing Peter Hilton, a solution architect, application developer, and technical manager with some great remote working stories. If you have questions at all during this Hangout, feel free to ask them through the Q&A on Google+ or you can tweet to #remoteinterview on Twitter. Just use the #remoteinterview and we’ll get to that. So Peter, welcome! Thanks for letting me interview you.
Peter: Hi there! No problem.
Lisette: Why don’t we start with an introduction about who you are and a bit about your background so that people can understand the context of this conversation?
Peter: Okay. So I’m a software developer and my whole career, I’ve been a programmer. I’ve got into lots of other things including traveling in other countries. And so that sort of inevitably got me involved in collaborating with people who are also in other countries, not just the ones I left. So I traveled around a lot. I worked with people who were in the same room but also another continent. And without really thinking or planning to get into this, I mean just the act of being a sort of commercial software developer these days inevitably involves various kinds of remote working and collaboration online. And just to add something to that, so now, I’m in Rotterdam which is not where I started. I’m from the UK, but I’ve been here for many years. It’s country #6 but that kind of travel stopped. I mentioned I’m a programmer but I do other stuff as well so I manage teams here but also I get involved in other projects like Play [inaudible 1:42] book which in itself is a remote collaboration because that’s an American Publisher who I’ve never met.
Lisette: That’s true. That’s also forum.
Peter: Yeah. So software developer also for development is also a broad topic. I mean it’s a broad activity. It’s not just one thing. And so mostly what I’m about is just lots of variety, what I have been doing for many years.
Lisette: Okay. And you currently work for a company called Lunatech in Rotterdam, right?
Peter: That’s right so Lunatech’s quite a small company. We’re less than 20 people based in Rotterdam but we’ve always worked with companies in different cities and countries. So we’re currently working with a customer in Northern France. I previously worked for companies in the UK and the United States. And so what’s really obvious for a small company like us is that most people are outside the building. Perhaps this is less obvious if you work somewhere like IBM but even then, it’s true that most people are outside the building as it were, not your colleagues, not in the same country, and work with you if you work with most people in the world, then that’s going to be about some kind of remote collaboration.
Lisette: That’s true so most of the people that work at Lunatech then are also working colocated, I’m assuming, or is there a branch of remote as well?
Peter: It depends on the day of the week so in any given day, most people are somewhere else but they’ll probably here at some point this week. So I’m in the office now and it’s quite today. There are probably half a dozen people here at some point today. Tomorrow, it’s going to be busy because Friday is the day that people hang out together face to face. The people who are working on customer location 4 days a week tend to pick Friday well sometimes Wednesday as their office so we can also get together face to face and do the whiteboard thing or the beer in the kitchen thing.
Lisette: Okay.
Peter: I would just sort of combine things so whatever we do, that’s not the only thing they do. There’s variety in a week as well as our customer in other locations.
Lisette: So then all of the employees at Lunatech it’s up to them if they want to come in and work in the office or work at home. Somehow, it’s coordinated amongst the employees themselves.
Peter: It varies. I wouldn’t quite say it’s just up to the individual because everybody’s part of the team so it’s really up to the team. And for one project or one customer, that’s going to have different requirements or just not work so we do have some projects and customers where really the only viable option is we go and sit in the customer’s office.
Lisette: Right.
Peter: Some projects, we are not in the same country so it doesn’t matter where we are and they’re here.
Lisette: Okay.
Peter: Sometimes people will work from home. People don’t usually work from home structurally or for long term but that’s happened in the past. So where someone needs to be usually depends on where the rest of the team is on that particular day. And any location might be the best location most of the time but never all the time so wherever’s the best location, you still need to go either to visit the customer, or to hang out in the office or spend the occasion there at home.
Lisette: And how do you know when people are doing their work or not doing their work? What is it that you see as a company? I’m assuming you have great employees.
Peter: Yeah, yeah. This is sort of a very immediate question for lots of people.
Lisette: Of course.
Peter: You don’t know. If we have to know minute by minute what somebody is working on, then you’re doing it wrong. The way you know is that you see results, you see deliverables, you see work produced. I mean you see value delivered. There’s lots of different ways of saying it but if people are being productive then you will see something for that.
Lisette: Okay. You’ve given me a list of stories actually, interesting stories that involve remote working so maybe let’s go through some of these stories and talk about them a little bit depth and the one that I want to start with is the story where you successfully trained your client to instead of having a weekly status meetings that they are now able to log into, I think JIRA you said.
Peter: Yeah.
Lisette: And see the status themselves so you’re saying time from meetings. How did you do that? I think most people want to know how you trained your client.
Peter: Yeah. Look on the bright side. I mean herding customers is easier than herding programmers. This was actually the first project that I worked on way back in 2005. And it was an old school customer. It was Ernst & Young Tax Advisers in the Netherlands. They’re sort of a traditional organization but traditional [inaudible 06:23] are not necessarily in the work our doing but they were quite innovative in that project. And so this was a project to develop a new product. And for me as a software developer, it seemed almost like a contradiction that here we have this very traditional-looking organization trying to do something new and so that sort of encouraged us. And maybe that’s what made us bold. And anyway, as a programmer, I wasn’t thinking things through that much. I just didn’t want to sit in so many meetings. So for me, it was all driven by the idea that if I’m in a meeting, I’m not doing useful work which for me was even more so back then, writing code. So the point at the kickoff meeting when the customer said, “Why, I would like weekly status reports, I would like status meetings,” we just sort of instinctively said, “Well, no, surely not. Surely that’s not the best use of everybody’s time.” And that was the same time that we just started using JIRA. Now, at that time, I’ve been working in a project organization for years doing software development where work was organized around what you might call units of work or work packages with is the software development task, fix a bug, spend half a day adding a feature, this kind of thing. And so when I first started using JIRA, this was obviously the solution to so much that was wrong in collaboration. And in particular, the big shock to our customer was how we explained why we didn’t need to send them status reports and why we didn’t need to have meetings every week just to tell them however it’s going. And the reason was this: we said, “Well, we’ve got this new piece of software and we’ve installed it and you can access it from your office. And if you want to know if we’re done yet, then just look at this one page and this little green bar and we’re going to complete features in the next release. And if there’s a problem or if there’s a conversation, then it’s going to happen here in JIRA. And so you don’t have to travel to our office to have a conversation about the work we’re doing. You can just see that. How many tasks we have finished this week is not a very interesting question. Interesting question is something else. There are exceptions to talk about. There are problems that might come up. But if it’s just to know, “Are we done yet?” then we don’t need to have meetings for that. So the bare facts of status and progress, we have a webpage for that. So we just have to log in.”
Lisette: So I’m curious. I’ve tried to say, “This link has everything you need. You just need to bookmark this link and anytime you need to look at the status, it’s right here.” Now, that seems to be a problem for some people. Just the idea of bookmarking a link, that’s not normal so I’m kind of wondering for an old school Ernst & Young environment, how did you get them to do it?
Peter: Well, maybe they were in practice the easy group of people because I think that they just got it. What was it that made it easy was that there was [inaudible 9:12] old school organization to hire and IT person on their side to be the application manager of the application we are building who fielded a lot of the contact. So for example, after we decided releasing test versions when we were doing testing and they’re reporting bugs they found or they’re sort of creating feature requests, they’ve got a single point of contact. They’ve got an IT person who’s organizing all of that problem for them so from our point of view, we really had to persuade this one person how much easier it’s going to be.
Lisette: I see. So they were the touch point and they would log in naturally because they are more IT oriented.
Peter: Yeah.
Lisette: And then communicate back to whoever they need to communicate back to.
Peter: Yeah. Exactly, exactly. And also, we pretty [inaudible 9:57] about it. Maybe not even without realizing that this might have been less helpful but we just got a way of saying, “Just don’t send email.” Every time they send an email, we have a reply in JIRA. We just not respond that way, gradually say that, “Well, go to the webpage. Reply an email with a link to a JIRA issue.” And maybe this would have sort of damaged the social relationship but we met up enough face to face anyway for that not to be a problem. So we didn’t meet once a week but once every let’s say couple of weeks every few weeks. We have difficult functionality issues to discuss.
Lisette: Right.
Peter: And we met for slightly more social things occasionally during the project. And so we got used to the idea of what we were like and they probably thought we were weird socially in that programmers, they insist on using this web tool but it did really work for us. And of course that thing that really works for this kind of tool is that it has context because the wrong kind of email is like the colleague who walks into my room halfway through a sentence as he walks through the door and I’ve had to learn to sort of stop him and say, and in fact more than one of these colleagues, right, so I’m not just talking about one person, I had to stop and say, “Stop! What are we talking about?”
Lisette: Right.
Peter: What is the context? And then the email, you have to write a subject line. You have to say, “Well, I’m writing about this.” And if you’re adding a comment to a webpage collaboration tool such as JIRA where in JIRA, JIRA has an issue that we’re looking at. It’s the particular bug report. The comment is in that context. It’s on the end of a conversation thread. It’s on a webpage whose title is the subject line. You don’t have to write the subject line every time.
Lisette: Right.
Peter: And so you can’t write a one-word email. Nobody’s going to be able to know what you’re talking about especially if there’s no subject line. That would just be weird. But you can reasonably add a one-word comment to a JIRA issue. I mean you can click “add comment” and type “Yes.”
Lisette: Well I’m assuming what you’re basically saying is you’ve got the institutional knowledge of everything around this subject all in one place for anybody to look at so if the programmer gets sick and somebody else needs to take over in the middle of the project, they’ve got the entire history of what was done on this bug right at their fingertips.
Peter: Yes, because the context is not just which is the bug we’re talking about but it’s also what’s the conversation that’s happened so far, who’s worked on this from where and when, and when was this assigned to this person, the whole timeline.
Lisette: Right.
Peter: And so the timeline during a project is very much a thing about start, middle, and end. It’s a whole story. And so these are the sub-stories of the project.
Lisette: Right. And weird things happen during the project. And sometimes, I mean looking back, it doesn’t make any sense but if you know the story..,
Peter: Right, absolutely. And so we see people trying to do the same things with email and this is just obviously silly. That’s the positive way of looking at it. It’s sort of painfully and heart-destroyedly tempting most of the time. Just last week, I’m experiencing a different organization who’s sort of developing a long email flared with a dozen people on the CC list. And the email thread goes back for 20 messages over the course of 10 days. And then I get an email which is another reply all which is adding somebody to the CC list and the reply all says the message is adding so and so to the stream using a reply all as the thing. And this is very [inaudible 13:39]. This doesn’t work very well.
Lisette: Right.
Peter: There are all sorts of things that are a missed opportunity there. And so going back to the question you asked just now which was “How did we train the customer to use this?” It’s very much the [inaudible 13:53] and the stick which is the combination of the stubbornness of “We’re weird, we’re programmers, we expect the programmers to be weird. We use this tool. I hope you can live with that” but also the carat of look how much nicer this is than to write these long emails or having to have all these boring meetings just to have someone experience. So there are many things that if you like it, if someone says to me, “Why should I do this thing that you do that you say is good?” This is a great example of explaining doesn’t really achieve nearly as much saying like “Can you trust me for a week and try it out because a week’s experience with this will be far more explanatory than anything I could say today. Give me a week. Let’s try it.” So the experience is the training. We got them to try it then it sold itself.
Lisette: Right because it’s clearly the way to do work. I’m sorry. I’m showing my bias here.
Peter: Well in this case, so this is a very specific example of using a sort of webpage collaboration tool where people are not familiar with that but very quickly bought into it just very quickly. They said, “Well this is how it’s going to work on this project.” And so what it was really great was when we met up instead of going for a list of 30 development tasks, and “Is it done? Is it not done? Is it halfway through?” all that kind of stuff. We say, “Okay, as you can see on the roadmap, there are 30 tasks are in progress and you can see how many are done by looking at the webpage. But today, let’s talk about the two that turn out to be a problem.” And so when you have a meeting, you talk about just the two.
Lisette: Right, because everything else is fine, nothing to worry about. We’re as expected.
Peter: Yeah, you don’t need to have a conversation about that and so this is the thing that is perhaps in some of my experience is difficult for people to get used to is that some information, some status of information, or some of the information that you exchange when collaborating is boring. And the boring information does not deserve face-to-face bandwidth. Boring information does not deserve grabbing people and making them be in even a video chat. It could just be done asynchronously offline in a very sort of low key kind of way. You don’t need to spend so much time on that. The [inaudible 16:14] ask questions. If you understand the question, you just say no or yes.
Lisette: Right.
Peter: There’s no discussion.
Lisette: And do you ever need to use somebody else’s collaboration tool or do you try to get all of your clients to use JIRA or any other collaboration tool you might use?
Peter: Both as in yes we have to use their tools and yes make them use our tools but we change our minds. So for example, our two biggest customers who we’ve been working with for more than a decade now because we introduce it to them both have their own installations of JIRA and the conference, the Wiki which is great except for our own projects, the new projects, [inaudible 16:52], we don’t use JIRA anymore because now we’ve sort of moved on to newer, cooler, shinier tools. And so we’re still using the old stuff that we gave to our customers. So we have these huge diversity of tools that we’re using on a daily basis. There’s this great kind of discussion argument internally at the moment about chat room talks, group chat because as a group, as a team, we don’t all agree on one tool to use. Any tool we care to mention has a few people who will not use it, refuse, and so the status quo at the moment is now have 4 chat rooms, 4 chat room tools, not just 4 rooms but 4 completely separate software that I’m using for group chat plus various other collaboration tools. And this is maybe inconvenient. This might be a challenge that it’s just messy but this is so much better than just having any one of the tools than just the one tool.
Lisette: I was going to say, it seems that in my case, having a number of collaboration tools keeps me kind of up-to-date with how things are going in the world of collaboration tools and always keeps me fresh in questioning instead of just using one tool and relying on that. So that’s the bonus. The other side is I have logins to about 20 different tools that I use on a regular basis. But I suppose there’s an upside and a downside to letting the programmers choose or the employees choose which tools work for them and letting them work that out as long as there’s access for everybody, I guess. What will be the downsides?
Peter: Well, we have the historically [inaudible 18:26] maybe has some missing features. A fact, just one person. So for us, the chat room that’s been around since the dawn of time is the IRC channel. I mean this is ancient technology. Still works, you know, still busy today. And this is fine except if in a certain customer location that firewall will block it and you’re not there. You’re not in the room. You feel lonely. And so then you create a Skype chat, a Sky group chat because that works through the firewall. And there’s there and then till we start working with different customer and for some reason, then, they can’t get the Skype to work or they are not allows to use it so we start using a different web-based chat. So what happens is the tool that everybody would rather use and then there’s the compromise. So the tool everybody wants to use is ideally, where everybody can be happy and everybody can use that tool but we are going to need some compromise because group chat is only as effective at how many people are in the room. And there’s a splitting the community or splitting the team in two. That’s not good.
Lisette: Right. Well what are the arguments at Lunatech that you’re working on right now with the team?
Peter: I don’t think I can think of any good reasons for not using any other tool. So apart from the things it simply doesn’t work. The person I need to be in the room, my customer, cannot use this tools, they’re not allowed to install it or doesn’t work for the firewall. Other than that, it’s all personal preference and habit but personal preference and habit are very powerful, most [inaudible 20:01] especially for certain kind of programmer whose a bit stuck in his ways. So I don’t actually understand why somebody will hold on to the tool they’ve always used. I do understand why a certain tool just doesn’t work for somebody so they can’t use it. So yeah, the discussion’s actually stalled at the moment.
Lisette: Okay.
Peter: And the only people who’ve been stubborn about it is not in all of the [inaudible 20:27].
Lisette: So they miss out on some level but people know that they’re missing out somehow it works, it sounds like.
Peter: Yeah, yeah, yeah. I mean it does work. And because there are multiple channels, then people hear things they’re okay eventually anyway. I mean multiple channels are important you know. If it was only the type room, that will be important but we also have a room in the building with a more important piece of hardware which is the kitchen which has a fridge which contains beer. And people do drink beer and they do it together. And then they talk to each other and say they know their network and there’s a pool table which has a sort of similar function and a coffee machine which again creates this sort of situation where people will talk to each other. So these are also important parts of that kind of collaboration.
Lisette: Well actually, oh sorry, go ahead.
Peter: Well I was just going to say but these things on Friday when everybody’s in the office.
Lisette: Right. Of course, you have to be around the water cooler. But actually, what brings us to the second point, one of the second stories that you talked about which you said a success factor for online collaboration is to have spent an intense period of a few days working together in the same room at some point.
Peter: Yeah.
Lisette: So it sounds like you believe pretty strongly in that.
Peter: Yeah. And it doesn’t need to be every week. But if it’s never happen, then that makes it harder.
Lisette: It’s not impossible. We all know it’s not impossible.
Peter: I know so certainly you can do it. I’ve started doing some remote application support for a customer in France just last week and there have been a couple of people I’ve been interacting with in the group chat who I’ve never even met or even spoken on the telephone. And I don’t know them. I don’t know who they are. I don’t know what they’re background is and so who I can do at a group chat or a little bit quicker if I do video chat and we talk or use the telephone is work out how to talk to them. Should I talk about technical subject? Should I stay away from technical subject? Should I go into detail if they want to know [inaudible 22:25]? Are they going to find my jokes funny or should I stay away from humor because it’s just not going to work? Should I speak French or English? I mean there’s all sorts of communication choices to make. And if you’ve never met in them face-to-face, it just takes a lot longer to work them out. And so what’s missing here is that we just haven’t met. On another project where we have a similar situation, a customer in another country, but we had a project kickoff meeting where we got together in an office and we sort of talked for the project plan but the real purpose of the flights to their country was to spend an evening at a bar or restaurant or whatever and to just spend some time talking. It didn’t even matter what we’re talking about. We just got to know, “Okay, this is how communication works for this person.”
Lisette: Right.
Peter: And then we worked for 6 months. So if it’s just about knowing how you talk to somebody, then one evening is good for 6 months. If you got to have a close working relationship and you need to understand a lot more or you know you got to survive some stressful or emotional moments, then it’s really good to have done it a bit more than that. And so I asked about this for the same people in France. They said, “Yeah, my other colleague, like he knows this guy so well they’ve been working together for 15 years.” True. But in the beginning, they didn’t get on right here until they spend a week together.
Lisette: Wow.
Peter: And then at a certain point, the guy from Rotterdam goes to Paris for a week, they sit next to each other. By the end of the week, they totally understand each other. And not liking somebody or liking somebody is often code for understanding them or not understanding them. Why does someone say that? What makes them tick? What do they care about? And so spending a week sitting next to them or going out at night, whatever it is, whether it’s social, professional, just the constant interaction for a week, then you know how to communicate with that person and then it’s much easier. And so these guys, they work together daily basis but remotely. But they have a meal in a restaurant face-to-face a few times a year. And that’s important to maintain that, to sort of keep up-to-date with “Okay, how do we communicate?” And so the system thing that I think, that’s why I call it success factor is that it’s going to be hard to use the remote collaboration effectively with someone you’ve never met. Having met somebody once for a couple of hours makes the online thing just so much easier because you can remember, “Okay, yeah, it looks funny over Skype but this is what’s really going on here.”
Lisette: Right, right or “Oh, they really do like the color purple a lot” or “Their favorite beer is this or…”
Peter: Yeah. And it probably means just how you interpret their body language.
Lisette: Right.
Peter: If somebody never smiles, then that’s good to know.
Lisette: Right it could just be, I actually have a friend who doesn’t smile very much and I always thought always having a very bad time with me but then I wondered, “But why do we still keep hanging out?” but it was really just some sort of thing where he didn’t smile very much. But once I learned that, I thought, “Great. He just doesn’t smile very much but I know he’s always having a good time because otherwise, he would leave.”
Peter: Yeah, so these are the things that during remote collaboration there is you fixed them.
Lisette: Right.
Peter: And there’s the easy way and the hard way.
Lisette: Right.
Peter: Because it’s only an easy way if you can actually somehow get to meet face-to-face.
Lisette: Right. So it’s ideal if you can meet face-to-face. It’s not critical. It can be worked through.
Peter: It’s a shortcut, yeah. It’s a shortcut.
Lisette: Yes.
Peter: I mean for me, a good analogy is technical training. If you’re a programmer, you can teach others, you can learn anything yourself. You can self-learn anything. The whole point of paying good money to attend a classroom training course is to just do it quicker. That’s the only difference. And for me, this is a similar thing. The value of the plane ticket is just to accelerate something that would happen just fine by itself but would take longer.
Lisette: Ahh, that’s a good way of looking at it. That’s a good way of looking at it.
Peter: So if you can only afford one flight in your project, do it on day one even if you don’t have enough things to talk about. Just make sure you’ve met.
Lisette: Right. There’s always something to talk about when people get together.
Peter: Yeah. Right, exactly.
Lisette: There’s should be something that people can talk about, right? It depends but talking about developers here so it could be harder for some than others.
Peter: Yeah.
Lisette: So the other thing that I’m seeing, I looked through the stories that you’ve sent is that the single point of contact with a remote client for instance.
Peter: Yeah.
Lisette: Yeah, that being an issue so if there’s somebody that’s actually formed a very good relationship with remotely and they’re the only ones talking, then that’s actually a danger on the project.
Peter: Yeah, it’s just like any kind of project knowledge or skill. It takes sort of effort to build this up. It takes cost to build this up but at certain point, if you leave it in one person, then your project’s box number is one person. When one person is not available, then suddenly, you have no relationship. If one person is off sick, you have nobody who knows how to do the thing and how to do the work. So there’s sort of a tension here between having one person have the best relationship being the single point of contact but then having a backup for that person or rotating in some way. And so what makes the relationship work so well with people in France is that we have [inaudible 27:59] people one on each side who’ve worked together for 15 years. But they both went on a holiday last week at the same time. And so there’s me in Rotterdam. I’m the backup for the guy here talking to the backup for the guy in Paris and we’ve never communicated in any way before. This is tricky. It takes [inaudible 28:19]. And so this is the cost. And so the smart move is to spread your bets a little bit and we fortunately have met some of the people, Paris guys, back at his desk this week and we’ve met not recently but we went out to dinner six months ago when he came to Rotterdam. So this week’s a lot easier than last week.
Lisette: Right.
Peter: Because I now know who it is I’m dealing with. At least I can understand when he’s telling a joke.
Lisette: Right. So how do you then train your new employees? Are there people that come to you that have never worked remotely as developers anymore? Is that common?
Peter: Yeah. It happens. There tend to be people who just finished university or college and they’ve always lived in the same town. Maybe the even still live at home so they’ve just not done that remote thing. But with programmers, we have this great opportunity that maybe they have worked on an open source project since they were 15 or something. Software development is one of the things where you really can do the real thing as a teenager in your bedroom. This is not true of being a doctor. You can’t practice; whereas you can do the real thing as an open source project member even if you’re not yet at a stage where you are able to be a professional sort of developer. And so this means that increasingly, you do get new joiners who have this experience. So maybe in the past, there’s a difference between people with more experience who have had experience of working remotely or with distributed teams but nowadays, even quite young people have worked from open source projects. And so in software development, open source communities are the original remote collaborators.
Lisette: Right.
Peter: Vast number of small teams who’ve never met is very common. And these are teams who have solved all of the harder problems so it’s a good place to look actually if you’re looking how to solve these problems. I mean the great irony is that these days, someone in their 20s is more likely to have been doing this than someone in their 30s or 40s who actually may be coming from a big company where they did everything the old fashioned way in meeting those.
Lisette: Right.
Peter: And so specifically, what’s nice in the software development world maybe is true in other industries is that there is a particular online community particular tool that we all use and this is GitHub for collaboratively working on code. And so that moment at the start of a job interview where I say, well what’s your GitHub user name. And if someone says, “I don’t have an account,” that would be a bit awful because that would be weird. That’s why it would be awkward.
Lisette: Right.
Peter: In practice, it’s weird if it’s not in the CV they send. That’s like possibly even minus points. And so because of the way that this is so normal in software development to use these kinds of global collaboration tools, most people have experience. They need more experience perhaps especially and that’s [inaudible 31:31] as they’ve just come from school but that’s inevitable to where you work. Any project you work on, you end up using these tools.
Lisette: Oh, sorry.
Peter: I was just going to say even if your project is in the building or your customer is in this town, you’re still going to use these tools because I’ve got some colleagues who are upstairs and so sometimes, I use the chat rooms than walk upstairs.
Lisette: Right.
Peter: Just to ask a quick question. We just use all the tools all the time. And actually, partly, this is because I don’t actually know if the guys is upstairs today [inaudible 32:03]. I don’t need to know. That’s a feature. That’s not a problem.
Lisette: What are the things then that people struggle with?
Peter: People struggle with interacting enough. Programmers are frequently shy. Also, programmers would rather not be bothered with people and interacting with them at all and just want to work some code. So the biggest challenge with a chat room is not getting people to kind of install the tools and join the chat room. It’s getting to actually say things, getting them to actually talk, and specifically, ask questions. And so the thing that I always tell new colleagues especially juniors, especially people who haven’t worked in the industry before is you have to ask a lot of questions. You have to be asking questions in the group, in the chat room. Now, I don’t mind so much whether it’s in the group chat or at the coffee machine but if you’re not doing it in the group chat, you’re probably not doing it in the coffee machine either. And if you’re not asking questions then it’s not really working.
Lisette: And people to overcome their fear. I see this all the time in online communities.
Peter: Yeah.
Lisette: People are afraid and it’s rational.
Peter: Absolutely. It’s very much human nature and so the most important thing obviously I think is to set an example to ask all of the questions including the stupid questions to develop a sort of a culture that you need to be very careful about keeping which is that when people ask questions, that you have the right combination of safe environment where people are not going to experience bad experiences for asking a question but also enough humor that questions that are obviously stupid are dealt with in a kind of humorous way.
Lisette: Sound like a supportive way in some ways whether you’re making fun of somebody. I mean we’ve all been there.
Peter: Yeah, exactly. I mean the worst thing that can happen when you’re asking a question is that nothing happens. And so a question needs a response and it needs to be clear and interacting with people by [inaudible 34:12] and asking questions that has to be a good habit [inaudible 34:16]. So just by doing it, just be redirecting people, and they’re saying, “Well you should have asked me an hour ago because you didn’t need to be stopped for an hour when I could have just told you the answer. You should ask that question to the group not to me individually because actually, I’m not the right person to ask that kind of question,” or “I do know but I was busy for the last few hours and somebody also could have helped you.”
Lisette: Right. Or you need these four perspectives and there’s no way to get it from just me.
Peter: Yeah. So specifically, this means that the tool that I use the least actually and that I’ll be quite happy for nobody to use is instant messaging, the one-on-one version of group chat or the telephone just because it excludes everybody else and doesn’t give everybody the opportunity to join in or help or answer first if they can. And also, the exclusion; you lose the indication that stuff’s happening that things are going on. I mean when you’ve got 5 to 10 programmers in a building in different rooms, in different floors writing code, it’s really quiet, bizarrely quiet. You show people around the building, it’s like “Nobody’s talking.” You whisper. Yeah, they’re probably chatting to each other in the chat room because they’re talking to somebody who’s downstairs and they can’t put people together downstairs. There’s interaction. And one of the nice things about the chat room and the coffee machine and the fridge is that all of these things make noise in a certain kind of way. I mean the coffee machine is literally noisy. Maybe the chat room kind of flashes on the screen or shows [inaudible 35:59]. And this is positive because this shows me that there’s stuff happening that there’s things going on and it reminds me I’m not alone in the building or if I’m working from home, it reminds me that I’m not alone in the team, that there are people around me and that kind of connected us, and stuff’s going on. And it reminds me, “Oh, maybe I should join in.” You know the great thing about the noisy coffee machine is that it reminds you even if only subconsciously that you probably want coffee. And so when you go to the coffee machine, there’s usually somebody there making their coffee.
Lisette: Right.
Peter: Because you only went because you were triggered by the noise of them making their coffee.
Lisette: So it sounds like then these systems, these group chat system, it’s an interesting concept that I’ve been explaining a number of ways which is called working out loud. I probably bring it up in every interview that I do because I find it a very powerful concept which is letting people know what you’re working on all the time somehow. For me, what I do is I keep my Skype status accurate so that people always know where I am, maybe I’ve gone out for a run or a walk but people know when they can expect me and what I’m working on. And I do find that people say, “Oh, I see that you’re working on the book tour. I have a question about the book tour.” And I’m assuming that the same thing happens with these group chats. People are seeing what each other are working on because they’re asking questions.
Peter: Right.
Lisette: And you’re stepping in, you’re saying, “Oh, you shouldn’t even be asking this question. Ted’s been working on this project for 3 years. Just go to him. He’ll finish it for you.”
Peter: Yeah, absolutely. And so this happens quite a lot. It’s important to know if people are working on so you can help out whatever and to stop because they shouldn’t be doing it. That’s the function actually of a lot of the messages on the chat that I announce for example that sometimes, this can be quite explicit. “Oh, I’ve just started working on this and I’m probably going to get stuck.” I’m not asking for help yet. I’m just sort of worrying it up. I’m going to get stuck. Or I ask a question and say, meanwhile, I’m off looking for this myself. If you ask a silly question, you might get an answer like, “Well, Google it.”
Lisette: Let me Google that for you.
Peter: But you don’t sometimes realize that’s not going to work until you’ve been stuck for half an hour and then you should have said half an hour later, “I predict I’m going to be stuck for half an hour.” Well that’s kind of tricky. So sometimes, you need to say again, “Now, I’m trying to work this out.” And it’s not a question yet but it’s an indication that I’m going to try and figure this out and this sounds hard so if you think it’s easy or you know how, then interrupt me and tell me but I’m not asking a question yet because I’m at least going to try and fix this myself.
Lisette: And that happens. This is something that people, that your programmers, or your team does with each other.
Peter: Yeah but not everybody learns this habit. Not everybody does it. And so this is the thing that is tricky and using this kind of group tools is to discover and develop habits of the kind of behaviors that make it work better for you. So this is the opportunities to use the tools better.
Lisette: Is this talked about as a team often? Is this sort of a subject that comes up?
Peter: No. I think they’re too busy talking about coding to actually talk about remote collaboration. So I don’t have this conversation so explicitly but it often is in the channel. It is often in the chat itself. Somebody says, “Well, you should have told me you were working on that because that’s easy. I did it yesterday,” or “I know it’s a stupid question don’t tell me to Google it. I’m already doing that obviously.” It’s just part of the interaction that it becomes clear what we’re doing.
Lisette: Right. So then any other challenges that you can think of that you run into with? I mean I guess in a sense, a lot of things are remote. Anytime you have a subcontractor, somebody on another floor is remote.
Peter: Yeah. I mentioned that it’s kind of complicated because now I have 10 different channels to use. But that’s sort of a good problem to have. I mentioned that people are frequently likely to stick to their old tools and not want to use new ones. That’s very much a human nature thing. Sometimes, there are skills which you have to learn and not everybody is equally good at. It’s a real pain if people can’t touch type. I mean two-finger typing is a problem because it just makes you slow like talking slowly. I mean people get bored and go away. So if you’re taking this from the humor angle, your joke is only funny if you can get it on the chat room in the next five seconds. You better type faster. If you don’t have that skill, that’s inconvenient. And related to that is well can you actually express yourself clearly in 20 words. This if for me the thing I like most about Twitter as a communication tool is that hugely defining constraint of 140 characters affects the way you write. And that’s a very useful kind of writing skill. Writing 140 characters is a different skill to writing a 1000-word essay. And a 1000-word essay is less useful day to day.
Lisette: It’s funny. I’m thinking about the live journal days when live journal was really big and everybody wrote these long journal posts and it is kind of amusing now that it’s shrunk down to the Facebook, Twitter size.
Peter: Yeah, yeah. So being able to do that well is, again, something that varies between people and notably can. So some people, you just can’t them [inaudible 41:24] clear. That’s less of an issue that happens again. I mean [inaudible 41:32]. Another issue that comes up a lot that whole big discussion of how and when should you or should you not use online tools when there’s a motion involved. And I mentioned earlier using a tool like JIRA to avoid boring meetings when you’re just swapping facts. That’s frequently the essence of online collaboration is sticks and facts online and save the kind of complicated emotional stuff for a higher bandwidth channel that’s on this video chat or if not face to face meeting. But it’s not natural for everybody, I find, to accept that a certain medium is going to be just the facts. That email I sent you, I did mean it literally. I didn’t mean anything by it. I just meant literally the sentence I wrote. That’s all.
Lisette: Right.
Peter: The fact that I wrote one sentence email instead of asking how your weekend was not something rude, it’s just that that’s how email works better or the fact that I didn’t ask you how your weekend was is that it was a tweet and it didn’t fit. And that applies quite extremely to sort of certain tools. Email, you could write a long email. You probably shouldn’t but you could.
Lisette: Right.
Peter: And so getting used to the benefit of keeping things concise is again tricky especially if somebody is very used to making everything a social interaction and so not everything is a social interaction. Sometimes, it’s just [inaudible 42:59] a social interaction for lunch time for now, can we just swap some facts?
Lisette: Right. So there’s a savvy-ness around which tool to use, what’s best for the communication that needs to happen.
Peter: Yeah, and to my mind, I’ve worked with a lot of people and of course as a programmer, for me this is really the [inaudible 43:17] technical people I’ve worked with who I think has some really weird ideas about this. I’ve worked with people who are less [inaudible 43:25] as managers who are annoyed that I want to use email instead of the telephone. It’s factual and we kind of agree about it but don’t send an email if you’re upset. For me, okay, that’s the reason we’re advised but why do you think it’s okay to make a telephone call if you’re upset? I mean it’s not less bad. That’s going to end just as badly in fact. At least if I write an email, I’ve got time to rewrite it a few times and either remove some of the exclamation marks.
Lisette: Right.
Peter: And some things like that. It’s not all bad when it comes through an emotional [inaudible 43:53]. I mean the great thing about a lot of the declaration tools is something I haven’t mentioned yet is that most of them are asynchronous that you get to consider what you’re doing. You get to think twice, you get to write it a few times before you actually commit to it. When you speak, you say it and it’s already out. There’s no editing there.
Lisette: Yeah.
Peter: And so email’s kind of missed opportunity sometimes.
Lisette: Well there are different personality types that are different for each communication type. I mean there are the types that are the thinkers who really need to think about what they say for a while before they’re actually formulate what it is that they really think so the writing style must be really good in that instance.
Peter: Yeah, so I think that’s going to mean that some people will naturally perform better with certain tools than others. I think everybody can all use a channel but that’s where I say it helps if you spent an evening in a pub together first. You know what to expect or how to write that email.
Lisette: Right.
Peter: You know are they joking all the time or are they just going to try to get through the day. How should [inaudible 44:58]. So these are the challenges. I mean there’s the practical stuff of all of the professional tools and scheduling because you need these skills but then there’s also the human stuff about how you use tools when you have an emotional message or how you deal with the emotion of wanting to stick with your favorite tools even if it’s something archaic like an IRC channel. But for some people, the IRC channel is telephone. I mean there are people who object to not being able to use the telephone.
Lisette: Right. Everybody has a style that needs to be adapted to somehow.
Peter: Yeah, and sometimes, I mean I’m not proud to say it but it comes down to kind of a power play like who needs this communication more. Sometimes, recruits just want to talk to me because I look at CVs and hire people sometimes while unfortunately, I get to dictate that we do not interact from the telephone. I will not take calls from recruiters because I don’t have to thank God. I can just say no. And if that’s a problem for them, then there are plenty of other recruiters.
Lisette: Right.
Peter: So it doesn’t bother me. Unfortunately, I’m not going to say that to my customers, only to my suppliers. So I do need to actually use the telephone for my customers. Given half the chance, I’ll train them to use group chat or email instead because I’m just not a telephone person.
Lisette: Right.
Peter: I don’t normally do video chat even actually come to that but same difference. So people have their person preferences probably aligned to they like. And so you have another question about different kinds of people and different kinds of tools. I don’t think there really is a kind of person but the question of should someone use this tool, for me is well, do they like it. Do they like using the tool? That’s the relevant question. For me, that’s maybe the only relevant question. If you don’t like using the tool, then don’t use it or at least compromise if you were a team. And the team has to use something.
Lisette: Right.
Peter: Yeah.
Lisette: So then one question that I have then that this all brings up is in terms of team building remotely, when you need to sort of do team building exercise but you can’t, maybe you’ve met face-to-face so that is one technique, meeting first face-to-face.
Peter: Yeah.
Lisette: Meeting regularly, that’s a huge team building exercise and one might say that could be enough but what do you do in the meantime?
Peter: Do you mean until you’ve met for the first time?
Lisette: Either until you’ve met or maybe in the in-between times to keep the relationships going.
Peter: Until you first met, it’s a tricky one and I don’t really an answer there because I’m stuck. And I’m lucky enough to have worked in the commercial software development where if this is the real thing that tends to be money for plane tickets. I mean even open source developers often meet at conferences. That’s why sort of open source software development is like science, the international science and scientists need to meet in conferences [inaudible 47:52]. In the meantime, just very small amount of daily interactions are enough. If I’m working, and this I’ve done a lot actually, I’ll be working for months at a time with somebody who I’ll only see once every few months or a couple of times a year. But we’ll probably interact briefly once per day and that’s enough. Some days, we have some work stuff to do and sometimes we don’t have work stuff to do so we should just interact anyway even if we don’t have anything to talk about using the same tools even. I mean I’m not going to create a bug report, “Hey, how’s the weather.”
Lisette: Right.
Peter: I mean that’s why you need informal channels like chat as well or you an email worst case scenario.
Lisette: So just keeping in regular contact in one form or another on a daily basis, it sounds like.
Peter: Yeah. And depending of the nature of the relationship or how kind of close it needs to be to work maybe doesn’t have to be daily. And there are people who I don’t need to work with so closely that once a week is plenty. It’s fine. Just “How’s it going? What’s new this week? By the way…” and make some fake news. News is an interesting sort of topic. Sometimes, in asking people questions, you’re just telling them things that are new that you think they need to know. And maybe it’s a mistake to only contact somebody with some news if there’s something really important. I mean you should contact them regularly. Maybe don’t go to the extreme of television news which is going to be half an hour a day even if nothing happened because then you get silly stories but at least have a minimum threshold. At least, once a week or once a day depending on how close the relationship is will highlight the day, highlight the week. Say something, exchange something, give somebody something.
Lisette: Right.
Peter: Or we know other things you can give somebody where it doesn’t have to be news. I mean it could just be saying thank you which is another example which I’ve been talking about recently. So find some excuse to interact with somebody in between.
Lisette: Okay.
Peter: And this is what keeps it going for months at a time in between the face-to-face meetings. And that’s why for a lot of online relationships, once a year is plenty.
Lisette: In terms of seeing each other face-to-face.
Peter: Yeah.
Lisette: Because in the meantime, you’re in touch. And it is very to be in touch on a regular basis given the number of channels that exist.
Peter: Yeah. And one of the things that are interesting is how what we’ve seen from social networks, just talking from point of view of personal lives is that what’s good about group channels unless [inaudible 50:24] the example there is that I don’t have to actually directly interact if I can just read what somebody is doing. If I see somebody posting something, I feel a little bit connected even though they’re not specifically talking to me. And so I think of social connections, people I wouldn’t naturally see once a year even, I mean people I haven’t seen since, what, decades ago. But if I regularly have some kind of information about what’s going on, then it will be a bit easier to interact or engage if we do need to get in touch.
Lisette: On some level, right.
Peter: On some level.
Lisette: Yeah, yeah.
Peter: And so even if it’s sort of somebody who I used to work with or haven’t worked with for years, if I still read their blog or I still read their tweets, then that’s going to make it a bit easier just to slightly lower the barrier to interact with them next time.
Lisette: Right, because you’re a little bit up-to-date and there are reasons to like their post or offer some advice when you know the answer to the question that they’re talking or something.
Peter: Yeah.
Lisette: I like that piece of advice actually.
Peter: Yeah. There’s some context. If we’re talking about long term scales, yes, then people change. They grow, they become better or worse. I mean, particularly, [inaudible 51:38] communication. And so it’s good to know, “Hey, this person’s funny now or apparently they learned to write or something,” or in our case where we’re expats, “Hey, their English improved.”
Lisette: Right. Or they’re not improved.
Peter: Or the other way around. Heaven forbid but that happens too.
Lisette: Actually, I feel like I’m losing my English now that I live in the Netherlands that sometimes I’m just going to be a mute. I can’t learn either language very well.
Peter: Right. And if you’re multilingual and you’re doing this, I mean this is something that’s relevant for us as well. Tweet in Dutch once every now and then just to kind of broadcast that this also works. This is something that is relevant on a group chat where the customer knows the country. Occasionally say something in the other language if you can even if that is not preferred. It indicates that that’s possible. Tell a joke every now and then to indicate that you don’t mind humor.
Lisette: Right.
Peter: So sometimes, you’re just sort of indicating how you can communicate.
Lisette: Okay.
Peter: I mean there’s an analogy here that sort of programmers would understand is that, well at least network engineers, is that network technologies often include some kind of handshaking protocol where there’s an initial bit of communication which isn’t communication. It’s establishing how to communicate.
Lisette: Right.
Peter: Very easily expressed in an old rule of thumb for Morse codes. Morse code is [inaudible 53:07] now, at least a generation in the past. But think about Morse code is that everybody can tap out their beeps at different speeds but also understand that in real time, listen to this at different speeds. So how do you negotiate what’s sort of fast enough and not too fast? And the rule of thumb is don’t send faster than you can receive and then don’t send faster than the other person is sending, and you sort of settle down to the fastest speed that’s good for the both of you.
Lisette: Oh.
Peter: This is the kind of thinking that if you think about it is actually something we instinctively do in sort of [inaudible 53:47] communication with people is that we sort of settle into the way they communicate. If I’m talking to a non-native English speaker, I would probably drop some of the slang.
Lisette: Right. Speak more slowly.
Peter: Yeah, if somebody’s having trouble, I’ll sort of switch to their level. And then if it’s then somebody else, a visitor from the UK, then all the slang comes back and then my colleagues can’t understand me anymore.
Lisette: I really like it. The focus it seems to me has been really around communication, the types of communication, and being savvy enough to distinguish between these various types and using what works. And it seems of course obvious but if it were so obvious, we wouldn’t have the problems that we have. So clearly, it’s not.
Peter: Yeah, I mean trying to sort of reflect on what we have been talking about for the last sort of 45 minutes is, and the two of us analyzing what this is all about because we’re interested in this. But that’s not actually necessary to be able to succeed. There are very few rules of thumb necessary. It’s sort of use all of the possible tools, learn to type faster, and accept that you’re dealing with humans, and accept that using all the possible tools means actually that you meet face-to-face sometimes. But that kind of collection of sort of basic advice gets you a really long way.
Lisette: Yeah.
Peter: Provided that you’re willing to do things like experiment and continuously improve. And if you’re not somebody who’s not going to experiment and continuously improve, then you’ve got bigger problems than not being able to do online collaboration.
Lisette: Well, it’s not even that you’ll have bigger problems. It’s you’ll simply get left behind.
Peter: Yes. Absolutely, absolutely.
Lisette: So the last story that I want to touch on is the story about the Department of Defense.
Peter: Oh yeah.
Lisette: I love this.
Peter: It was great because there’s always the exceptions that really sort of test what you believe. And this is the software project that shouldn’t have happened, isn’t possible, defies all rational explanation. And the deal was basically this: We did a project, a software development project, for the US Government. And we entered into a kind of contract which is very unusual. Now, I mean up until that point and since then, I’m used to a kind of contract where the custom were either we agree what kind of work we were meant to do and an hourly rate, and then we start doing work, and at a certain point, we stop; or we do the other kind that is we agree in advance what we’re going to do and the price, and we do that. And once we persuaded them that we’ve done what we said we’re going to do, they give us the amount of money we agreed. Now this was neither of those things. It looked like a standard fixed priced project. There was in fact a fixed price. And I figured that the first part of this project would be working out in detail what we’re going to do, say that we kind of agreed in advance when we’re going to be done. That’s not the way it happened. And so this is sort of a background to the weirdness of the project. What happened was we got a contract that Stacy said, “You’re going to do stuff for this amount of money and it’s going to happen between these two dates.” And this is in all sorts of jargon. There was start day and end day, six months later, we work six months. And what was clear and I can sort of understand why a government contract might have this, it said, “You will be paid for work you do between these two dates and under no circumstances will you be paid for work after the end date.” So despite the fact there’s no real description of what you’re going to do, that we could get anything, it’s not going to cost us more than this. That was the thing, okay?
Lisette: Okay.
Peter: So I figured, “Okay, that’s okay. We’ll probably interact a lot during the project to basically treat it like working on an hourly rate working as an agile kind of way, you might imagine.” So we arranged the project kickoff. Three of us flew over to Washington D.C. where we spent 3, 4 days and we went to the PowerPoint slides, we talked about the project goals, we demoed what we were basing our software on, yeah, and we went to a few museums, and we went to a thousand restaurants with our kind of new customer, and socialized, and got to know them a bit. And during these few days, it gradually became clear that we weren’t nearly talking about what we were going to build or how. We were just going to do stuff. And every time we tried to start a conversation, “You’ll work it out.” It’s like “You’ll work it out.” Okay, we’re going to do it during the project. So the project started within a very intense period of a few days getting to know each other, only getting to know each other, not really talking about any content. Then for six months, we had almost no contact: nothing. We didn’t see them during the project. There was no kind of direct contact like telephone or Skype. We emailed but they tended to not reply very quickly. Sometimes, it took weeks. And once they replied, saying, “Effectively, we’re sorry it took six weeks to reply to this question but we were on a mission.” And I realized later that they were literally on a mission. And so we did this whole project with no interaction at all. And at the end of the project, we flew over to the States again and had that kind of end of project meeting where we all sort of said how jolly fun it was and how great it was that we achieved all of the project goals. And that was that. And so we had this interaction where we started it up in exactly the right way to have the alien interaction with our customer remotely and then nothing. And so we had a six month remote project where it didn’t matter where in the world we were because there was no contact.
Lisette: Wow. So how did you know you’re on the right path?
Peter: I guess just because we’re clever. We didn’t know.
Lisette: Luck.
Peter: And so this was their choice. I mean this the way they manage their risk. The risk is we build the wrong software while this was all dealt with by upfront. We talked about it before we start the project. And then the project, the whole end for the project is the experiment. If after the six months, we built the wrong thing, I guess we just try another one.
Lisette: Right, given the constraints.
Peter: Yeah, I mean this should be like doing like a [inaudible 1:00:22] project where you have a one six month sprint and then you do a demo. And then that’s it. So talking about strange and very strange in terms of collaboration because of the huge contrast between this great kickoff where we got to know this customer and then actually no interaction. And so sometimes, and we talked about during the project for the US Government but from the Netherlands, “Well, wasn’t that difficult?” Well, it wouldn’t be any different if we’d been somewhere else in Washington D.C. We still wouldn’t have seen them for six months.
Lisette: Right. They were on a mission.
Peter: It was just entirely irrelevant where we were. And of course, this is the great thing about doing software development is the fact that it can be entirely irrelevant because obviously several times during the project, there was some virtual interaction like several times when we reached the software development [inaudible 1:01:10] and did the software release, we gave them the software release. But you don’t need to meet people to do that. Probably you don’t hand over a floppy disk. [Inaudible 1:01:19]. And so we had some interaction. We gave them visibility of progress. Back then, it was JIRA as well. We gave them access so they can look at the roadmap and see how far we’ve gotten, see when we’re planning the release of it, and that kind of thing. And they did respond to some technical questions sort of functional question by email. But there was definitely no group chat, there was no Skype thing, and there was no daily standup, nothing of the sort.
Lisette: Right. So once again, you’ve got a situation where had you had all of these things, it would have gone maybe a bit faster, maybe a bit easier.
Peter: Well, I mean maybe. From our point of view, we can’t really conclude anything other than the project was a complete success. Even though we had it not being successful and we’ve got the wrong software, we still wouldn’t have found out because well we weren’t really allowed to know what they did with it afterwards. But it also made it clear that actually it sort of shocked us because our expectations are to have a lot of interaction with our customer when we’re working remotely. And this was surprising because it didn’t happen and so it made me realize, “Oh, yeah, we’re really used a lot of interaction. We’re used to behaving like a remote part of the same team.” And so it was surprising when although it could have happened, it was just not the way that they wanted to work, not the way they work.
Lisette: Right.
Peter: And this was also particularly interesting bearing on a different topic of agile software development which is often based on the premise that you need to have your customer or a representative of your customer physically in the room. Well I mean this project was nothing like not in the room. I mean we didn’t see them six months.
Lisette: Right.
Peter: And so that’s a challenge, a challenge to know how to proceed when you don’t have the interaction. But it wasn’t because we weren’t ready, it wasn’t because we didn’t have the tools. So sometimes, there are situations where we could have done all the beautiful collaborations in the world. It’s just that they didn’t want it. They were happy. They said, “No, that’s fine. Don’t worry about it.” We asked them. We kind of, maybe we annoyed them just by saying, “Please talk to us.”
Lisette: Here’s my IRC channel, please.
Peter: Yeah, yeah. But in the end, they sort of talked to us. I mean we understood that’s just what they needed. They were comfortable. If they’re happy, we’re happy. And so it was such an exception. Every normal project will do need daily interaction across the whole team and with the customer and between teams. And so to have this one project where it’s not needed was so shocking. That really illustrated how it’s just on every other project essential.
Lisette: Right.
Peter: And so actually going back to talking about normal projects and normal remote collaboration, it’s inevitable on all projects, even the projects where you say there’s no remote working, even if you’re in your customer’s office, they’re in a different room, there’s still use for these tools. Somebody’s working from home because they’re waiting for the plumber to come. There are all sorts of reasons, less obvious reasons, why we need these kinds of practices and tools and less obvious benefits of remote working. It makes the non-remote working easier.
Lisette: Right.
Peter: We have this idea that remote working is my colleague who lives in the South of France and he kind of works from home in the South of France and we interact only online. But it’s not mostly about that. Actually, it’s about we have remote working for 20 minutes because somebody’s in a different part of the building or we’re remote working for half a day because this person’s at home waiting for the plumber or waiting for delivery or kind of offset the they’re now so sick, they can’t use the keyboard well enough that they can’t go outside into the weather.
Lisette: And you don’t want them in your office.
Peter: Well exactly and infect everybody. And so this is the more subtle benefit of remote working is that if you don’t enable all of this stuff, then you basically lose out on a lot of work that would have got done, a lot of interaction that would have happened. But if you say, “No, you can only interact if you’re in the same room,” if your IT infrastructure doesn’t let people connect electronically, if they’re not allowed to take their laptops home, there’s all sorts of kind of policy reasons that people have.
Lisette: Yeah.
Peter: Or they’re not allowed to work from home, if you’re not allowed to work from home, then if you’re at home anyway for some other reason, you can’t work from home because there’s no infrastructure for it.
Lisette: Right. So you simply are limiting people. You don’t have the processes in place.
Peter: Yeah. And actually, by the same token, creating the infrastructure, making it easy to work remotely making it easy to have an employee who lives in Alaska is actually benefit for all the employees, the ones who don’t live in Alaska for that kind of reason. My favor analogy there is like the good grips brand of kitchen tools originally developed for people with arthritis. They’ve got this really big handles. [Inaudible 1:06:31] the big handle, easier to hold if you kind of have trouble holding things. Well it turns out, even if you have normal use with your hands, they’re still easy to use. Better usability benefits everybody.
Lisette: Right.
Peter: Better access benefits everybody. So the value is not just for the people who have no alternative. It’s actually for everyone.
Lisette: I really like that.
Peter: That’s what we’ve discovered. And so it becomes a natural tool part of the way we work. And of course, what’s interesting now is that we have a younger generation who has always used the social versions of these tools, things like Facebook. And so [inaudible 1:07:09] go to the office and not be able to kind of interact with people, they’ll say, “Where’s the wall? Where’s the chat room? How do I send people a picture or whatever?” and that would just be weird if you can’t
Lisette: Right.
Peter: That would be painful.
Lisette: So we’re at the end of the time that I have actually but I have one final question which is if people want to contact you, what is the best way to find you and get a hold of you? What’s your preferred method of communication?
Peter: Well I do like email. I like to write. I like to read. It’s very old school. But that’s quite a high barrier so Twitter’s pretty good to start with. Twitter’s quite easy because all you need to know is my name, PeterHilton, and that’s my Twitter. And you can find me sort of through the Lunatech website and what you find is that actually, well, there are several channels that all work as a way to kind of get in touch first and then we’ll work out what we actually prefer to use. So just because the first contact is through LinkedIn doesn’t mean that either of us think it’s a good way to communicate.
Lisette: Right.
Peter: And we’ll settle down to something else quickly enough. But I think Twitter is my favorite way to communicate to people I don’t know.
Lisette: Okay.
Peter: LinkedIn, I’m a bit shy about it if we’ve never actually met. I mean that would actually just seem a bit weird. Sorry but unless we’ve had a beer together, then it’s not going to be Facebook.
Lisette: Right. Every channel has its use and its style, and yeah, very interesting. Well thanks so much for all the information today. I’m really looking forward to digesting this a little bit more and writing it out into a full case study. I think there are some really interesting points that we brought up.
Peter: Yeah.
Lisette: And if I have other questions to you, I will certainly get in touch with you.
Peter: There are all sorts of ways you can do that.
Lisette: Absolutely, absolutely. I think it should involve a beer somehow.
Peter: Yeah, yeah.
Lisette: Okay, well thanks, Peter. I really appreciate it.
Peter: Okay.
Lisette: Okay. And I’m going to go ahead and stop the broadcast.
Peter: Okay. [Inaudible 1:09:08]. Bye!
