Project Management For People Who Just Want To Build
It’s funny to realize, as I’m pacing around the room thinking of how to open this post, that I’ve been working for sixteen years and not once has anyone taught me to run a project. For a long time it didn’t even seem like a skill that you could learn. It was a chore that distracted from the “real” work of writing code.
When you love your craft, just doing it can be the most relaxing time. You put down all your stresses and responsbilities and just build. Most engineers I know feel that way about programming. The ambitious ones want to choose what they work on. They want to control their destiny. If the people around you trust you to set goals and deliver, to ask for help when you need it, to steer around obstacles, to let people know when you’ve hit a wall, and to just generally share what’s up, they’ll trust you to choose what you work on.
That’s project management. Not Gantt charts. Not kanban boards. Not tickets. Not the backlog.
Project management isn’t the tools or the six-hour planning meeting. It’s basically asking two questions over and over again and writing down the answers in different ways:
- What’s our goal?
- What stands between us and the goal?
That’s it. It’s those two questions all the way down.
Ask and answer them all the time. In meetings, ask “what are we trying to do here?” When writing a todo list/board/whatever, write tasks in terms of goals.
Increase retention 0.X% by setting the background color to red. When writing an email about your progress, remind people of the overarching goal, what you’re working toward right now, and what’s left between you and your immediate goal. When you start work for the day ask yourself, “what am I trying to do again?” When someone asks you how it’s going, don’t say “fine” or “you know”, tell them what you’re working toward and where you’re at.
You will have to regularly, proactively communicate your goals and progress to people, both in meetings and in writing.
If this sounds a little like public relations it is. Not in the sense that you’re trying to raise your brand. More in the sense that people have a hard enough time keeping everything they’ve got to do straight and don’t have much time to figure out what you’re up to. For example, saying “I upgraded the kernel across the fleet” isn’t going to mean anything to people off your team. Saying “I prevented all our customer data from leaking by upgrading to a freshly-patched kernel” will make sense to just about anyone at your company.
What’s all this got to do with building? Whenever I’m writing code, usually when I get stuck, I ask myself “just what am I trying to do here?” Often the answer doesn’t come until the next morning, but when it does come it’s in the form of “I can do this instead and avoid writing all this code.” You’re probably asking yourself where you’re headed and what’s left to do anyway in the course of building. You’ve just got to get that conversation out of your head.
When you talk about projects in terms of goals, it’s much easier for other people to grasp their impact. So if you want to go use a new technology to reduce build times, it’s much easier for people to say “go for it” if you talk about the engineering time and salary saved than if you talk about how cool it would be. People will trust you more and more to just build because they’ll be able to see the impact it’s having on people other than you.