Episode 04: Dysfunctions of Digital Teams

Christy Ennis-Kloote: Sure. I think teams that work on these products, like, this whole service end from a digital something that you might see on your phone, on your laptop, but also it might include other services, right? So it’s a whole product approach. This could be connected products too. 

Aaron Kapuis: Yeah, yeah.   

Christy: Include physical hardware. But, yeah. 

Lizzie: All right. Well, I’m sure we have probably countless examples, but let’s just kick it off and start with one. What is one dysfunction you see in a lot of digital teams, that you think needs to be addressed? 

Aaron: I think some of it’s about organizing the teams. It takes like a village to make a digital product and you’ve design and strategy and mobile and backend development. And like, how do you organize that? 

Christy: Right. And we’ve seen these come together, pretty awfully, in some ways sometimes when you might startup with just one aspect of that team. We’ve seen them, like, seeing people run ahead and think, like, “I’ve got developers, I can make a thing and I’m good.” Like, we’re gonna run.  

Aaron: Yeah, absolutely. Sometimes it’s like take each of those different teams and completely isolate them into their comfort zone. 

Lizzie: Yeah. 

Aaron: And never really, like, create a cadence or create a way that they are actually building something together, or go the completely opposite of the spectrum, which is, “OK, we have a deadline. We have a lot of money, we have a lot of people put them in a room and magic will happen in nine months.” That also has been, results in some grand failures. 

Lizzie: Right. Right. So somewhere in between those two? 

Aaron: It’s more nuanced than that, right?  

Christy: Yeah, yeah. 

Aaron: Yeah, it’s absolutely more nuance, you know, it’s really around figuring how these teams can be productive together and also, kinda, go off and do their own work. And also as a function of the size of the team. Right? If we’re talking, like, the two-pizza team, oftentimes they can be productive in a space. 

Lizzie: I think I’m gonna need to know what the two-pizza team is? ‘Cause that sounds like a team I wanna join. 

Aaron: Right. Right. The two-pizza team, the theory behind the two-pizza team and AWS talks about this a lot, Amazon talks about this a lot. You know, a team size that can be fed with two pizzas, so mentally that you put that number in your head. 

Lizzie: So like me, right, got it. [laughter]  

Christy: Yeah. But you can personally scale it enough that you can have personal relationships between the members on the team. But if it becomes too large a scale that you start to lose that connection. 

Aaron: Yeah. And you have to start using different ways that organize the team. Once it gets out beyond that. 

Christy: Right.  

Aaron: So some of the stuff that we’ve done with SAFe, and a team of teams, kinda, helps you go beyond that two-pizza team and still, you know, build something big. Like, it gives you a good cadence and a good way to organize and an example of that. 

Lizzie: So, SAFe and a team of teams are two things I just heard you reference that I’m sure some of our listeners absolutely know it. But for those of us who don’t, do you want to give a high level? 

Christy: Yeah, sure. It’s a Scaled Agile Frameworks­—so—for enterprise. But that size, that scale, it’s, you have these smaller individual teams that may deliver a line or a service line inside this larger product or ecosystem of products, and having them coordinate and actually understand the dependencies between all of those groups. So they can map, kind of, where and when they deliver, when do they work on certain pieces, just so they can map this out and understand how they’re all working and running as a team. 

But without that, you’ve got a little bit of mass chaos of people blaming each other for not helping each other out, leaving them stranded when really, it’s just bad communication, you know? And if we can anticipate and plan and help feed everybody what they need, when they need it, it can go so much smoother. 

Aaron: Yeah, and kinda, related to that, too and just, kind of, tail-end to the scaled agile conversation is, you know, another dysfunction we see is using agile words, but not an agile process. And so giving these teams, whether it’s a smaller two-pizza team or a much larger team, you have to use Scaled Agile or team of teams, get them leveraging reorganization, real process and using that as a framework to move forward and to establish a good baseline for the productivity of the team. So things really start to look at what their output is gonna be so that you know where you’re landing with your roadmap. 

