Stop Talking & Start Doing - Leading Teams to Action!

Well, welcome to the only - well, maybe there are a couple - but this one does not involve AI. We're going to talk today about how to lead your teams through some GSD facilitation. So what does that mean? Get stuff done. If you don't know what that means - you have the clicker, so you get to do that. I think this goes over here, the clicker.

So thanks for coming, everybody. Nice big crowd today. We'll start by introducing ourselves. I am Steve Bauer, product director for an organization called Thrivent. We'll talk a little bit more about Thrivent in a slide or two. Previously I was the director of product transformation for Thrivent, so I've been in a coaching function for a long time now. Now I shifted over to become a product director, and I'm back kind of in the arena.

And I'm Dawn Cooper. I am the director of product and portfolio management for our digital engineering teams.

All right. About Thrivent: Thrivent is a financial security or services company. If you look on the slide, you can see we do advice, investments, insurance, banking, and generosity. I just wanted to give a quick overview. Most people probably haven't heard of Thrivent. We are a member-owned company founded more than a century ago. Today we serve 2.4 million clients through our financial advisors. So just a little bit of a big company out there that you maybe haven't heard of.

What I really love about Thrivent is that we're a purpose-driven organization. Many of you probably work for big organizations, and you talk about things like returning shareholder value and EBITDA and all that kind of stuff. The thing that we focus on every year is: how big was the dividend that we returned to our customers? From my perspective, it's really nice to be aligned to a purpose. That fits very well with a product operating model, where we're trying to say, how do we align to our purpose and align that purpose to our delivery?

We're a not-for-profit fraternal organization. I have no idea what that means, but I thought I would throw that out there because it sounds kind of interesting.

Very unique. Thrivent is in the middle of a transformation journey like many other companies. We got our leadership team together last week and talked through how many companies don't succeed in it, but we feel that we really are right now.

Most of our clients preferred - thinking about a hundred-year-old company, they were very old - they're aging, and they loved in-person communication: come sit with me at my kitchen table and hang out. Obviously, their grandchildren and children that are inheriting some of these investments from them want to look at everything on their phone. So we're taking a massive leap forward in our digital transformation, which also requires us to upskill and change our product operating model as well to deliver faster.

So we've gone through what many of you have probably also gone through, which is a project-to-product transformation. It required a tremendous amount of coaching, shifting into product teams, activating those product teams. We have most of our product teams activated at this point, so we're at the point in time where we're trying to continue to mature. I'm sure many of you can relate to where we are in that journey.

Yes. All right: the bucket of sadness. This was made with AI. I won't read these to you, but if you look at some of this, you've all probably been a part of one of those meetings that we call the bucket of sadness, where you think you're going to go in there, you're going to get something done, and you get nothing done. You have a three-hour icebreaker, you have the meeting before the meeting, but nothing ever seems to get really finished. I don't know if you see - a couple head nods can relate to being a part of the bucket of sadness.

Part of our talk today is: how do you avoid the bucket of sadness? How do you get some stuff done? Anybody relate to that? Maybe a show of hands: have any of these things ever happened to you? Yes, universal. I just love the bucket of sadness. I think that's going to stick around for a long time.

Many of you are probably pretty familiar with these tools: flash builds, dojos, discovery sprints. Just recently I learned about innovation sprints and foundation sprints. This talk is about two different kinds of journeys. One is the Thrivent transformation journey, and then one is the journey that we've been on. I think I've been on it about 13 years now. That started with flash build, moved into dojos, and we're still using that methodology today. That tells me that it's still really relevant, and we've shaped it and shifted it a little bit differently.

But these are still the most powerful tools that I've used to build team cohesion and activate a team. Now, you might say, well, Steve, if your only tool is a hammer, everything is going to look like a nail. That might be fair. But I still believe that these are some of the most powerful tools that I've ever encountered.

