Driving projects is a lot of work. There's a lot of stuff to do, stuff to think about, and stuff to navigate. If you haven't led many projects before, I hope you'll enjoy this post where I share my process!
In general, a project will go through a lifecycle something like this:
All told, roughly 6 phases for a project, 7 if you include the impetus.
Cool - let's get into it!
The project needs a purpose in order to be valuable. This could be basically anything, but critically, it has to be important to somebody.
Does a product take too long to run a common use case? Are your systems failing unexpectedly? Can your users easily interact with your systems, or is it only error-prone, slow, manual processes to use them?
It's possible you can identify these just by doing your normal work duties. I think it's far more effective, however, to have lots of conversations with people. People love to vent, and frustrations are a great way to get a pulse on what could be improved.
Remember not to fixate on a problem before validating a wide enough impact! If you're the only one who thinks it's a problem, you won't get very far spending energy trying to convince others - and you would probably fail at that. There are plenty of problems to work on, so work on the big ones.
Also consider who agrees with you that the problem is a problem. If your whole team thinks something is a worthwhile problem, it probably is. If the CEO thinks something is a worthwhile problem, it almost certainly is! Though meeting the CEO frequently probably isn't easy, so you can aim for a couple levels above you instead.
Once you've found some comrades who agree you've found a problem, come up with some ways to solve it. These should be rough ideas, and at least theoretically viable. This step is a good opportunity to do some shotgun googling, and if you're on a cloud platform, you can dig around the offerings to see what's new and possibly applicable to your other work as well.
It will help a lot to estimate a few things about each idea, such as:
The estimates will pretty much always be in relation to your team's composition, processes, and collective skills, so consider those variables as well.
At this stage, you should be talking to people! You can get fresh perspective on the problem and collect some extra ideas.
With your ideas in pre-crystallized form, it's time to start writing a design document!
There are an infinite number of approaches to this, and your company may have a template for design docs. I like to keep things as simple as possible, typically with sections like:
There are a lot of examples of design doc guidance out there, but the best starting point I've found is from Will Larson's post on engineering strategy. Also, his book rocks. Tanya Reilly's book "The Staff Engineer's Path" also rocks.
I have one very important piece of advice to pass on for design docs. You should have a one-sentence central vision to any design doc you write. The scope and solutions should satisfy that vision. If someone asks why we're doing this, you point to that vision and read it verbatim.
Well, okay, don't be a dick about it. But you get the idea.
You definitely want to get some eyes on your document while you work on it to identify points that need clarifying or simplifying and other feedback. You also want to get several rounds of feedback, at different stages of the draft's progress, and ideally from a variety of people.
Maybe your candidate solutions are nearly tied in terms of viability. Maybe you have a leading solution, and you'd really like to hammer the point home that it can work. Maybe you want to try something out before presenting it as a possible solution.
Some designs benefit from creating a prototype. This is a judgment call, but prototypes are great for clarifying the components of a solution, and validating that the concept of something works.
After a lot of iterating, feedback, and writing, you'll have a well-shaped document, almost all the obvious questions have been addressed, and the probability of a surprising and catastrophic revelation that shatters the fabric of reality the document was based on has been reduced to 0.
Now you get to schedule a 1-hour meeting with a bunch of people, most who should have read a past life of the document, and get them to fight over which solution you've proposed is the best. You should already know which solution will win, but just like in sports, upsets happen!
It is possible, but non-ideal, that one meeting won't allow for a consensus. This probably means you didn't have enough feedback sessions, or you didn't cast a wide enough net for your feedback. It's not the end of the world, but you really want to make sure you have some smaller sessions with the dissenters to figure out how to bring them on board.
Tragically, politics.
The easy part is finally here - time to build!
I find it helps a lot to start by getting the termini in place, even if it does nothing in between. By that I mean, if you're standing up a new API or web app for example, get it to handle a request, send it to the business logic layer, and provide a response. Then automate that via testing or a repeating cURL invocation or something. Any discrepancies while you build will become immediately obvious, and it's more comprehensive than unit testing (which you should also do!).
Eventually, you will have completed enough building to Ship It! Check that it
works in a Not-Your-Machine environment, double check, make absolutely damn
sure it works (hopefully this is just a ./run_the_tests.sh invocation), and
then announce it in whatever forum is appropriate!
Watch the party hat, hands clapping, rocket flare, and other celebratory emojis flood in, grab a coffee, do a victory lap, and do some push-ups.
Not too many, though. Because you'll need your arms for...
You deployed the project to great fanfare, and that is something to be proud of!
But the work is not done. Now the project is walking around, trying to drink cleaning products under the sink, and still needs diaper changes.
Well, the software equivalent, anyway. There are still more features to complete, feature requests to inbox, bugs to fix, pipelines to optimize, and so on. And for at least a while after your stewardship of the initial zero-to-ship stage is over, you'll probably still be involved, and even if not, you'll still be involved indirectly. You shipped it, so you're kind of the "go-to guy or gal" for it.
That might be a post for another day, though! :)
This page brought to you by Stephen Hara.