Christy: So if I can expand that agile thing, right? Like the — yeah, so, in agile, like, some of those principles, right? It’s really reinforcing a community of autonomy. So you’re really trusting people to run on their own thing. And you’re absolutely going anti-that if you’re asking for all the small things or you’re micromanaging in that space and not letting people make their own decisions, you know, and trust them to move forward because you just kill and ruin the basis of the movement inside those teams. So. 

Aaron: You know, in kinda breaking, like, decomposing that a little bit. Let’s talk about the more concrete example of that, of how designing in dev can work together, right? 

Christy: Right. So I have a very rigorous way that I try to suggest that works together. But if, say, design is pushed out of the flow of the system. Say we’re given a task, but yet we’re not communicating to dev what we’re working on, or we don’t have timelines to know this handoff. We’re outside the system that is a complete dysfunction of something that’s not gonna roll over, right?  

So we’re building a piece and aspect may be of a screen that has placement buttons and an understanding of what goes there. And then we get to a point and maybe we get held up by decision-makers and they want to review it by committee and share with all sorts of other people. Well, then it’s never gonna make it to development in time in order for them to meet this two-week cadence that they have to run on. And they don’t know all the decisions that have been made around it ’cause it wasn’t outside the system, isn’t documented, so it’s just gonna break apart. And so if you keep it inside there, keep it rolling as a team. And they know when to expect it so that they’re stuff that’s lining up that they have to do behind it is ready. Yeah.  

Aaron: So really understanding the dependencies between design and dev, right? You want design working ahead of dev. And then when design exits their sprint that feeds the devs’ sprint. 

Lizzie: Are those the two main teams? 

Christy: I think that’s a great question. It can be so much broader than that. It can work about that light. But you could have everything from, like, business owner details, kind of like, business processes that need to be ahead of design. That definition gets set of what really needs to happen, or a discovery space, like, “Let’s figure out what needs to happen.” Then there’s usually design and development, some sort of application development. It could be mobile. It could be even if there is a desktop application related to it. And then there could be the firmware application side of it or those. 

Aaron: You’re talking about connected products.  

Christy: I am. I mean it could really go big. 

[crosstalk] 

Aaron: Like it’s more specific than digital. 

Christy: Yeah, but it could then be the whole platform, right? Piece to it too, of like, “What are all these?” And then even internally, like companies too what are all the other services that they have to plug into and know that those are ready to get pulled from. So. 

Aaron: So even breaking hardware and platform apart even you have– 

Christy: Yeah, yeah. 

Aaron: Like, your device interactivity, connectivity layer that connects the mobile experience with the physical device. But then you also have the ingestion data and the data analytics teams that are working. You may even have any integration teams.  

Christy: Yeah. And you could have on the internal services, like, a whole e-commerce side that is so not ready and set up. So, yeah. 

Lizzie: Have you seen? I’m sure you have. Have you seen that where it’s, like, a product was developed without all parties at the table?  

Christy: Correct, yes. And it is absolutely stressful. So. And that I think my favorite, I will call it, one piece. My favorite example is when you physically saw somebody shut down and zip up inside their hoodie and try to hide from what was happening because they just were not ready for all the activity. Yeah. 

Aaron: In denial. Yeah. 

Christy: In denial. I mean, I love it as an example, though, of like, you know, when people are fighting change and fighting all this, like, you can see the dysfunction because they’re just really going through processing and grieving through this like, “Oh, my God, I have to deal with this change now.” 

Lizzie: Yeah. So you can imagine the alternative to that would be feeling really good. 

Christy: Yeah. 

Lizzie: And energized. 

Aaron: Well, the other thing that really comes out as these massive gaps. Just because the teams are communicating requirements, right? If you go from the hard requirements, you have to have firmware updates, right? And how that process works in the device. 

Lizzie: Right. 

Aaron: To what is required on the platform to what’s the user experience going through this very risky process, right?  