We will talk through these in a little bit more detail, but we're not going to exhaustively explain these methodologies because you probably know them. They've been in this DevOps community ecosystem for a long time. What we want to talk about today is the kind of secret sauce that we've found or developed over the years as we've run literally hundreds of these.

I think it really takes it from something you read on a piece of paper, an article, a book, to how do you actually apply it in person? Sometimes that's the hardest part.

All right. We've created the three components of our immersive GSD workshop. We'll go through each one of these as we progress forward today. It's kind of an ecosystem that we've worked through and had quite a bit of success. The three complete parts are convene, contain, and create. We'll dive into those now.

We really love this because it's got a great alliteration, and it kind of makes a really nice icon if you need to use it. We could have had like six of these, but we thought, no, let's just keep it to three.

All right: bringing everyone together. This part is really important. When you think about how do you get people to align, how do you get people together in today's working world where we're online all day, it's hard. If you can get people in person together, it helps you communicate differently. It breaks down the silos. It humanizes people a little bit.

There are some key parts that are really important. Finding a large collaborative space. Classroom style like this doesn't allow you to interact well with others if you're trying to be more collaborative, if you're trying to work together. I try to have room set up where people can move around and engage with people.

I also do snacks, food, games, things. You want to bring a little bit of the fun. It doesn't need to be so serious.

When you look at who then should be there, some of the really important parts are: who needs to do the work? A lot of times you get people in there that want opinions on the work, and that's where you end up in the bucket of sadness. But who can really contribute? When I say work, it can mean a multitude of things. If you're trying to define a product vision, if you're trying to fix your roadmaps, if you're trying to align on a goal, you need to get the people in the room that are closer to the work so that they can actually contribute while they're in there. If you have people that are just there to observe, then things don't get done and you're back in the bucket of sadness.

One of the other things that we will go into in our next slide is we want to have two facilitators. You've probably noticed Steve and I have volleyed back and forth. We run a lot of these workshops together. It's just really nice to have some folks in the room that can work with each other.

And then I added: exercise caution adding leaders. When I say leaders in this context, it means the bosses, the managers of the people that are in the room. They often won't share and speak in the open ways that you want them to if their boss is there, because it creates a little bit of fear. So I tend to kick them out.

That's our convene: bring everybody together.

To go a little bit more into what Dawn was mentioning about having two facilitators, we find that it's really important for those facilitators to be very complementary to each other. You don't want two people that are wired the same way. Dawn and I are similar, but very different. We complement each other. We look for an opportunity to play off of each other. I have a certain set of strengths and a very large set of opportunities. Dawn has a different set of strengths. We balance off of each other.

We're always looking to have fun. We play off each other, we keep it whimsical. We're very comfortable being wrong, which for me happens almost all the time. As a facilitator of this sort of thing, give yourself some grace. Don't expect to be really amazing at this the first time that you've tried. I've done this a hundred times, and I still learn something new every time I do it. Practice makes good enough. This is never going to be perfect, but when I have my progress-over-perfection shirt on, it's going to probably end up pretty good.

I like wearing those shirts at the workshops too. Part of it too is when you're running a room by yourself, you become the teacher. Then you're not the facilitator. You're standing at the front, you're delivering it, and you can often miss the context of the room. Having a complementary facilitator can help navigate in those spaces where maybe you've lost the room, people aren't picking up what you're putting down, they kind of shift it a little bit, and that extra facilitator can watch for that and step in and move the room in a different direction.

One of my favorite anecdotes: we had a flash build that we did almost a little over a year ago, and it was a really tough crowd. We thought it was going to fail, which I don't think has ever happened before. People came in and their arms were crossed. They just did not want to be there.

Dawn made a really powerful move. She just went and sat with one of the teams. All of a sudden that changed everybody's body language. It opened them all up. They turned to face her. Dawn was completely oblivious to the fact that she had done that. Completely blew the room open, no idea. I was over on the side and was able to see that because I was observing not only what she was doing, but how the room was reacting.

