LinuxWebLog.com

Introduction

As a manager in charge of technical professionals, I have learned that managing projects with multiple team members requires certain people skills, as well as technical skills. In the world of management, there are many skills required when it comes to the management of people. These skills, and how you apply them, vary depending on the type of business you are in, as well as the type of people whom you manage.

Technical professionals, in general, tend to be a little different to manage than the standard office workers. Their jobs are not just about doing a mechanical process, but designing and writing software is also a creative, if not artistic process. I’m sure that everyone has heard stories about artists and how temperamental and bizarre their behavior can be. Does that sound like any software developers you know?

I stated earlier that I am a manager in charge of technical professionals, but before I was a manager, I was in the other side of the spectrum. I started my career as a software developer, and worked my way up through the ranks until I got where I am now. I have worked for many managers, some of whom understood technical people and much more who did not.

In this article, I’m going to discuss a number of points from both sides of the fence, that should help technical professionals and their managers work better together. We will begin with effective ways of managing technical professionals.

Get To Know Your Team

I mentioned before that your technical professionals don’t always have the same motivations as your typical employee. For starters, technical prople are interested in having an impact. They care about getting the proper credit for their accomplishments. It is very important when working with technical people to give them praise for exceptionally good work. A few well chosen words will go a long way to please your team members, especially when you give them credit in fron of their peers.

Since your technical people are scientists or engineers by training, it stands to reason that they really enjoy to solve difficult problems. Tackling a challenge can be a very fufilling experience for a lot of technical professionals. The more you can make them feel like they are part of the solution for a big problem, the more apt they are to excel in their performance.

Technical professionals are typically nearly as motivated by the work as they are by their compensation. They like to feel as if they are part of the project, all the way up to the decision making process. When your team members feel that they contribute to your projects on a higher level, it makes them more dedicated to the success of the project. Compare this to a factory worker who does the same thing over and over all day, and watches the clock until it is time to leave. With your team excited and dedicated to the project, you have a better chance of success than the factory worker mentality of many other jobs.

Make Your Professionals Feel Part Of Your Team

The way I go about making my team members feel involved, is to engage them in conversations in regards to the project, and discuss with them what we are trying to do as part of the team. Even when I have a plan in mind on how best to achieve my project goals, I organize a meeting with my team and explain the purpose of the project. I then outline my plan to achieve our goals, and ask for input. Ive been working with my team for some time now, so they know from experience that I am open to all suggestions and comments. You would be surprised on how often, no matter how good your design is, that better ideas can and often are suggested by your team members.

I often have a follow-up meeting a few days later to finalize the design, since many ideas may occur after the fact. If you listen to design suggestions and have discussions among the whole group as to the pros and cons, you can make a decision at the group level on how to procede. Don’t get me wrong, the decision is still yours. But technical prople, by nature, and very logical. In general, as long as you consider everyone's ideas, most teams react well to management decisions. If you have to make a business decision that conflicts with what your team wants to do, they will accept it as long as it is truly a business decision. Although, if the decision is based on a personal preference by someone who they do not respect professionally, then they will never agree with it. That being said, if you are facing a decision that you know will affect a team negatively, it may be beneficial to pass that decision through a developer who has that team's respect.

If you can get your development team to agree with what you are trying to accomplish, you might be amazed to see them self-organized to achieve that outcome. I’ve come to find that they can and will decide among themselves how best to distribute the workload, based on who is best suited for the different tasks at hand. I find that it is important to decide with them on what is going to be accomplished and how it is going to be done. If you don’t, you are going to need to find out exactly what it is what they are trying to accomplish; because regardless of what you want, that’s probably what they are going to do.

Keep Your Team Productive

One thing that took me time to realize, is that every group or team of developers has a natural leader. A natural leader is someone who the rest of the team respects, and goes to with questions and problems. This person typically has no problem making decisions and lending assistance to other members of the team. Problem is, this natural leader is very often not the official leader of the team.

