Setting objectives as a software developer

Most organisations include objective setting as one of the mechanisms for helping communicate what is important for the organisation, team or individual and what concrete steps they are taking to achieve them.

The research is pretty clear that those who create, communicate and commit to specific objectives are more successful than those with vague goals. This is true whether you use a Fitbit to track your steps or any other goal in your life. There are many different approaches for how to set objectives — Sir John Whitmore’s GROW model and Google’s OKRs are just two examples.

At their heart, whichever approach you use, they all share the same premise —identifying what success looks like and breaking this down into actionable steps. This helps you reflect on what is most important at this current point in time, what is holding you back from achieving it and what concrete, measurable steps you need to take to get to your goal.

The benefits of having this as a discipline in your life are many. You will be more focussed and have greater clarity on what is important. You will be more self-aware about what is helping and hindering you from making progress. As you celebrate your successes with each journey round the goal setting cycle, it creates its own virtuous momentum as you see the positive results of your hard work.

In many successful organisations, periodic goal setting is an important part of keeping the company aligned. Objectives are set at the top and then departments, teams and individuals set their own goals accordingly. That way everyone can ensure their efforts are aligned with what is currently important for the organisation. It also encourages collaboration and challenge between teams and individuals to ensure that everyones’ goals are ‘lined up’.

So what does this mean for software developers?

Having sat in many 1–2–1s with developers, a common pattern is that we can find it hard to define individual objectives and/or goals that are any more than tokenistic or just ‘jumping through hoops’.

When you probe deeper, the common themes I often hear are 1) we don’t have control over what we work on so I just do the work I’m told do and 2) I just want to work on interesting, challenging problems with great people.

Point 1 really scares me — surely we want our software development teams to be fully utilised when it comes to defining what they work on and not just treated as a factory floor? Software development teams should be in regular and frequent communication with their colleagues in other parts of the business about what should be built next to best benefit the business. This is a whole discussion in it’s own right, and I’ll assume for the rest of this article that your teams have say over what they work on — if they don’t, you’re wasting them :-)

If done well, setting objectives can help teams take ownership of what they work on and also identify what ‘interesting and challenging work’ means for them.

Team objectives

Before personal objectives can be set, it’s helpful for a team to set their targets for the next period. There are plenty of other articles on how to set good goals as a team so I won’t cover that in detail here. However for individual objectives to be most valuable, it’s worth ensuring the team as a whole know what they’re focussing on and why.

Individual objectives

So the organisation has a set of clear objectives and the team has sat down with their key stakeholders and agreed on what they will deliver in the next quarter. Take the following imaginary quarterly set of team goals:

1. Deliver feature A which results in X% improvement in onboarding
2. Deliver feature B which results in Y new customers
3. Improve API performance such that 99.9% of responses are returned within 500ms
4. Hire 2 new developers
5. Present our work at one meet-up or conference

How can a member of the team set personal objectives in light of these team objectives?

To get going, it can be helpful to consider the following questions:

1. What do I most enjoy work on? What is it about this I find most satisfying?
2. What is the largest contribution I make to the team?
3. What do I most shy away from? What is it I feel when I think about doing this work? What is the impact of this for the team?
4. What new things do I want to learn?
5. What is the team most lacking at the moment? How does this hold the team back? How can I help?
6. What are the team’s strengths? How can I reinforce this?
7. How do my colleagues perceive me? What do they see as my strengths and weaknesses?

Hopefully this can help clarify the role the individual plays in the team and how they want to grow this over the next period. This may generate the following set of responses:

I most enjoy working on projects that I know help improve the efficiency of the company. I love knowing that our work makes someone else’s life easier and more productive. I think I most contribute to the team by taking the time to really understand how others in the company work and that this can help fill in the gaps in the requirements we’re given. For example, I thought the recent workflow we had to implement was missing some detail so I went to speak to Julie about what she actually does at the moment and it became clear that we were missing some steps.

