This is my first article here. I'm welcoming of feedback so I can make this better.

Project planning. It's what makes engineers productive. You should definitely do it.

What's that? You already do? You already know how to plan a project? Okay, what do you do first? Start coding or write a project plan?

I was the same way too, once. I admit to just jumping in and coding my way into a corner. I thought I was saving time, but instead I burned up a ton of time. I'm writing this article to distill down what I went to two different universities to learn about, in conjunction with over a decade of industry experience, so congratulations! You've read my article and saved tens of thousands on tuition and caught up to my current career!

Terminology - not really just making up words

For sake of this article, I'm going to use some simple terms that may equate to your place of business (or not-business, you might work on your own project, a non-profit, volunteer group, etc.)

Goals - the things you kinda sorta know you definitely want

In a workplace environment, the people/business/organization/etc will need to accomplish things. We'll call them goals. Goals can be more nebulous, like get more users or speed up deploy time. Companies may call these something different, like "objectives."

A measurable goal is just that, measurable. One can take a metric and review before and after some time and effort to see a result. Such goals may look something like these:

• Reduce number of alerts
• Speed up deploy time
• Reduce CapEx budget

An immeasurable goal is not something where a simple metric can be applied, but it is clear to a human observer that there has ben a change. Some aspects may be measured (more on that later), but the overall goal doesn't have a metric. Such goals make look something like these:

• Improve operational overhead
• Become more proficient in Java
• Improve team morale

Projects - The pieces of that goal that must be done

When a goal is in mind, a project can be defined to work towards that goal. Goals can be observed, but don't have to be measurable. Projects should absolutely be measurable. Additionally, a project should be generally time-scoped. Consider what you can get done in the next quarter/half/etc. This can be helpful during review cycles.

Let's define a few projects based on a few goals from before:

• Reduce number of alerts:
  • Configure 50% of stateless services for automatic instance remediation
  • Upgrade MySQL hosts from 1G to 10G NICs
• Speed up deploy time:
  • Migrate main backend service to SSDs
  • Examine and implement service warmup settings in FooBarBaz service
• Become more proficient in Java
  • Complete 30 HackerRank challenges
  • Make at least one "major" production code change in a Java repository

Some projects are incremental and will have a ratio of completion. Assume that you have six stateless services on your team, but you feel you can only handle three of them this quarter. Then your project can theoretically progress 1/3 at a time.

When planning projects out that have a metric attached, it should be known how to measure that metric. Adding a metric may be a goal in and of itself. For speed up deploy time goal, you may need to start measuring your actual deploy time before you can actually start. Draw that up as a project and get to it first!

At Twitter, we use OKRs to plan our work. Objectives are the word we use for the unstructured goals. Key Results are what we use to define projects as a measurable chunk of work to be done.

Tasks - the things that actually get done

Projects are specific, but not necessarily a discrete unit of work. We'll call them tasks. Tasks are specific units of work. Let's define a few tasks for some of our projects:

• Configure 50% of stateless services for automatic instance remediation
  • Define standard alert set for our stateless services
  • Bind service X to standard alert set
  • Hook up service X to remediation platform
  • Bind service Y to standard alert set
  • Hook up service Y to remediation platform
  • Bind service Z to standard alert set
  • Hook up service Z to remediation platform
• Upgrade MySQL hosts from 1G to 10G NICs
  • Acquire 2 10G hosts for testing
  • Test production services against 10G hosts
  • Fix cmalloc startup bug
  • Acquire 8 10G hosts for production rollout
  • Production cutover
  • Set up deploy config changes
  • Set up service config changes
  • Run production deploy

Sometimes, these specific units of work may involve even smaller units of work. Try to avoid task inception though (sub-tasks within sub-tasks). Hours can be wasted managing projects too deeply, but it's sometimes necessary. Our Production cutover here has several steps, but they're all in the same goal. It's your call if you want to run those tasks hierarchically.

