“Measuring programming progress by lines of code is like measuring aircraft building progress by weight” — Bill Gates
Years ago I was tasked for the first time with coming up with my yearly PMOs — Performance Management Objectives. PMOs are a fairly common planning metric primarily used in sales organizations to plan out the year to come. I have always hated PMOs.
For a number of reasons, most software companies don’t utilize PMOs, but as a software developer working for a company that is not primarily software, it’s pretty much a given that you’ll be forced to fill them out just like the rest of the company.
Each employee defines a set of measurable objectives they plan to accomplish over the next year. Generally your PMOs will have to align with your boss, which has to align with their boss, all the way up to the president.
I have always liked the idea of PMOs for a sales organization. I like the idea of each employee setting out yearly objectives that help their manager accomplish a subset of their goals. I can think of other industries it makes great sense as well. There’s just one industry where I have specifically not liked the idea: software.
What is a PMO? SMART Goals
If you haven’t heard of PMOs, perhaps you’re familiar with the SMART acronym:
- Specific — The goal is easily defined to anyone familiar with the project.
- Measurable —You can put a number on it. You can show progress. It is clear when the goal is complete.
- Agreed Upon (or assignable) — Someone has to do it.
- Realistic —The goal should actually be achievable in the given timeframe.
- Time-related — Enough time to achieve the goal, but not enough not to motivate.
From Project Smart
For many industries, the measurable section is the easy part. Increase sales by 10%. Add 500 new accounts. Have a 95% customer satisfaction rating. A little closer to home, even DevOps can quantify things. Uptime of 99.9%. Average response time of one hour or lower. Admittedly, these could apply to some programming teams as well.
But what about one programmer? How does one individual programmer set measurable goals that are valuable? How can the goals be specific and yet still follow the general unpredictability in software?
Measuring Programmers
The software industry has been trying to find a way to quantify the success of programmers for years. It’s pretty much universally believed that lines of codes is certainly not a good indicator anymore. Git commits don’t tell us much. A small number of failed builds could just mean the programmer didn’t push that often. Code coverage can be fooled.
But the main reason I resisted PMOs for so long is that software is so unpredictable. I could potentially be working on a completely different project in a month than I am right now. Why would I want to spend my time making plans that I knew would ultimately be changed?
The software industry has been trying to find a way to quantify the success of programmers for years.
To be clear, it is certainly true that software-focused companies are a bit easier to predict. It’s reasonable to believe the projects that are outlined for my year will actually be what I work on. However, in an organization whose primary focus is not on software (one that would enforce PMOs), projects tend to bounce around a bit more.
Software is simply seen as a solution to any problem that comes up. Problems regularly come up all the time, of course, so shifts are regular and common. There are advantages and disadvantages to each mindset. That’s a whole separate topic. But one of the disadvantages is that it makes it very difficult to plan out far into the future.
So What Do We Do?
All that being said, most companies won’t exempt a single department from a process everyone else follows, so you’ll have to jump in and make it happen. Here’s my advice on the types of goals to add
Focus on Projects
As a software developer, the vast majority of your time is going to be devoted to simply completing projects. If you do have some projects that you are planning for this year, make completing them a part of your PMO. The completion of the project is how it is measured.
If the projects haven’t been outlined quite yet, or the only projects that are outlined won’t take up the whole year, search for some insight on what is next. If it doesn’t exist yet, make it exist. You can always revisit these later, but wanting to have a plan for what you’re working on for the year is good for both you and the business.
Focus on Metrics
There are some things that can be measured that bring value to the business. Chances are, you already know what those are for your situation. Perhaps it is uptime, code coverage, the number of bugs in a system, how often code is send back to the developer after a code review, etc.
If you already have a metric on this, great. Use it. If not, part of your PMO goal could simply be to identify and start tracking the metric. Plan to have a metric in place by mid-year and then revisit the metric then to put a specific and measurable number on it to achieve.
Focus on Personal Development
Personal development is something that is extremely beneficial both to the company and to the individual. I can’t tell you how many times I’ve planned to spend just a small part of each day learning and improving myself. Perhaps it’s watching a Pluralsight video, reading a technology book or reading up on soft skills.
Deadlines and being “too busy” always end up getting in the way though. This negatively impacts my skills and growth which negatively impacts the business as well. By having personal development as a PMO goal, it forces you to spend the agreed upon time each day as it is a goal you and your manager agreed upon.
Revisit, Revise and Repeat
The main thing that has changed by perception of PMOs has been deciding to dedicate regular time to revisit my goals with my manager and adjust them as needed. There is a very small chance that your goals will be 100% aligned in 11 months. I had a problem with committing to something I knew would regularly change.
By revisiting the goals, it gives you the ability to make adjustments as the business has made adjustments. It is also a constant reminder of your goals. As programmers, it’s easy to get stuck in the day to day of just solving the next problem that comes up. It’s extremely helpful to take a step back and take a look the big picture.
If you don’t know where you’re going, you’ll never know if you got there. Make it a habit to reflect on your yearly goals regularly and PMOs can go from a burden to an invaluable tool to accomplish your goals.