What Kind of Dev Manager Are You?
What Kind of Dev Manager Are You?
Zone Leader John Vester builds upon a list of established management styles to provide a baseline for Dev Managers to review their personal style.
Join the DZone community and get the full member experience.Join For Free
Just like traditional Agile teams, I maintain a backlog. In my case, the backlog consists of thoughts, ideas and sometimes ramblings that in time may find their way into a post on DZone.com or my personal blog.
As part of a monthly DZone bounty hunt campaign, one of the suggestions was to submit an article focused on Dev Managers. The bounty was titled, "What Kind of Dev Manager Are You?" After some thought on the topic, I finally pulled this item from my backlog and into my current sprint of articles focused on submissions for January 2018.
What Dev Manager Styles Exist?
If I were to ask the Dev Managers who are connected to me over social media, "What Kind of Dev Manager Are You?" I am certain the number one answer would be, "I have no idea that different 'kinds' of Dev Managers even exist." In fact, just a year ago, I was a Dev Manager leading an Enterprise Architecture team. My answer would have been exactly that answer.
Since we are Information Technology (IT) professionals, most maintaining some level of object-oriented programming during our careers, I figured that the Dev Manager attributes likely inherit from management attributes. Focusing on this super class of management, I found an interesting article by Joe Neely called "6 Types of Management Styles for Effective Leadership."
Mr. Neely identified the six management styles as:
Taking this base class and inheriting the attributes (or management styles) into the Dev Manager role, I arrived at six Dev Manager styles, buildt upon Joe Neely's design.
In the Authoritative management style, it is the Dev Manager's way or the highway. This is certainly a one-way decision-making approach where the open-door policy simply does not exist.
One might think that this style is dated, something that IT professionals lived through decades ago and has worn out its welcome in today's landscape. However, when one pulls away the shock factor associated with this style, some practical implementations do still exist.
Take Production Support teams as an example, especially in highly-regulated environments. Those team members must abide within set guidelines, where processes and procedures are not only documented, but required. As a result, the list of tasks completed on a daily basis are predefined and the team members are executing steps that have a high probability of resolving the situation.
The challenge to the Authoritative management style is the low number of valid scenarios where this can be applied. Additionally, Dev Managers employing this management style can struggle finding team members who can work in this type of environment for a prolonged period of time.
2. Bridge Builder
With the Bridge Builder management style, the Dev Manager is focused on building harmony between the members of the team. The goal is to make sure team members get along with each other in order to create a strong working environment.
As I noted in the introduction, one year ago I was in a Dev Manager role. Upon accepting the position, I was given a brand-new team made up of the brightest and most talented team members across the corporation. Since the team needed to sort out our roles and responsibilities, I employed the Bridge Builder style.
This was my best bet, since I seriously had some very bright team members with experiences and skills that place them in the leading edge of our field. I needed to balance keeping each team member challenged and focused with understanding what was expected of our team. When those two aspects did not line up, I needed to build bridges to close the gap so our team could deliver solutions that would be utilized by the teams we supported.
In hindsight, the challenge I saw with the Bridge Builder management style is that I felt like my team members did not respect me as their manager. I believe that if this approach was not the sole management style employed, the respect level from my team members would have been much higher.
The Inspirational management style allows the Dev Manager to incorporate the Authoritative and Bridge Builder styles with the underlying focus on resembling a coach more than a manager.
Recently, my son finished his final year of playing high school football. His high school football team was ranked in the top ten football teams in the United States for the entire season. In fact, during their final game for the state championship, 16 individual and 11 team records were broken. If interested, you can read the recap on the IHSAA web-site.
During a post-game conference, the head coach of my son's team talked about an in-game conversation he had with the future Division I college quarterback. The conversation was during a challenging section of a crucial game. He basically gave his thoughts and looked at the quarterback to ask, "Reese, what do you think we should do?"
This example is a perfect example of the Inspirational management style at work. The leader provides his thoughts, but immediately opens up floor for feedback. By doing so, the trust that has been gained is employed leading to a high probability that stronger performance levels will be gained.
The challenge to applying the Inspirational management style centers around being able to build trust with team members to the point where a coach-focused manager can lean on and empower the team members.
With the Egalitarian approach, the Dev Manager deems that everyone has an equal say in the decisions required by the team.
What comes to mind for me is an Agile grooming session where everyone has to agree 100% on the aspects and scoring of a given story. To get to this point, the team must have ample time to understand the views of others and reach a full consensus among the group. When the Egalitarian approach is employed successfully, the team will reach a high level of productivity, because their thoughts and views are part of the feature that is being delivered.
To me, this is similar to how I feel when working on projects as a hobby. A project where I get to decide how the solution will be designed, the tools and technologies I will use to create the solution, and acceptance criteria I fully understand. When working in this mode, I can't wait to get started and look forward to the time I get to spent focused on my solution.
The challenge to the Egalitarian management style is the required investment to allow all voices to be heard and for the team to reach a consensus.
5. Dog Sled Pilot
I referred to the fifth approach as the Dog Sled Pilot, because this is the scenario where the Dev Manager allows a group of driven employees to thrive, plowing the field ahead for others on the team.
The role of a dog sled pilot is to get the attention of the dogs and to make them start running. The dogs love to run and cannot wait to get started, they are just waiting for a signal in most cases. Once they start, the pilot behind them hangs on tightly and attempts to navigate as needed. Most of the time, the dogs know where they are going and are focused on performing strongly — for not only themselves but the other dogs around them.
Like the dogs racing at full speed, those team members driving the productivity reward the customer with features that are delivered in a highly productive environment. However, like the dogs which eventually tire, the driven employees can reach a level of burnout over time. The challenge for the Dev Manager using the Dog Sled Pilot approach is to remain focused on high performance and not on an obsession with short-term goals.
In Greek mythology, a phoenix is known to rise above the ashes of others — obtaining new life along the way. With the Phoenix management style, the Dev Manager rises above the situation and brings new life to the team.
A key quality to utilizing the Phoenix management style is the ability to listen carefully and closely. This requires time and effort to focus on what is being said and gaining a full understanding of the current state.
Once the situation is known, the Phoenix will understand the challenges and create the vision, helping the team see the light at the end of the metaphorical tunnel that was not comprehendible. This same management style instills trust in the team, with the reward of team members buying into the vision.
The Phoenix management style can be the most difficult to implement, since not all Dev Managers have the ability to become a Phoenix. Even those with visionary qualities often lack the ability to truly listen, which is an equally important attribute to gain the support of team members as they buy into the vision.
What Kind of Dev Manager Are You?
Taking the six management styles by Joe Neely and implementing them into Dev Manager styles provides a starting point to understanding what style applies to you now. Understanding the differences between each style can help set goals on how you want your management style to improve over time.
Of course, there is no right or wrong answer. Factors include the roles and responsibility of your team, the culture of your team, the type of support received by senior leadership and, of course, your strengths and weaknesses, as well as a host of other drivers.
Personally, I have utilized multiple of these management styles, based upon the situation and tasks assigned to the teams I have been fortunate to manage. The key is to understand how to differentiate between each style and understand the benefits and risks associated with each.
Have a really great day!
Opinions expressed by DZone contributors are their own.