Lizzie: Right. 

Aaron: How do you make it seamless, where if you just, kinda like, one part of that equation, not the full equation just throws it at the wall. 

Lizzie: Right.  

Aaron: Something’s gonna break. And it’s either gonna be user experience or it’s gonna be, you know, creating an impossible scenario where the firmware update will not really happen.  

Aaron: Well, it will fail and break the machine like an example. 

Christy: Yeah. I love throwing out these examples of, like of course, designers could run at it and say like, “Well, it’ll be magic and it will all happen in the background.” But if they truly as designers also understand all the handoffs that have to happen in the background, they can design for that and make it better and more seamless between it and, kind of, find ways to not have to have that come out forward and hide that from the user so they don’t have to see it. But. 

Lizzie: Yeah, it makes a lot of sense. 

Aaron: It is a little bit tricky, though, in a lot of digital teams can run in Agile processes or Scaled Agile processes, hardware and firmware teams typically follow a more waterfall process. It’s very rigid. There’s hardware involved. Your procurement of, you know, contract manufacturing and everything that has to happen and so they have these bigger loops. And so how do you connect these two-week loops with three, six-month loops and understanding those dependencies and planning that out can be really tricky. Now we’ve got a strong connected product vent here on digital, but it’s something we do a lot here. 

Christy: A lot of assumptions can happen and things can go very wrong. So. 

Aaron: Yeah, another area where we see digital teams really fall down, is not having a testing validation culture. And that means something totally different to me than probably with a lot of people using the IT field means. 

Christy: Yeah. 

Aaron: That it’s really making sure you’re building the right thing. 

Christy: Yeah. 

Aaron: And I don’t know if you want to unpack that a little bit.  

Christy: Yeah. I mean, so again, like the worst case we’ve seen is where people think they have to have it done and bring it to the market, done. I had some person tell me, like, “I don’t want to see us release multiple times a year. I think it’s better if we just release, like, twice a year.” And I’m like, “Okay, that’s not necessarily the direction I would go.” I would try and encourage more, again, Agile environment of releasing more often so you can put little things out, little things you can learn from versus waiting until we’ve called them, like, more expensive experiments, right?  

Lizzie: Yeah.  

Christy: If you wanna wait for so long.  

Lizzie: It is such a shift though, you know, as in the business community of, like, getting your product as perfect as possible. 

Christy: Unfinished. 

Lizzie: Before it’s– 

Christy: Yeah.  

Lizzie: On the shelves, right? 

Christy: Yeah.  

Lizzie: Compared to a digital product. 

Aaron: And the reality is if that’s your mission, you’re probably building the wrong thing and you’re not giving yourself the opportunity to learn from getting something else sooner. And that’s really what we knew about testing and validation. It’s not the software process of testing. That, of course, is really important, but it’s truly creating a prototype and doing validation, making sure that there’s a market differentiating that, you know. And again, heavy connected product vent. I’ll take the heat for that. But just doing yet another commanding control with a durable good.  

Lizzie: Yeah. 

Aaron: Isn’t really… may not be solving a problem for the end-user that is worth the cost, of the additional cost of the device and the effort to keep it connected, going through the provisioning process and everything else. 

Lizzie: Yeah. 

Aaron: Just to get something you can control over your phone. You can go over and just touch anyway. It needs to be much deeper than that oftentimes and uncovering that value, both first from idea, but then also turn to flip it around, create a test whether it’s a paper prototype or a mock-up prototype or rough prototype where you can validate that, that’s important to users. 

Christy: Like my favorite example where I’ve seen somebody actually do this, like, so opposite dysfunction of, like, you’ve sold a bunch of products onto the market. You’ve put them out there to distribute and then nobody buys it, right? Where I really like what the Switch did in creating these little kits that were, like, paper kits, that is really, like, they just sold the prototypes basically. 

