Managing a Project

Project management is the act of breaking a complex end goal down into smaller pieces, putting those pieces in roughly the most effective order they should be done, identifying which pieces can be done in parallel and which must be done in sequence, and attempting to tease out the unknowns of the project that may cause it to slow down or fail completely. You are addressing uncertainty, trying to find the unknowns, and recognizing that you are going to make mistakes in the process and miss some unknowns despite your best efforts. Here are some guidelines:

Break down the work. Get out a spreadsheet, or a Gantt chart, or whatever works for you, and start breaking down your big deliverable (say, rewriting your billing system) into tasks. Start with the biggest pieces, then break the big pieces down into smaller pieces, then break those down into even smaller pieces. You don’t actually have to do it all yourself. If there are parts of the system you don’t understand well, ask for help from the person who does. Get the big stuff broken down some, and then turn your attention to the ordering of the work. What can start immediately? Hand those tasks off to the people who can actually turn them into ticket-sized work.
Push through the details and the unknowns. The trick of project management is not to stop when you feel a little bit stuck, or tired of it. It is tiring and tedious, as I said earlier. And it’s not something you probably know how to do well. So keep pushing through it past those points of irritation, boredom, and pain. A good manager will sit with you and tell you where it isn’t good enough, ask questions to prompt you, or even work through some of it with you. We don’t enjoy it either, but it is part of the teaching exercise. Work through the unknowns until you really feel that there is no more value to be gained in spending time on them.
Run the project and adjust the plan as you go. The value of a good planning process is that it helps you know approximately how far the project has come, and approximately how far it is from completion. As things slip (and they always do), keep everyone apprised of the status. But now, instead of guessing how far you have to go, you can clearly point to the milestones that have been hit and outline the expected remaining work.
Use the insights gained in the planning process to manage requirements changes. You learned a lot by breaking down the project given the original set of requirements. If requirements start to change midflight, take those insights and apply them to the changes. If the changes add significant risk to the project, necessitate a bunch of new planning, or simply require a lot of additional work, be clear about the cost of those changes. If you’re working toward a hard deadline, knowing roughly the effort required will help you prioritize, cut, and simplify work to get the best compromise of features, quality, and delivery date.
Revisit the details as you get close to completion. Toward the end of the project, the tedium returns. It is time to really attend to the finishing details. What is missing? What testing? What verification? Run a premortem, an exercise where you go through all the things that could fail on the launch of this big project. Decide where the line for “good enough” is, socialize it, and commit to it. Cut the work that falls below the “good enough” line, and focus the team on the most important final details. Make a launch plan; make a rollback plan. And at the end of it, don’t forget to celebrate!

Ask the CTO: I’m Not Sure I Want to Be a Tech Lead

My manager keeps pushing me to consider being a tech lead. She wants me to run a big project. I know if I took the role I would have much less time to write code because I’d have to be in a lot of meetings and dealing with a bunch of coordination. I don’t think I want this, but how do I decide?

I have a strong opinion on pushing people into management roles, which is that you shouldn’t do it. If you’re not ready to take on management-type responsibilities, don’t take them on. There’s nothing wrong with staying deep in the technology, especially if you feel like you still have a lot to learn before you become an expert.

Good managers are looking out for talented people who could be given bigger leadership roles, but sometimes this leads them to push people away from coding before they’re ready. This practice can have a very negative impact on your career, because at more senior levels people who are considered “not technical enough” can find it hard to be promoted into management positions with more responsibility. It’s much easier to stay in a focused individual contributor role and learn what you need to learn there than it is to try to learn all of those skills while also learning management skills.

At some point, to progress in your career, you’ll probably need to do the tech lead job, even if you’re interested in staying on the individual contributor (nonmanagement) career path. That doesn’t mean you need to do it now. If you feel like there’s plenty of purely technical learning for you to do on your team, and you’d rather work individually on this project with someone else running it, don’t take the tech lead role. If, on the other hand, you don’t think the individual work would challenge you technically, perhaps it’s time to push yourself into learning some new skills — and the skills of the tech lead are good ones to try out.