If you have properly motivated your team, you will be able to recognize your natural leaders pretty easily. One of the key methods to keeping the team happy and productive is to make sure that your natural leader is well equipped. This may seem like favoritism of sorts, but it is not. I’ve said earlier that technical professionals, developers in general, march to the beat of a different drum. If you can find the right sheet music, your team will happily march to your drums. The natural leaders are one of the key elements to such a success. Nurture the natural leaders, and in essence you are nurturing your entire team.

Another method of keeping a team productive is with a good influx of peer-group pressure within your teams. Technical professionals care a great deal about how they are perceived by their peers and team members. If they know that their peers will publicly critique their work, it will motivate them to do better. Technical people are very good at judging their own, and will often be very harsh with their team members. An example of constructive peer pressure would be to have team members present project design ideas to the rest of the group. There are many developers out there who are arrogant, and frankly not as good as they think they are. I’ve found that using the team approach has been a very successful method for dealing with such an issue.

Find The Right Size For The Job

The size of your project teams can affect their productivity. As a general rule, keep your teams small to keep them productive. It seems that in the software business, a large majority of problems occur as a byproduct to the efforts of large group of people. Some companies tend to solve a problem by gathering a large team of people and instructing them to fix it. In our industry, this is almost never successful. The reason for this, is because when your team is very large, an individual’s contribution to the solution is very small. This, in turn, leads to a drop in overall productivity.

There are many industry examples of this phenomenon. The fact of the matter remains, that the smaller the team is, the faster the members of the team will work. When you add too many members to a team, you actually make the project take longer, because of the overall drop in productivity. This may seem shocking to you, because it does not make sense on paper, but it does occur in our industry. This may not be a problem for small to medium sized companies, but for the bigger companies this can be a serious problem.

If you have a large project that does require a substantial amount of members, it would be beneficial to break the larger project down into smaller subprojects. Keeping the teams small and focused on certain pieces of the puzzle will help keep productivity at a maximum, and your project on schedule.

In summation, technical professionals are people just like everyone else that you work with. But due to the nature of how they think, and more specifically how they work it is important to understand how to deal with them from a management level. I’m hoping that my experiences with managing technical people will be beneficial in helping you better understand your technical staff, if not be better equipped to manage them.

Tips For The Technical Professional

As I said before, I used to be on the other side of the fence. Unfortunately, few managers understood how to motivate me. After some time of frustration, it dawned on me that if I wanted a change in how I was managed, I would have to do something about it. In my time I’ve broken in numerous managers who had not a clue how technical people work. There are many things that even the developer can contribute that can make the relationship between manager and employee more productive and beneficial for both sides.

Learn To Communicate

You might look at this topic and completely miss what I mean by it. If so, then the very fact that you don’t understand illustrates my point. Technical professionals, by nature, are very logical. While this is extremely helpful when working on projects, it can often be problematic when communicating with management, or anyone else for that matter.

Before I learned to communicate effectively, I had a very bad reputation. I could not be trusted to speak to customers or managers of other departments without having one of my immediate managers in the room. You see, when I would say something, what I said was logical and to the point. The problem was not the content of what I said, but the context in which I said it. In other words, it’s not what I said that was the problem; it is how I said it. Luckily, my immediate manager at the time understood technical people, and would quickly translate what I said into the appropriate communication.

As luck would have it, the above-mentioned manager was later replaced. His replacement, unfortunately, was not so familiar with the workings of the technical mind. In the very beginning of working with this new person, it felt as if he was an adversary. He was always questioning the things I would say, and was never happy with my explanations. It didn’t dawn on me until later that maybe he just didn’t understand what I meant.

So, the next time I spoke with him, I took the time to think about what it was that I was going to say, and then how I was going to say it. It was difficult at first, since technical people seem to share an affinity for speaking quickly and very logically. But as I was speaking with him, he stopped me at one point and said “I don’t understand that, can you explain it to me?