And now you’re playing with all these prototypes that you could build yourself. So they’ve pushed the costs out to let other people experiment with them and find out what got traction. What did people buy? You know, that’s the part I find pretty exciting. And, like, there’s a tangible example. I think I’ve experienced this on the other end, too.  

Lizzie: What is Switch? 

Christy: Oh, sorry. Yeah. 

Lizzie: So I was, like, thinking, like the data center but no, I don’t think that’s what you’re talking about. 

Christy: I’m not a big advocate of actually all these game plays, but I like to keep just as close enough. But it is probably– it’s a pretty dynamic little toolset that you can actually have gameplay happen in a little, like, GameBoy style, single unit, or you can actually attach it to a display up on your TV and plug it in as a main-game console. But you’re literally playing on the same device through both. And it just disassembles into pieces or comes back together as one whole. 

Lizzie: Pretty awesome. Sounds fun.  

Christy: Pretty fun. Nintendo.  

Lizzie: Yeah. Ok. 

Christy: And they are to me, like, they’re taking huge strides to really live this culture, like, all the way through. You know? And try it out. So I feel, like, there are parts where I’ve, as the consumer, felt this where I have experience, kinda, products that were unfinished and I’m trying to also live it. On the other end of, like, I need to accept this as a consumer and appreciate the culture of like, “I’d rather have something than nothing.” You know, or do, “Am I okay with waiting till the rest of the product gets finished and getting exposed to just a piece of it right now?” But if they’re communicating well enough that other features are coming, I think that’s fine. People will have tolerance to that and they’ll learn much more quickly. 

Lizzie: Yeah, and the idea that you’re buying something that value will be added to it.  

Christy: Yes. 

Lizzie: Right. Whatever that is. 

Christy: Extended product. 

Lizzie: Yeah. Kind of a different way of thinking about things.  

Christy: Yeah. ‘Cause they keep thinking, like, even others, like, there are other toolsets we’ve seen grow and change over time. I’ve seen some go wrong too, where they’ve just gone too far. So, yeah. 

Aaron: You know what? Another dysfunction that we’ve seen is this concept of getting to the finish line and in companies believing that their digital teams believing, that’ll be done.  

Lizzie: Mm-hmm. 

Christy: Yeah, that’s that other side. 

Aaron: That’s a hundred percent wrong. You know, if you’re creating a new engagement platform for your customers or you’re adding connectivity to a durable good that’s been in the marketplace, your responsibility to those customers in the engagement model totally changes in a way that you’re now always connected to them. And that’s gonna force you to stand up programs and engage with the customers differently. And you’re gonna learn how they use your product versus how they don’t, how you think they are, who’s gonna be wrong. Some other ideas you have are gonna be right, hopefully. But. 

Christy: I think about, like, physical products have always thought, like, you have a 10-year lifecycle or a five-year or they have already, like, planned obsolescence kinda thing, obsolescence, that it will phase out over time. But if you communicate that well versus turning it into a brick just because you decide not to support it as a company anymore, or I think other people have experienced this around paying for a membership or paying for a thing that you’re invested, you’re now into this piece of whatever you bought. If it’s an app or something else and then suddenly they quit supporting it or it just never keeps growing. And you’re like, “Where’s the value? What happened to this thing?” They’ll lose you and they’ll start having people drop off and then they have to reinvest totally from the beginning again to start a whole nother product. When why not build on a base of something? 

Aaron: Absolutely. Absolutely. And in a lot of companies, if they start backing off their plans. Even if, because they’ve had limited commercial success but the idea’s good– 

Aaron: Are leaving a lot of potential opportunity on the table. We’re seeing, once you know who’s using your goods, how they’re using it. There’s a strong, like, insights and analytics play with this where you can fold that into later phases of your project. And if you don’t do that, you’re not gonna differentiate yourself from your current competition or differentiator that’s gonna come in and use analytics as a strategy against you. 

