The Collaboration Commission – Part 1

Recent events pushed me into a burnout phase at work. This provoked a lot of things, my posting on Learning to Manage: Recovering from a crash being one of them. That same day, the power of community shined its light on me. A fellow data professional read the blog post and reached out with a recommendation.

As of this moment, I have a list of three more books which I plan to read on this topic and I am only on page 90 of The Responsibility Virus.

The author explains that the first third of the book is about defining the problem and the last two thirds of the book are about setting up an effective strategy for inoculating yourself and/or your team from the virus. I cannot keep my mind waiting in patience, however. I keep reading about my problems as if Mr. Martin observed my team and my behavior before writing his book. This sends my mind off into a cyclone of new ideas on how to solve my problem while waiting in eager anticipation of hearing by Mr. Martin has to recommend.

My biggest question is:

Can a team, which has already fallen into a pattern of mistrust and resentment, recover?

Problem statement

Myself, my team, and my project likely have multiple areas of improvement. As I seek education on management and leadership skills, I should focus my efforts on what problem(s) I am trying to solve.

This leads me into writing a proper problem statement. I have chosen one area to focus on as my first step.

My team is infected with the responsibility virus. My behaviors of over-responsibility (heroic leadership) has caused others to react as passive followers and it has fanned the flame of fear of making mistakes. This cycle has caused me to resent and mistrust my team.

This situation has stifled collaboration and has already caused us to miss a deadline which has not yet come.

Background

Phase 1

Heavy load

Nine months ago we started a project which was enormous and planned to take over one year to complete. At that time, we built a small team.

Myself as the Solution Owner

Two employees

Four consultants

The initial team dynamics were acceptable. Generally, the entire team was invited to talk through design decisions and had input into what we were going to be doing.

I was capable of:

Directly managing the tasks of the team (Scrum master or Technical Manager)

Acting as, “THE UNBLOCKER.” Managing all cross team dependencies and resolving everything from legal negotiations to working with IT Security to helping the team reset their passwords.

Weighing in as lead Solution Architect

Acting as Product Owner (defining scope and managing the legacy system analysis)

Acting as legal and vendor liaison (negotiating contracts and business terms)

Continuing to directly manage four other employees which were not on this project.

While the dynamic felt acceptable, for the scale of work and people, the responsibility virus was already beginning to take hold. The team would reschedule any meeting which I couldn’t attend. They had already abandoned any chance of acting on their own and then reporting. Their highest level of initiative was to recommend and seek approval, whenever they weren’t simply asking what to do.

Phase 2

A couple of months later, some of our foundational tasks were complete. We were already behind schedule with many of them but we blamed external factors like the availability of other teams’ support and carried forward.

Supposedly ready for the bulk of the project’s labor, we expanded the team.

Myself as the Solution Owner (Solution Owner = that long list of roles from above)

Three employees

Twelve consultants

It was during phase 2 that I began to realize that I was in trouble. First, I was responsible for resourcing and had not planned for any team leads or any sort of management structure in my team, other than myself. I rapidly realized that I could not function properly with all of my roles plus to increase in my number of direct reports.

This is when I tried to implement team leads by using the best resources that I had available. I selected three leads which would head up three major functions of the project and sought to empower them to take my Scrum master and Technical Manager responsibilities. This “empowerment” school of thought was that I could simply push down power and responsibility and then sit back as a passive observer, allowing them to handle things.

Passive observer (follower)

This did not work. The problem being that I was handing down authority and expectations but I was not handing down capability. Each of the team performed at different levels but each of them accepted their role with noble intentions to try to fill the team lead shoes while acknowledging that they had not performed these duties previously.

Another factor, which was unknown to me at the time, was that I was only performing each of my roles at some percentage less than 50%. This was making it harder and harder for us to manage tasks and manage project dependencies. Also, delegation of this one role was insufficient. I still held too many full time jobs. If anything, the growth of the team added more to my shoulders than I was removing by making the team leads. So, I never felt any form of relief what-so-ever and my resentment grew with every work item which was not completed on-time and with every sub-optimal technical decision they made.

Phase 3

I had a mentor who was trying to help me with personal and career goals. He had recommended a number of strategies and a number of pieces of reading material. One of them being, Measure What Matters: How Google, Bono, and the Gates Foundation Rock the World with OKRs, by John Doeer.

I learned a lot from OKRs and thought to try and get my project back on track by inspiring a sense of shared purpose and clarifying project goals. I thought that we could make major improvements by getting the team to buy into the speed and quality of work that we needed in order to meet aggressive timelines. In effect, I was trying to combat the passive followers which I perceived to be the problem. Without understanding or acknowledging how my own tendency to snatch responsibility and control was contributing to the issues.

In addition to this, I received my third project manager. TIME-OUT! I know what you are thinking. I never mentioned a project manager. True. That is because I was doing all of the project management work. I had two separate PMs assigned to this project and neither contributed much. I mentioned my third PM because he was different. He, from day one, has been an all-in kind of guy and has contributed directly to trying to get this project moving forward.

With the addition of a PM, we collaborated and many ideas for improvement came out of these discussion. To name only a few:

We also realized that more human power was necessary to hit our deadlines because we were not achieving the per developer velocity which would be necessary to get on track.

This is when we added an India based team of thirteen to the project and I officially had more people directly reporting to me than exist in my sub-department.

Next

All of that culminated with my burnout and the need to make changes. Now that I have defined one of our problem statements it is time for me to learn how encourage the team to rebound from the unhealthy state that we are in.

Problem statement restated

My team is infected with the responsibility virus. My behaviors of over-responsibility (heroic leadership) has caused others to react as passive followers and it has fanned the flame of fear of making mistakes. This cycle has caused me to resent and mistrust my team.

This situation has stifled collaboration has already caused us to miss a deadline which has not yet come.

I hope to make this blog series a journal to document the journey I take while learning the answer to my first question.

Can a team, which has already fallen into a pattern of mistrust and resentment, recover?