I most shy away from doing code reviews — I don’t always feel confident making comments on others’ code. I know there are times when this holds the team up because code can’t be released as it’s waiting on a PR. I’m perfectly happy chatting through issues around coding style, how tests are written or how to structure code face to face. I think I have some kind of mental block when I try and do it on Github.

I want to learn more about building resilient software. I’m becoming more fascinated with the fact that failure is inevitable — so how can we write software in the light of this?

The team is most lacking clarity on some of it’s requirements — which is funny given I’ve said I enjoy working with colleagues to understand the real detail. This is obviously something I can help with.

The team is very strong technically. Which is probably why I struggle with commenting on PRs. The team take pride in the work they do. Code coverage is high and we take time to refactor the code we write. This means we release code that has a pretty low bug count. I can help reinforce this by believing in myself a bit more. The team do look to me to clarify exactly how the code should function and I should be happy and confident to play this role more.

In our last feedback session my colleagues told me that they see me as friendly and approachable and someone who is calm in a crisis. They told me that they’d like to see me take more ownership for technical design decisions and be more opinionated on what I think.

Once they’ve collected their thoughts, they can then think about how to turn them into SMART objectives or personal OKRs. These might end up as:

1. As a team we are committing to deliver feature A in the next quarter. I enjoy spending time to deeply understand what the users of the functionality need. I will volunteer to create the executable specifications for this functionality. I will review the requirements we are given and ensure they are complete.
2. I will contribute to at least 4 PRs per week.
3. I will enable Chaos Monkey to run against our applications to introduce randomised failure and document the weaknesses it exposes in Trello.
4. When I have technical questions about the way to do something, I will ensure I propose a solution and not just ask how the rest of the team would solve it.

The individual now has a set of objectives that are both linked to the objectives of the team and also their own growth goals and are also mindful of how they can best contribute to the overall success of the team.

Going deeper — psychological projection, your shadow and setting objectives

Carl Jung first proposed the idea that people have a ‘shadow side’ to their psyche. Your shadow encompasses all the aspects of your personality that you struggle to identify with. Some of these characteristics can be things you’ve learned are not acceptable in society. Some of them can be positive and creative aspects of yourself that you struggle to own or admit you might be capable of. [https://scottjeffrey.com/shadow-work/]

Because you struggle to see these parts of yourself (ie they are in shadow), you can end up ‘projecting’ these characteristics on to others. For example, if you are uncomfortable with the fact that you can be opinionated and arrogant in discussions, you will be more sensitive to this trait in others. In other words, because you can’t get angry with yourself for being over opinionated, you instead focus your frustration on others.

This can also work for positive characteristics. You may have a deep desire (and capability) to be a good public speaker but were told by a teacher that you were not good at it. As a child that was a difficult experience to come to terms with so it gets pushed into your shadow. So now, rather than developing this skill, you are too afraid to try for fear of being rejected again. Instead you now project this onto others and admire and idolise others who are talented public speakers.

Being aware of our shadow can give us powerful insights into ourselves which can really help us in our personal growth and objective setting.

For example, you may get frustrated at a team member who doesn’t listen well to others. Your frustration may be genuine, but if you feel your response is stronger than the situation warrants, you may want to explore whether this is pointing out something in your shadow. Do you also have a habit of not listening well to others?

Equally, you may admire someone who is skilled at teaching others. If this admiration expresses itself as jealousy or hero-worship, you may want to explore whether this is pointing out a deeper desire within you to also teach others.

Taking time to become more aware of your emotional responses to situations and interactions with others is a great discipline to learn and can be a powerful tool for developing yourself and setting growth objectives.

Summary

Goal setting is a proven tool for improving individual and team performance.

As software developers we need to ensure we are being proactive in both our own growth and the growth of our team. Whatever our role is within the team, we can all have influence and impact which will ultimately pave the way for a successful and fulfilling career and success as an organisation.