Transcript
Kilby: A little bit about me. Since everybody likes to throw icons up about where they were, I figured I got to do that too. On this side here is the professional side. Since about 2001, when the first books and articles came out about Agile, I was all in. I was testing with teams and sometimes torturing the teams by trying new Agile approaches, trying not to, but working through various scenarios. I always ended up in places that Agile wasn't supposed to work. The first picture here is working with the U.S. military. "Agile won't work there." When you're getting bullets and things coming at you, inspect and adapt works pretty good. They get it.
From my time and working in various consulting groups, I was always with different teams, different organizations, teams of teams, big programs where they say, "Yes, everybody's co-located." I would come in and there'd be one person off several time zones away that I'd have to figure out, "How do I train them? How do I coach them with the rest of the team?"
Right now I'm at this company called Sonatype. Has anybody heard of Sonatype? I would hope so, we're a sponsor. The other interesting thing about Sonatype, if you didn't swing by the booth, we are, I would say, about 90% distributed. We have a main group of administrative and finance staff in Washington DC but we have engineers, support, customer success, sales engineers spread worldwide, from Australia to Alaska. The engineering teams are from India to Alaska. I will actually say the joy of working with a fully-distributed team because it does make a big difference when everyone is distributed.
On the right-hand side here, I've also got involved in many volunteer activities. I helped found the Agile Orlando organization, Agile Florida, which is sort of a network of groups. I got involved in the big conferences, in some initiatives through the International Agile Alliance organization. The funny thing is they all work distributed too.
Things that I learned from the volunteer group I brought to the working side, and what I learned from the working side I brought to the volunteer side. Judy [Rees] was very kind in saying I was the world Agile expert, I probably just have the most battle scars really, is what it comes down to.
This is our path through this subject today. What is a mindset shift? Because that's really what we're talking about. I'm just going to say mind shift. Then, we'll talk about these three disciplines for leading distributed Agile teams. Then, we'll talk about experimenting to explore some of these mind shifts.
What Is a Mind Shift?
What is a mind shift, other than cool funky images? This goes back to my first trip to the UK, about 12 years ago. My wife and I had a great day, we did the tourist thing, we would visit Stonehenge, we found a pub, maybe two or three, I've lost count. By the end of the day, we were tired and we wanted to drive back to our hotel. This was sort of the image. Do you notice anything wrong with this image? What's wrong? I'm on the right side of the road, yes. It works for me in the U.S., why doesn't it work here? I went with my best practice for driving by staying on the right side of the road.
That was my first aha moment really with mind shifts, that really only work in certain contexts. If you're not careful, they can hurt if you use them the wrong way.
I see the same thing when people try to apply Agile practices to distributed teams. You might have teams that are 8, 10, 13 times zones apart and somebody says, "Let's do stand-ups." Which means somebody's up at 3:00 a.m., somebody's up at 8:00 a.m. Who knows where the others are in this? It's painful for the people on that team. I'm not going to ask, "Who does that?" I'm hoping that it doesn't happen to you but I still bump into too many teams where it does happen.
Let's talk about another common issue there. Are time zones really a problem? This is another mind shift. One of the things I discovered working with my teams is it's not so much the time zones. It's really getting to know the people and their work preferences. Here we have an example. At the top there, we've got Sarah and Mary in Raleigh, North Carolina. Sarah comes in a little earlier, Mary comes in a little bit later. They're pretty close in hours and same time zone. Boston, same time zone, Jane and Mike, but they have very different hours. Mike is an early bird, he likes to come in early before the rest of the office is in there and get things done. Then, we have Ian in London. He has kids and he also has a lot of fun riding the Tube, I hear that's an adventure every day. He comes in a little bit later and stays a little bit later. Then, we have Garrett in Berlin. Garrett happens to be a developer and he's ok with shifting his time a little bit later because he's a little bit of a nighttime person anyway. To be working with the rest of the team, he shifts later and is able to collaborate.
When you start summing up where their hours overlap, you can see at the bottom there, in the green, where they have significant overlap. How many of you were at Charles Humble's talk just before lunch? Yes, so a good number of you. Charles [Humble] had mentioned 4 hours. I also feel 4 hours is a minimum. This team doesn't really have 4 hours but this arrangement worked for them. Now I'm going to ask if you have arrangements like this where you can shift a little bit in your times so you do have overlap? Not as many but a few.
However, what if we take this a little bit further? Notice the previous one that I have behind it was for Monday Wednesday Thursday, that's how they started out all week, but Jane also has kids. Jane never has time to work out, so she asked the team, "You know what, I would really love to have 2 hours in the middle of a workday where I could work out, and then, come back." She goes, "I promise, I'll be back right on time." The team says, "Let's try and experiment. Let's see how you do, let's see how it affects the team." We can see how it changed a little bit of their work time. They still have their 2 hours, they're 100% overlapping, they lost one of their hours where most of the team is overlapped. What they noticed was, other than Jane coming back a little pink-faced on the video camera from working out, she was energized, she was ready to go for the second part of the day, she started producing better code, she was being more focused, she was able to help out more on pole requests because she was taking care of herself. I think Charles [Humble] was talking about that in his talk as well. We didn't collaborate but it was just serendipity that he was hitting some of my topics here. Allowing the team to decide those hours of overlap is key.
It's not just this team. How many of you know about the buffer state of remote report? A couple. I think this is its 4th or 5th year that it's come out. This is one of the statistics and it seems, I think it was 3,900 respondents this year, "The ability have a flexible schedule," "the ability to work anywhere," "not having to commute," "ability to spend time with family," that idea of choice is not only key for remote workers, it's an attractor. If you're building a team and you can provide that flexibility, if you can provide that choice, that is a tremendous help.
One of the ahas or mind shifts that came to me is, for people who are actually based in offices, they should not be imposed with office hours. If there's somebody local that says, "You should be here 9:00 to 5:00," or whatever the time frame is, ignore that. It's really what's up to the team, what works best for the team to get those hours of overlap where they can collaborate 4, 5, 6 hours. Also, what other things can you do to give the team choice? For some of the teams that I work with now at Sonatype, they have a choice of which process they use. They have some choices on tooling. We've got to be somewhat physically conservative, we can't buy everything, but there's also a process for them to suggest tools. Whoever suggests that, we ask them, "Put together an evaluation group, get some different developers from different parts of the organization to help you out and evaluate, set up criteria, work through with a senior manager as part of that. Let's see if this new tool can replace an existing tool or it gives us a capability that doesn't previously exist."
How many of you have that capability where anybody in the organization can suggest choices and tooling? A decent number, I would say roughly half. Good. Different types of choices become important.
3 Disciplines for Leading Distributed Teams
Let's talk about these three disciplines. Really, they in themselves are three mind shifts. Managing for change through experimentation, amplifying communication and collaboration, and focusing on principles over practices. We'll dive into each one of these. If you really get good at making this part of your way of thinking day to day, it becomes your daily operating system as a team leader, or as a director. Actually, where I'm at right now, the senior VP is the chief experimenter. When I came in, 6 years ago, to Sonatype, we set up some small experiments that kept growing and growing, experiments to see what would help the teams, what would help collaboration across the teams, what would help with tooling. Any problem that came up through the teams, we would look at what are some small experiments, and then, some larger experiments for them to try. This is what the entire management staff is now trained to do is, "How do we set up this environment?"
Let's talk about manage change through experiments. Let's say we have a team. They're doing fairly well over time, hence the performance is hovering around an average there. Then, a change is introduced. What could that change be? This is the shortlist: new process, new team member. Just one team member can change the dynamics of a team. New leader, new tools, new conflict – either on the team or between the teams. Some of that I think was Judy's [Rees] talk earlier this morning. Urgent requests – I'm sure nobody here gets those. Urgent change in direction – a competitor just released something, we've got to pivot and do something with that. Tool failure, process failure, team member out unexpectedly, leader unavailable. A small little virus causing problems in our area – just happens to be the latest little change that we're dealing with right now.
It depends on whether you've chosen the change or the change comes at you. On the top, shows our expectations when we push change on our teams. I've got this great new process called Scrum, I'm sure that's never happened to you. Or Kanban, or the blue-pill methodology, or the red-pill methodology. Let's do it. The expectation is it's going to make the team perform much better. As somebody who's an Agile coach, I've come into those situations and let them know the dotted line does not lead there right away. However, if the change is happening to you, you see it just going down. "I don't know how to deal with this," "I've got other stuff on my plate," "I can't handle this" kaput, performance goes down.
What really happens? When that change first occurs, there's usually some disruption. Under the right conditions, the individual or the team that's facing the change starts to figure it out. They start to figure out, "There's a way to maybe make this work, there's a way for us to mitigate this new risk that's popped up. There's some way for us to get past this or some way to get better at this."
Has anybody ever seen a curve like this? If you smooth that out, that curve is called the J curve. Some call it the Kubler-Ross curve or the Satir Change Model, so there's a few different names for it. Number one, the team's at its status quo, the old way of working. Then, the change is introduced, at number two, that challenges those assumptions. That's where the real struggle comes in. It's something that changes your way of working, your way of moving through your work environment. That's where the resistance comes in. That's natural. We are wired to resist that change if we don't see an immediate need for this change.
Then, once we start to wrestle with it a little bit, and hopefully we have some support in wrestling with it, that's where we start to take apart those assumptions and unlearn what we've learned and say, "Now, I'm not so sure that this way of branching works," or, "I'm not so sure this way of sprints works. Maybe there's another way this will work better." It still gets you down into number five where performance goes down, things still are rocky. Then, somebody has an idea, something clicks for somebody, "I think I know how this is going to work for us now. I think I now know how we can do this. I've got an idea, I've got an experiment in mind." That's the transforming idea. It might be the first of several to get the team back to where it needs to be, or even better. Through those series of experiments, that's where they integrate the new learning. Ideally the new status quo is higher, but not necessarily.
One of you might be thinking, "But wait, you said, 'Under the right conditions.'" That'll be at the end of the presentation, where we're going to talk about how you do these experiments so it works better.
For now, let's talk about amplifying communication and collaboration. On our remote teams, a lot of people think, "This is a great way to work." There's times where I want this to work, I want the full head set, I want to just plug in, let's go, let's focus. Whether you're a designer, developer, tech writer – by the way, technology's not there yet. I did VR stuff 20 years ago, it's still not there. Unfortunately though, even if you're in the zone, are you always sure you're building the right thing? Or do you end up wrestling with a problem? I know, as engineers, I'd start off as an engineer, you want to wrestle that problem and just beat it and get it done. Sometimes we can burn a lot of time on that. We do need the collaboration on our teams, but there's one more kink that gets thrown in with distributed teams.
Here, in the image, we have one of the typical types of setups where you've got a few people in location one that are co-located. They feel an affinity, they feel closeness, and that's why there's that solid circle around those four people. Then, you've got a couple of satellite remote people at location 2 and 3. You might've hired these good people, you might've figured out the hours of overlap for them. All the location 1 people are working well together, they're talking, they're grabbing the whiteboard and sketching. In location 2 and 3 people miss some things, they end up not understanding and planning sessions, reviews, like yes, "I'm not really getting that. Can you explain that to me again?" They feel disconnected. I have been in location 2 and 3, I don't know if any of you have. There's a word for that that I'm not going to use, but yes, it's not fun.
Eventually, what I find is those people in location 2 and 3, they go look for another team or they go look for another job. The funny thing is they won't necessarily go look for a job at a co-located team because now they've been remote, they've started to appreciate some of those freedoms of schedule flexibility and location flexibility and they say, "That part was cool. I'm going to find another company that will do that." While there are not a large number of companies, there is a growing number of companies that are going remote. If you're curious about that, come talk to me later.
What we really need to do is we need to shift those circles, we need to change those circles. We need to make it where that location-based affinity is not that big a deal, and really focus on a team-based affinity. There are some ways to do this. We talked about hours of overlap. Another one is a team back channel. You might already be doing something like this, but it's usually a dedicated chat channel where it's just the team and everything is discussed in that channel. Even during a meeting, that team will use that chat channel to dig up information and share it, maybe pop in questions. By the way, yes, there are many introverts on remote teams. This back-channel really helps them. If they don't feel like they can jump in on the conversation, they'll post things there. It's making everyone aware of that back channel and using it as another level of communication.
Also, buddy system and co-pilots. Ranga [Balashanmugam], you had the concept of a local leader? Yes, so it's a similar idea. There's various forms of this. With the buddy system, if you've got some people in office and some remote, is there a way you can buddy them up so that they're always checking in with each other? You might already have people that have connections but when I'm in a meeting and I have people in a conference room and some remote, I might be facilitating but what I'll say is, "Can a few of you just stay connected?" Can I ask you to connect with one person? Ranga [Balashanmugam], would you connect with just one other person? I just give you one person to watch out for. Just open up a chat channel with them, maybe it's that back channel, see if they're struggling with anything in the meeting. Or if they've got questions and they can't break in on the meeting, your buddy that's in the room helps you out with that. If you're doing activities in the room, the buddy can help with that. That buddy is another concept.
The co-pilot is similar but it works more when you have clusters of people in different locations. That local leader in each location, like Ranga [Balashanmugam] talked about, helps coordinate meetings and they almost co-facilitate meetings. That's another pattern you might notice under another word called pairing. It's just different forms of pairing, so it's pairing for facilitation, it's pairing for coordination and collaboration.
The other part is really getting to know the whole person. How can you really get to know people on your team? I will say, where I'm at right now, at Sonatype, the people at Sonatype are really good at keeping their cameras on. Not everybody, and we don't force anybody to turn on their cameras, but they're really good about turning their cameras on. We know, if it's an internal meeting, just employees, we know your family's back there, we know the dog's going to bark, nobody gets upset by that. You start getting 20-25 people in the meeting, we're going to ask, "Keep your microphone muted," but if your dog pops up, then, "Show us your dog, tell us about your dog," because there's probably two other people that have dogs. I think Charles [Humble] talked about something similar. You start making connections with people.
There's certain items in my office, and Judy [Rees] has seen them because we've collaborated online, where she's asked, "What in the world is that on your shelf?" and so I tell a story about that. Another thing is my kids know that, if they come into the office and they see my cheap IKEA light on and it's red, it means the camera is on, I'm in a meeting, and if they come in, they will automatically be introduced to everyone in that meeting. For some reason, they never come in when that red light's on. It took about five times for each of my three kids, then they finally got it. My daughter still busts in and I say, "I'm going to introduce you, come on, come here."
Just providing some of those simple signals and allowing people to get to know you, getting to know your family a little bit, because you do the same thing in an office. You have pictures on your desk in an office, you get to know a little bit about people.
Also, the little part, also understanding, "Where's the growth? Where do you want to grow?" If you let the rest of your team know, "I work more back-end. I'd really be interested in doing more front-end. I want to learn React," or, "I want to learn this," then, maybe there's opportunities to pair up and expand your skills a little bit, depending on what requirement or story comes down the road. Having opportunities to share this, and there's different ways to do that, I don't have time to get to it in this talk, and also bringing everyone together.
What we found that works best is bringing everyone together once a year. I know you read that a lot in many places, and I think a couple of speakers here mention it. If you've got teams collaborating, is it possible that you can bring them together in one spot with some whiteboards, cheap Airbnb or a house or something like that, say, "Here's a week, here's some whiteboards, here's the product owner or a product manager with you. We're just going to jam on, here's the vision, we're going to come up with the team charter and work through it that way." What that allows you to do is, not only hash through many questions and issues and technical concerns, but to really get to know the other team members on the other teams, so you get to understand when they have some challenges. Getting to know that personal side. If you can't do it in person, there are ways to do it online. For us, when we're starting new initiatives, we will pull teams together and say, "You guys look like you're centered around Toronto. That's the location, you're going there and work it out for a week to see what you're going to work on."
These are all results of experiments that teams have tried. They've tried different variations of these, but it's how it's allowed them to work better, to collaborate better together.
Let's talk about the last one, focus on principles over practices. Up at the top, above the blue line, you might have seen one, two, or maybe even all of these. I'm guessing those who raised their hand, I'm hoping you've seen the Agile manifesto by now. It's only been around 20 plus years. How many have seen the Scrum values? XP values? Good. It's still alive. Lean software principles? Cool. A bid number of you have seen those. Some of your teams might use those to judge what you change. That's usually something you bring into a retrospective, "We follow these principles," or your team might come up with their own principles as a guideline.
There might be a slew of things under the blue line for practices. Stand-ups, retrospectives, evolving architectures. If you do [inaudible 00:31:58] for some other scaling, large-scale PI-type planning, Scrum of Scrums. There's all kinds of technical and project-management type of processes. Where teams get in trouble is where they try to bring this all in as described in the books to the distribute teams. That's where the challenge comes in.
Last year, Janna Rothman and I – Janna has written many books – we co-wrote a book on distributed Agile teams and we boiled the principles down to these eight. The first one you've already heard, "Established acceptable hours of overlap," which means 4 or more hours. Usually this means a team of five or six. If you've got a team larger than that, seriously consider splitting into two teams. Why? Because one, it's easier to coordinate the hours of overlap. It's also easier to coordinate the communication channels, because those exponentially grow as you add people.
Creating transparency at all levels, that's reporting up and out, but also within the team, creating a culture of improvement so you're always experimenting, practicing pervasive communication. That means the important messages might need to be sent a few times a few different ways, so it might have to be given in all hands, it might have to be put up on a Wiki, it might have to have an AMA of its own by whoever's sponsoring the big change behind that.
Assume good intent because we're always so good at reading the intent in text messages, aren't we? We're really good at that. If you can do that and realize that, "Maybe I don't understand," that's a very important one.
A quick side note, I had a CTO who had a rule of thumb. If any message, text, email went back and forth, started to look combative and it went back and forth more than two times, call. I thought it was a great idea, never thought about it until I got into an email fight with him and after the second message, I got my phone ringing. It was him, it was the CTO. "I see you follow your own rule. That's good to know." Ever since then I do the same thing.
Creating a project rhythm. This doesn't necessarily mean sprints. Sprints are actually really really difficult with distribute teams because, if you've got people in multiple time zones, when does the sprint really start? When does it really end? I find a lot of teams struggle with that. It's, "Do you have a rhythm or cadence to your planning? Do you have a rhythm or cadence to how you review as a team? Do you have a rhythm to how you review with your stakeholders?" Just make sure you have those rhythms set up.
Creating that culture of resilience. What do you do if a team member is out? Always trying to default to collaborative work, which sounds weird, especially to developers, but if you've been on a really good Agile team, it sometimes feels weird being solo for too long.
You've got all these practices now, you have these principles. How do we make these work? As an example, one of my teams, I think they had about 5 hours of overlap. They liked daily stand-ups because they liked the socialization that happened in stand-ups. They actually blocked out 30 minutes per stand-up. The actual check-in portion, the time they checked-in with each other, was about 5 or 10 minutes of a fairly good stand-up. They would use that extra time to talk about an issue they were discussing in Slack and say, "Let's see if we can hash it out right now while we're all here." Or, "I've got something I really want to bounce off of you, a design that I want to bounce off of you folks. Can I just take this screen and go with it?" They always reserved that full half hour so the team had flexibility.
Then, after a while, they realized this particular team had a lot of short assignments, they did a lot of integration work. They pulled in a lot of products across the platform. They were doing about every 3 weeks, and when it comes time for our retrospectives and reflect on how things are going, we have all these little things and it's hard for us to remember. What if we mixed it into the stand up? What if we started blending the stand-ups and the retrospectives a little bit?
What they did is they set up a new channel in Slack just for them, they called it the Kaizen Channel. You might have heard that word before, Kaizen – small changes. The team would use that as their list of things to talk about. As soon as something happened, they'd pop it in there. Sometimes other team members would comment, "Yes, that bothers me too," or, "Yes, I think they have an idea." Once a week, at one of these stand-ups they would have available, where they would just take off this list of small things. Every week they were making tiny improvements. Anything on that list that ended up taking more than about a 10-minute discussion, got tagged for the retrospective. They realized, "This is bigger than we thought. Let's save it for the retro," and then, any time two of those items would pop up, that would be a signal we have to retro. They did their own poll-based retrospective that way. They would go no longer than 6 weeks, they don't want to go too long on that, but this team made so many improvements so fast that they ended up releasing some major integrations.
That's where, as you start thinking about your remote context, some of these ceremonies you can start mixing and matching if you understand the principles behind them. What's the principle behind a stand up? Just shout it out.
Participant 1: Staying in sync about where people are going.
Kilby: Staying in sync, yes, so it's not a status report. What's the purpose of a retrospective?
Participant 2: To improve.
Kilby: To improve. Yes. If you're staying in sync, can't you improve at the same time? I mean that's basically the conclusion that came to us, "Sure. Why not? Let's try it." That was their experiment. They kick off many experiments, and then, larger experiments through their retrospective.
Experimenting to Explore Mind Shifts
How does this experimentation work? Back to our old friend, the J curve. How you manage this change is that bottom part of the curve. This is sometimes known as the point of chaos. This is where you might say things hit rotating devices, at this point in the chart here. It's important that, when you see the change, you've got to let your team mates, or if you're the leader let the team know, "It's going to get rough, we're going to find a way through it. I've got some ideas, but we're going to talk about this together on how we can navigate through this, how we can get through the chaos." If you try to have too big of a change, you push that chaos out, you expand that chaos in some different ways. It could extend the time you're dealing with it, it could also push the performance down for the teams. That's always fun.
The other thing, and I have been guilty of this, trying to put too many changes on the team. Remember, that part down the curve is the unlearning. It's taking apart those assumptions to make sure, "Yes, they don't quite work for how our work has changed now." It's important to give that time for the team to unlearn, to find that transforming idea, and then, to relearn. Otherwise, they just keep going down.
The easiest way to do this is set experiments. You might have seen a chart like this in your early school days. It's the same idea. Set a hypothesis, define the experiment, along with a time box around it, "How long do you want to run this?" "What is it you got to measure?" "What is it you're not going to mess with?" and gather that information during that time box, and then, make sure that you meet with those impacted and say, "What did we learn from this? Is it something we want to make a permanent change or is it something that, no, we've got to try something else?" How many of you experiment like this now? a few. That's good.
If you haven't done that, a really excellent way to do this is through what's referred to as an A3 experiment template. The only reason it's called A3 is that it was the size of the paper that Toyota used to use for their change improvements. The idea was you get it on one sheet of paper, you can even download this one there, agendashift.com/a3-template. On this one, you see that hypothesis up at the top left. We believe that, whatever the hypothesis is, will result in so you're expecting something out of this. What is it you're expecting to change out of this and what's the evidence, if successful? Don't just say, "We're going to change our CI tool." What do you hope to get out of that? What is it going to do for us? What are some of the risks involved? What are the downside but what might actually be an upside to some of this if it works? Who needs to be involved? Who needs to be directly involved in the experiment? Who just needs to be maybe informed as stakeholders or influencers that might need to kick in a little money as part of this experiment?" Then, what are our assumptions and dependencies that we have to deal with? What's the actual experiment, the pilot experiment? There might be a few. If there's a few, we have to put some ownership around that.
Then, that last part is, "What did we learn out of this?" This is not a one-and-done tool, this is a thinking tool that you walk around with people and say, " I'm thinking about this experiment, I want to talk through this." "This is my hypothesis. Do I have the assumptions Do I have some of the risks right or did I miss anything?" You want to walk it around to those people you think need to be directly involved and make sure you involve them. Experiment with them, not on them. I could tell you, many teams do not like being lab rats. As a matter of fact, I've heard some teams actually use that statement, "I feel like a lab rat," I said, "We're going to cut the experiment right now. Let's stop and reset this," because somebody did not involve them in the conversations around this.
To wrap up, we've covered what is a mind shift, we've covered what are the three disciplines which in themselves are mind shifts, managing change through experiments, amplifying the communication and collaboration in your distributed Agile teams, focusing on the principles instead of the practices so you can get some better ways of working on your distributed Agile teams. Then, exploring through experimentation to find and understand those mind shifts that you have to deal with.
Questions and Answers
Participant 3: What about cultural differences? How do you deal with that in this area?
Kilby: I have found that, if you get to know the people, you learn their part of the culture very quickly. One-to-ones are a wonderful way, and I mean one-to-ones between team members can be a way to do that. As a team lead or director, you might give them a list of prompt questions and say, "You can use some of these or not but these might help you discover some of the cultural differences." In Deval Panchal's book, he's got a great retrospective about learning values, and sometimes some of those cultural things come out. It basically starts with, "I don't like," and you do it individually first, and then, in pairs. Individually it makes it safer for some cultures, as well as those who are little more introverted, to think about what they don't like. It helps understand and come up with some working agreements for the team around that.
Participant 4: In the case where you do have a group that is partially co-located and partially remote, how do you encourage the people who are co-located to collaborate more with the remotes? They would much rather collaborate with the people that are co-located because it's easier for them.
Kilby: Yes, because they're right there. The question I would have is, do these people go out, like lunch, happy hour, things like that and so they've got some social connection as well?
Participant 4: Some yes, some no.
Kilby: That gets back to the affinity distance that that Ranga [Balashanmugam] was talking about. Can you find some ways to socialize online? Ranga [Balashanmugam] had some great ideas, another thing that we do, and a lot of people do this, in Slack, we had a channel called Engineering that nobody used. They would never put anything because they knew it's the whole company. We switched it to The Lounge. We got Spotify playlist, we got vacation pictures, we got piles of everything in there. We said, "You could post anything. Keep it clean please." Two years later, somebody said, "We really need some special-interest groups." Those special interest groups, do-it-yourself home repair, motorcycles, bicycles, board games, and video games. I've lost count of how many channels. Having those kind of connections, people get to meet each other that way and feel a little more connected with them. Using the buddy system and meetings helps too, I've found. They may not know the person that well, so they're like, "I don't know," but if you say, "Can you just be a buddy in this meeting?" it helps them get a little more connected and understand their situation.
See more presentations with transcripts