Again, the importance of that complementarity. Then we were able to lean into her creating a wedge into that group, and we were able to expand on that. But again, if Dawn would have been shouldering the whole thing by herself, she probably would not have even realized that she kind of blew it open like that.

All right: your contain section. When we say container in this, it's really thinking about, once you're in the room, the box that you create around the people. We don't mean the physical box, like the walls. We mean the interactions, the relationship, the collaboration of the people in that room.

We create that container. We set a very strong intention for that. We also like to create a little bit of a heat experience. What do we mean by that? We mean that there needs to be some urgency in this room. If you have done a whole bunch of planning and everything and it just turns into execution, you're just going to have an execution-focused delivery back in the bucket of sadness again. We want some tension in here. We want some urgency. What that does is really heighten the collaboration, really gets people playing off each other.

We will be not only allowing for that collaboration, but setting an intention that we want to foster that in there, want to encourage talking to each other. What's really effective here is oscillating back and forth between working individually and then working collaboratively or working in a pair. You don't have to force pairing all of the time, but be cognizant to make sure that people are talking to each other. If it's quiet, try to detect: is it quiet because people don't know what to do, or is it quiet because people are working?

Another item we have here is don't teach too much. There may be opportunities where you have to teach a concept, but don't turn this into a classroom for the entire time. That's not the intent of this.

And let's be very clear about the outcome that we want to get to. At the end of the day, what is it that we want to deliver? We're going to demo that. That's got to be pretty crisp. We have to all be on the same page about that.

For sure. If we go to our next slide, this is sort of the framework for what does that heat experience look like. This is a little bit of the magic sauce. I think it's been around forever. You don't have to recreate too much, but you can customize it for what you need.

As Steve was pointing out, you set that outcome at the beginning of the day, which becomes what you're going to demo. You're letting the group in that container know that they're driving towards a specific outcome, and then it creates that heat experience.

Let's say you're doing a product roadmap. Let's say you're trying to do a product definition. Or maybe you're trying to work towards working software that you're going to demo. Whatever you tell them at the end of the day, then you work backwards for those activities. What things do we need to do to get us to that delivery at the end of the day?

Retrospecting on how it went is super important so that people can figure out where they have opportunities as they do this more often. I love the fun activity at the end of the day. It gives people something to look forward to. Also, if you do this over a multi-day - like when we do our flash builds, we're doing it over two days - getting people out of that stress space and into something fun, and then they go home, their brains come alive. They think; not everyone processes the same. They come back the next day, and that next planning session in the morning, you reiterate what your goal is by the end of the day. But they've had some time to think about it, and they come in really inspired with ideas.

It's been a really great framework for us to create with the team: what are we aligned on? How do we get to the action where you don't end up in the bucket of sadness because you get to the end of the day and nothing really came out of it but conversation? That's that facilitation part that's getting them closer and closer to the end of the day.

The fun activity: everybody has been working really hard all day, then they like to unwind a little bit at the end of the day. That's where we've really seen some of the power of this come to land. Okay, we've been working together, now let's hang out and have fun. A lot of people don't love mandated fun, but usually just creating the space for this really opens people up.

I want to point out that this is very modular. Wherever we have that work line, that is work that is relevant to whatever it is that you are trying to accomplish for the day. If you have an engineering task and you want to build and deliver something, that's the engineering work that you need to do. If you're doing much more of a product discovery or a foundation sprint or something like that, it's much more product-discovery-focused work. There are all kinds of different work that can fit within this framework, and the framework largely stays the same.

All right. This is the fun part: getting this stuff done. This is where you actually take that framework and you help the people along throughout the day. Obviously, if this was automated, you would just show them the slide we did and say, go in a room and do that. But it's not that simple.

