Over the years, in various positions, I’ve participated in many projects as a developer, lead developer, architect, jack-of-all-trades administrator, etc. I’ve also had the opportunity to lead technical projects as well.

This post focuses on techniques I have employed to successfully manage technical projects. Read on for tips regarding meetings, communication, and building your confidence.

Feature Image / License

What is Technical Project Management?

There are many different ways to define this; however, I’ll limit it to the scope I have worked with.

• Developing a new feature for a program
• Creating a new software application
• Architect a new system
• Manage a complex upgrade or migration
• Coordinate specialists for hard-to-solve technical problems
• Designing department policies and procedures for a technical group
• Lead custom projects for high value customers

In general, I define this as being the coordinator for some large piece of software work that actively involves people from various departments within the organization to produce some artifact of software.

That’s a mouthful! Let me simplify:

Managing technical projects is basically herding cats to produce a software product or build some technical component. It is your job to combine the work of your team to deliver something.

How Can I Be an Effective Technical Project Manager?

You need to have a set of skills – both “hard” and “soft”.

Hard Skills

You need to have solid technical skills and abilities to manage a technical project. I know there are plenty of PMs who are strictly on the business side but that isn’t the focus of this post.

You need to know the technical ins-and-outs of what you are managing because otherwise the smart technical people you rely upon will not trust you.

This is especially true if you are going to manage:

• Expensive people who do not directly report to you (this sort of matrix management is almost always present)
• Coach, train, mentor junior people

You need to understand the technology at least to the degree that an end user does. You don’t have to go grepping through source control but you do need to understand at a high level what the program is doing (sometimes known as the “flow”).

Soft Skills

I’ve found that you don’t necessarily have to be “good with people” but rather good with managing the work. Consequently, you’ll need a set of soft skills to help drive the project to completion. These usually include:

• Leadership
• Communication
• Time Management
• Adaptability
• Critical Thinking
• Detail Oriented
• Active Listening

Additionally, you might also have to be good with other factors:

• Organizational culture – know yours and make sure your style fits in
• Management style – most organizations have prescribed ways of doing things – what works and what doesn’t
• Languages, countries, cultures, customs – you might need to be keenly aware of time zone overlaps, English as a 2nd or 3rd language, foreign holidays, etc.

Advice for Managing Technical Projects

All that said – I want to focus on 3 things for successfully managing technical projects:

• Meetings
• Communication
• Building Your Confidence

Technical Project Meetings

Here you need to understand that meetings are an expensive use of time. The agenda and minutes are non-negotiable parts of your meetings. Lastly, action items are the end of our discussion and what drives progress for next time.

Meetings are Expensive

Your frame of mind should be that meetings are expensive. Consider your next meeting: add up all the people who attended, calculate their average hourly rate, and use that to estimate how expensive that 30 or 60 minutes cost.

• Not everything needs to be a meeting! Meetings should be a last resort and not a first line activity.
• Start on time and end on time – people will be more likely to show up and attend if they know you take their time seriously
• Project manager acts like an official – you are the MC of the project.
  • Cut off ramblers
  • Keep it moving along the agenda
  • Know when to shelf a conversation and take it offline
• Keep it concise and actionable
• Don’t be too familiar – you are not their friend. You are asking them to conduct work which are you directly accountable for getting done.

Agenda

Everyone should know, in advance, what you are here to discuss and decide. If there is no clear agenda there should be no meeting.

Minutes

If it isn’t worth writing down then it isn’t worth doing. There has to be some record of who attended, what was discussed, and what was decided. You will greatly benefit from this especially if you run multiple different projects at the same time and need to remember the details. Reviewing your minutes (that you wrote) can be a real time-saver.

Action Items

This is the key output from the meeting. A key part of project management is driving results. In order to drive results you must hold others accountable for the things agreed upon that must be done. This means chasing up on outstanding action items before the meeting.

How I Run Meetings

A few of the techniques I use here are:

• Share the camera for every meeting. It is nice if everyone does the same but more important for you in the leadership role.
• Share the screen and type up the minutes in front of everybody. This will help with a few things:
  • There can be no dispute after the call because everything was done in front of everyone. If something was wrong it should have been said during the call. This helps catch those who are overly distracted or asleep to be responsible.
  • It saves time rather than trying to remember it all after the call.
• Agenda goes on the invite – the top of the invite before the Zoom dialogue I put in bold letters the Agenda: WhatWeAreHereToDo
• Block off the calendar both before and after the scheduled call.
  • It’s not always possible but helpful
  • Before the call to prepare if necessary
  • After the call to pretty-up the minutes and get them sent along with any action items assigned to you e.g. setting up another meeting, talking to someone, getting approval, etc.

Technical Project Communication

It is critical to know your audience, understand RACI, and have good business writing. Speak with confidence and from a place of authority – you are the SME for the project! If you don’t understand what is going on then who does?

Don’t be afraid to say “I don’t know”. Make sure you follow it up with something like “I don’t know the answer right now but I will find out”. Then make sure you actually get back to them – no matter how trivial. If I say I’m going to look into something for you then you’ll hear from me about it.

Know Your Audience

Your audience matters – it often determines how you will deliver the message more than the content. Of course not everyone needs to know the same things so use discretion.

Speak to upper management with care. With them I like to communicate in this way:

• Be confident, concise, respectful, and high level – if anyone should know how the project is going it is you.
• I keep the communication high-level but always have the details prepared if asked. Some managers are more technical than others and will want to deep dive into the nuances.
• BLUF = bottom line up front. Executives have lots of demands on their time. Make it easier for you and them by putting the ask up top – then explain it.

RACI

Create a responsibility assignment matrix, aka RACI matrix, to help understand who does what.

• Responsible – this is who actually does the work
• Accountable – this is who is on the line for the responsible person for doing the work
• Consulted – these are people we engage in bi-directional communications
• Informed – these we only engage in one-way communication. We tell them what is going on.

A RACI chart may look something like this:

Business Writing

When writing for business, remember that it isn’t prosaic but terse. Think poetry without the elegance. Your written communication needs to be concise and actionable.

• Use bullet points instead of paragraphs
• Summarizing – do this up top and at the bottom. The explanation and details are in the middle for those interested
• Do this for all your writing ex. emails, group chats, IMs

ProTip: I use a lot of keyboard shortcuts. One for Outlook is Ctrl+Enter – this automatically sends the email you have open. To avoid sending half-baked emails, I like to put a string of characters in the cc. Ex. “zzz” will prevent it from being sent because it doesn’t exist in the GAL.

Building Your Confidence

If you do the above you’ll likely acquire more respect from your team and it will make your job easier. Unless you’ve been doing this for a while, it doesn’t come on day 1. You’ll have to earn the respect of your team and feel comfortable within yourself that you can deliver.

• Stop apologizing – only do it once and mean it
• Don’t show vulnerability – you are supposed to be in charge
• Know the product – understand at least on a high level the technology stack
• Know the different departments, teams, and key players
• Fake it until you make it
  • This doesn’t mean “be a giant phony”
  • You might have to do a bit of acting but make it genuine and authentic

Over time you’ll build confidence and find it much easier to work with others – especially those who do not report to you and you need to ask them to do work for you.

Summary

To be good at managing technical projects, you need to understand the technology well enough to follow what’s going on. If you can focus on running good meetings, getting good at communicating with others, and building your own confidence then I think you will prosper.

Thanks for reading!

---