Goals and objectives for software engineers

Setting goals and objectives usually divides engineers into one of three categories:

Excited at the prospect of working with their manager towards a common vision.
Indifferent because the entire process feels like a chore, but you believe it's still valuable for knowing what to focus on.
Almost dreadful of the moment you have to fill out that periodic self-assessment and goals form because you feel it's done just for the sake of formality and nobody pays attention to them.

In my experience, very few fall into the first category, and even fewer stay there consistently throughout their career. That being said, I think it's incredibly important to regularly and consistently set goals and objectives for yourself. This becomes even more important for someone working in the field of software engineering, which is a very complex domain and can feel overwhelming at times.

Importance of goals

So why should you care about goals anyway? Let me put it simply:

💡

It's the single best tool that you have for growing and advancing your career.

You might get away without setting goals and objectives in the first couple of years of getting started as an engineer - though I don't recommend it. But as you become more experienced, I believe that strong goals are essential in growing as an engineer, technical person, and ultimately as an individual.

Let's first answer the question of what happens if you don't bother with goal setting at all? Well, I've seen a few things in my experience:

You might spend many years in the same role, not knowing what to do in order to progress.
You might end up working on a project you don't like or a part of a team that is not a good fit for you.
You might become disengaged with your day-to-day, which could eventually affect your overall attitude and enjoyment of your job as a whole.

These are just a few examples from my personal experience. While we might blame other external factors for these consequences, the truth is that we have a lot of control over this. And while goals are not the answer to everything, it's a simple and very effective tool that can make a big difference in the long run. Goals are of course not specific to software engineering, so a lot of things in this article are widely applicable.

How to set bad goals

We have all been there, looking over the annual review document and seeing something like this:

Demonstrate excellent communication.
Deliver a medium-to-large feature with good quality.
Become proficient with technology X.

And this is the second-worst thing you can do, besides not having any goals at all, of course. Let's try to understand what's wrong with the goals above:

Vague - What does excellent communication mean exactly? Are we talking about verbal or written communication? Inside or outside the team? Do presentations count?
Subjective - If we ask 10 engineers I'm sure we're going to get at least 7 different answers to what constitutes a medium-to-large feature.
Hard to measure - How do we know if the quality is good? What does proficient mean exactly?
Unbounded - Do I have 6 months or 2 years to demonstrate that excellent communication?

Unfortunately, I've seen too many instances where phrases like the above were commonplace. It doesn't come from a bad place, but rather a misunderstanding of the importance of goal setting.

Who is responsible?

A lot of engineers feel like their managers should come up with these goals, while some managers feel engineers should be proactive and drive this discussion. The truth is, of course, somewhere in the middle.

I fully agree that each engineer should take responsibility for their growth, learning, and overall career. At the same time, I also feel it's the manager's role to nudge engineers in the right direction and guide them through this process. That being said, at the end of the day, they are your goals, for your growth and it's ultimately you who is directly impacted if they are met or not.

Anatomy of a good goal

I'm sure you heard this many times by now, but a good goal must be SMART. This means that each of our goals should be:

Specific
Measurable
Achievable
Relevant
Time-bound

While the theory is fine, it's usually the practice that poses a challenge. People get too hung up on the technicalities of the acronym, but for the most part, things are straightforward if we follow a few simple steps. Let's dive a bit deeper and see what those are:

Start with relevant first. Look at what the company or your team is trying to achieve in the next 6-12 months and also consider what you want to do. A good goal makes sense for the business. A great goal also makes sense for you. Think where you want to be in the next several months and look at the goal as a stepping stone in that direction. You might have a few big ideas like "My objective is to become a Tech Lead" or "I want to own the front-end implementation for project XYZ" - note them down, discuss them with your manager to get feedback and move on to step number two.
Be specific. What should you do in order to work towards those bigger ideas? Continuing the example above, maybe to become a Tech Lead, you should mentor at least two engineers in the team and work on your presentation skills. But again, this is a bit vague, so you can say something like deliver one internal technical presentation in the monthly lightning talks session. In my opinion, here is the place to think about how the work can be measured as well. I don't usually see this aspect being a problem in practice, because if you are specific enough, usually measuring the success becomes evident.
Set a deadline for the goal and assess if it's achievable by that point. You should try to stretch your abilities but remain realistic in terms of expectations. In my experience, a period of fewer than 3 months is too short for any meaningful progress and anything over 12 months is too loose. If you find yourself setting short deadlines, you're probably focusing too much on the details. Longer window goals usually indicate that you're thinking too big or abstract and it's a sign you should break that bigger goal into multiple smaller (and more specific) goals. For me personally, the sweet spot is 6 months - it gives you enough time to work towards your objective, while also being close enough to instill a sense of urgency.

