Communications Between Technical Professionals And Their Managers

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.

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. {mospagebreak title=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. {mospagebreak title=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 people, by nature, are 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. {mospagebreak title=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. {mospagebreak title=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. {mospagebreak title=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.{mospagebreak title=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?” I was shocked. We had been taking about this one portion of the project for 2 weeks, and the whole time he had absolutely no idea what I was even referring to. By just slowing down, and taking the time to think about what I was going to say and who I was saying it to, I was able to better communicate with my manager and we quickly got off to a great working relationship.

I quickly employed this method to all of the other channels that I communicated with. Within a few months, my bad reputation had all but disappeared, and I was actually sought after for technical discussions with internal teams and even customers, since I seemed to have developed an ability to discuss even the most complicated projects in layman’s terms even with non-technical people. {mospagebreak title=If You Dont Like How You Are Being Managed Make Suggestions} I’m sure you’ve been there. You are working for the manager from hell. He has all these requirements, and all these rules. You feel as if you are working in a concentration camp. This is not what you signed up for, and you are very unhappy working in these conditions. Your productivity is suffering because you lack the motivation to do your job effectively.

I’m sure that you know that your managers can tell when their employees are not happy in their environment. Believe it or not, they sometimes don’t have any idea exactly what it is that makes the employees unhappy.

One manager I once had didn’t seem to have any respect for developers. He wanted work to begin at 8:30 sharp, break for lunch at 12:00, and resume again from 1:00 until 5:30. During the day you were permitted a couple of 5-minute breaks, and of course the obligatory trips to the restroom. It was like working on a chain gang. The whole team dreaded coming to work and operating under the always watching eye of big brother.

Well, this manager could tell that the team was unhappy, so he sent out a questionnaire to his people, asking for suggestions on what we could do to improve the working environment. Know how many responses he got from the 19 people on the team? None. Not a single reply. Everyone was convinced that if they responded it would be used against them for being the only person to speak out. It was a trick. But in retrospect, what were we afraid of?

It was a couple weeks after the questionnaire went out when I found out that nobody had responded to it. I was in the manager’s office being lectured about being 10 minutes late to work. He expected my full 8 hours of work and was very disappointed at my tardiness. In exasperation, I asked him if he even understood what it was that we, as developers did. I think this took him aback, because he sat back and asked me if I would explain it to him. I talked about the nature of developing software, about how it was a creative process as well as a mechanical process. When I was done with my explanation, he asked me how I thought he could better manage the team. I told him that we were are professionals, and felt that we were being treated like children with his bean counting methods. I suggested that we be managed by our work being completed, rather than the number of minutes we sat in front of the computer each day. He agreed to give it a shot, and it worked out beautifully.

So basically, if you have a suggestion that you think will make your working environment more productive, don’t be afraid to voice it. That is, of course, so long as your request is within reason. {mospagebreak title=Work Well With Others} There are a lot of technical professionals out there who like to work alone. Well, unless you own a one-person company this is not going to be possible. It is important that you learn to work with effectively other people.

I’m not merely talking about other people in the same development team, I am speaking of the larger team you are on; your whole company. In a medium to large sized company, there are many departments and groups of people that you will eventually find cause to communicate with. These may include business analysts, quality assurance people, documentation writers, customer service representatives, and product deployment specialists.

All of these people work in different departments of the company, but they are all a part of the big team. Working effectively with them cannot only increase the well-being of the company, but make your job much easier as well.

Here’s an example for you. You, the developer, finish a complex program and turn it over to product deployment to be shipped to a customer. They put it on a CD, and mail it out to the customer who is waiting for it. The customer, upon receiving a code install that is missing something calls the customer service representatives for help. Going through their documentation, they can see no reference to the problem listed so they call the documentation department, who in turn calls you to assist. Since the problem has been through so many hands, they miss an important piece of information that would have helped you identify it quickly, and you spend a whole day trying to diagnose the problem before you realize what the issue is.

Instead of just giving your code to the product deployment specialists to ship out the door, if you take the time to explain to them the dependencies the code has and any intricacies of it’s configuration that need to be addressed you can save a lot of people a lot of time. The install instructions, written by the documentation department, would mention all steps and nuances of configuring and running your applications. If the customer still has a problem, a quick call to customer service should help him, since the customer service representatives have a copy of the same documentation and can assist the customer in achieving his goals, without having to involve the doc people, or yourself.

This goes for all aspects in your company. Not to mention, management always favors team members that work well in the team environment. In this day and age, if you are unable to operate as a functional member of a team, there is a good chance that you wont last long as a member. {mospagebreak title=Be Realistic} The last piece of advice I have for dealing with management is to be realistic. I’m sure that most people reading this are familiar with Scotty from the original Star Trek series. He would always tell Captain Kirk that is was going to take forever to get those engines working, and two minutes later they were zooming through space at warp speed.

Now, I’m going to brandish my geek credentials for all to see. In an episode of Star Trek: The Next Generation called “Relics”, Scotty makes a guest appearance on the new Enterprise with their chief engineer, Geordi LaForge. During the show, Captain Picard asks Geordi for estimates on fixing different technical problems. Each time, Geordi gives a precise estimate of how much time he believes it will take. Scotty, standing nearby, is aghast that Geordi told the truth. Scotty then encourages Geordi always inflate the time dramatically, so that when it was fixed quickly, he could seem like a miracle worker.

What Scotty didn’t understand about the Enterprise of the future is the same thing that many technical professionals today don’t understand about their team leaders today. Management, here on earth or on the starship Enterprise, is not looking for miracle workers. They are looking for team players that they can rely on. Each team member is a smaller part of a larger operation. The manager’s job is to get the smaller members to operate in such a way that they can all achieve a common goal in an acceptable amount of time. By not being realistic about the time involved to fix something, or even on the impact of certain design changes, you could completely cause a major scheduling conflict and affect the timely delivery of your project.

Even worse, overestimating, underestimating, and/or exaggerating any facts can severely damage your credibility with your managers and others within your team and organization. {mospagebreak title=That’s It} Well, that does it for my words of wisdom. I’ve learned from experience on both sides of the management equations, that there are many methods of making the interactions between technical professionals and their managers more productive. I hope that my experiences and suggestions can help others build a better work environment for their technical teams and management staff alike.
[gp-comments width="770" linklove="off" ]

chat sex hikayeleri Ensest hikaye