Habit-based Goals
A goal-setting approach for Software Engineers
Around this time of the year, we set personal development goals for ourselves and — if we’re managers — we help our reports do the same for themselves.
While I don’t know what it’s like to work in other professions, I do believe that Software Engineers have a more challenging time with goal-setting than in other lines of work.
Goal-setting challenges for software engineers
For one, there is a high degree of flux in the software industry. Most software companies are startups, which means their primary purpose is to find product-market fit. Now, let’s say that you work at a startup and you set a personal development goal to learn a specific business domain (e.g. real estate) because the product that you’re building lies within that domain. If the company subsequently pivots the product to a new set of use cases covering an entirely different business domain (e.g. business partnerships), then your goal has become irrelevant, and the time you’ve spent towards it has become a sunk cost.
Goal-setting for Software Engineers can also be challenging because there is frequent change within the software development domain itself. New frameworks pop up every year, and when one’s effectiveness eclipses an incumbent’s, then Software Engineers are expected to learn about and adopt the new framework. If these same engineers have development goals around learning the now-obsolete framework, it’s prudent for them to abandon their old goal and recognize yet another sunk cost. The past two decades of web frameworks provides us with a good example of this phenomenon.
Goal-setting for Software Engineers can also be difficult because of how we work. As of this writing, Scrum is the predominant way of working for software development professionals (see chart below). Typically, this means working on a product team with daily stand-ups and weekly (or bi-weekly) sprints. The team sets a goal for the sprint and a sprint backlog with an ample supply of work for the team members to work on. Even once the sprint backlog is emptied, there is typically a broader-scoped backlog to draw from.
In short, a software engineer on a Scrum team will never run out of work to do. This is, of course, by design1.
Lastly, even if time is afforded for personal development, the product team and wider organization rarely does much to support beyond affording time via initiatives such as 20% time or exploration days. These can be effective, but they are rare and can be challenging to sustain. Ultimately, the primary means of support in personal development comes from a Software Engineer’s manager.
The Engineering Manager’s challenge
In the face of a rapidly-changing industry and product teams laser-focused on customer value delivery, how can Engineering Managers support their reports’ personal development? Aligning their personal goals with that of the product team and the customer can only go so far. Learning goals of Software Engineers, for example, may have eventual customer value but this value cannot always be achieved incrementally.
Consequently, time and energy should always be set aside for Software Engineers’ development goals that do not necessarily align with their product team.
SMART Goals for Software Engineers
The de-facto model for setting professional development goals is SMART criteria. Breaking down the acronym and contextualizing it for Software Engineers could look like this:
Specific. Instead of: “learn React”, consider: “build a React app that uses routes, context, and hooks”.
Measurable. Instead of: “pair program more”, consider: “pair program a minimum of 12 hours a week”
Achievable. Instead of: “become an expert in TDD”, consider: “complete 1 code kata a month”
Relevant. Instead of: “become more accurate at estimation”, consider: “facilitate more user story slicing sessions”
Timely. Instead of: “facilitate a retrospective”, consider: “facilitate a retrospective by the end of the quarter”.
As long as all five criteria are applied, SMART goals can be an effective tool. However, they do not address the issues raised earlier, especially if goals are set around large, culminant milestones. Moreover, they can create dilemmatic situations for Software Engineers; the unyielding rigidity of SMART goals means that they are forced to decide between prioritizing the product team’s sprint goal, or their own SMART goal.
Habit-based goals
Habit-based goals are about setting goals around the journey (habits) instead of the destination (milestones). Such goals can still meet SMART criteria. To revisit some of the earlier examples in a “habit-based” context:
Spend 30 minutes every morning coding in React while learning at least one of these React features: routes, context, hooks
Spend 1 hour every week on a pair programming coaching session with another software engineer
Spend 30 minutes at the end of every day to work on (but not necessarily complete) a coding kata
Spend 15 minutes every morning to write down your thoughts
Spend 30 minutes every week to record yourself explaining something on video
The common thread in the above examples: define goals around a recurring time spent on a specific yet minimally-defined activity. This is in contrast to defining goals around the achievement of longer-term milestones.
Benefits of habit-based goals
There are a few benefits to this approach. For one, it is less likely to compete with goals set in other contexts, such as the sprint goals of the product team. This is because it only requires a relatively small and predictable amount of time to be carved out of a Software Engineer’s day or week.
It’s also a more sustainable approach. Because of the consistent nature of habit-based goals, there is a lower likelihood for a need to cram work into a short timeframe in order to achieve a milestone.
This leads to yet another benefit of habit-based goals. They don’t necessary preclude milestones, and can in fact complement them. For example, a Software Engineer may have an idea about certain milestones that they wish to achieve. Instead of formalizing constraints around those milestones (such as scope or timeline), they instead formalize the habits that will be developed to achieve them.
Perhaps most importantly (when it comes to personal development), habit-based goals help us develop the ability to build beneficial habits and shed detrimental ones. James Clear covers concrete strategies to help develop the skill of habit management in his book, Atomic Habits.
Wrap-up
If habit-based goals seem easier than milestone-based ones, then I invite you to try them for yourself. Since reading Atomic Habits over a year ago, I have been trying to work on both my personal and professional habits. I’ve found that it’s actually quite a challenge!
Be that as it may, if you are a manager then leading by example (i.e. trying it for yourself) is probably the best place to start. Just don’t expect a flawless execution right off the bat. Instead, recognize that habit management is a skill that takes many years to hone.
Your beliefs become your thoughts,
Your thoughts become your words,
Your words become your actions,
Your actions become your habits,
Your habits become your values,
Your values become your destiny.— Ghandi
As I finalize my annual goals in the next few weeks, I will prioritize my habit-based goals over any related to milestones. If you are similarly motivated, I’d love to hear how it goes for you!
There are exceptions to this — I once worked on an XP team who set aside time every morning for personal development; you can read about how we did that here: The First Pomodoro Habit for Continuous Learning.
Great post! I am inspired by this to be more deliberate about the time I spend every morning towards my software development learning. The graphic at the beginning explaining how we have to keep our goals up-to-date in an ever changing landscape made things clearer for me. There is a certain amount of detachment we have to cultivate with our goals and learnings because the environment can and will change.