Regardless of the size of your development organization, everybody has specific roles to play. There are people who handle the day-to-day tasks that make the organization run-developers. There are people who make sure that these tasks fit with the organization's goals-team leads. There are people who define the goals based on their vision for the organization-software development managers.
Look into any development team, no matter how small, and you will find people filling these roles. On the smallest teams, one person may fill multiple roles. As the team grows, these roles become more distinct, and several people are often needed to fill the same role.
In keeping with their roles, software development managers are the ones who attend meetings with the organization's senior managers and officers. They see the organization from the perspective of profit and loss and long-term strategies. They don't always let their developers in on all of the details-nor should they. Software managers tell their team what they need to understand in order to be effective.
But when software managers withhold the wrong information, they inadvertently create an environment that is ripe for disgruntlement. They guide their teams by providing just the information they think the development team needs to get through whatever they, the managers, view as the next step. Unfortunately, this leads to a team fully dependent on the manager to provide all insight into organizational directions. Team members begin to feel like mushrooms-sitting in the dark, with manure occasionally being shoveled on top of them.
They don't see the policies being made; they see only the results. And sometimes those results don't make sense to them.
They feel jerked around. They feel small, as if they don't count enough to be told the really important stuff about the organization. They blame the software manager for this seeming lack of compassion. Meanwhile, the manager feels harassed by the team who keeps asking questions that "have nothing to do" with the work they are currently performing.
I call this gap between management and employees the "communication storm front." Just like a meteorological storm front, there is tremendous energy on either side of the frontal boundary. On one side, software managers are trying to maintain control of their teams in order to keep them moving safely toward the desired goals. On the other side, the teams are frustrated with the lack of information they receive, feeling trapped and unable to make the contributions that make them feel fulfilled. Just like a powerful thunderstorm, the communication storm front has potential for great danger.
As the gap increases, team members lose faith and trust in their software managers. At the same time, software managers feel threatened by team members who are overstepping the bounds of their jobs. The result is discontent, low morale, and high turnover.
The Skills Continuum
"The most difficult things in the world must be done when they are easy; the greatest things in the world must be done while they are small." -Lao-Tzu
When I started programming, too many years ago to consider, I had to learn the basics-programming language syntax, compiling, and debugging. As I became proficient in these building blocks, I was able to develop programs. I understood the basics and began seeing the patterns, concepts, and processes that combined to become a computer program. With more practice, I learned to define patterns and concepts so I could use them again and again. This proficiency resulted in my being asked to lead small development projects. To do this successfully, I had to learn what makes people other than myself tick. (I was actually surprised to discover that developers on my team looked at problems differently than I did!) People skills provided me with the tools I needed to influence others toward a common outcome.
Eventually, I became a software manager. I began to see some of the inner workings of the organization and how decisions were made. The higher up in management I rose, the more in tune I had to be with the organization's raison d'etre. I had to be able to interpret the values that make the organization work. I then had to communicate these values through the decisions I made and in the way I handled myself in my day-to-day activities. It wasn't enough for me to talk about the organization's values; I had to demonstrate these values to my team.
The skills required for a software development team exist on a continuum, as shown in Figure 1. Concrete skills, tasks that can be learned through repetition, manuals, and training anchor one end of the continuum. Abstract skills, like the ability to recognize and integrate the team's and organization's values and goals, anchor the other end.
I like this model because it can be applied to so many things we do in software development management. My team of leads and developers is responsible for understanding all of the details, the nuts and bolts of their day-to-day tasks. I trust them to know these details. It is far too much for me to keep up with, and they are the experts. I value them and their expertise by staying out of the way.
My job is to point them in the right direction. They depend on me to understand what the organization requires. When I communicate the mission of the organization, I am freeing my team to do the work they have to do and empowering them to align their activities with this mission. I help them by setting the example of the mission. I "walk the walk" and make sure I am available to my team to answer questions they have about direction.
I am responsible for keeping my team striving toward the goals of the organization. The team is responsible for producing the work products that allow the team and the organization to exist.
We have different responsibilities, but that doesn't mean I can't enlist the help of my team to achieve organizational goals-or that my team can't make suggestions to me about how things could be changed within the team to better align with the organization. After all, I view my team as an important part of what makes me successful in the eyes of my management.
I can represent my form of management on this continuum with one diagonal line (see Figure 2). My team is responsible for acquiring those skills and tasks that are "most readily learned," to the left of the continuum. These include detailed skills for their job and the processes they develop to make those skills more efficient. The most readily learned tasks are also those most easily obtained through texts, courses, and workshops. Where I can help in their learning process, I will. Otherwise, I make sure they are aware of all learning opportunities available to them.
I mentor the more advanced team members, grooming them for future leadership roles. I look at the way they organize their work and the way they communicate their requirements to others contributing to their projects. I start infusing people skills, using the organization's values and my own management experience. Again, where useful, I make sure to connect them with whatever training is available and appropriate.
Organizational values are not always cut-and-dried. Of all of the skills that make us valuable to the organization, these are the most difficult to communicate and to maintain. Of all of the skills we look for in choosing people for management roles, the capacity for these skills is the most difficult to evaluate. It takes time to understand what the values are and to integrate these into your daily work-sometimes years. And it is the manager's responsibility to make sure that the vision is communicated clearly, consistently, and without ambiguity.
How much of my managerial time and effort is devoted to communicating each aspect of my team members' job duties? Figure 3 shows this as a diagonal line in the other direction. I leave the acquisition of tasks and concepts to the developers who will use those in their day-to-day activities. My efforts focus on the more abstract issues of software development management that can only be learned through experience and contact with the upper levels of management.
As the manager I am responsible for maintaining the big picture for my employees. Managers see the organization differently than the developers. This is a simple fact of priorities. Developers are working too hard trying to achieve deadlines to spend time finding the right meetings to attend to get this global point of view. And the developers need to understand where they are in the organization and how their efforts contribute to the success of the organization.
Find Your Leverage Point
"What is softest in the world drives what is hardest in the world." -Lao-Tzu
Something interesting happens when these two graphs are overlaid. There is an intersection of the two lines somewhere between concepts and people skills. Did this happen by accident? I don't think so. My most effective development teams have been those that learned all they needed to know about the details of their projects. I learned just enough about their projects to ask the right questions to make sure the project was on track and moving in a direction consistent with what the organization required. My team saw my management technique. It worked for them. They wanted to learn how to manage others in the same way I was managing them. They would ask me techniques for teaching someone else new skills and ways of guiding projects that didn't feel like military drills.
These observations directly match the intersection zone shown in Figure 4. I call this zone "working at the leverage point." When all members of the development team, including the manager, are working at exactly the level they should be, the manager is getting the maximum performance from the team for the organization and the customers. Managers working too far to the left of this zone are in danger of micromanaging. The team will sense the lack of control over their actions and the perceived lack of trust from their manager. Morale can plummet; turnover can skyrocket.
Managers working too far to the right of this zone are at risk of leaving their team in the dark. When a team doesn't have all of the information they think they require, paranoia can set in. "Why doesn't my manager tell us what we need to know? Doesn't he trust us? Does he even know?" Again, there is the risk of low morale and high turnover.
Of course, not all development teams are equal-nor are all development environments. Suppose I have been asked to manage a newly created team consisting of newly hired developers. This team has a lot to learn, and the responsibility for much of this learning is going to fall squarely on my shoulders. In this situation, I'm going to spend more time working in the zone below the central leverage point. As my team comes up to speed, I'll shift my activities from teaching and coaching towards my more abstract management tasks. My team no longer needs me to help them with the details. As manager, I need to recognize when this transition begins in each developer on the team-and get out of the way.
I take a very different approach managing a team that has worked together for a significant period of time and has, as a team, solved some pretty advanced problems. In this situation, I join the team working in the zone above the leverage point. Most of my initial activities are going to support the team by sheltering them from the management details. When managing a well-functioning team, my job is to get out of the way and let them run-with gentle nudges to make sure they are running in the right direction.
Nobody said that management was going to be easy. Of all roles in software development, the balance required to keep a team working in the leverage zone is perhaps the most difficult.
How Can You Tell Where You Are?
Most of us have an internal barometer that lets us know when we're doing the right things well. I experience an euphoric rush of adrenaline running up and down my spine when I see my team taking off in the right direction because of my gentle nudging. When I miss, I feel tired. I have three questions that I use to maintain my management technique as close to my leverage point as possible:
Let's take each of these in turn.
Am I Happy?
First, if you're happy and you know it, clap your hands! No, really-it's hard being the manager, and if you are doing so with enough energy left over to feel good about yourself and what you're doing, you deserve a hand. But what if you aren't happy?
Take a look at how you spend your time. How much time do you spend working one-on-one with one team member? Are you training her in skills you feel she should already have? Are you telling her things that you feel she should already know? Are you wasting time telling her the same things over and over again? Why? You are at risk of micromanaging. Here's the trap: If a team member knows that the manager is always available to answer any and all questions, then she has little incentive to learn. You will always be there with some little detail that she should know by now.
It's hard to just stop, but you must wean your team from coming to you for every little detail. If not, your days will be spent on their projects instead of clearing the path for future projects. You will always feel "behind," like you just can't get caught up enough to get ahead. Now, the hard part-telling them "no." Force them to remember by asking them how you answered the last time they asked you that same question. You are beginning to take back some of your power. One, you have caught them being lazy, asking you instead of remembering. Shame on them! Two, you have let them know you remember and they had better remember, too.
Does My Team Show Respect?
I had a software development manager who would intermittently leave me alone (for weeks) to complete projects, then switch to peppering me with constant interruptions regarding my progress. I never knew what to expect. Did he think I was doing a good job and wanted to understand the steps I was taking? Or did he think I needed help and was providing it-at every opportunity he could. (What made it worse was that our cubicles were side by side so I couldn't even hide when I saw him coming!) This was frustrating to me, as I'm sure it was to him. My coping strategy was to ignore most of what he said, nodding affirmatively so he would Go Away!
My strategy as a team member wasn't terribly productive, but the experience helps me know what to look for in my teams when I've strayed too far to the left of my leverage zone. Most often, developers react with enough passive aggression to get the job done, but without the enthusiasm and creativity I know they could bring to the project. I lose as a manager because I'm not getting their best work. They lose as developers because they are withholding energies that make them feel good about their work. Nobody sets out to build a project that is substandard!
My favorite example of team buy-in is a commercial that aired during the Women's World Cup last year, featuring the U.S. soccer team-one of the strongest teams I have seen in a long time. This commercial has one of the women coming out of the dentist's office holding her jaw. The doctor tells the anxious waiting team that their team member will need two fillings. One by one, each team member stands and heroically proclaims, "Then Ishall have two fillings!" Their sense of commitment to each other was a critical component to their success on the soccer field. So, if you came back from the dentist with a new filling, how many of your developers would stand?
Does My Team Show Enthusiasm?
We have all worked on a project where we felt we were kept in the dark. For whatever reasons, our managers were keeping information to themselves. No amount of queries could shake loose reasons for the development project. If Management couldn't tell us why what we were doing was so important to the grand scheme, could this project be that important? We put in our time with the hopes of drawing a better project next time.
Watch the body language of your team. Are they striding with purpose or just shuffling down the hall? When you say "Hello!" do they respond in kind or just mumble something to get past the conversation? When they talk to you about their projects, do you see the light of enthusiasm in their eyes? Are they with you?
The worst jobs I have ever held were those in which my software development manager didn't feel I was important enough for him to spend time helping me see my place in the organization. This is my cynical interpretation; I never knew what the real reasons were. I did my job the best could, collected my paycheck, and eventually moved on. Now imagine your whole team working on projects for you with this kind of attitude. What can you, as manager, do about it?
Johanna Rothman, a colleague of mine and an occasional STQE contributor, publishes a newsletter that recently featured an article entitled "Rumors." Her recommendation is to start your meetings by asking for rumors others have heard. We all know there are rumors flying around the workplace. Why not just get them out in the open with as much factual information as can be found?
I tried this with one of my development teams, and the results were amazing! It became a light-hearted competition to see who could come up with the best organizational rumor first. As their manager, I often had insights into the facts behind some of these rumors. I would tell them what I knew to be true, what was still up in the air, and what I felt the chances of resolution might be. The team felt a part of the organization, not just a ball at the end of a chain being spun around. My open sharing increased their trust in me, and-by extension-the organization. Enthusiasm soared.
Caveat: You must be totally honest with your team when discussing this kind of information, even if it isn't what the team wants to hear. If you don't know, say so. If you aren't in a position to have that information, say so. If you don't feel it is appropriate to share that information, explain why in a way that retains the trust they have put in you and lets them know you aren't just blowing them off. Don't be afraid to say, "I don't know, but I'll find out." And follow through.
Bringing It All Together
The communication storm front is a real phenomenon that crops up in all development teams and in all organizations. You need not be the victim of such storms. You, as development manager, have the tools to reduce the power of the storm front and create a team that is ever more effective and efficient. Evaluate yourself often. Think about the questions and the answers. Turn the tables. If you were to ask your team these questions, would they answer the same way you do? If not, you may have a storm brewing. Catch it now while it's still manageable, and channel the energy in a constructive direction.