Weekly goals
How setting a weekly goal for your engineering team increases focus, alignment, and collaboration on the team, and helps deliver value to the business.
The problem
Over the course of my years working with engineering teams, here’s a dysfunction that I have observed repeatedly. A team is composed of 4 to 8 software engineers and an engineering manager. A product manager and a designer are embedded with the team.
The team follows “agile” and works in a 2-week sprint cadence to achieve milestones that were pre-determined at quarterly / yearly planning. Before each sprint, the engineering manager works with the product manager to select tickets from the backlog and then assigns them to individual engineers.
This is a very common way of working. It “works”. Here are the issues that I have seen with it:
Lack of tangible results. Pulling from the top of the backlog doesn’t guarantee delivery of any meaningful goal. Teams can go for long periods of time (months!) doing busy work that doesn’t result in any meaningful impact to the customer or the business.
Lack of collaboration and focus. The engineering manager usually assigns work so that each engineer can work independently. This can lead to multiple work streams, often resulting in lack of shared context and alignment, disengagement, delays in getting PRs reviewed, lower team morale, and more bugs.
Lack of agility. The work is typically planned a week before the two week sprint, leading to a 3 week reaction time. This is most noticeable in case of cross-team collaboration, when team A asks team B to do something for them and the answer from team B is “sure, we’ll get to it in 3 weeks”.
There are certainly multiple ways to solve those issues. Below I propose an alternate way of working that I have used successfully to solve those issues.
Weekly goals as an alternative approach
What is a weekly goal?
A weekly goal is a goal that the team is aiming to achieve in a week. It’s the answer to: “What is the outcome that we want to have achieved by the end of the week?”. It is a high-level goal that anyone on the team can explain in about 10 seconds. It should be clear to everyone on the team how the goal maps to value delivered to customers.
A great weekly goal is small in scope yet deep in impact. Ideally, it is composed of one single focus. A singular goal for the week forces the team to think about how all of their activities will come together at the end of the week to produce something meaningful for a customer. This is unusual and requires a mindset shift: engineers often want to “own” a thing from A to Z even if it’s going to take more time to complete it and may therefore not be the best solution overall.
In practice it may be hard for all things to be aligned with one goal. Bugs, or work left over from the previous week may require attention from the team. That is normal and does not mean that the team shouldn’t aim to align on a weekly goal.
With larger teams, it may also be hard to have only one weekly goal. In most cases I have found that 2-4 engineers can work on a single weekly goal. With larger teams, it is common to have two work streams, and therefore two distinct weekly goals.
The weekly goal frames all activities and discussions that the team is involved in for that week. Achieving a weekly goal may require other activities than delivering code to production. It is whatever is going to help the team iterate on the “build – measure – learn” loop. It may require talking to customers, doing a spike, conducting some research, or a mix of all those things.
A weekly goal is not a list of all tickets or activities that we wish to accomplish during the week. Creating a list of things to do in the form of user stories, spikes, customers calls, etc. is a natural next step after a team comes up with the weekly goal. Detailing the work and aligning on the details is valuable and should absolutely happen (for example during grooming).
Here are some examples of weekly goals:
“Turn on feature X for 10 customers and start gathering feedback.”
“Get rid of technical debt from our last project”.
"Migrate services X, Y, and Z to our new infrastructure".
“Address as many bugs as many open bugs as we can”.
“Create a list of initiatives that will demonstrably increase a conversion rate from trial to paid account”.
…
When and how to define the weekly goal?
Setting a weekly goal should take no more than 15 minutes. The day of the week when it is set doesn’t really matter. I personally like Mondays because it aligns with the natural weekly cadence, but there are often many other meetings on Mondays and some people prefer other days.
To come up with a weekly goal, the team has to have a clear longer term objective. That objective is set as part of a planning process that is separate from setting the weekly goal. I have found that having a proximate objective that is no more than 6 weeks out in the future.
A good way to come up with the weekly goal is to ask the question: “Given where we are in our project and our next proximate objective, what is the one thing that we need to achieve this week that will bring us closer to achieving that objective?”
Who sets the weekly goal?
The entire team! It is common for the EM, the tech lead, or the PM to come up with a proposal or have a stronger opinion when setting the goal. However, it is important that everyone on the team participates in setting the goal. It creates alignment and empowerment for all members of the team.
Why is a weekly goal important?
A weekly goal creates the following benefits:
It increases the value of the work produced by the team. By being intentional and starting with the goal as opposed to a list of things from the backlog that “must have some value because they are on the backlog”, the team only does the most valuable work.
It increases clarity for all members of the team and creates alignment. That means less pulling in different directions, which in turn means less wasted effort.
It increases agility by letting the team take into account the most recent context (customer feedback, etc.) and re-orient on a weekly basis, rather than having pre-set tickets that may be outdated and get worked on because they are at the top of the backlog.
It increases collaboration. Product development and software engineering is a team activity. There is sometimes a default to considering software development as an assembly line activity where software engineers pick up work items and deliver them individually.
It creates focus and a sense of urgency. There is little time in 5 days for scope creep or to veer off on an irrelevant tangent. In case it does happen, the team can realign and correct the trajectory after only 5 days.
Value is shipped faster to customers. Rather than having engineers work on parallel tracks that will take longer to deliver, the team delivers value to the customer sequentially.
By contrast, teams that do not have a weekly goal are in danger of “prioritizing” work by picking up whatever tickets are next in their backlog. They tend to lose sight of the bigger picture and risk working on outdated tickets and miss opportunities to deliver more value to customers.
A team that lacks focus and intentional prioritization will often feel like they are not moving the needle on anything despite cranking through tickets.
Conclusions
Running a team with weekly goals increases focus, alignment, and collaboration on the team. It helps deliver value to the business by starting from the goals/outcomes.
The key ingredients to this approach are:
Starting with the goal/outcome you want to achieve
Having short iterations
Focusing on as few things as possible
If the exact approach I described here may not work as is in your context, how can you make those 3 things happen in your context?