This is a tricky post for me to write, but one that needs said. Or at least… one I need to write. Sigh.
There’s a lot written out there about how to form teams. How to get them to really gel and be high functioning. How to streamline the environment so they keep rockin’ and rollin’, having fun and delivering cool stuff. People call those teams, “The best I’ve ever been on!” and “When I look back at my career sittin’ in the rocking chair on the porch at the Old Developers’ Home in the afternoon sun, that’s the one I’m gonna smile about most!”
I’ve been on those teams. I’ve been incredibly lucky to have been on more than one of them, actually, with people I would drop everything to work with again. When the whole team has their heads in the game and we’re demo’ing and debating at show-and-tell sessions, there is no better feeling in the world. I’ve generally been the person who – in addition to my architecture and implementation tasks – has been the one who focused on the gelling and rocking and rolling, giving high priority to what I call “the teaminess thing.” Someday I’ll write about that and add to the universe my grab bag of tricks to help facilitate this because every single product designer should know that exhilaration, as often as possible.
But that’s not this post.
This is about what happens when the great project with that great team ends, either because it comes to a close or due to an external event. What if that ending is happy? What if that ending is unhappy? Abrupt? Tapering? How do you do that well? What happens to the team psyche then? What happens to the individual members?
And most importantly, can you recreate the magic? Or find new magic?
I wish I had the answers, the definitive answers, the guaranteed-to-make-each-team-better-than-the-last answers. If you have them, please share. Seriously. Because I’ve had success and gone onto greater things. And I’ve had some very challenging times too, where it’s clear that the next-thing project just isn’t going the way I want my career to go and it’s time to move.
Meanwhile, here’s my take.
When the wheels come off of a team that’s tightly knit and focusing hard on delivery, the first thing that hits is shock and denial. Maybe there’s warning signs – funding evaporating, corporate rumors of layoffs and budget battles, even discussions of spinoffs and or acquihires. Maybe one or two key people bolt due to uncertainty or their dream job. At that point, a team lead’s and team members’ antennae are twitching wildly, maybe hearing lots of rumors about what’s coming next. But nothing concrete and definitive yet, except noises to calm the troops, lest the race horses and plow horses that make up a fabulous team get spooked.
And behind the scenes, lots of discussion about what might happen and whether it’s good or bad for “the best project I’ve ever worked on.” As Rands says, “In the absence of information, people make shit up. Worse, if they at all feel threatened they make shit up that amplifies their worst fears.” Every single team member has those fears and expresses them in his or her own way, and in a distributed team, those fears aren’t as visible. So lots of one on ones and group discussions and comparing notes and DMs and Skype sessions. Leads to more Fear, Uncertainty, and Doubt. And that FUD causes more disquiet, just as managers go quiet other than “Hang tight.”
Searching for a lifeline amidst the rumors becomes a roller coast ride for as much of the team as is in on the secret. A good, gelled team is a great hire, and companies and groups live for getting 4-6 high performance developers who work well together, especially if they’ve demonstrated that they can deliver. Meantime, politically sensitive team members are also putting up feelers individually and in pairs.
But the gelled team is a loyal team, and no one wants to break up that magic so there’s a lot of magical thinking and denial too. In the choice of technology or team, a tight knit team tries to find ways to work together across this transition, and at the same time imagining that things can continue if only certain features are delivered. Or even serious denial that anything is going on and the team turtles into its shell, ignoring the environment and just continuing as if nothing is wrong. At the same time, sharing lots and lots of rumors, and people start to think “What’s next?” and put out feelers..
Your job as lead or manager here is simple:
- Be open and honest about what you know and don’t know. Don’t spread FUD but do listen to rumors and assess the team’s concerns. Go for as much reality as you can, for good and bad. Make time to talk to everyone, from most senior to most junior.
- Acknowledge that the team is its own life, its own culture, separate from the software that you’re working on. Try to ascertain how loyal people are to that team versus technology.
- Be open that there’s a very real possibility that not every team member will cross the transition as part of the team. And so the team will change, no matter how tight things are.
- As lead, your job is to protect the herd as best you can, looking out for them individually and as a team, advocating for the continuation where possible and working to help folks transition if needed. Look for ways to have the team continue together and actively represent the team in that process. Play fairly with external opportunities for the team and for internal new projects, but focus on protecting the team psyche because it’s much harder to get back to fully-gelled and running comfortably at high performance than it appears, so focus on maintaining the communication and energy that make that happen: Keep up the rhythms and rituals and humor and happenings that make this team special. Even if the jokes become bittersweet at times.
If things back down from this stage and the team can continue its project, great! The dedication and loyalty shown here further binds the team, making it more resilient if the issue resurfaces. If the rumors start getting more concrete and leaning towards change, the openness that the lead fosters helps the team and its individuals cope with the impending change.
I’ve been the team lead here, worrying about getting everything done, even as I see our project coming to a very ambiguous close. It’s hard, it’s a crapshoot that you’re aiming for the right thing given that you have no crystal ball, and even when you talk with other team leaders, it’s not clear you’re doing the right thing. Looking at yourself in the mirror is painful as you ask whether you’re doing the right thing when you don’t have all the information either, especially if you’re pushing folks to complete something before the world ends, and you don’t even know whether it ends with a whimper, a bang, or a wormhole to the next thing.
At the point where rumor starts to become reality, the theoretical transitions break the old bonds. If you’re lucky, the old project wiggles through and keeps going, with many or all of the existing team members intact. If not, then the change is much more radical.
Each of us comes with a default reaction, an initial setting of how we view the world. That setting can be overridden by logic and reason over time, but the first reaction is purely fright-flight-or-fight, often based on a glass-half-empty vs glass-half-full life perspective. And so, as the rumor to reality transition occurs, this lizard-brain reaction becomes the first thing that each individual has to deal with, both privately and publicly.
And as team lead, you have to modulate your team’s reactions, public and private, while dealing with your own initial reaction.
What goal is the team striving for? The answer to that might seem to be cool technology, but in my experience, actually the answer for what a really high-performance team is working for most often is itself – the high performing team does not want to let itself down. That sense of “we face the world together and we’re doing this as a team and I want to live up to everyone else’s high standards” binds a truly gelled team more tightly than any management incentives could. Maintain that, and even if the team does get broken up, the loyalties and strong feelings remain. Lose that, and the team shatters like a bad teenager breakup. But maintaining the sense of “we did not let ourselves down” is incredibly hard in the face of a startup failure or project cancellation.
And further, everyone’s role is uncertain, which causes a lot of jitter across the whole team, those looking forward and those who had blinders.
If the rumor mill stage distracted the team, or if it focused down hard to deliver and position for an uncertain future, this phase mostly has the temporary effect of blowing the team out of the water. Even if the team is continuing, so much is changing rapidly, that very little gets done that can be directly used for the future. Too much uncertainty.
And often, too many goodbyes. Team members are letting go and perhaps flying apart. Maybe some or all will work together in a new spot, or have different, parallel roles. But the future is so uncertain beyond the next moment that there’s nothing reliable to hang a hat on and derive comfort.
No matter how optimistic a person is, no matter how pessimistic, the actual transition point is a shock and a blow, complete with the full on cycle of grief: denial, anger, bargaining, depression and acceptance. A good thing is changing, and while change can make things better, regression to the mean suggests that this high-performance team backs down the old performance scale at least for a while, if it even continues in some semblance. And that’s hard for everyone to accept. The gelled team looks to itself for standards, dontcha know. But now, everything’s changing.
If the team mostly stays together, with only a small amount of dissolution, then the lead’s role (in fact everyone’s role) is to look to its collective health.
If the team is breaking up and everyone’s role is changing, then essentially the old project is so radically changed or dropped. And that hits a team with strong ownership hard, even if the project or product was reasonably successful. When the project is stopped prior to a successful conclusion, it’s even harder. Perhaps the company is dissolving because the concept didn’t get the traction that the believers in the company thought it should. Perhaps the project didn’t quite get everyone over the wall and into the next thing and there’s survivor guilt and mourning combined. The product might be cancelled for technical reasons or political reasons, causing everyone on the team to question the project underpinnings. The product might be facing a retirement itself, leaving others to wonder uncertainly about what’s next after a period of being a comfortable expert.
At the same time, the team’s leadership is faced with its own mixed emotions at the end of the project. A gelled team finds that the team’s loyalties are as much to each other as to the product, and now both are being blown apart, and the leaders are forced to examine what led to this result. Asking hard questions and focusing on preserving the high points and building them into next steps for everyone – hard, very hard.
No matter how successful or unsuccessful the project was, for a gelled team, this is the hardest phase. Used to operating collectively, the team has its own life and its own style with each member’s contributions as essential as breathing for the whole. And now that’s ending. Emotions are ragged, people react in surprising ways and each member faces the reality in a different ways. This is where people say things you’d never expect. Sometimes incredibly poignant and highly complimentary as people appreciate the beauty of a gelled team and their colleagues. Sometimes incredibly rude or hurtful or angry as they lash out at the disappointment and unfairness. Sometimes things that can’t be unsaid, which just causes the team further pain. Why? For some people, sharing that pain is the way to dissipate it, to release it to the environment.
Be kind to one another in this phase, and try to understand and even forgive the hurtfulness and anger. I almost wrote “be unfailingly kind”, but really, that’s almost superhumanly hard. Be kind to yourself as well as others.
The team lead needs to talk with everyone, one on one and as a group and to encourage others to connect. The team is people first, project second, and is at its most rawly human at this moment. It’s a tall order for the mourning leadership, but it’s time to:
- Acknowledge what was: This team was a rare thing, so understand what and why and look for things to replicate, And celebrate and remember, ideally with something tangible, even if it’s just a drink in the local watering hole or a virtual coffee break for a distributed team, or a memento, light-hearted or serious, that symbolizes the project for everyone who contributed.
- Accept that things change: Change can be good or bad, but it’s a constant. Right at this point, each change can be like scraping open a skinned knee, over and over again. Quote Dory and “Just keep swimming, swimming, swimming”
- Laugh and mourn and look ahead and backward as needed: Communicate to the team and to each individual what s/he means to you and to the project. Remember the high times. Talk about what might’ve led to a different outcome and acknowledge that you did the best you could (or if you didn’t, come to terms with that – together). Tell one another that it is hard and a roller coaster, and that this is one last hurdle to get through together.
- Make sure that the connections are solid, even as the team flies apart: Set up parties and summaries, write recommendations, share contact information, ponder who belongs in your “If I ever start that company, I’d call this person up” list and tell them that
- Nudge that transition toward the future for each person, with openness and honesty and respect for each person: If you see someone struggling, offer a hand. If you’re struggling, speak out. But turn toward “We’re here. It’s now. What’s next?” rather than trying to recreate a past that doesn’t exist any more.
Here’s where you notice people struggling deeply. The more heavily invested in the project, the harder the transition. We’re all humans, even as we write kick-ass software. If someone seems to be having trouble coping, no matter your role on the team, take a few minutes to talk with them. Point them to additional resources in the community if it seems warranted. Acknowledge the change and hang tight. You’re still connected by common humanity, as well as a joyfully shared past. And perhaps a future too.
Even if the “now” part really, really sucks.
After the cataclysm and the shock of the team being blown apart comes the next thing. And that’s a restart. For many gelled teams, losing that sense of connection is harder than seeing the project dissolve. Especially if the next thing that comes along isn’t as great as the previous team, or just takes a while to really get rolling.
It’s a truism that often highly gelled teams in larger environments are sometimes broken up in an effort to spread the magic. If you take four great people who can complete each others’ project-sentences and propel each other toward the stars, and you spread them into four different teams, well, that’s four times the magic, right?
When you take a high-performing team and spread its members among multiple teams, either at the same company or in different companies, you’ve lost way more than you’ve gained, both short term and long. A high-performance team feeds off itself to be much greater than each individual part. When that team and those bonds are dissolved, individual and group productivity both go down again, way down. The supports, the mutual pushing to excel and delight in discovering together as a team is gone. Even if individually, each of the players was and is a star and everyone is local and bulding on each other, the collective magic is now dissipated.
It can be rebuilt over time. But “over time” is not “immediate.” As the team members start over in new gigs, singly or in small groups, it’s just… different. There’s new stuff to learn, different people to learn from and connect with and bond. But it’s now people speaking a slightly (or majorly) different language, with different culture and different jokes and different speech and habits, and they aren’t yet your peeps the way the old team was. Of course the high performance team members can usually pick these up, and if they’re stylistically compatible (a big if), they can grow. But meanwhile, there’s more of that mourning and feeling like you’re a stranger in a strange land. And when the change was incredibly abrupt or forced, well, that’s when you ponder a career change going away from something rather than to something. Because the new gig isn’t your home yet, and the old home was so fantastically awesome and probably not replaceable.
But the key here is to force looking forward and connecting. The new team might be better than the old team or it might not. But you never know until you commit because the only way to create a high-performing team is to get to the point where everyone on the team is fully committed.. As a wise person once said, “Commitment is a self-fulfilling prophecy.” That’s your very first step in the next phase of your journey – allowing yourself to go all-in at the next gig. When you do that, you know you’re ready to fully begin. Even if the tentative beginnings come in the form of two steps forward and one step back.
If you’re a team lead on a team with a new member coming off a project like this, your job is to:
- Expect some fits and starts, even if the new member is pro enough to not say anything. Every time a new member is added to the team, there’s a period of adjustment and rebalancing. It’s harder here because the new member is dealing with what’s missing, as well as learning the new ropes and culture and style, which could be high-performing but very different.
- Give the new team members something to commit to. Not something vague and nebulous, but concrete and forward looking. And a team of people to do it with. It’s hardest when the members of the blown up team are isolated on singleton projects or an isolated thread within a team project. At this point, connections are the most important thing for folks coming off a great team. Having lost his/her old connections and identity/role, it’s important to show that new ones are possible.
- Support and experiment to adapt culture in both directions. As team lead, it’s your job to experiment to get the best out of your team, sustainably. Try new ideas, encouraging open honesty from all parties. While the new member(s) can’t go back, they can bring the best of the previous project’s style with them as stuff to experiment with. Encourage positive, open honesty about what works and doesn’t, but give everything a fare shake.
- Balance innovation with respect for existing team members: A team member coming off a high-functioning team project, whether voluntarily or not, should not be set up as the “fix” for team issues. That’s threatening to the new team, both hierarchically and to each team individual, as well as a huge hurdle of heroism for the new member. Been there, done that, and between the pain of the layoff that blew up my old team and the resulting “I’m still here and they aren’t” survivor guilt, and the challenges of the team that I was dropped into, it was was hard and did not go well at all. I moved on pretty quickly from that one. Which leads to
- Accept that the new team member might move on more quickly than other new members. Why? Because s/he knows what a gelled team is like, and is trying to reproduce that. Or because s/he knows that the new gig was a landing place to figure out the real next step. Or cultural incompatibility. Or because of team chemistry. Or just needing time to breath if the switch was sudden and unexpected. But don’t let this linger – encourage commitment (ideally to your project) rather than twisting. Twisting just drags everyone down.
And if you’re the team member that is in the new gig, you need to:
- Be prepared to roll with differences. They speak a different language here. Learn it and learn the culture before you speak too deeply and publicly of a glorious past. Especially if you do so in contrast to the present.
- Look before you jump in with suggestions, cultural changes, etc. Build the connections that enable you to do this without criticism, and without sounding like a One True Believer in The Old Ways ™. Because this team was already working well for itself – no need to change that immediately when you’re the only one used to the new ways..
- Decide quickly if this isn’t the right gig for you. Coming off a project rebound is hard, so if the first position doesn’t work out, analyze it quickly and look for a second place to go. But be fair to your current teammates by being honest with them about the process.
- Be kind to yourself. This is really hard, and frankly, if it was that great of a team, you’re probably still feeling a bit of mourning.
Had dinner with an old colleague from the most recent iteration of “best project I ever worked on” last week, while I was down at my company’s headquarters for some new work responsibilities. The latest project ended abruptly when some of us were spun out to work on a project that I hadn’t previously worked on; unfortunately the awesome project we were working on didn’t get spun out with us. Still, a few of us from that team were included in the spinoff because we can adapt and deliver fast as utility infielders. So I’ve been floating, putting together stuff for training, setting up IT procedures, etc. for a startup. Learning a lot, but the old team, the best I ever worked on, was split in multiple directions and the ones who are in the spin out aren’t working together in the same way as before.
It was great to see him, to hear what was up at the previous company, and to get his impressions of what was happening there and for his career after the changes. We reminisced about old times and the fun that we had, even as folks on the team disagreed (sometimes vehemently) and then boom! we were off doing something. As he put it, “We worked long and hard, but we knew why we did it, we wanted it to happen and be great, and we had fun doing it.” No better testament to a great project than that – makes my day! I offered to help in his career planning and made some suggestions of things he could explore, and talked briefly about the new company.
But in the end, it was clear to both of us that it’s time to look ahead, not back. Yes, that was a great project, one of those “highlight of your career” moments. But it’s done and no going back. Take the lessons and skills and apply them to new situations, because the future is ahead of us, not behind.
Next time I’m in town, I’ll look him up and I hope we can have dinner and we can talk about what’s new as well as what was. And I look forward to hearing that it’s great things for both of us that we’ve moved on to other things, things which can be even better because we can apply the lessons from the previous project and build on those to do something even greater. And who knows, we might work together in the future, since he’s one of the guys on my short list of people I’d call if I start a startup. Meanwhile, best of luck to him and to every member of that awesomely amazing team, and if there’s anything I can do to help or just to listen, let me know.