Christy: So if I can bring this back to the team, though? Why is this important for the team? I think that’s a dysfunction we’ve seen, too, is just assuming you can just plug people in and it’ll all work out. But without communicating this vision and this idea of where it’s going, people are gonna be so short-sighted and just do exactly what they need to do without having to see where those fuzzy edges are and making sure that they blend together, right? From one piece to the next. They’ll all do their job. But it’s like, yeah, there are misses. There are hiccups. You know, it makes it not smooth. So. So it’s, kinda, this idea of, like you have this as a team to share it. We were joking and call it, like, team lore, you know kinda thing. But how do you actually get this thread that’s gonna carry it through even as maybe teams do need to rotate or people do leave need to have this clarity of habits and mindsets that, and the whole vision and share this as a team and where it’s going. 

Lizzie: So since both of you are managers of teams here, I mean, how do you help your teams, kind of, develop that trust and camaraderie in order to thrive? 

Christy: Yeah, so we say too, like, this happens often in strategy work, too. Like there’s this brilliant, beautiful plan, and strategy set forward, but without making it transparent, accessible, revisiting it, finding ways that you’re reinforcing why you’re doing the things you’re doing in your daily work. Making it apply to that person, it makes it so hard to carry forward. So we try to do that, try to make it something people will live and feel, you know, in the work they do and making something they’re responsible for, that they can have what they’re doing actually impact the end outcome. 

Aaron: I think the other simple answer to that is having work that they’re consuming as a team with clear goals, working through that work and being honest with each other in terms of accountability and also being safe. Be able to be safe, too. In some ways, be raw, very raw.  

Christy: Yeah.  

Aaron: And also, you know, the power of a well-run retro be example of that, whether it’s at the end of a sprint or at the end of a program increment or release. Where people really talk about what we’re celebrating meaningfully, you know, what is working well and then also be able to unpack the things that aren’t working and set those as goals in the next increment, whatever it might be, to address those issues.  

Christy: Yeah.  

Aaron: It’s so super important. Otherwise, they don’t get better, right? And so be it– but that takes trust and trust is built around real work.  

Christy: Yeah.  

Aaron: Think you’re producing something you’re able to celebrate the successes, you have something really strong. You can then go back and turn a critical eye to.  

Christy: Yeah. 

Aaron: If you don’t have that, then it’s pretty hard to be productive. 

Christy: Your credibility or we’ve talked about this is, like, you’re building a bank of trust that you can dip into then, now and then if you need to. You have the savings of how you can lean on each other and ask for that moment in time. You know, to try something different. 

Aaron: So, trust and the other one is invested, like, people need to — it’s hard. It’s harder to bring up a hard issue than you think. Right? People really, unless they’re jerks, really have to care enough because there’s a whole grain of nicety in, you know, the keeping everything even on the team that you’re risking when you raise an issue and say, “Hey, this didn’t work.” 

Christy: And just one last tip of like, just really if this is as a team, you all understand what success means, like, “Where are we going?” We all have that common idea of where we’re trying to end and that we can live it, you know, find ways that you embody that every day.  

Lizzie: Yeah. Awesome. Anything else you guys want to make sure we touch on before we start to land the plane? Guys get it? Ten thousand feet.  

Christy: How do we land the plane? [laughter] Yeah. 

Aaron: Yeah. I should have brought my parachute.  

Christy: Ohhhh. 

Lizzie: I wish they could see that I’ve got my captain’s hat on. Unfortunately, it’s a podcast. 

Christy: So, I would just say, like I mean, it’s there’s, like, a total morale builder. It’s something that really keeps people close and wanna stick around for the good time. You know, when you actually do these things well and pull it together versus, yeah, a little dysfunction. If you promote more of that, you’re gonna have less of the joys and keeping a good solid team together. 

Aaron: Have good, good processes that are malleable, that it’s good framework for the team to build on. But then the culture piece I think is the other side of it. So important to build. Start building trust.  

Christy: Yeah. Build your people. 

