A Simple Mindset Shift Turns Ineffective Teams into Productive Organizations

My job is to make teams more effective.

I am one of approximately one hundred Scrum Alliance Certified Enterprise Coaches (CECs) in the world. For the past 10 years, I have consulted, trained, and coached teams at dozens of companies, including PayPal, State Street, edX, Carbonite, and many other enterprises. 

Many of these teams are not small. In many cases, I am working to solve systematic problems that can impact organizational layers that affect tens of thousands of people.  At other times, I am coaching groups of 50 people.

Over this ten year period, I have learned several major lessons about turning unproductive and low performing teams into highly effective organizations.

My experience is that the great majority of teams that succeed over the long term are the teams that “buy in” to the lessons that I discuss below.

My goal is to try to get everyone within an organization some exposure and practice to the three lessons - because the more people who are on board with these lessons, the higher the likelihood for long-term team success.

The three lessons are:

1. Develop and Use a Coaching Mindset
2. Respect Your Team As Experts
3. Allow People Doing The Work To Make The Decisions

 These three lessons are aligned with the following Agile Manifesto values and principles: 

• Individuals and interactions over processes and tools.
• Build projects around motivated individuals.  Give them the environment and support they need, and trust them to get the job done.
• The best architectures, requirements, and designs emerge from self-organizing teams.
• At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

1. Develop and use a coaching mindset

We need to integrate a “coaching” mentality into our mindset (belief system) and action.

To me, every leader (technical managers, middle managers, line of business managers) within the organization needs to adopt a "coaching mindset" which is different from a "telling mindset".

As a CEC, I am often challenged by people who say to me: "Just give me the answer", or "I just need to tell other people what to do". 

Because my job is to improve team performance, I need to remember to put on my “coaching” hat and wear the “telling” hat less often.

When going from telling to coaching, make sure you explain to the team members that you are striving to shift your behavior and explain why.  Collaboratively, discuss this change and come up with a solution that helps everyone.

The best way I know to learn about the coaching mindset is to take the free, online, self paced "Path to Coaching Program" powered by Scrum Alliance Labs. The program has over 80+ videos and 20+ hours of content and is divided into five modules:

• Module 1: Professional Coaching
• Module 2: Systems Coaching
• Module 3: Scaling
• Module 4: Sustainability
• Module 5: Coaching Leaders

This is the best introduction to agile coaching I have seen.

2. Respect your team as experts

We need to communicate our respect for the team’s expertise.

Leaders need to ask ourselves,

Do I respect my team as experts? Do I send a message to the team members that I respect them as experts? Does the culture on the team foster decision-making by the team members?

Let’s think about team members for a moment.

We’re taught as children that if we don’t know something, we ask our parents. In addition, many of us grew up in an environment where we learned to ask permission before we did something. Of course, not all parenting styles are the same and some parents give their children a small dictionary and the rule at home is,

Look up the word before you ask me.

We arrive into adulthood.  For many of us, that "deferral to power" (child to parent) carries into our work lives. For example, when we don’t know how to solve a problem, we "immediately" ask our boss. Similarly, we often ask the boss when we are seeking permission before we do something that we think is out of the ordinary.

All too often, the "asking the boss" process is not just a quick, one-step affair. We ask the boss. Then, the boss asks his or her boss. Then another boss is asked and so forth up the chain. All of this certainly goes against the business value of "fast".  As you have perhaps experienced, getting an answer back can feel like it takes forever.

Fortunately, there is a relatively easy solution. From a leadership and technical manager perspective, all we need to do is to learn to respect our team as experts.

For some of my clients, it is a huge mental shift, to respect team members as experts. For other clients, the mental shift is much smaller. In an agile environment, I have seen how respecting team members as experts leads to improved performed, morale, and self-confidence.

What are the benefits of respecting team members as experts?

• You can streamline workflows and decision making.  
• When there is more of this type of respect, people feel greater personal empowerment to find effective solutions without going to the boss for permission.  
• People also feel more confidence.
• People feel appreciated; it is good to know that the boss respects what you bring to the table.

Here is an example that I have seen and have helped to change.

A software developer is an expert in the code he or she is writing and constructing. There is a breakdown or issue. The software developer goes to his/her manager, and the manager takes the issue to the senior manager. Then, it’s the senior manager who makes a decision, which is relayed back through the manager and then back to the software developer. (Yikes – is this really agile decision making?)

Very often, the software developer already knew the answer.  Everyone could have skipped this exhaustive and time-consuming process by trusting the developer.  Remember:  you hired the developer because he or she had expert-level knowledge in his field.

As a manager, I ask you to consider:

• How do you come across to the people you lead?
• Are you seen as trusting the team’s expertise?

When you are perceived as trusting the team’s expertise, the team will be more empowered to make decisions which will improve overall efficiency and reduce extended decision-making times.

What can you do to demonstrate more respect?

Discuss with your team the subject of your demonstrating respect for team members as experts. You can do this in team meetings and during one-on-one meetings.

If you want the team to come to you with fewer requests for decisions, tell the team this is what you want, and why. Collaboratively, come up with a solution that helps the team members feel greater respect for their expertise.

3. Allow the people doing the work to make the decisions

Trust your team with their input and decision.

Another major tenet of agile coaching is this:  the people who do the work greatly benefit from making decisions about the work itself.  

In addition, the people who do the work often have important insights that need to be acknowledged and used when decisions are made.

Implementing this tenet is another proven way to turn unproductive teams into highly effective organizations.

I remember a time when I was hired by a software company to help improve team and organizational performance.  

The chief architect had decided on the infrastructure of a project. All of his developers were required to work within that framework, even though they had zero input. So, not only did the chief architect decide on the infrastructure, he did not ask for any input from the developers.

When I came to coach, the chief architect complained to me about the developers and their low productivity, telling me that the developers were not working correctly within the project infrastructure that he had created. The chief architect had told everyone, "This is the infrastructure you are to use". 

I asked if he would help the developers perform better with the infrastructure and he sarcastically replied, "Well, if I created the right architecture, they wouldn’t be able to develop it".

I burst into laughter. How could the architecture possibly be correct if none of his team could work within it? I mean, he is the one who developed it, alone I might add, and yet he was complaining about the performance of the developers.

This was a problem that I attacked.

What I want to emphasize here is this:  If your goal is to develop a highly effective team, then do not place all the decision-making power in just one set of hands.  

Although there may be exceptions, it just seems that in almost all work situations, multiple minds contributing to the whole (the solution) is better than just one mind. When you think about it, logically or passionately, what is there to lose by allowing the people actually doing the work to have more input?

By trusting your team with their input and decisions, you’ll improve several key facets of your office.

• Your software product will be stronger because the people spending forty hours a week with it will have more say in its development.
• Your teams will be happier and more confident and motivated.  

Which should sound like a win-win to any leader who wants the best from people.

About the Author

Michael de la Maza is an agile coach at Heart Healthy Scrum and Scrum Alliance Certified Enterprise Coach (CEC). As an Agile consultant, his major engagements have been with Paypal, State Street, edX, Carbonite, Unum, and Symantec. Previously, he was VP of Corporate Strategy at Softricity (acquired by Microsoft in 2006) and co-founder of Inquira (acquired by Oracle in 2011). He is the co-author of Why Agile Works: The Values Behind The Results and co-editor of Agile Coaching: Wisdom from Practitioners and Best Agile Articles of 2017. He holds a PhD in Computer Science from MIT. He is on email at michael.delamaza@gmail.com and on Twitter @hearthealthyscr.