How Process Street Facilitates Teaming and Retains Company Knowledge

“It is largely determined by the mindset and practices of teamwork, not by the design and structures of effective teams. Teaming is teamwork on the fly.” – Professor Amy Edmondson, Teaming: How Organizations Learn, Innovate, and Compete in the Knowledge Economy

When I started this post for Process Street, it suddenly occurred to me exactly how much of my time is spent on the concept of “teams” – writing about them, talking about them, thinking about them, participating in them.

Teams have taken over my life. It was only a matter of time before I ran into “teaming.”

Teaming was coined and developed by Professor Amy Edmondson, who also has the rather distinguished achievement of founding the MIT Leadership Center.

Obviously, she’s a very qualified person who knows what she’s talking about, but when has that ever stopped my skepticism before?

I’m kidding. Teaming is an idea purpose-built for the contemporary tech-centric, remote office, pivot on a dime work environment. This post will explain what it is, how it’s been used, and how Process Street makes it easy for anyone to adopt.

• “Teaming on the fly”
• Successful teams, teaming, and a Chilean mine
• Teaming the Process Street way

Let’s team up!

“Teaming calls for developing both affective (feeling) and cognitive (thinking) skills. Enabled by distributed leadership, the purpose of teaming is to expand knowledge and expertise so that organizations and their customers can capture the value.” – Professor Edmondson, Teaming

Team dynamics can make or break a project.

If you have a strong team where the members all communicate well, support each other, and maintain mutual respect, the work – however complex it might be – won’t be unachievable.

On the other hand, if you have a team where information isn’t shared effectively, members refuse to compromise, or one person ends up shouldering more than their fair share, the chances of realizing your vision are pretty slim.

In 2002, Harvard psychologist Professor Richard Hackman conducted a study on team effectiveness. As a result, he determined there are five conditions that increase a team’s chances of success:

1. Is the group a real team, with clear boundaries, interdependence among members, and at least moderate stability of membership over time?
2. Does the team have a compelling direction with a clear, challenging, and consequential purpose that focuses on the ends rather than the means?
3. Does the team’s structure (task, composition, and core norms of conduct) enable rather than impede teamwork?
4. Does the team’s social system provide the resources and support that members need to carry out their work?
5. Is competent coaching available to help members handle obstacles and take advantage of opportunities, and is this coaching provided at the most appropriate points in the team life cycle?

This model is very effective in the design and management of effective teams – provided those teams and their leaders have the time to learn each other’s behaviors and establish trust over the long term.

This is the flaw – or caveat is probably more applicable – that Professor Edmondson identified. Fast-moving organizations – like, say, a start-up, for instance – don’t have the luxury of relying on teams that work as established, static entities. Instead, they require teams that are flexible and agile.

These teams aren’t so much built around specific team members as specific roles, responsibilities, and processes. Knowledge is communicated so accurately and precisely that anyone can step into a role and perform its functions flawlessly from the start.

This is, essentially, teaming.

According to Edmondson, for teaming to work, you first need to build a culture that reinforces the idea that teaming is expected and feels natural.

Establishing this culture requires that those involved share three very important characteristics:

• Curiosity
• Passion
• Empathy

“Curiosity drives people to find out what others know, what they bring to the table, what they can add. Passion fuels enthusiasm and effort. […] Empathy is the ability to see another’s perspective, which is absolutely critical to effective collaboration under pressure.” – Prof. Edmondson (emphasis mine)

If you model these characteristics as a leader, your employees will naturally follow. A leader who shows genuine interest in hearing others’ ideas will encourage employees to share those ideas more frequently. This ultimately leads to your employees feeling more valued and therefore more invested, as well as generating loyalty and trust.

In addition, it also establishes knowledge sharing as a natural part of any process. Employees will be more likely to learn from their peers, as well, and that sharing will lead to more empathetic interactions – or, at least, the ability to understand other team members’ thought processes.

As for passion… Well, think about a task you dread doing. Do you put a lot of effort and attention to detail in completing that task, or are you more focused on getting it done as quickly as possible?

Now consider something you enjoy. How much time and energy do you put into making sure every aspect of it is exactly the way it should be?

Even the most dedicated worker will usually skimp on projects they aren’t invested in to focus on a project they have a stake in.

Professor Hackman has his 5 conditions for a team’s success; I say there are 9 elements. If these 9 elements are present, regardless of how long (or little) a team has been together, they can be successful.

The “vital” part of these “vital elements” is that a majority of them should be in place well before the team is. If you aren’t forming a team that has a clear direction, defined roles, achievable goals, and built-in accountability, that’s your first problem. You absolutely cannot have a successful team without a clear vision of who is going to do what, why, and towards what aim.

You also need to make sure your team is able to offer different perspectives, experiences, and insights. Think about this:

Crash test dummies were designed in the mid-1970s to represent the “standard” driver: a 5’9″ 170 lb man.

There’s an obvious gender bias there that puts a huge portion of the population in danger, but “things were different back then,” right?

Well. Those exact same specifications are still in use – despite no longer even matching the average American male in terms of size – which means that a woman has a 73% greater chance of being injured in a frontal crash, and 17% more likely to be killed.

Even as recently as 2019, the “female” test dummy was just a scaled-down version of the male one, and is small enough to double as a 12-year-old child.

