Leadership

A practical statement of what a technical project manager does


When we think of project management, we generally think about either software project managers or PMI certified folks who manage communication streams.  However, we rarely talk much about the life of a technical project manager, one of those competent folks who grew up though the technical ranks and took his place as a project leader though wit, skill, and the ability to communicate clearly to non-technical audiences.

These folks combine the often conflicting roles of technical manager, communicator, and quality assurance analyst.  They also assess technical risks, assist with technical problem solving, and cut though the layers of bull-feathers surrounding any given technical project to determine what is really going on.  Within their own technical areas they can estimate project time-lines to within hours of actual work; outside of it they can make accurate guesstimates based on years of technical experience.

More importantly, technical project managers think like IT professionals.  They understand the allure of difficult problems, the "explicit answer to the question we want to avoid" strategy IT people deploy to avoid conflict, and the need to save technical face for the team even when it would be easier to hang someone out to dry.  This allows them to get straight answers and good work out of employees non-technical project managers would classify as hopeless, negative, or uncooperative.

On any given day a technical project manager will:

  1. Write a status report
  2. Compose a dozen communications emails
  3. Help his team prioritize the latest set of technical issues
  4. Assist his team in identifying the problem at the root of several technical issues
  5. Employ one or more mitigation strategies for technical risks
  6. Pull at least one IT professional out of a tempting rabbit-hole - also known as an unrelated technical problem 

This work has to get done.  It also shades into the realm of team leaders, lead analysts, and others who might be more technically suited for specific tasks.  This creates a very confused situation, especially when technical project managers move from one organization to another.  What role do they play?  How does the technical project manager, with his technical background and grounding in IT methods, fit into a PMI process-oriented organization?  To what extent does he need to change, and to what extent is the role of the TPM simply misunderstood?

Oddly enough, I'm actually working on a book that talks about some of this in greater detail.  I'll post more about it when I've done some more research. 

12 comments
mhpries
mhpries

I loved this description. Very accurate. Except for the gender bias. Sometimes the right pronoun is she / her; as in she does this, her team does that.

#1Techtalentmatcher
#1Techtalentmatcher

I get this all the time, one type of PM against the other.

Tech PM non Tech PM always ones better than the other type animosity towards each other

There are pro's and Con's to both sides. I interview thousands of tech PM's, andnon Tech P's

Usually the size of the company is the biggest determiner why you have one versus the other.

The bigger the environment the more layers needed, and sometimes its just in the Coulter DNA of the company, but Tony there are an upper 10% of Tech PMs that are capable of both Tech and PM best Practices, and why hire someone who is considered in the upper 10%

Tony Hopkinson
Tony Hopkinson

to within hours of actual work. What the heck use is that? If any one told me they were a technical PM because of their ability to do that. I'd assume they were technically and managerially incompetent. Someone else estimate is useless. Perhaps it would take me four times as long, or a quarter of that time. As for being accurate to a number of hours, I am laughing my arse off. That's precision, six months actual for a task estimated to take 1 year +/- six months is accurate! Now you might say it was bit high, but at what level of detail was it estimated. How many of the unknowns had been bottomed, how many times did someone important move the goal posts. How does what you actually achieved compare with what you thought you wanted to months ago? This is why most IT projects fail, this foolish assumption that there's some one right way to do it, that a reductionist approach to a system will be effective. A PM manages expectation, the others are a waste of space, no matter their background.

Tony Hopkinson
Tony Hopkinson

As`nice as the thought is of having a PM who understands what you are taking about, one who's incapable of applying their knowledge to managing the project, is worse than than one who is knowingly ignorant of the issues. I'd rather explain myself to the non-technical, than miss the issue through an assumption made by someone not doing the work. The rabbit hole could be a very useful short cut. I don't care how good they are technically, they can't hope to be as aware of the underlying technical issues as their people and manage at the same time. Background is always useful, technical, people, domain, but management is what's required. leave the technical gubbins to us, it's our role.

IKL
IKL

The "practical characteristics" described in this post are those of a subject matter expert. Regardless of how glorified the title is, it's still misses the number one trait of a project leader -- leadership. A "technical project manager" makes sure the paperwork gets done right. A leader makes sure the project gets done right, paperwork or not. And that ability makes all the difference.

prosenjit11
prosenjit11

This is something which is true. Important is honestly execute projects, no matter if there are dozens of emails and sometimes bugs the non-technical managers, there are situations when it becomes difficult to predict and give a judgement on the current situation depending on the complex dynamics of the project and customer requirements. Most important at that particular instant is get to the core root cause and start providing detailed answers to show the light at the end of the tunnel and also put into consideration what should not be provided to them protecting the interests of the organisation. Sometimes some reports wanted by customers or schedules are very ambitious creating conflicting situations. The Project Leader takes it as a responsibility to clarify the technical requirements and the demands and co-ordinates with the entire team and with his technical experience and analysis answers all the queries with a thorough system analysis working out the hardware and software customisations and complex dynamics of a compromise on the requirements protecting the interests of both the parties, the organisation and the customer. No matter doing this he may get negative remarks or sacrifice his job. A project executed from a challenging situation is job satisfaction.

jfederline
jfederline

The bullet list is on the money - nice. The tech PM keeps the techies focused on the most value-add technical task at hand - job #1!!! And they leverage their understanding and rapport with techies to skip over communication barriers that slow down some non-tech PMs, by leveraging their technical knowledge. The true value proposition for hiring technical PMs...

18th Letter
18th Letter

You are on the money with your description of a Technical Manager. However I have found that the role you play in the organization usually determines who gets to lead the project, i.e a Network Admin would actully be the Project Manager for a major router upgrade project. During that project he most likely fits your exact description. I said that really just to say that soo many technical folks fit the description & just don't know it..It can be a very bennificial point to add to your resume. Thanks for the post.

D2KK
D2KK

You forgot an IT PM also - help define user requirements - interface with the outside customers - interface with the operations or IS teams - accompany the product manager on customer visits - generate and report metrics - plan the team's activities for the next month - monitor staffing allocation and reallocation - provide input to Product roadmaps for year - plan team projects and staff allocations appropriately to balance customer funded projects and internal "must do projects" - and on, and on If your company is anything like where I am, the same person performs the role of PM and line manager. The blending of responsibilities gets pretty overwhelming some days.

duckboxxer
duckboxxer

Loved the post. I'm trying to get into project management and away from the code itself. But I do most of the tasks listed. My problem is I wear many hats right now. I take on the a number of the tasks mentioned, but I am still doing a chunk of the design and coding. There has always been an official project manger on projects I work on. So on my resume I simply can't put project manager, because that's not my real title and role. Best I can figure out is Analyst, which can mean anything really, and then list management tasks. Honestly my development skills are growing weaker by the day due to all the other things I do (and the old, crappy system I am supporting). A friend of mine said if you skills are rusty, you are in management. .... So anyone in DC that needs a web-based project manager.... :) Just had to throw that in.

Tony Hopkinson
Tony Hopkinson

"right". : D That's a concept redolent with ambiguity.

cln
cln

Wearing many hats makes it difficult to do things well. Some things suffer, especially the management portion, if PMs also have to perform line manager responsilities such as performance reviews, priorities, assign tasks, review tasks, etc.

Editor's Picks