How is it that high-performing teams work so well? Is it something innate? Is it luck? Or is there a repeatable formula that results in outstanding team performance? The spoiler is in the title of this post! Leaders can produce superior results by consciously managing team dynamics to create ideal environmental factors for a team’s unique demands.
It’s all about giving teams what they need to thrive. Here is the model we use to determine what a given team needs to succeed.
The Nature and Nurture of Teams
What forces decide who we are as people? What shapes us, determining our motivations, methods, or fears? Are genetics the primary determinants of behavior? Or is it a person’s environment, such as upbringing and life experiences, that form a person’s ways? As is often the case, the truth tends to be somewhat in the middle. It’s particularly difficult to determine which is more important, as for most people, our parents provide both our genes and the environment in which we are raised, and it’s the combination of those two that makes us who we are.
Applying this concept to project teams, both nature (the leadership and composition) and nurture (organizational culture and team history) are important in driving performance. And just as parents are often responsible for both in a household, so are we as IT leaders.
We have control over team values, behaviors, and culture. To be effective, we need to understand how to influence team behaviors and manage the dynamics that can make or break a team.
A Primer on Behavioral Profiles
One framework that seeks to define these models is called Structural Dynamics, developed by David Kantor. The Structural Dynamics model breaks down behavioral profiles into three categories:
- Communication domains: the specific words that we use to communicate our thoughts
- Action domains: the responses we have when we communicate with others
- Access domains: the group environment in which we work best
Each individual is partial to a certain combination of communicating, behaving, and interacting with others. This fact presents an opportunity to understand and use these preferences as a tool to improve performance.
Communication Domains
Recognizing various communication styles helps team members speak the same language and reduce misunderstanding.
| POWER | AFFECT | MEANING |
|---|---|---|
| Action & productivity Time-bound Completion-oriented “I do” “I want / need” | Trust & relationships Emotions Consideration of others “I feel” “I care” | Data & analysis Purpose & mission Ideas & understanding “I think” “I wonder” |
Action Domains
One team member’s first impulse after learning new information may not be the same as the others.
| MOVE | OPPOSE | BYSTAND | FOLLOW |
|---|---|---|---|
| Initiate Take action Be first | Challenge Push back Vet concepts | Connect Be unbiased Big picture focus | Support Carry ideas forward Get behind |
Access Domains
Some environments are better for certain outcomes than others.
| CLOSED | OPEN | RANDOM |
|---|---|---|
| Formal leader Defined roles Plan-focused Command-and-control | Egalitarian Process-focused Inclusive Collaborative | No process or structure Autonomy Individuality Creative |
Let’s look at a few examples of how these ideas can help change the course of real-world projects:
Turning Around a Death March
An IT department found itself in Year 2 of a 6-month system implementation. The project had been passed back and forth between various departments, reprioritized, frozen, restarted, rescoped, and everything in between. Executive satisfaction with the project was low, and nobody on the team actually believed the tool they were standing up—a contract lifecycle management system—would benefit them in any way.
The project team was not even the same team that started the project. In fact, almost everyone on the original project team had resigned, been reassigned, or been terminated.
It was a dreaded death march project.
In project management, a death march is a project that the participants feel is destined to fail, or that requires a stretch of unsustainable overwork. The general feel of the project reflects that of an actual death march because project members are forced to continue the project by their superiors against their better judgment.
Wikipedia
The current team members seemed to operate best in an open meaning model, which called for collaborative work involving understanding the reasoning behind each decision. Unfortunately, the organization as a whole operated mostly in a closed power structure, which is typical of large corporations. Here, senior leaders set deadlines and expected fast results.
We facilitated a workshop with the project team and stakeholders and asked:
- Why are we doing this project?
- Who will benefit from it?
- What do we need to do to get it done?
- Who can get these things done?
- When do we think we’ll be finished?
At the end of the day, the team came up with a new plan. Team members each took on various tasks to help drive the overall project to completion. The team became self-responsible, and morale improved significantly. After just a few weeks, we started to make real, measurable progress towards the final goal, which, in turn, increased satisfaction and engagement from executives.
Simply meeting the team’s need to be included, collaborate, and understand the reasons behind decisions created noticeable momentum. What had started as a project destined to fail went live in just 4 months.
Increasing Participation
On a recent ERP package implementation project, the Finance team had not been participating much. On top of the testing, validation, and calls required for the implementation, the finance team still had their daily duties to attend to.
The root cause of these conflicts came from a lack of advocacy from the main project team. If the Finance team reported issues, they would often get lost in the shuffle. There was little representation from their specific team in the debriefs, and tasks were handed to them without consideration for their preexisting workload.
Turns out, the Finance team operated mostly in open and random affect, which conflicted with the overall project team’s operation in a closed meaning and power model. Where the Finance team sought consideration or at least acknowledgement of their situation, they received explanations for why a specific task was important, and questions about when it would be done.
Naturally, without participation from Finance, an ERP implementation is not going very far. It was critical to get them on board.
First, we put together a list of all issues that the team had identified and put them in the pipeline for resolution. Once the issues they had logged finally started getting resolved, the team felt much more motivated to participate in the other project activities.
Next, we addressed the matter of workload. Finance was short-staffed to start, and the amount of testing and processing was difficult to fit into the schedule. After evaluation of the process, we found that some procedures could be taken off their plate and performed by those who had more bandwidth.
Quickly thereafter, performance greatly improved. Once Finance felt their input was valued by the project team, their concerns were addressed, and their relater tasks were relevant to their function, participation increased dramatically.
When the system went live a few months later, the Finance team was heavily involved in the project. They went from being one of the last teams to complete their tasks to being one of the first. Better still, once the system went live, there were fewer issues in the Finance module than in any other.
The Magic Formula
Team Nature + Healthy Environment = High Performance
When the optimal environment is created to support a team’s natural inclinations toward communication styles, action, and access, you have the formula for success.
