Motivating Teams: The CAST framework
As an engineering leader, one of your most important responsibilities is to rally people behind the goals your organization needs to achieve. There are many ways to motivate people, from using incentive monetary rewards (always useful in the short term, less so over extended periods of time), to using your rank to get people to do what you want (the technique of last resort).
The most effective way to get people aligned with goals is to generate intrinsic motivation: get your team to truly want to achieve whatever it is that you want them to do. This can be done using simple, honest techniques rather than by doing anything manipulative.
I’ve found the following principles useful when motivating people to accomplish important goals. Together, these principles form a framework that I believe can be used by many leaders to generate clarity, excitement and alignment around their team’s goals.
Context
Good engineers want to know why they are building a feature or working on a project. As a leader, it’s likely that you have more context around the need for what your team is working on than they do; it’s your job to clearly communicate this understanding.
Provide the big picture context for what your team is building as much as possible: specifically, answer the question: “Why is this goal important, and how will the world change if we accomplish it?” Repetition is important, as is telling a story; don’t assume that people remember everything you tell them, or that they can piece together a narrative from the data. Wherever possible, refer to quantitative or qualitative research backing up the need for the goals the team is working toward: the more specific, the better. Quantitative evidence will often come in the form of A/B test results from previous features that the team has built; qualitative evidence can come from focus tests or user interviews.
Your job as a leader is to make sure that your team is aligned behind a broad mission that they understand the need for, and are energized by.
Accountability
Accountability, in this context, means ownership of objectives. Make specific people clearly responsible for accomplishing a goal. It is often useful to state explicitly in a public setting who, specifically, is accountable for achieving an objective.
Sometimes, you need to perform this assignment of people to objectives yourself, because success may depend on a specific set of people working on the problem. However, if this is not the case, you can often generate a high level of excitement by allowing team members to self-organize around objectives, letting people nominate themselves to be on the groups tasked with the objectives they care most about. When people publicly commit themselves to achieving a goal, they are usually highly motivated to accomplish it.
Your next step should be to get out of the way, and let the team figure out the details of how to achieve their goals. Teams that have the skills to achieve their goals are likely to be better than you at fleshing out the details, and leaving this to the team unleashes creativity and generates more alignment.
Your job as a leader is to hold the team accountable to progress toward those goals. You can do this through regular checkins with the team where you evaluate progress, recommend new courses of action, and make mid-course corrections when appropriate. Do not shy away from participating in some of the day to day activities of the team, like standups and technical reviews; and when you have positive or negative feedback, express it in as direct and actionable a way as possible. But leave the functioning of the team to its members, and hold them fully accountable for achieving their goals.
Success Criteria
As a wise cat once said, “If you don’t know where you’re going, any road will take you there.” Setting clear, measurable goals for your team is your job as a leader.
For any project, think carefully with your team about what the deliverables for the project are, and what success on the project looks like. The more clear you can be about these deliverables, the better — when people know exactly what the criteria for success are, they are better equipped to use their judgement in order to meet those criteria.
Defining good success criteria often means using a technique called “crystallizing fantasy”: help your team visualize a future, successful state of the project, in as much detail as possible. This might mean talking about the product as though the feature that you’re starting to build already exists, and describing in detail what the product looks and feels like with that feature. Then write down exactly the outcomes desired from the project in order to achieve that future successful state.
This step is often done best in collaboration with a product manager or a product owner who can serve as the voice of the customer. Tactically, it means defining an MVP, thinking through what edge cases will or will not be handled by the initial release, and potentially defining a staged release plan for a few releases beyond MVP.
Timeline
Clearly set timelines for a project are an essential part of team motivation. In some cases, this means establishing a hard deadline for when the project should be shipped to production; in others, you establish dates only for the first few iterative milestones of the project. The second approach is especially useful when there are important implementation or other details whose complexity cannot be reliably estimated at the outset of the project.
Hard deadlines can be toxic when they are unrealistic or imposed from above. However, ambitious but achievable timelines can often have a galvanizing effect on a team, especially when they are determined in collaboration with team members.
Good timeline-setting is based on the previous step: setting clear, measurable deliverables for MVP allows the team to estimate with reasonable confidence how long that release will take. Often, the timeline emerges organically from the process of defining an MVP: the team starts not with the question “Given this set of things to build, how long will it take?”, but “What can we build in three weeks?” — the timeline comes first (often based on market conditions or customer expectations), and the MVP is shaped to fit within that time.
There is one exception when a “ship date” does need to be imposed from outside the team: when it’s necessary to meet an external commitment like a marketing campaign, press release, trade show, or partnership. (This is also true in highly seasonal industries like games, where missing the important Christmas ship period by a month could mean halving your sales.)
In this case, it’s still your job to explain to the team why the ship date exists (part of setting the context, the C in CAST), and to shield the team from unreasonable expectations as a result of that timeline. If your team needs to “death march” to meet a date you’ve committed to, you’ve failed as a leader; good engineering leadership consists of delivering a product that satisfies business needs without over-stretching your team.
Keep your team accountable to the timeline by defining intermediate milestones; as Fred Brooks famously remarked, software projects that are a year delayed slip one day at a time. The final shipped version of your feature should not be the first measurable milestone; the team should make regular, iterative progress toward their goals that can be seen and measured.
In summary, motivating teams often involves the following steps:
- Setting Context
- Maintaining Accountability
- Defining clear, measurable Success criteria
- Setting a Timeline
Used together, these techniques — the “CAST framework” — can help you run high-performance teams that are highly motivated, energized and equipped to tackle ambitious goals.
