Hi folks,

This is the weekly digest for my blog, Irrational Exuberance, and these are my posts from the last week. Always grateful to hear your thoughts and suggestions for topics to write about, drop me a tweet or direct message over on Twitter at @lethain.

Read posts on the blog:

- Programs: tips for owning the unownable.
- Some career advice.

Programs: tips for owning the unownable.

Good organizational design minimizes the cross-team coordination required to achieve team goals. Teams that move with little coordination finish projects while the others are still ratifying their implementation proposal.

However, complex organizations can't enclose every company goal in a reassuringly simple box. These goals that don’t map easily include some of the most interesting goals that companies have. Things like reliability, security, efficiency, and so on.

These goals don’t map well because they are properties that require active investment across every facet across the organization, but they’re also difficult to wholly decentralize because they have economies of scale and domain specific context that disincentive uniformly disseminating responsibility across every team. Can every team of six engineers have someone with domain expertise on security and cloud costs and performance and API design and the so list winds onward into oblivion? Probably not.

As I’ve become responsible for more goals that that don’t fit into the scope of a single team, I’ve become increasingly enamored with using programs to accomplish those goals.

Programs are initiatives led by a dedicated team with the goal of maintaining a property across an organization. Some examples of programs I’ve encountered are incident programs, various flavors of architecture reviews, maintaining infrastructure efficiency, UX consistency work, etc.

Programs are fascinating, because they’re like projects but for properties rather than tasks, and maintaining a property requires continual, ongoing investment. Because they're never ending, they are an amazing cauldron for experimentation, and because they’re supporting critical goals, they typically get staffed to success. Combined, they’re a unique opportunity for an organization to learn and improve quickly.

While I’m still actively learning how to make programs successful, I’ve written up what I’ve learned thus far.

As is often the case, there are more folks who deserve credit for these ideas and practices than fit on any finite list, but particular thanks to my coworkers Cecily, Charles, Grace, Davin, Drew, Erin, Roberto, Smruti and Taleena at Stripe.

When to use

Running a successful program is far harder than running a successful team. This means that programs are a bad default tactic, rather their relatively high fixed costs make them a tool for deliberate use only.

A successful program requires systems thinkers with experience in process design, folks with significant domain expertise, oh, and don’t forget the ability to keep executive sponsors engaged in areas they might not be natively engaged with while also accomplishing much of your work through influence without authority. If you don’t have all of those things, you probably shouldn’t use a program.

Conversely, if you need to make progress on something that requires broad, consistent application across numerous teams and projects, then programs are one of the few tools that truly work. Properly resourced and designed, I’ve seen programs move and retain mountains that no other approach can rival.

Designing the program

Assuming a program is the right solution for the problem at hand, let’s walk through the steps to launch it from concept to functional program: (1) assemble the team, (2) do initial discovery, and then (3) design the process.

When you decide to launch a program, the first step is to assemble the program team. The folks your soon-to-be-successful program needs are:

• Program designer / systems thinker who has experience leading at scale with influence, knows how to leverage sponsors, knows how to engage partner teams, and can do all of these things in the most economical way for both the program team and the organization the program is guiding.
• Subject-matter expert who can steer policy decisions, influence and educate other teams, and lean on their past experience to skip past the first series of missteps (moving on to novel, original missteps as quickly as possible).
• System and tool builders who will partner with the other members of the program to create the automation and feedback loops to make the program successful with a fixed amount of time spent coordinating humans (avoiding linear growth of time spent supporting a program as the organization it supports continues to grow).
• Executive sponsor who will ensure the program gets the resources it requires to succeed, and also serve as the escalation point when the programs projects need to get prioritized.

Once you’ve gathered your team, your next step is to do initial discovery for the programs. The goal is to understand the problem clearly enough to start designing a program to solve it, and to determine the limits of the organization’s desire to address the problem. Some approaches to guide that learning are:

• Learn from your partner teams. The partner teams across that organization will supply the majority of the hands to accomplish your program’s goals, and you need to understand their needs and priorities before they’re going to be interested in understanding yours. Build these relationships early and you’ll get ongoing feedback about how to reduce their friction and make the program work.
• Learn from your executive sponsor. Programs that don’t leverage their executive sponsors well don’t succeed. Similarly, programs that lean too heavily on their sponsors typically don’t do super well either, becoming bottlenecked on their sponsor’s scarce time. Take the time upfront to agree on boundaries, escalation mechanisms and what not.
• Learn from industry peers. Most companies “at scale” will have a program similar to the one that you’re running. Meet with as many of those folks as you can and learn from their successes and failures.
• Learn from literature. Not every program is going to have relevant literature, but there are a surprisingly large number of relevant books out there, many of them hiding in the DevOps category. Ask around for suggestions!

Finally, with both the team and the context, you can start designing your program. The tools, systems and structures you need to create are:

• Program data is the underpinning of successful programs, and a prerequisite for most of the other other tools and systems you need to create. Having accurate, defensible data to ground your program on is the first thing to focus on building. Until you’ve built that data — and the program team has become deeply familiar with it — none of these other approaches will be particularly effective.
• Program goals. Your program needs to have clear top-level goals that are used to track whether the program’s approach is succeeding. These should be both top-level goals that tie tightly to your users’ and business needs, as well as intermediary goals that help you understand the health of the program’s approach.
• Sub-goals for partner teams. Each team you partner with should have its own contribution towards the overall program goal, and should have a sub-goal that holds them accountable to that contribution. These sub-goals should be proposed by the program and then refined together with the partner team into something everyone feels comfortable committing towards.
• Dashboards that show program progress against goals and allow each team to dig into and understand their progress against their sub-goals. The best versions of these provide clear recommendations on where the program team should focus their attendion, as well as which areas teams should focus on to meet their targets.
• Nudges that push updates to teams who are falling behind on their sub-goals. It’s impractical to assume folks will poll dashboard to learn they’re falling behind, so instead you need to bring that context to them. Conversely, you should never send a nudge to someone who doesn’t need to take action, which will cause them to tune out all further nudges.
• Program status review. You’ll need a recurring forum to hold yourself accountable to your own goals (I’d recommend a quarterly review). It’s essential that your sponsor is a participant in these meetings, providing a mechanism for ongoing alignment as priorities change.
• Partner-team status review. You’ll need another set of forums to ensure that each partner team is holding itself accountable to their goals. This is likely adding the sub-goals into an existing review forum for the partner teams, not creating a brand new forum. For example, this might be specifying an additional OKR for each partner team to review during their OKR reviews. It’s usually impractical to attend all of these, but it’s quite useful to attend those where the team is struggling to meet its program sub-goals, you’ll learn a lot about the challenges they’re up against and how you can adapt the program to work with them where they are.
• Team operating meeting. Your program will learn so, so much as it operates, and you need a place to make the numerous ongoing tweaks that are the lifeblood of successful, effective, efficient programs. The program team should be meeting at least every other week for an hour.
• Program retrospective. You need a forum for the program team to learn about and evolve the program together, perhaps once or twice a year. These meetings should take a broader view than the operating meeting, rebuilding your strategy based on your organization’s evolving context.

Combine these three bits together, and congratulations you have the beginnings of an organizational program that can take on the sort of broad goals that so far you’ve been trying to lead in the spare minutes between meetings.

Making them effective

Beyond the above steps for designing and launching a new program, a few more comments and tips for how to make your program work:

• Manual work is a prototype, not a solution. The best way to make programs fail is to adopt manual processes as long-term solutions. Manual work is boring, error prone and misinvests your energy into execution instead of evolution. It’s extremely important to do the first version of most program work manually to understand where the rough edges are and fix them before doing a broad rollout, but you should never rely on manual work to perform the broad rollout. Automate instead, even if that means ramping more slowly, because the automation is going to get you much further in the medium and long-term.
• Build for beginners. Program leaders must focus their approach and tools on supporting beginners, not on supporting experts. This can be difficult because part of ramping up to lead a program is becoming an expert in its domain. When working with many teams, most of those teams will focus on your program’s area so infrequently that they’ve forgotten whatever they learned last time before they think about it again. Build your tools and guidelines with the assumption that your users have never used them before and will never use them again.
• Be explicit about team roles. Each program team will have a different set of folks with different strengths and interests, which means each program will have slightly different roles. The important thing is to have the team sit down together and clarify their roles and responsibilities.
• Each domain has a different cadence. An incident program is a good example of a domain with a very short cadence, needing to drive from incident to remediation to understanding in hours or days. On the other hand, a program responsible for consistent API design would generally have a longer cadence, taking days or weeks to consider the long-lasting implications of evolving your API specification. A program managing your spend on cloud infrastructure (meaning AWS, GCP, etc) might operate over months and quarters, since money is spent slowly over time. \ \ Your program design needs to factor that cadence into your reporting and review mechanisms, ensuring they’re appropriate to the underlying domain you’re working in.
• Stay aligned with your sponsor’s goals. Some programs find themselves struggling as they push their goals further than their sponsor is willing to support, and burn out themselves and their relationships with partner teams. Every program is competing for resources with many parallel initiatives, and being aligned with your sponsor on how to encourage folks to make trade offs is essential to succeed. If you’re consistently aligned with your sponsor, then folks won’t escalate, because they know it’ll not change the direction, and your life will get much easier.
• Iterate quickly to reduce friction. Even the best programs create friction for the teams they work with, because they want teams to prioritize projects when the that teams themselves often has conflicting priorities. The secret to success isn’t creating no friction, but rather responding very quickly to friction as partner teams flag concerns.

This isn’t the complete list of things you should be thinking about to make your program effective, but it’s a good start! Drop me a note if you have suggestions for more and I’ll add them in.

What’s next?

There is no “one true program design”, and I’ve found each sort of program I”ve worked on has ended up being quite different in its details. Take these ideas as a framework to tweak and occasionally defy.

If you’re looking for more reading about program design, some of the lightly related books I’ve enjoyed are The Deadline by DeMarco, Peopleware by DeMarco and Lister, and The Phoenix Project by Kim, Spafford and Behr. It’s true that these are not truly about program management, but I think the thinking in each of these books translates quite directly. What is a program, anyway, if not a project whose goal simply refuses to stay fixed.

Some career advice.

One unexpected perk of publishing a book is that folks start to ask you questions about all sorts of loosely related things. One pretty common thread has been around career advice, I’ve written up most of my advice for easier reusability. Some of the ideas are a bit contradictory, which I suspect is the nature of all useful advice: you’ll have to work through the conflicts and details yourself.

My career advice for folks in software, and maybe generally:

• “Advice is a form of nostalgia” is an excellent line from Everyone’s free to wear sunscreen, which is song with good, fairly unactionable advice and a particularly weird backstory. Advice you get is someone’s attempt to synthesize their experiences, not an accurate statement about how the world works.
• You’re just getting started. Particularly in tech in the Bay area, you can find yourself in some companies and jobs where you feel like an old-timer even though you’re only ten or even five years into your career. Although it certainly feels that way, rest assured it is not the case. You’re still just getting started, there is still more to learn and new things to do.
• Don’t assume you’ll make this much money forever. As you go deeper into your career, at some point many folks find themselves earning a lot more money than they were the year before. This is an exciting moment, but also a dangerous one. It’s far from certain that you’ll be able to retrace your steps into a similarly compensated role in the future. Save as much as you can when times are good.
• Decisions aren’t permanent. Increasingly I believe that there are very few trapdoor decisions. Do you want to become a manager? Go for it. It’s not a neutral event to return from management to engineering, but it’s a very common operation that many folks do successfully.
• Measure before you leap. Although decisions aren’t permanent, there are probably only ten or twenty key decisions you’ll make that define the trajectory of your career, mostly around which companies you join and roles you take on. Be wary of consistently considering only one opportunity — sometimes you’ll find an opportunity that is unique and don’t hold yourself back from that — but generally you should be considering a portfolio of options and picking among them rather than comparing between your current situation and a new one in isolation.
• Stay humble. I’ve seen a surprising number of folks who have their own “taking my talents to South Beach” moment, alienating the folks around them and landing in a worse spot.
• Specialization can be a financial trapdoor. It’s easy to worry too much about specialization trapping you into a certain type of role (I once was told to never write PHP, because if you wrote PHP companies would never let you write C++ again). However, if you specialize, then it often is true that your ability to get compensated outside of your specialty will be significantly lower. It’s likely that you would be able to recapture that difference over a few years in a new role, but lifestyle inflation can make that challenging to swallow.
• Be mindful of your risk tolerance. A lot of career advice makes assumptions about what sort of risk tolerance you have, but only you can answer this. If you’re only supporting yourself, went to a well-known school and have a family to fall back on, then you can be much more focused on maximizing upside rather than minimizing downside. If you are not in a position to take large risks, don’t buy into advice that assumes you are.
• Learn what you can learn everywhere you go, but don’t stay where you aren’t valued. If you’re lucky, at some point in your career you’ll find a company that values you much, much more than previous ones. Typically this will be because you’ve finally found a place where your values are mostly aligned. If you don’t feel that way, know that there is another company out there, somewhere, that will align with your values and they will value you much more as a result. That said, it takes a while to find such places, so don’t wait to learn until you find one, be a deliberate learner everywhere you go.
• Build a reservoir of prestige. Once your resume “looks right”, you’ll have more and easier access to interesting opportunities, including second opportunities if something you try doesn’t end up working out. Even if you enter the industry without much prestige, this is something you can deliberately build over time by working at increasingly well-respected companies, writing online, maintaining relationships and speaking at meetups (perhaps graduating eventually to conferences).
• Be discoverable. One of the reasons I write online is so that folks can discover me, and being discoverable has lead to many of the best things in my life. I suspect getting access to most exceptionally interesting jobs depends on first being widely discoverable.
• Don’t chase roles that you’ll hate. Sometimes you get onto the track for a high prestige role that doesn’t actually energize or excite you. Many folks who are passionate team managers find that organizational leadership — rife with conflict and the pursuit of resources — is not their jam. Learn about how you’d spend your time in the roles you’re considering and make sure it aligns with what you personally need.
• Don’t stay comfortable for too long. Growth compounds and if you stay somewhere that you’re very comfortable for too long, then you’re missing out on so much future growth.
• Marathon, not a sprint. You don’t have to be career optimizing all the time, it’s important and valid to prioritize other parts of your life. As you stay longer in your profession, it’s essential to make sure you’re getting what you need to sustain yourself long-term.
• Don’t get captured by your own strengths. Some folks are so good at something that they end up being irreplaceable in their current role, which causes them to get stuck in their role even if they’re a good candidate for more interesting ones. These folks typically have to leave their company in order to find new opportunities, a loss for everyone involved.
• Try internal moves first. If you’re ready to do something new, try to find something internal to your existing company before trying something external. Part of managing your career is not moving too often (not more than every couple of years, unless you find yourself in a bad situation, in which case ignore this advice and move now!), and looking internally gives you a freebie career change without any of the job-hopper connotations.
• Present your weaknesses (in the interview). You want to get hired for what you can actually do, if you oversell yourself too much, you’re setting yourself for failure. This is not saying you shouldn’t apply to larger roles — you should! — just that you shouldn’t hide your flaws and expect it to not catch up with you later.
• People, not jobs, last forever. You won’t love everyone you work with, but it’s unique valuable to start collecting people you truly do. You’ll switch jobs many times in your career, but the people around you in the industry will be there over your entire career. Great relationships will follow you everywhere you go. Bad ones too.
• Write your own career narrative. There are more paths out there than anyone will tell you about, especially as you get further into your career. Don’t assume you have to follow the beaten path, because that forces you to compete with everyone else for the same scarce roles.
• Try a lot of different things. Early in your career, try to work at as many different kinds of companies and in different product vertical as you can. Going broad before you go deep makes it much easier to ensure you’re spending your life energy on avenues that you’ll be grateful for later.

Finally, I suppose, I'd say that a surprising amount of a good career is about getting lucky and taking advantage of when you've gotten lucky. It's clear to me that many of the best things that have happened to me were only partially in my control, if that.

Thanks to Laurel for help with this post.

That's all for now! Hope to hear your thoughts on Twitter at @lethain!