I like to work in the “team of teams” component of a program or project. It’s a role focused entirely on quickly assembling high performing teams, constructing artifacts and decisions that answer the “why” and “what” of things to be done, while leaving the agency of “how” to do those things to the workstream teams delivering the work.
Over the past few years, I have taken leadership roles in the delivery of large, complex programs focused on clearly defined business outcomes. Or, to translate, “go build the team that makes the thing and setup our users for success to use the thing.” I have greatly enjoyed this work and have made a few observations.
(By the way, go read Setting the Technical Direction for a Team)
Contents
Measuring Program Success
When you’re leading a complex program comprised of multiple teams all swimming in their respective swim lanes, success is defined in ways that may be completely unfamiliar for those working on smaller projects or as individual contributors.
I use these three key metrics to chart my success:
- Excellence: A high degree of consistency is evident across all aspects of the work
- Efficiency: The quantifiable reduction of duplicative work and strategic use of technical debt
- Efficacy: The joy of operating as a high velocity team and the morale benefits of solving problems
Of all the levers and dials I have at my disposal when leading a program, these metrics are closest to my mission goals and most clearly related to my responsibilities.
I’ll go into more detail in the subsequent sections.
Ensuring Consistency
Poor consistency shows up in a variety of ways. It could be that deliverables feel out of sync from one another. Parts of the team work, but parts don’t. Work feels jerky and filled with hotspots. Perhaps this is one of those “you know when you see it” types of moments.
If everyone feels aligned across teams, the resulting output will be shaped in a consistent manner. Work feels connected and reinforcing. Teams are able to eyeball the work of another team and quickly understand the approach. The feeling of siloes is absent. Information flows are happening at the team level without weird trombone shapes.
This has everything to do with your leadership team of business and application owners. Their job is to provide decisions that guide and shape work done at the workstream level. If consistency is not evident, this is the first place to start investigating.
Realize that your program leadership team is there to provide their expertise on a particular topic or domain. They have a narrow and deep path to traverse. Provide the structure these team members need to plug into each other, share concerns, and align on the path forward. Consistency results when these key stakeholders are talking frequently and making course corrections as a group, much like a flock of majestic falcons. 🦅
Ensuring Efficiency
Efficiency is the most tactical way to influence a program. It’s not something you worry about too much at the start because everyone is still learning their place in the world. But it’s something to measure against once teams begin to sprint. I suggest re-visiting this on a monthly basis.
The first model to adopt is Continuous Improvement. The biggest mistake I see program leadership take is setting up a program model – org structure, meeting processes, etc. – and then never revisiting as the work takes shape. The program’s model should be different when researching problems than it is when delivering solutions. Take the time to regularly revisit the program and its processes, then compare the results to the target business outcomes. Don’t ignore the red flags you see here, fix them!
My other advice is on technical debt. When I was younger, I thought technical debt was inherently bad. Any debt was bad debt. I realize now that this is a flawed perspective. There are times where, for whatever reason, be it budget, staffing plan, or an unmet dependency, you’re going to have to move on and take on some technical debt.
The correct action is to then record this debt, place the resolution into the backlog, and ensure that the regular engine of the sprint rhythms will pull that debt back in at the appropriate time. Make the debt super visible and well understood. Technical debt is bad when it’s invisible and waiting to explode in someone’s face.
Ensuring Efficacy
Teams that skip the norming and forming process are setup for failure. And yet, it’s the part I see skipped the most. Be an inspirational leader to your teams. You will feel the urge to immediately jump in and start describing the technical aspects of the program. That’s natural. Resist it.
Regardless of how your team is split out among different groups or work organizations, focus on building a high performance team. Start there as the highest and only priority. At a minimum, your team should understand why everyone is here, how they are expected to contribute, and what that process looks like.
Here are a couple good artifacts to generate:
- Team Charter – describe your team’s mission, methods of communication, career goals, pet peeves, and more to help add shape and depth to your team’s human side
- Onboarding – socialize how much you value having a descriptive and actionable onboarding document, place it into the hands of your team, and give them agency over how it’s developed
- Team Working Norms – write down how you want to work together, for what hours, and any special needs the team may have so that no one feels “weird” for asking for the time they need
I’d also recommend reading Starting Your Leadership Journey.
Summary
Seek that which is both known and unknown. In this place exists greatness.
And with that
✌
