June 26, 2019.
Some of my favorite pieces to write are those that end up being interesting to a pretty small audience, but tap into a central nerve for that small audience. So far, Programs: tips for owning the unownable, has been in that category. Most folks don't engage much with leading programs, but folks who are have feelings and thoughts.
One particularly good email came in from someone creating a new program, who was curious about advice for a common program challenge:
I joined my current company as a [resiliency] engineer, and now my team is working to spread a culture of [resilience] throughout the rest of the engineering org. We've identified three teams we need buy-in from for this program to be successful, but one of them seems tough to convince. Do you have any recommendations for getting buy-in from partner teams? Is there anything else you've written on this topic?
Note: email wasn't about resiliency, changed to protect the innocent.
Programs are often first designed with the assumption that they can accomplish some kind of essential cultural shift while operating from a place of influence, rather than operating from a place of authority.
And, for what it's worth, I still believe that programs should start operating from a place of influence! Operating from top-down authority makes it easy to skip over creating the guide rails required for successful program adoption, whereas taking an influence-driven approach forces you to perfect your guides first, before you start increasing the pressure.
Consider two different programs.
For the first program, your company is having stability problems, and you have a top-down mandate to reduce outages. Each team gets an incident budget and are required to have fewer incidents than their budget. As teams start to approach their budget, they start to panic, what are they supposed to do?
For the second program, you create a checklist of reliability practices that you recommend teams follow. You then integrate that checklist into your deployment tool so teams who aren't practicing certain important practices get reminded about the missing practices each time they deploy. Later there is a reliability push from senior leadership, but teams already know where to focus their efforts: follow the checklist!
Thinking through those examples, the specific recommendations I have for folks who are not getting program engagement they need from teams:
Clearly document the path. It should be extremely clear what steps a team should take to make progress on your initiative. There are many useful forms of documentation: examples of previous successes, tutorials, checklists, documentation, office hours, etc. If folks can't quickly identify their next steps, they'll probably not work on it.
As an addition caveat, most teams are going to be beginners when it comes to your new initiative. Not only are they beginners, but they'll likely never be experts, because they have many different projects and programs to satisfy. Design your instructions using your expertise, not on the assumption that every team will develop their own expertise.
Sell the dream. Folks are sometimes skeptical of why something matters, especially when it was something that the company used to not prioritize. This is very common for things like efficiency programs, where companies often prioritize growth over costs early on, and end up with a bit of a growth hangover where folks are convinced the company doesn't value cost efficiency, even when the company is franatically trying to improve their cost management.
The solution here is to (1) create new sound bites from your senior leadership emphasizing the new tradeoff, and (2) talk about it a lot in large, public places that emphasize why this is so important.
Build your dataset. Good programs live and die based on having a very clear dataset that they then build all reporting, analytics and tooling on. This might be tickets or it might be something much more sophisticated, but you'll struggle to show progress without it. You must do this before using subsequent approaches.
Push information, don't require polling. When you're creating a new program, it's usually because you want folks to prioritize a new area more than they currently are, and in that scenario I've found it very important to push information to folks, rather than assuming they'll come somewhere to review it.
Benchmarking everywhere. Once you have folks engaging, create leaderboards of which teams are engaging the most directly. This creates social proof that other folks are engaging with the program, and makes folks who aren't engaging realize they're part of an increasingly small minority.
Celebrate success loudly. When teams do engage, you have to celebrate them and ensure they get credit for their participation. This is a positive feedback loop, where teams that get that credit will then give the credit back to the program in turn.
Add explicit goals. Returning to your leaderboard, the final step is to work with your executive sponsor to add explicit goals around the minimum engagement that teams should be making towards the program. Once you have those goals, instrument them on your dashboards and leaderboards, and make sure that teams are reviewing those goals wherever they review their goals (in quarterly planning or what not).
Escalate with precision. Once you have clear goals that you've aligned with your executive sponsor, your goal is then to escalate very specific requests to that sponsor for teams that are having trouble prioritizing your asks. However, you want to make the narrowest possible escalations, to avoid overspending your sponsor's time and social capital. If you escalate broadly, they'll usually struggle to help, even though they want to.
As a final thought, typically lack of engagement comes from either (1) a team experiencing conflicting priorities or (2) a team's lack of clarity on how to engage. I've personally never encountered a team that didn't engage out of malice, bad intent or what not. Folks are out there doing their best, and if their behavior seems irrational it's because you're missing information.