You'll perhaps find that some of the tasks from your projects really belong to other colleagues or teams. For example, host acquisition may take several days or weeks depending on approvals and provisioning - specifically, work done by other people. Now you've discovered blocking tasks, and those are good to identify and kick off right away. You can't test until you get those test hosts, so order them right away and switch over to another task while you wait.

Project management - be your own boss?

Now, how do you manage these things going forward? Project planning leads into project management. Now if you're a reasonably-sized tech company, you might use Jira for managing your work items. Goals are something that you have stuck to the wall on a poster, where as projects and tasks equate to Jira epics and stories/tasks.

Atlassian, the company that makes Jira, published an article that gets into the details of how to manage projects using epics and stories/tasks.

Getting things done - look at what you wrote down!

When projects are planned this way, as units of work that stack up towards a given goal, then the work you're doing is clearly trending towards that goal. Now I know you probably don't want to write out another task in Jira, or Asana, or whatever else you may have at hand, but it's definitely worth it to have and use these tools.

Sprint planning - just look at your list and decide what's next

Regardless of the tool you use, USE IT! Look at your lists of tasks. Jira lets you create a thing called a Kanban board, that's straight out of any Agile textbook. You have columns for tasks that are not yet worked on, currently working, and done.

You can IMMEDIATELY see the state of what's going on with your projects, which is a fine feeling. When the manager says "How's the Jenkins migration going?" She can look at your Kanban board and see your progress. Amazing! It's also a great feeling to see your backlog gradually grind down less and less.

Communication is your friend

OK, so you've done all the tasks for your project, and it's definitely working towards your goal. Now what? How does anyone know what you did? You tell them!

Most of us in the tech industry have weekly one-on-one meetings with our managers. This is where we tell our manager what we have on our plate and where we're blocked. Got a task that bob-from-accounting has been camping on since you got it to him? Tell your manager that you're waiting on it, and she should be the one to go try to move it along. Not enough budget for those SSD's? Discuss with your manager what the budget is like.

You should also let your manager know what you got done this week. This is how you build your reputation as a worthwhile engineer. You can say "hey, that goal that the CEO/VP/etc. set? Well, I got us two steps closer to that because of X!" She'll see how thoughtful you were with your planning and trust that you'll continue to work on the rest of your tasks.

The continued reminder of your successes and your intent on blockers will reinforce that perception of your ability to get things done. Then people won't mind as much that you surf reddit while your project is compiling.

Share your project work with your colleagues, but avoid bragging too much. Nobody likes a know-it-all, but nobody likes it when someone seems incompetent either. Moderation is key. A routine (bi)weekly email summarizing accomplishments is always a good thing. If nobody else on your team is doing it, start it and include team members' accomplishments. If someone else is doing one, then make sure your completed tasks get mentioned.

Brand is all about perception. It's about how others feel about you. You may not have direct control, but you do have an influence.

Prototyping - buyer beware!

Have you ever seen that one tool or service that nobody wants to touch because it never should've been shipped and nobody knows who owns it now? This is often the byproduct of somebody's hackathon project or a prototyped tool that was never really well planned. Prototyping is just writing a just-barely-minimum-viable-product to show that the idea has merit.

Drawing up a prototype should be done in the context of something like a hackathon. That's the space to throw something at the wall and see if it sticks. But, consider the hierarchy. The thing being built should work towards a given goal. That goal may be learn more about machine learning and the project of the hackathon may be build a basic ML model to predict something. You can plan your ad-hoc projects too!

Be careful when diving into writing code before planning a project. It's much easier to push things to production than it is to remove from production. Use a prototype to make decisions about what and how to build something, and spend as little time on it as possible until a proper project can be drafted.

Summary

Project planning for fun and profit! You can do it too! Plan and execute on your projects and you'll be climbing the ranks in no time! Follow these steps to success:

• Define your goals
• Set up projects that work towards those goals
• Break up your projects into tasks and assign those tasks to people
• When tasks are on other people or teams, raise awareness ASAP
• Watch your task lists every day so you know what to work on next.
• Tell your manager about what you've done
• Prototype with caution