How to Write Impactful Software Engineering Goals
An Impactful Goals can Help Accelerate Your Growth as a Software Engineer
"So, Edward, let's have do career goal setting on our next 1:1. Be prepared to write down a list of goals that you want to achieve this quarter."
I'm not too fond of goal-setting conversations during 1:1 because I don't know if my goal aligns with the company's north star.
Don't get me wrong - I love goal-setting. It gives me immense clarity and focuses when I am lost and confused. It pushes me to grow as an individual.
However, 1:1 goal setting is different than personal goal setting. 1:1 goal discussion is about how to set the expectation and help you get promoted to the next level.
You have to think about goals that not only help you grow but also help the company grow. If you set goals outside the company's growth criteria, you may be chasing a wasted objective.
This week, I will share the why of goal setting (for those who don't see the value of setting goals in your workplace), the tips for setting impact-driven goals, and three examples of impact-driven goals.
Why Should Software Engineers Set Goals?
The whole point of goal setting is to make you grow and keep you committed during resistance. Setting goals can showcase your growth and also your impact on the leadership. Impact and growth help you gain leverage in your team.
Software engineering is constantly changing and evolving. Thus, setting good goals help software engineers grow and stay current with the latest technology.
Tips On Setting Profound Impact-Driven Goals
Goals should be visible to you and your leadership and include key results so progress can be tracked. Create a few goals per year (two to three), and track the progress towards completing these goals.
They should Measure the outcome, not the process of work.
Well-constructed goals measure the outcome of an individual's contributions, not their role in the company or the amount of work they do.
For instance, work Y amount of hours writing onboarding documentation for the team is a weak goal. A better goal will be to decrease the engineer onboarding time in Q2 to Y days.
Instead of saying your goal is to be the "lead of X project," it is better to say, "I would plan a Q4 roadmap that will be approved".
They Can Be Objectively Quantified
Well-constructed goals have measurable results.
Why? Objectively quantifying helps showcase key results that are easily tracked.
Usually, quantified results in the form of:
💰 Revenue or cost. You want to decrease the infrastructure cost.
％ Percentage improvement. You want to decrease the memory by X%.
⫴ Binary. You want to ship cascading feature by Q2. Shipping a feature by a certain date.
For instance, I want to learn Android development in Q2 is not a well-defined goal because there are no measurable results. A better goal is to increase our Android codebases' code coverage to 80% in Q2. The later goal project is that you want to improve your Android development skills and use that skill set to improve the Android's code coverage by a measurable amount.
They Should Focus on the Input Metrics Instead of the Output Metrics
In their book Working Backwards, Colin Bryar and Bill Carr mentioned that Amazon has a weekly leadership meeting where they analyze 400-500 metrics in a single session to determine how they should operate. Amazon divides its metrics into "uncontrollable output metrics" and "controllable input metrics." Output metrics are a distraction because they're lagging action indicators that can be directly influenced. As a result, output metrics are unattainable. It's better to focus on what you have direct control over inputs.
For instance, increasing the payment-processing integration authorization rate by 10% is not a good goal because it doesn't tell you any actionable insights. On the other hand, optimizing shopper payment flow, such as better error messages, can increase the authorization rate.
Focusing on uncontrollable output is a recipe for stress and decreases your trust in your team members and leader.
They Should Have a Why
Having a why creates great stories and purpose.
It keeps you motivated to keep at it, even during tough times. It is also clear if your goal aligns with the company's north star.
When leaders think about who to promote to the next level, they will look at the potential promotions case study and determine which case study is the most impactful.
Leadership will not care that you have made a slack bot to answer stakeholders' questions. However, when you explain why you want to create the slack bot, it gives context and story behind the action follow up with the result. Your case study is ten times more impactful than action without a why.
Your why also serve as a litmus test for all your decisions, enabling you to make smart, prompt, and more confident choices in all areas of your work.
Example of Setting Impact Drive Goals
I give three examples I used to set on my 1:1 with my manager, and I realized that these are not impact-driven goals.
Weak Goals
This year, I want to be better at learning AWS.
Why?
Not quantifiable. It is hard to quantify what it means by "better." Is finishing the AWS courses count as better?
There is no why. Why do you want to be better at learning AWS? What are the purpose of the team and the company?
Better Goals
I want to create an onboarding tutorial course to introduce AWS to newly joined team members by Q3 to speed up their onboarding time to 60 days.
Explanation:
It gives quantifiable measurement - speeds up the onboarding experience 10 x.
It is specific and time-bound. I want to create such a course to reach certain output by Q3.
I want to create a tutorial course for introduction to AWS - to help myself get better at it and help the team speed up their onboarding time.
Weak Goals
Mentor more engineers in Q2.
Why?
Similar to the one above. It is not quantifiable what "more" means.
The goal indicates the process of work but not the outcome of that work.
Better Goals
Guide and work together with Bob in executing the SCA project in Q2.
Explanation:
Specific. I want to guide and work with Bob, an engineer, in executing the SCA project.
The outcome of mentoring more engineers is having Bob lead and execute the SCA project.
Weak Goals
Increase the resiliency of service X by August 2023.
Why?
It measures the process of work but not the desired outcome.
Resiliency is an output metric. What indication and metrics indicate that we have increased the resiliency of service X?
Better Goals
Decrease the amount of Pager Duty alerts by 20% and increase the SLA of service X by 1% by August 2023.
Explanation:
The goal is objectively quantified - decrease alert by 20% and increase SLA of service X by 1%
Conclusion
Setting an effective impact-driven goal that can benefit a software engineer's and company's career interests can be hard. You will need to start working backward by identifying the quantifiable outcome of your goal to track your progress and results. The best way to quantify your outcome is by using metrics. When focusing on metrics, a general rule of thumb is to find metrics you can control. Lastly, you will need to have a story of impact to grow within your organization. Start crafting the story. Every action should have a justifiable reason for doing.
Now, back to you!
What tips and actions do you usually take to create a goal that is impact driven?
Hit reply to this email or comment in the comment section below. I'd love to hear from you.