The create part of this is where we're actually working towards getting to that end goal of delivering something by the end of the day, or the end of two days. It's really helping the team solution together. Pushing for imperfect delivery is really critical to this, because if they feel like they have to have something amazing by the end of the day, it often stunts that availability to get there. We remind them a lot throughout the day that you need to just get towards something.

My two goals are usually something cool that was delivered or a lot of really great lessons because we failed miserably. Both are acceptable. It's really helping people as they work through the day get out of their own space, and head things that they're thinking through and things that are preventing them from progress.

You'll frequently hit a lot of resistance here, and resistance shows up in a whole bunch of different ways. One way that it shows up is: well, I don't want to create any more technical debt. You can find me later; we can talk about my philosophy on technical debt. Everything that we build at some point becomes technical debt. You don't want to be reckless, but you also can't paralyze yourself by saying, I'm not going to build this or deploy it until it's perfect.

This is really where the getting comfortable being uncomfortable cliche comes in. We tell them at the beginning of the day it's going to be really uncomfortable. This is very different than how you've normally operated in more of a methodical way. I think the next one talks a lot about our muscular facilitation.

We call it muscular facilitation because it's really kind of assertive and you want to be present here. We're looking to break up spin - we say ruthlessly; that's maybe an overstatement, but it's dramatic to make the point. We don't want to let this group just sit there and spin forever. As facilitators, we want to lean into that.

We're going to push for that imperfect delivery. We want to get something done. We're going to nudge collaboration as much as possible. We want to get to work as fast as possible. We don't want to sit there and plan eternally. We want to start to get stuff going.

You mentioned this already: this is not a college class, so we don't want to teach forever either. This is really a great opportunity to do some coaching also, and challenge some norms or some deeply held beliefs that people will state as laws that may or may not be true. Like: I can't push that to that environment because of X, Y, and Z reason. Really? Are you sure? Or is that something that you're telling yourself that's a blocker?

We want to stay oriented to that goal. We want to be looking for anybody that might be silent or kind of alienated from the group, and try to pull them in.

I think this part too is really where bringing back that dual facilitator method really helps a lot. Teams will break off into different work streams and work through stuff throughout the day. Having people that can move around and help - breaking up that spin, checking in with the groups, what are they stuck on, what do they need help on, how do you keep moving them towards the goal - is really part of this.

But it can be really hard because people can get really frustrated with you, where they're like, we're on a thing. And we're like, well, you've been doing that for a long time now and we're trying to get to the demo. It's really helping them get that moving forward.

You're pushing as hard, but also as gently as possible to keep things moving here, which might sound contradictory, but I think we like that. It will make sense.

All right, here's the super secret goal of this whole thing: the transformation part. Obviously the software delivery part of it, product delivery, whatever you're demoing at the end of the day, is a really important piece. But there's a lot of stuff that comes out of this as well. It's sort of an add-on where you're also helping to shift teams' minds, behaviors, breaking through perfectionism. You're exploring agile, product, and DevOps principles throughout the day with what you're doing.

The whole goal that we have by doing a lot of these different types of workshops is helping teams get out of their own way, even in their day-to-day work; to take these learnings back to realize they don't have to spend as much time planning, thinking, over-architecting, looking at all the things that they need to do to get something delivered. Sometimes you can just do it really fast in a room, and it's okay to not have it be perfect. There have just been some really good learnings that we've had and outcomes we've seen from doing this type of workshop facilitation.

I envision a world where most of us have done a big discrete transformation event, and then we'll say, we're done transforming. I think any of us that have worked in these environments know that is not true, and that transformation keeps going forever. Maybe you did a big dojo when you activated everybody. Well, what do you do next? You can continue to sprinkle this type of activity in there to reinforce that. Then you've got a self-reinforcing transformation that continues to carry itself forward.

I like to think about: what if an organization did this once a quarter with a hundred teams? Not only the productivity that you would hit, but the transformation that would propagate across that organization. I love to think about that. That's kind of a goal that we have for Thrivent: to get into that self-reinforcing transformation loop, because I think that's really important. It's not enough to just set it and forget it or do it once and move on. It's very important that this continues to evolve.