I wonder what test dummies would look like now if more women had been on that design team. Or at least some men who could imagine a world where women drove cars.

The final three elements are open communication, collaboration, and trust. Open communication and successful collaboration are inherently entwined and, it goes without saying, a natural result of trust.

Now, I’m not talking about trust in terms of shared bank details or deciding whether or not to pull the plug if you’re in a coma. When it comes to teams and teaming, you only have to trust that every member will do perform their role. That level of trust is usually established – or not – very early in the collaboration process.

Possessing all nine of these elements is a pretty good indicator of success. Even with only possessing most of them, a team can likely achieve its goals. The fewer of these elements present, however, and the more chance there is that you’ll end up with an ineffective and fractured team that can’t even decide what to have for lunch.

Coordinating the rescue of “The 33” from the San Jose mine

I know what you’re thinking. You’ve been a dedicated reader of my posts for a while now (I appreciate you, too) and know exactly how much management gurus and their clever buzzwords irk me.

So why am I drinking Professor Edmondson’s Kool-Aid?

Because teaming – as a verb – makes sense.

Think about it. When was the last time you built a team that stayed exactly the same? No one left, no one took on a new role, no one new joined later: everyone added to the team on Day 1 remained on the team on Day 492.

That never happens, right? There’s always some sort of shuffling of individuals, responsibilities, tasks, or even goals. I’d be willing to wager that Edmondson’s model of teams – where individuals may change from one day to the next – is more common than Hackman’s idea of a stable team nurtured slowly over time.

Take this example:

On August 5, 2010, an explosion at the San Jose copper mine in Chile left 33 miners trapped 700 meters beneath half a million tons of rock.

Initial estimates figured there was only a 10% chance of finding any survivors – a chance that diminished further after a second explosion a few days after the first.

69 days after the initial collapse, all 33 miners returned to their families, alive.

What began with President Piæera and Minister of Mining, Laurance Golborne, reaching out to their respective networks grew into an example of “extreme teaming” that involved hundreds of experts across every boundary – geographic, cultural, physical, organizational, professional – coming together to solve an impossible problem.

Rescuers were divided into three primary teams to each deal with a specific problem:

• Locating the men
• How to keep the miners alive if they found them
• How to get them out of the mine if they were alive

These primary teams inevitably formed into subteams focusing on specific aspects of the problem, communicating and learning from each other’s failures and discoveries.

“No one person, or even one leadership team, or one organization or agency, could have successfully innovated to solve this problem.” – Professor Edmondson

By coming together quickly and establishing efficient ways of communicating, rescuers achieved the unfeasible, despite the challenges of different languages, cultures, time zones, and even the fact that most were strangers who wouldn’t have had any reason to work together if not for this one exceptional incident.

I’ve never met anyone else at Process Street in person. While the introvert in me really loves being able to shut everything out some days, as a fully remote company, we’ve had to seriously max out our communication skills.

Likewise, being a start-up means everything happens fast. Teams move and change as new needs emerge and specializations are required. Some of those teams stay together long-term; some of them are only collaborating for a single project.

Basically, we’re teaming all the time, and Process Street workflows help us do it.

One of our company values is to overcommunicate. When I first started at Process Street, I thought this meant I had loads of redundant conversations and meetings in my future. I was wrong.

Overcommunication is about not being stingy with information, and it’s a vital part of working asynchronously.

For example, our graphic designers are literally on the other side of the world from me. We’re almost never available at the same time unless one of us is working either very late or very early.

When I make an image request, I have to think of every single piece of information they might need to create that image or we’d waste days on what would have been a 5-minute conversation in real-time. I can’t make assumptions or presumptions about what they may or may not know – for one, I usually don’t even know which designer is working on the image until I get the finished product.

I use this process often enough that overcommunicating is just habit. But say someone new joins the team, and this someone – like me – doesn’t quite get what overcommunication means. In a fast-paced environment – particularly one where colleagues meeting their deadlines is often contingent on you meeting yours and vice versa – there simply isn’t time for someone to slowly learn how to do a process correctly through trial and error.

This is the problem our workflows are designed to solve. Every process we use is documented in a workflow that we can run every time we need to use that process.

So, there’s a workflow for requesting an image. That workflow prompts me to enter all the information the designer might need – what the image is for, what it should say, what it should look like, and so on. I’m also prompted to provide reference images or links to clarify what I mean and give them something to work from. We even have a standard format for citing sources for each image.

Someone could join the team tomorrow, be given a two-minute tutorial on that workflow, and be able to request an image just as effectively as someone who’s been here for years.

The TL;DR: Don’t be stingy with the information

For teaming to work, your processes need to be agile enough that anyone can come in, with zero experience, and run them without a problem. This does mean documenting pretty much everything in the thoroughest of thorough detail, and that can be overwhelming if you haven’t been doing it all along.

It also means, however, that it doesn’t matter who’s on your team today or tomorrow or three weeks from now; every process, no matter who runs it, will be completed the right way, every time. When you’re in the midst of teaming, with people from all sorts of backgrounds and experiences who may or may not have ever worked together, documenting your processes is exactly what you need to ensure that team – however long it lasts – is completely effective.

What are your thoughts on teaming? Is it an idea we need or a repackaging of what already exists? Tell us in the comments!