Communications Between Technical Professionals And Their Managers

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. To read the full article, click .

Discuss this article in this thread. You can read the article here .

I like how you point out that over/underestimating deadlines can damage your credibility. In the past I've told my managers things will take longer than they should ONLY when that manager wasn't a technical person. Of course, there were exceptions, but this is the trend. When I'm lucky enough to have a techie manager, being honest with them puts them in the role of Scottie: they can communicate time estimates to their superiors based on my truthful estimate, which itself is based on my past turnover times for similar tasks.

When deprived of a techie manager, I sometimes switch to "damage control" mode, since in my experience non-techie managers tend to create unrealistic deadlines. Ironically I usually let them know my estimate may be unrealistic! If they have a marketing or business development background, they have probably grown used to this from techies

I have found it helpful to estimate on a task-by-task basis, and when/if the estimate needs to be changed, I record this replanning data. Using this technique, I've been able to estimate my own turnovers pretty accurately. As developers, we can build things to automate a lot of this stuff!

Just some food for thought. Excellent article.


Mike Britton

It should not be at all surprising that a bigger team does not necessarily produce more or better work. The problem has, in fact, a technical analog in parallel computation. As you add processors to a task, you add communications requirements. Those requirements can indeed increase geometrically. At some point, the processors spend more time communicating than they do computing, and work output and efficiency both drop.

To the extent that you reduce the need for communications (again in analogy to parallel processing), you increase the efficiency of a larger group.