I think in that vein too, if you're in the middle of a transformation and you have teams that are struggling, they're in the bucket of sadness, as you start to see those opportunities, pull this. This is a tool you can pull out and try to help them get out of their own way a little bit.

One of the other bullets I would call out here is that some of us who work in large organizations sometimes get frustrated by the bureaucracy, or the rules, or the laws that we have to follow. I'm not saying I would, of course not, but some people do. This is a great opportunity to emulate a greenfield startup culture within a larger organization. The importance or the opportunity of that cannot be overstated. By creating that container, you're creating a little mini-startup within a larger organization that really unlocks a lot of potential for you.

All right. Success criteria that we accidentally discovered. I like to call them the counterintuitive principles because they don't make sense in how we normally work: creating that sense of urgency, not smoothing out tension. The discomfort, some of that stuff feels like it shouldn't be.

I think you had a quote about the best high-performing teams.

There's more conflict in higher-performing teams than there is on lower-performing teams. I think we often shy away from that kind of conflict.

We're from Minnesota, so we're very familiar with what's called Minnesota nice, which is passive aggressiveness and conflict avoidance. What that leads to is a whole bunch of people who have a very strongly held belief but don't share it. Then we just sit back and develop a whole bunch of resentment for each other, which I'm sure you can understand is a really healthy organizational culture at that point.

Our goal with creating, putting some pressure in here, is to bring some of that tension forward, make it transparent, make it stated, create some conflict perhaps, and healthy conflict to continue to move these things forward.

I love the bottom one: celebrate progress even if it results in catastrophic failure. The more you can celebrate that, the more helpful your teams will be in getting some of this stuff done.

We've talked a lot about being uncomfortable or creating some discomfort. In my perspective, discomfort is where the growth happens. Again, we're talking about you want to build something, but we're also pushing people to personally and professionally develop and grow here. We want to make sure that people are enrolled and enlisted in that. We don't want to be doing that to them. But that discomfort is often where people look at their own boundaries and grow past that.

All right. Definitely not reading you this slide, and they will go out; you will get them. Measuring success with humans is hard. Trying to put a data slide up here that shows you all how this is amazing and you can do it with your teams - it's hard to put that data behind humans.

What we looked at was just a couple examples of some of the recent workshops that we did that really were impactful for people, and we got great feedback on, and how this might help you look for some areas where maybe you can see some of your teams within this and say, hey, this might be a method I can use. You can take a picture; otherwise they will go out if you want to read through them. I think just some of the quotes that we've gotten out of here have been really awesome.

This is where we hear, well, we got more done in two hours than we would have gotten done in six months, and all of that kind of stuff. That's almost universal because we've reduced the barriers for people to communicate and collaborate with each other. If you think about if you take all the interactions that happen in this kind of workshop and spread it out across emails and Teams chats, the duration of this sort of thing starts to take like eight months. We compress that all down into a tiny workshop, and people continue to just be baffled by, oh my God, I can't believe we got this much done.

Another thing that's kind of interesting: that workshop I mentioned earlier, we spent two days in there. I think we got to the point that it took about 32 seconds of coding to actually fix the problem that had been bothering people for months. It's amazing. Sometimes I think Dawn and I are like, can you believe we get paid to get people to understand what the problem is, and then it takes 32 seconds to fix it? But that really is often the case. There's just a miscommunication or a misalignment. Bringing people together often resolves that.

All right. Well, we put some fancy QR codes on there too. If you want to connect with us on LinkedIn, we'd love to hear your stories and how this worked for you. We'll stick around too if you have questions.

And I can talk about this for hours and hours and hours, so be careful. But I would love to talk to you and hear from you. I know many of you have used these kinds of methods before. So again, thanks for coming.

Thank you.