Some have enhanced or modified the classical SMART acronym over the years. One that I like is SMARTER, which adds the evaluated and reviewed elements, which I believe are very important. Goal setting is a two-way street between you and your manager. It's very unlikely your manager could come up with a perfect list of objectives for you, as it's you that have the clearest sense of direction for your career. It's also just as unlikely you can devise a complete list of goals by yourself, without having the business context and broader picture that your manager can provide.

Another property that every goal should have is importance. This is more of a meta-property, as it's not part of the goal itself, but rather is applicable once you have defined your list of goals. Usually, importance is quantified in percentages e.g. 20% for your most important goal and maybe 5% for a less important one. These percentages are usually assigned based on the business need combined with your growth plan and should be agreed upon between you and your manager. I wouldn't recommend more than 25% for any goal because software engineering is a complex, multi-faceted domain, so you want breadth of skills, not just depth. It won't matter so much in a few years if you're an expert Java or Python developer, but what will matter is the extra communication, presentation, mentorship, and planning skills (just to give some examples) that you can also focus on.

A final recommendation here is to keep your list of goals short. It's rarely useful to have many goals just for the sake of having them. Try to have 3-5 of what I call goal categories - overarching areas of growth and development with sub-goals or sections detailing the specifics. Let's take as an example the mentorship category. The sub-goals could look something like this:

Be a buddy for the engineer that joins the team next and help them with the onboarding process.
Provide feedback in at least 75% of the code reviews in the team.
Have at least 2 pair programming sessions with a more junior member of the team.

The broad categories give you the direction and the sub-goals give you specific targets that you need to hit. You should sort the sub-goals by priority and even mark some as stretch - that way you know what are the key ones that you have to focus on.

A good goal needs to stretch your abilities a bit, so it's a sign you're on the right track if some stretch items are met, but not all.

Tracking your goals

I would add one more property to keep in mind for all goals - tracked. No matter how good a goal is, if it's not tracked it's not going to bring a lot of value. Too often I see people setting some goals for a year and only revisiting them at the next annual review and appraisal cycle. That being said, you shouldn't look at these goals every day, rather aim for reviewing them at least every 2 to 3 months.

Using a tool that has this support, such as Workday, makes things easier. But even if you don't and just use an Excel sheet or a simple Google doc, the same basic principles apply. Here are a few things that I personally use:

Periodically update your progress for each goal. It's much easier to do this along the way rather than remembering and filling out all the details after 6 or 12 months.
Ask for feedback. This is very useful for any course correction that needs to happen and the best place to do this is in a 1:1 meeting with your manager.
Always adjust. Sometimes priorities or the business context changes and you need to adjust the goals accordingly. This might mean changing the scope, the deadline or maybe removing the goal completely. Don't be afraid of adjusting the goals as you go - it's worse to stick with goals that are obsolete or irrelevant.

Templates

Let's see some practical templates that you can take and adjust to your need. These are just a small glimpse into the world of goal setting, but I hope they can be of some use to you.

Technical expertise

Design and implement a solution for feature A to support 1000 transactions per day by Q2 of 2022.
Grow the code coverage to at least 80% for service B by the first half of 2022.
Learn technology C and be able to work on at least 2 tickets for project D by Q1 of 2022.
Migrate the backend for service E from technology F to technology G in the first half of 2022.

Communication & Collaboration

Hold an internal technical presentation about technology A in Q2 of 2022.
Become the main point of contact for component B by Q1 of 2022.
Identify assumptions and risks in the design phase of project C and document them as Jira tickets.
Present new feature D to sales and marketing teams in Q2 of 2022.

Leadership

Successfully mentor 2 new engineers by August of 2022.
Be the scrum master for project A in Q1 of 2022.
Work with product and engineering management to define the roadmap for product B for the first half of 2022.
Become an active interviewer for the system design interview, holding at least 2 interviews per month, by August 2022.

Maintenance

Be part of the on-call rotation for services A and B in Q1 and Q2 of 2022.
Increase availability SLO for service C to 99.99% by June 2022.
Reduce production deployment duration by 40% by March 2022.
Allocate 10% time in Q1 of 2022 for customer issues for product D and close them in a timely manner.

There are many more goal categories that you can use, such as:

Testing
Mentorship
Business Impact
Team Growth
Architecture

You can argue that some of these sub-goals can fall into multiple categories and I agree, many goals have multiple labels. The idea is to not get too hung up on these categories - you can even remove them entirely if you want and it wouldn't affect the overall efficiency. They are just there to remind you of the big picture and overall direction and also keep yourself and your manager aligned - which is the biggest value of setting goals.