Below is an excerpt from Tom’s Expectations For Project Management — a private document written for engineers who report to me and who are running projects in a technical lead role, which lists out a set of project management responsibilities and expectations.
I want to include a bit of an explanation about how I view project management. Hopefully this is useful context, and helps to make sense of the rest of this document.
A project is any deliverable that takes longer than about a week.
Software projects are dangerous. Smaller, individual bits of work like tweaks and fixes can’t really fail, but projects can, and often do. The last 60 years or so of the software industry have taught us that it’s actually quite difficult to run large software projects successfully. The consequences of failure range from slightly inconvenient to disastrous — affecting customers, the business, and the careers of everyone involved. Thankfully, software projects fail in somewhat predictable ways, which can be mitigated.
Most software projects are inherently highly uncertain, especially so at the beginning. The only way to achieve certainty is to release to production and observe the results. Uncertainty means risk, and so risk management is very important. Risk management is the most important aspect of software project management.
The ineffectiveness of waterfall-style project management tells us that no amount of up-front planning can guarantee success. In fact, heavy up-front planning is a predictor of failure. Due to the inherent uncertainty of software projects, the safest and most effective form of project management is an iterative one, where work is prioritised by its potential to reduce risk. This usually involves seeking feedback early and often, and continually adjusting the plan based on that feedback.
The definition of project success is social: if the stakeholders think it’s a success, then it is. Yes, there are objective measures of success, but those measures only matter if a someone cares about them. Put another way, if a project is successful based on objective measures but most stakeholders consider it a failure, then the project is a failure (and vice versa). Stakeholder communication is the second most important aspect of software project management. It could be the most important, but stakeholder management can be seen as a form of risk management, so risk management wins.
And hey, sometimes projects fail even when you do everything right. I like to frame them as “bets” because sometimes you win and sometimes you lose, but results are not random — typically, smart bets lead to good outcomes and foolish bets lead to tragedy. What matters is that we make the best decisions we can with the information that we have, and give it the best chance of success.
Failure isn’t necessarily a bad thing. If we fail fast, fail cheap, fail safe, and learn something useful in the process, that is also good project management. If the stakeholders are thankful for a fast failure that avoids a major disaster, that’s actually a success.
For engineers, project management is overhead. Every minute spent managing a project is a minute that wasn’t spent building the project. That’s not to say that it’s unimportant — it’s super important — but every project management activity needs to provide real value, otherwise it’s just waste. And I hate waste. I hate engineers being dragged into useless meetings, being distracted from what they do best. The goal is to run as lean as possible — to run the project effectively with the minimal amount of project management overhead. Small projects need hardly any project management, and the bigger the project the more it needs.
People do their best work when given autonomy, and that includes the choice of how to manage the projects they are leading. The best decisions are made by the people closest to the work, and so tech leads should be empowered to decide the best way to run their projects. However, autonomy always comes with responsibility — if you make the decisions then you also bear the consequences of those decisions. My primary goal for this document is to be clear about what you are responsible for as an autonomous tech lead for a project, not to dictate how your projects should be run. Recommendations provided in this document are just that: recommendations. You are free to ignore any and all recommendations so long as you’re able to meet your responsibilities some other way.