Transcript
Webber: I want you, for a moment, to imagine the best team. I'm going to describe a team to you that I think is the best team. This is everything from idea creation, to getting things in the hands of users, so all the flow. Imagine that you have all the roles that you need to create things, to plan things, to create ideas, to get things built, to get things designed, to get things deployed, to see how things are working, to learn from how your users are doing stuff, to learn from each other. You have great collaboration. You work really well together. You work really well with other bits of your organization, with business, with other functions with other people that you need to be successful. You get to input and collaborate on product decisions and prioritization. You have time to be creative. A happy well-oiled machine. Is this situation true for anyone, this description? Literally, no one.
Background
My name is Emily. I am a UK based, independent, agile organizational consultant. I call myself different things depending on the situation and what it is that I'm doing. I work mostly to help organizations that help people thrive so that organizations can thrive. I have been working independent for about eight-and-a-half years. What that means is I get to go around lots of different organizations and see how they work, or more likely how they don't work, dysfunction everywhere. I do a lot of work around things like communities of practice and joining people up. I also do a lot of work in government in the UK. Some of my frame of reference comes from how UK government build products and services. That's some of my things. I'm going to talk to you about what I see in a lot of organizations, some anti-patterns around collaboration, things around silos, some problems with this, and some of the things that I think that we can do to help make those things better. Hopefully, you'll be able to maybe identify some things when you think maybe our organization is doing some odd stuff that they shouldn't do. A couple of things that you can take away from that as well.
Scope
My subtitle for this talk is, why can't we all just get along? In today's general climate, that's a good existential question anyway. I've noticed this increasingly worrying trend in the industry of a focus on specialization, of specialisms at the expense of collaboration, at the expense of working together and shared responsibility, creating valuable outcomes. There's lots of reasons for this, and I'll talk about some of them. It creates silos. This means that with silos, all the value that you get from working together and bringing lots of minds together just goes out the window. This talk is all written in threes, everything is in threes, three things in threes. Nice and easy to remember. I am going to talk about three anti-patterns first, so these are anti-patterns of collaboration, anti-patterns that I have probably noticed on the rise, more recently. It'd be interesting to know if any of these resonate with you if you see them in your organizations, if you've experienced them yourself.
Anti-pattern 1: One Role Across Many Teams
The first anti-pattern is this, one role across many teams. Imagine these colored dots represent team members in a truly cross-functional multidisciplinary team. We've got different roles all working together towards a common goal. This circle here, the blue one represents a designer. I'm going to use designer because I've definitely seen this happen with designers. When I say designer I mean UX designer. The UX designers in this team, they work together really regularly, they collaborate, brilliant. Everything's great. They pair together, they sometimes mob together. Everything's going well. What happens is the organization spin up another team. They've got this thing that they really need to get done, a new product, new feature has to get done, but they don't have enough designers to go around. They take this designer, she's called Anita. They take Anita and they split her time in two. Now Anita is working on two multidisciplinary teams. What's starting to happen is that she doesn't have time to go to all of the standups. She doesn't have time to be in the retrospectives, planning sessions, points in time where decisions get made. She can't keep up with all the multitude of Slack messages or Team's messages, or any kind of platform that's going on there. She starts to slip. She feels like the quality of her work is slipping, and she's being a lot more reactive. She doesn't always know why decisions are getting made.
The organization then decides they're going to spin up another team. Another team is really important, a new product, a new feature that needs to get done. Can you guess what happens next? They split Anita's time three ways, they don't have enough designers in the organization. Now Anita is on three teams. It was just about working, but now she's split across these three teams. She has got no time, no headspace to be creative. She's constantly playing catch-up. Her work is guided by what other people put in the backlog and put her name against. They are blaming her for being a blocker. We can't finish this piece of work. We can't get it to be done because the designer doesn't have enough time to work on it. The organization thinks, this needs to happen because we've got these three really important things, and Anita thinks, I don't want to stop this. I want to be a team player. She goes ahead with it. She's miserable. She's not having a very good time. She's not able to actually do the thing that she really loves doing. She's not very happy.
One thing that can happen at this point is the design team decided to take all the designers out and put them in a separate function because everyone's got too much work to do. That's an anti-pattern on top of the anti-pattern. The problem here as well is not only you might think, Anita has got a third of her time on each of these projects. Actually, that's not really true, because you have this graph here. This is from a paper called, "The impact of task switching and work interruptions on software development processes." What they did there is they looked at time spent context switching compared to the number of projects that people were working on. The average number of projects a week, the more projects people are working on, the more hours are spent context switching. That time when you're coming off of one thing, and you're having to ramp down and then remember what it was you're doing on the other thing and ramp up. There's a spread out a bit these things. The more complicated the things you're working on, the more time it takes to remember what is it that I was doing, or go and find out what decisions we made that you weren't aware of. It takes up a lot of time. I circled this bit here that just says, according to this graph, it can be up to five hours a week that you spend context switching if you're working just on two different projects. That's actually quite a lot of time. The more projects you're working on, obviously, the more time you're spending context switching. It's not just a third of the time on each project, it's also this extra time which isn't accounted for, which is why she's miserable. Has anyone experienced this anti-pattern before? Quite a lot. Anyone been Anita? It's usually for maybe team leads or quality people pulled across. Not great.
Anti-pattern 2: Product vs. Engineering Wars
The next anti-pattern is product versus engineering wars. Does this feel familiar already to some people? It's really prevalent at the moment. This is where an organization has split itself into these two main areas, product, which might include things like design and research and some other things in there. Engineering which might also include things like data, operations, development, testing those things. When organizations do this, they end up creating two different cultures in the same organization. You then build supporting structures around each of these as well, so you have product ops on one side, maybe some engineering stuff on the other side, and you're creating these real silos between the two. I got this model from an article on Martin Fowler's blog, it's by Rick Kick and Kennedy Collins. It talks about bottlenecks. This particular post is called product versus engineering. It's completely on point. What they describe here is this organization that's split into two, Chief Product Officer heading up one side of it, Chief Technology Officer heading up the other side of it. Then down this hierarchy that sits under those two, and it happens all the way down. You might have Chief Product Officer, VPs, directors, down to the team level where there's an expectation that the team is going to collaborate at that point when the whole way above that there's been this split between the two. What tends to happen here is that communication flows through that hierarchy rather than across. You've got these splits and these different motivations and priorities that are happening across the two.
What they say in the anti-pattern is that team members align themselves with their management structure, or functional leadership as their primary identity, instead of their business or customer value stream, making it easier for teams to assume an us versus them posture. They also talk about this idea that it can create really bad actions and bad feelings between those two people. It can also lead quite a lot to something I see as the product side of the organization making a lot of decisions about what's going to be built and why, and they're kind of throwing it over the fence to the engineering side of the organization. Has anyone seen that anti-pattern? Is anyone experiencing that right now in their organization?
Anti-pattern 3: X-led
Anti-pattern three is X-led. What X-led is, I hear this more, so organizations say we are x discipline led. They might be data led, product led, engineering led, user led, customer led, or HiPPO led, highest paid person's opinion led. There might be lots of reasons that they do this. What it tends to lead to is heavy focus on that one area. Someone might say we're data led, and suddenly that drives all the decisions that are made about absolutely everything. When I was first researching this talk, I wanted to see what people were saying about these different kinds of led organizations. I found a few examples. The first one is this, is engineering led. This is somebody that I think was really grumpy when they wrote this blog post. They were obviously not very happy in their organization. The blog post was called, "Why engineers should seek out engineering-led companies and how to find them?" They said this, at places where engineers aren't in charge, it feels like they're just blindly applying bog-standard operating procedures of the industry: working agile, doing sprints. They were seeking out the ones with engineering-led organization where they were going to be seen as important. They obviously felt in their own organization, they weren't seen as important. Maybe this is fine. You say, yes, indeed, we want to be engineering led because we want to create great code, we want to create great tech. I've also worked in very engineering-led organizations where it can lead to very rigid, upfront technical design. A lot of decisions being made right up front and leaving no room for emerging needs to appear, or for anyone to pivot or make new changes along the way. I've also worked with an organization that is very engineering led that the whole thing is about deploying, just putting stuff out. It doesn't matter if it's right or if it's wrong, just build stuff and put it out there. We're not going to think about who our users are going to be. That actually can really break your products, it can also break your users. It can also break your people a little bit.
The next one that I found was data led. This is from a white paper called, "Five steps to becoming a data-driven organization." They said, the objectivity of data-driven, means it can lead insights that drive success without any restricting factors or preconceptions. They really said, if we do things this way, then they'll be no preconceptions, and everything would be brilliant. The problem can be with this. Using data is great, is very useful for making decisions. The thing is, data isn't actually really objective. It might be that the data that you see you think it's numbers, it's objective, but the way people interpret it isn't necessarily objective. If you're getting data, and you're not actually interrogating it and understand why things are happening, it does give you a very narrow view of things. If everything that you do is just based on data, then it can be like you're missing out on the whole context about why certain things are happening.
The third example is product-led organization. This is from a book called, "The Product-Led Organization." It says, product organizations make their product the vehicle for acquiring and retaining customers, driving growth, and influencing organizational priorities. They represent the future of business in a digital-first world. You say, that's great, because it's about customers, growth, organizational priorities. That's great. I've also seen, and maybe you've experienced this, overnight product-led organizations where product managers are basically in charge of everything and make decisions on their own, don't necessarily do it very collaboratively. It's not necessarily the intention of these X-led organizations that this happens, but it tends to happen. The people that are the x bit of the led, are in charge of everything. The challenge here is, if you only have a hammer, everything looks like a nail. If you've only got one opinion of how things are going to be, then everything looks like a nail. If you only look at things through one lens, you're really biased towards the decisions that you make.
Problems with Anti-Patterns: One Group Holds the Power
Some problems with these anti-patterns. I'm going to talk again in threes, I've talked about three anti-patterns, one role across many teams, product versus engineering wars, and X-led. I'm going to talk about some of the problems with these. The first one is one group holds the power. One group holds all the decision-making power, and others can't properly contribute. They aren't given the opportunity to contribute. In our first example, Anita the designer doesn't hold any power because all she's doing is playing catch-up. She's got no time to really contribute to decisions. In the second anti-pattern in the product versus engineering, there's always a battle between who holds the power. It's not collaborative, there's silos between the two. Both sides are trying to put their case forward. In the third example, X-led. It's the X that holds the power, so they will be making decisions. This is the problem with this because it's not about creating a rounded view, and creating something that makes sense with lots of perspectives.
Problems with Anti-Patterns: It Reinforces Professional Protectionism
The second thing is it reinforces professional protectionism. I came across this term when I was first researching this talk. I thought it was brilliant. This term professional protectionism summed up what I've seen a lot in organizations. Professional protectionism is about people protecting their professional boundaries and not letting other people step into them. It's like, "No, this is my area, you stay over there and you do your thing and I'll do my thing over here." Maybe some people have experienced this. For example, I was working with an organization recently and they said the user research team didn't want to publish how they did user research, because other people might do it. I was like, this is ours. It's really tied into how we see ourselves and our sense of self and our sense of worth in the workplace. In this paper, which is called, "Developing professional identity in multi-professional teams." It says, if an individual has an overly rigid professional identity, it can lead to poor teamworking, resistance to change, and even bullying behaviors towards those things they consider different. It's really about holding on to their area. An example is if a doctor regards a particular medical test as a core part of their professional role, if they were to give that up to someone else, it would feel like a loss of status, a loss of authority, a loss of responsibility or experience. It really is about sense of self. This is particularly true if it's backed by existing power structures. If you have one of those X-led organizations, people aren't necessarily going to want to give up some of what they do, if they're seen as like the most important people in the organization, or they're in a position where they get to make decisions. If those structures are in place, it can be really hard to break them. I think one thing that really adds to that as well is budgets. If you give different people budgets to spend, it's a real anti-collaboration. It's like, I've got my money now, so I don't need to work with anyone else. You separate your budgets out like that.
I had a sense as well when I was looking into this, and it's a sense of self and professional protectionism. That's this new world of either working from home or hybrid working, whatever the future looks like. Have a part to play in that. I found this article here which is called, "4 Ways the Pandemic Changed How We See Ourselves." In that it said, isolation tested our sense of identity, because it limited our access to in-person social feedback. The whole period when we weren't going into the office, and everyone was working over video, it's like, how do you show your worth and your value in your role? Some of that led to people holding on to their boundaries a bit more and saying, "No, I did that. That's mine." Holding on to their boundaries to show like this is the value that I bring, and probably particularly difficult if you started in an organization remotely, when everyone else was still trying to work out how to talk to each other. The other thing here as well is that incentives and rewards encourage this behavior. This holding on to our own areas can be encouraged by the way that the organization reward people. That might not be the way that they pay them, it might be that you get a company notification that that team did this or this person is a hero for what they did, and like superstar. No matter what you might say in your policies, talking about people, rewarding people in that way will encourage people to continue to not collaborate. This idea of celebrating individuals for work rather than teams. It can also present itself sometimes in objectives, so people have very individual objectives that don't talk about team contribution or collaboration. It can encourage this behavior of holding on to your own area.
Problems with Anti-Patterns: Causing In-team Silos
This can also cause these in-team silos. Do people feel like they have silos in their own teams? It can create hierarchy within a team. A team that has in-team silos might look like a team, you might go, there's people there, they're in a team together, they're working together every day. Actually, they're not necessarily behaving like a team. They're still keeping their boundaries really clear and passing things on to each other. It might look a bit like this. You might have one person does a piece of work then they hand it over to the next person, they hand it over to the next person, somewhere down the end someone is getting blamed for everything not getting done. What happens in teams that are siloed like this is that you do end up with somebody that's being massively overworked, ending up feeling like a blocker. It's usually the QA person, at the end, or deployment person at the end, someone saying, no, we can't do anything because they haven't got that done. The other thing it can lead to is way too many people on a team. I was talking to a friend of mine recently who said in his organization, they wanted to create a 4-page static website. They said, we need to have a delivery manager and a product manager and a content designer and a frontend developer and a backend developer. We need to have this and this. They mapped out this team, and it was a 14-person team, because they had all these different roles that had to be fulfilled. It was a 4-page static website, probably would have taken just one person to do it. It ended up like this idea that everyone had to do their own thing, so that ended up being that big.
The problem with this, as well, is that actually, a lot of the time, in teams, when we're building products and services, we're actually dealing with wicked problems. Wicked problems are problems that don't have a single solution, and we're not necessarily going to get to the end of solving them. We're always looking for different ways and different approaches and different things that we might do. We're not getting to the end of it. We're finding different ways to do it. This is David Epstein. He wrote a book called, "Range: Why Generalists Triumph in a Specialist World," which is really interesting. He talks a lot about the idea that we specialize too early. Even like university is too soon to specialize. According to David Epstein, he said, we should be going out and doing lots of different things and lots of different roles before we specialize, because it gives us a view of a lot of things. He says, in a wicked world, relying on experience from a single domain, is not only limiting, it can be disastrous, because we've got these preconceptions, we can't necessarily see outside our specialism funnel.
That's true in our teams as well. It's really important in our teams, that we have all these different domains, we have these different viewpoints, because it brings diversity to solutions, making them more rounded. When we have different people with different experiences, different specialisms, different life experiences, different viewpoints, it makes something that's much better than the sum of its parts. I keep looking to healthcare sometimes, because I have some really interesting concepts. They're dealing with life and death. Most of us aren't dealing with life and death on a day-to-day basis, but they are. In healthcare, you have this idea that if there's something wrong with you, you'll have a multidisciplinary team that looks after you. Instead of having just one person with one single domain, so if you have cancer, for example, you'll have an oncologist, you'll have a physiotherapist, you'll have all these different points of view and people that look after you because we have different needs, and you don't want one person who just has that one hammer and treats everything the same.
A great example I wanted to give you of different experiences and views of the world comes from this website here. This is a website called Draw Toast. Draw Toast is a collaboration workshop exercise that comes from Dave Gray, but this website is by Tom Wujec. What he does when he wants to get people working together and thinking through a problem, he starts with this thing called Draw Toast, where he gets people to draw how they make toast. It helps to highlight where different people's mental models are. I went to the website and I took these four examples, which I thought were all really interesting for different reasons, and really show that people coming from different places when they think about something, which you think is really simple, which is, how to make toast. In the first one, it's very procedural, you get a loaf of bread, it's even numbered. You get a loaf of bread, put a slice in a toaster. You butter the toast, and it's like, just put it in someone's face at the end, number seven. In the second one, it's much more thinking about the system. We're stepping back, you grow the wheat, you grind it, you make flour, someone bakes the bread. Somewhere along the line it comes out, and we've got toast, that's much more step back.
In number three, it's toast in a frying pan. It might be cultural. When I was growing up in the '80s, we made toast on an eye-level grill, actually. A toaster was often a revelation when I got one of those. It's a whole different viewpoint about, your view of the world is different, because, culturally, you might do things differently. In number four, it's very user focused. There's this person, in each step of the way, and they are really happy about making toast. They're really happy that they've got toast at the end. That's really cool. What I thought was interesting is like something as simple as drawing toast has these really different perspectives. What Tom Wujec does is he gets people to do an exercise like this and say, there's these very different mental models. Now let's work together and create a shared mental model by taking all these different perspectives, and you get a much more rounded view. If this was a team, for example, that was going to build something that helped people make toast, they've got a much better view of all these different ways of thinking about doing it. There's a TED talk called, "Got a wicked problem? First, tell me how you make toast." It says, when people work together under the right circumstances, group models are much better than individual models. When you do that exercise, and you take all these different points of view, you end up with a unified systems model. You think about that on a day-to-day, these decisions that we're making. We've got these different experiences and different disciplines together making decisions, we're going to end up with something that's much better at the end of it.
Create Enabling Organizational Structures
I have spoken to you about three anti-patterns, so one role across many teams, product versus engineering wars, and X-led, and three problems with that, so one group holds the power, reinforces professional protectionism, and it creates in-team silos. I'm going to give you some thoughts on how you might be able to make things better. There's a different level. I'm going to talk about organizational structures, and also about team structures. I'm going to talk about things you can do in a team, maybe if you're an individual contributor, so depending on where you are, and what influence you have in your organization. The first one is to create enabling organizational structures. It's not always easy to do this, if you're not in the position to make those kinds of decisions. There is no perfect organization structure, but there are some that are better than other ones. Back to the diagram that I put up before from Rick Kick and Kennedy Collins. This describes this idea of creating one team at all levels. Instead of these two, product versus engineering, or whatever those structures might be in your organization, like how can you create cross-functional teams at every level? Cross-functional team at your C-suite level, your VP level, your director level, and then at your team level. What that means is then you're making decisions, you've got aligned approaches, you're making shared responsibility across each of those levels, and you're making decisions collaboratively rather than arguing all the way down and expecting people to collaborate at the bottom. There's aligned approaches, insights, and strategies communicated between levels. Does anyone have this in their organization?
Has anyone read Patrick Lencioni's, "The Five Dysfunctions of a Team?" It's a fable, so it's written like a novel. Who doesn't love a management novel? It's quite good. In this, he basically takes his management team on an away day and you go through the experience that they have. He talks about his first team principle, which is this idea that leaders support their fellow leaders over their direct reports. It's that this model of your first team is the people that are the same level as you rather than the people that you manage. If they're your first team, then you will be working together towards common goals with shared responsibility. It will help create that model that I talked about before. You need to have that first team principle, because, again, you might look like a team, but you might have the people that are your direct reports as your first team. When this doesn't happen, and I've seen this thing not happen, you get people pulling in lots of different directions, and it is very confusing.
Build Multidisciplinary Teams
The other thing that you can do is build multidisciplinary teams. I've mentioned multidisciplinary teams a little bit. For me, this means teams of people that can do everything from idea to getting things live. It doesn't just include engineers, it includes product managers and delivery people, and designers, and researchers. It can include people that are outside the tech space as well. I've seen teams, for example, a team of people working in a Department for Work and Pensions in the UK, who had frontline staff, people working in job centers in the team as well, because they were bringing important knowledge and experience into the team. One way to do that when you are putting a team together, if you're in a position where you're able to do that, is instead of saying, what roles do we need on the team? Is to ask the question, what knowledge, skills, and experience do we need on the team to achieve the outcome that we need to achieve? With the second question is, how do we get that without making the team too big? I've been in sessions where we're putting new teams together, and having a negotiation to say, if you put all of those people into the team, we end up with a team of 20, and that's way too big. We need to bring that down so people can properly collaborate and communicate with each other. Then the question becomes, how do we talk about knowledge, skills, and experience? We need more knowledge, skills, and experience people have to create a team around that rather than roles. Then, if we don't need full-time people, like who do we need to collaborate with?
One way to help do that is this idea that disciplines is not the same as roles and job titles. Has anyone ever been in an organization where you have resource management by spreadsheet? I've seen that, where someone goes, that's the developer and that's the blah, and we just put them together on a spreadsheet, and that makes a team. Then not forgetting the fact that you've got massive gaps, or massive overlaps. What I find a lot of the time is that roles and job titles is one thing, what people actually do is different, and there's a lot of overlapping in disciplines. You might be a user researcher, but you do a bit of product management, or you might be a user researcher, but you can do some test engineering. There's a lot of overlap when thinking about people in terms of their skill sets or knowledge, skills, experience, is a much better way to get a team that has everything that you need in it. Or it might be that actually you have a team, and you want to explicitly build some of those knowledge, skills, and experience. You might create a plan to do that.
It's also useful to think beyond the multidisciplinary team. Another thing that I pinched from healthcare. This is from a paper called, "Understanding and improving multidisciplinary team working in geriatric medicine," which might sound like it might not be relevant, but it is relevant in this case. They talk about definitions of conceptual models of teamworking. The one on the far left here is multidisciplinary teams. The way that they describe this in this paper is that members may have separate but interrelated roles and maintain their own discipline boundaries. It's additive not integrative. Then we go beyond them and say, actually, how do we blur those boundaries a lot more and create much more of a team where everyone is working together? The next step there is interdisciplinary teams. That's where team members might start to blur some of those discipline boundaries, but may still maintain a discipline specific base. You might say, this is my main discipline, but actually, you're starting to overlap with other people on the team. Maybe it's a role that is very different to your role, but teams integrate closer to complete a shared goal. Then even further on from that we have transdisciplinary teams, where team members share roles and goals, they share skills, they allow others to learn as well as acquire new skills. Really blended model of a team that shares objectives, core skills, as required to achieve their overall goal, and really blend their skill sets and really create shared responsibility. I'm not saying that you should be aiming for the team over on the right, but I think it's a useful thing to think in any team, it's like, where are we and where do we want to be? How can we maybe be a bit more collaborative or blur the lines a little bit more, or how might you think about leading on something while allowing other people to do it. I once worked with a team, they were in a discovery mode. I went to see them and I said, what are you up to today? They said, we're just still waiting for this researcher to book in some user research interviews? We can't do anything until she's done those interviews. I said, is there anything that maybe you could all do to help move that along? Maybe like anything? They were like, maybe a week, but the user research interview is in. I said, maybe you could. It was like you don't have to do them, but, actually, what can you do as a team to help move work along together?
Embrace Collaboration in Teams
The third thing that you can do at a team level is to actually embrace collaboration in your own team. If you're not somebody that's setting up teams, you're not somebody that's able to create the organizational structure, and you're in a team as an individual contributor, what might you do to embrace collaboration in the team? The first thing is to remember that actually, we all have these very different backgrounds, like generally, we didn't start out in one career and just go up that career ladder in one very narrow area. I went to art college for six years. I'm a master of fine art. I've done some tour management. I've slept on a tour bus. I've done loads of different things. Going to art college for many years, really helps me now confine different concepts and bring them together into something new. That experience of doing something completely different from what I do now, gives me the ability to do that. Having those different and varied background really helps.
Does anyone feel like they have squiggly careers? We have this unique set of knowledge and skills and experience, so how might you embrace that on your own teams? First of all, remember that people are not interchangeable. We have these squiggly careers. We have all these different backgrounds. A lot of organizations try and think about people in these kinds of I, T, and Pi shaped people. Is anyone familiar with these concepts? I is you have a deep expertise in one area. T is you have a deep expertise in one area, kind of broad skills, generally skills across the top. Pi is you might have deep expertise in two areas and broad skills across the top. I think these are not very helpful. I think we're more likely like this. We're more likely this kind of broken comb model. We have lots of different specialisms, and we have this breadth and this team working across the top. That might be all within your area, or it might be within lots of different areas. One thing that I have started to do with a few teams is take this into an exercise and get people to talk to each other about how they might describe their own unique set of skills and experience. Start to actually say what are some of the things that I also want to get better at. People saying, I might be a chief engineer, this person says, but they want to get better at public speaking, or they want to get better at coding, because they've lost some of that. You might get somebody that wants to get better at design, but they're a QA person. If you have these conversations in your team, first of all, you recognize what each other brings to the team. Start to identify areas where you can collaborate, and start to just treat each other like appreciate the skills that you have. When you do something like this, you don't have to put in the stuff that you might be really good at that you don't want to do. You say, what are the things that we do want to do? There's more about that in this blog post here.
I just wanted to finish actually with this quote. This is Margaret Heffernan who's brilliant, she's an organizational consultant. She says, companies don't have ideas, only people do. What motivates people are the bonds and loyalty and trust they develop between each other. What matters is the mortar, not just the bricks. They're really understanding each other building trust and empathy is important. Only by true collaboration, empathy and shared responsibility, will we really be able to work as real teams and create things that makes everyone happy. It makes us happy, it makes our organizations happy, and makes our users happy.
Hopefully, there's a few things there that you maybe can spot some of these anti-patterns, maybe there's some things you might be able to highlight, and maybe there's some things you might be able to do.
Questions and Answers
Participant 1: I have a question around in-team silos, and especially with our recently hybrid or remote world, time zones are a big factor that I see playing out in terms of creating silos, not necessarily for any malicious impact, but just that they happen. Do you have any suggestions for how to capture in-team silos that results from actually larger time zones?
Webber: I've always been distributed. I think one is to actually try and take that into consideration when you're putting teams together. If there's no overlap, then it's going to be really difficult to build. Trust is going to be very difficult to collaborate. The question might be, maybe move people who don't do that. I think there's other things as well. I think we have to be quite intentional about creating opportunities for people to talk and to build trust anyway. We don't just pass people in the corridors anymore. We can't just be like, "Hi, how are you doing? I haven't seen you for a while," because we're not in corridors as much, so being really intentional about that stuff. I really encourage people to do things like random coffees where you're paired up with someone for half an hour with no agenda, just like chat about stuff, or channels in Slack like share your pet. I have one in a couple of my Slack groups, which is people sharing photos, daily outside photos. People share photos of like things they saw that day or in different things of the world. Finding opportunities like that, I think, some of those can be asynchronous as well, can help.
See more presentations with transcripts