Aaron: Have an open culture where, you know, be able to question and tackle hard issues as a team is super important.  

Lizzie: Awesome. Yeah. So do you guys have any good resources or things that we should share with our listeners that would be helpful for them? 

Christy: I think we have some exercises out there too. There is sometimes some frameworks. I mean, I’ll throw out a couple that this is really more on an individual level. Like, how do you build a person or how do you kinda match up a team? Everybody uses that T-shaped person just as a reference. If you’re looking, what does a T-shaped person mean? I think that it’s an idea of reference and kind of thing as the T-shape. But I love the Jared Spool reference. It’s more of a broken comb and that even applies as a team. So you might have some people that are stronger than one’s base and some people that are less strong in another. And then how do you balance out those needs and fits? We’ve even talked about it as how you do a match-up between the customer or the company. 

Lizzie: Oh, right.  

Christy: And the– 

Lizzie: The team working on it.  

Christy: The team working on it. Yeah. So that you actually make sure that you’ve got a match of needs and sets. So you kind of complement the things that they don’t have lined that up. 

Aaron: So I’m gonna go really old school on everybody and go at a much broader topic. 

You know, I’ve been around in the consulting field for a while. And a book that I keep falling back on, in terms of the topic around trust is the one by, it’s called “The Trusted Advisor” by David H. Maister, it’s a great book. It’s old, it’s a little campy, but it gives you, kind of, a good perspective on, like, trust and how you can apply that in your professional life.  

Aaron: I think some of that can project down into, you know, team and team building. 

Christy: I had two more—now you say books. I’m like, “Oh, that I could run on books for quite a while.” 

Lizzie: Oh, we can always add some to our podcast story notes, if you think of more.  

Christy: Yeah, but I’ve got, campy too– I do think of “The Five Dysfunctions of a Team.” I actually feel like, it feels reading through it. It’s a little tough, but actually it’s a really easy read story that has some very solid things that just don’t change they’re through and through true.  

Lizzie: And I think they have a video, you can watch it on YouTube, it’s, like, fifteen minutes. If you aren’t a big reader.  

Christy: Yeah. And that as well as when I like them very much. I actually felt like this was a little bit outside of my range to read, but it was very applicable. But was the “Phoenix Project.” I recommend this to people over and over again because it talks about the end -to-end needs inside of IT, while you have some fast-moving needs in a team. There’s also the internal things that help you run constantly as a business. And how do you balance the requests? Right, so that you’re not, you can focus on the product—the thing that digital team space that you’re trying to create without getting distracted and pulled in different directions of what people need from you. But it’s managing the work, gives you different ideas there. 

Lizzie: Awesome. Thank you so much. I’m sure our listeners will be thrilled to have some resources. I know that I certainly learned a lot today from your conversations. I appreciate that. And as we kind of wind down, some of our listeners know this, you both obviously do. But OST’s headquarters are actually based in Grand Rapids, Michigan in an old game factory, it’s called The Drueke Factory. So we have a lot of games all around our offices and in our conference rooms. So I wanna close this with asking both of you: what is your favorite game? 

And now I feel, like, maybe I need to also look into that Switch system because I feel like that’s of interest to me. Aaron, do you have one? 

Christy: Zelda: Call of the Wild, by the way, is really fun. 

Lizzie: What was it?  

Christy: Zelda: Call of the Wild.  

Lizzie: Is that on the Switch?  

Christy: Sorry. Breath of the wild. Yeah.  

Lizzie: Are you– Is that your final answer?  

Christy: Yeah.  

Lizzie: Okay. Locking it in.  

Aaron: Favorite game, Monopoly. 

Lizzie: Oh, man. I just played some Monopoly. It got wild. Actually, it didn’t. But it did get long. Mostly. 

Lizzie: All right. Well, thank you both for joining us. We really appreciate it. And hopefully, we’ll have you back on to the podcast sometime soon. 

Lizzie: OST, changing how the world connects together. For more information go to ostusa.com/podcast.