Revisiting Manager READMEs

Several years ago, I published a critique of manager READMEs that succeeded in stirring up a lot of feelings, pro and con. I’d like to believe it prompted some people to reconsider whether these are actually effective tools.

Today, I want to revisit this. Not to encourage you to write a manager README, but to suggest other ways forward that I have learned in the years since writing the first post.

The Problem

When you become a senior manager or an executive, you face new challenges. Your job involves directing work across many people with different approaches, styles, and opinions. Left to their own devices, each person will develop a slightly different way of communicating with you, one that works for them and that they believe works for you.

With a broad scope of work to oversee, you need to quickly grasp what matters and should be shared upward, outward, and down into different parts of your organization. Now, at most companies, this is a known problem and inevitably someone has already tried to solve it by means of standardized tooling and reporting. Everyone uses Jira for a reason and it’s not that Jira is the best tool ever, but it is malleable to many types of standardization. Companies implement OKR tools and Tableau dashboards, they institute various program management processes, they run quarterly business reviews, and all of these are done in the name of standardizing the information that is passed upward and outward so that people can make better decisions.

Unfortunately, this is typically the lowest common denominator of usefulness to any senior manager. Reporting generated in this way obscures as much as it reveals, and it rarely addresses the things that you really care about¹. So senior managers need other mechanisms for imparting what they want to hear about and see. The README can sometimes be an attempt to impart that cultural overlay: a way of saying, “I care about X, and want you to focus on that when you communicate to me; I don’t care much about Y and Z, and by the way, it’s best if you communicate with me in these ways.”

I remain steadfast that this is not a good approach. It creates a focus on you as the person to be managed up to. Your personality must be accommodated, your preferences honored. I get the desire for this, and I’m certainly not immune to being managed up to, but my preference is to avoid major blind spots. I want to hear what I care about, yes, but I don’t want to live in an information bubble either.

READMEs are also rather lazy. There’s a kernel of truth in their purpose: we want people to focus certain types of communication on what we believe is most valuable. However, doing it in the form of a general README isn’t actually the most effective approach.

So if not READMEs, what then?

The Solution: Appropriate Templates and Ceremonies

Instead of one doc that attempts to communicate all of your preferences and warts and creates a you-focused mindset, it’s time to level up and recognize that a big part of the job of senior/executive management is setting standards for doing certain types of work. The best way to set those standards, in my experience, is lightweight templates and ceremonies for information sharing, discussion, and decision-making.

I think that every good senior manager should have some toolkit of these. You aren’t just going to operate against the lowest common denominator of pre-existing reports and processes in your company, you have to establish a few processes that exist to show what you care about and where you want the organization to focus. One of mine is Wins and Challenges (discussed in my recent book), which I’ve brought from startups to giant teams and everything in-between. Is it extra work on top of whatever people might be doing in Jira or other tools? Possibly. Does it create far more valuable conversation across my leadership team than those tools? Yes. Does it help me specifically understand things and do my job better? Absolutely.

There is a very lightweight template to follow for my Wins and Challenges, and the process details are owned by the team gathering the information (although I specify opinions about how it should be done, I only check the outcomes). I find that the best templates and processes are lightweight in a way that they show what information should be collected but don’t dictate exactly the process to collect that information.

Developing templates that expose the right useful information is hard. You will both over-do and under-do this as you’re figuring it out, whether it’s your first time in the job, you’ve moved to a different company or team, or your team has just evolved past the usefulness of the old methods. My advice is to start simple and add on new details or processes only when it’s clear you have a widespread gap. A good rhythm for a new job/team is to learn for 90 days, then introduce what you need, and evolve from there with enough time to learn from each iteration (usually, 1-2 quarters).

Don’t Try To Template/Processify Everything

I recently asked an experienced CPO about good product processes, and what they looked like from his perspective. One piece of advice was that not everything should have a fixed process or template. When you need to leave room for discussion, it’s often best to limit the structure; a walkthrough of a prototype might be better done as an open-ended exploration and discussion rather than a formal set of steps.

It’s important not to give into the temptation (or external pressure) to create processes for everything. I personally do not have a fixed format for my 1-1s, and dislike even the expectation of coming with a set of written and shared topics. I don’t want to feel rushed to finish everything on an agenda, and the temptation to immediately jump to conclusions about a topic based on an agenda item often increases miscommunication. Sometimes there’s a need to pre-read and prepare, but sometimes we just need to talk and see where the exploration of current top-of-mind concerns and information takes us.

So, senior leaders, you can tell people how you want them to work with you, but don’t do it via the crude mechanism of a manager README. Drive clarity through templates and processes where needed, resist the urge to create them everywhere, and lead your organization by showing them where to spend their time and focus as a collective good, not just good for you.

---

¹ Think of it this way, if you could easily see the problems via the pre-existing dashboards, they’d already be on their way to being solved. Dashboards are like alerts and tests in this way, they tend to catch what you know could go wrong, but rarely the surprise problems that lead to big incidents. Necessary, but insufficient.

Enjoy this post? You might like my books: The Manager’s Path, and Platform Engineering: A Guide for Technical, Product, and People Leaders, available on Amazon and Safari Online.

Dude, Where's My Strategy?

I’m working on a talk about rewriting platforms for LDX3 later this month. Spoiler alert: a lot of the talk centers around why rewriting platforms is usually a very bad idea. For more on that you can read the rearchitecting platforms chapter of my latest book.

One of the points we make in the book is that, generally speaking, platform teams are not the foci of innovation at companies. Platform innovations often come either by adopting external innovations, or absorbing and expanding platform-like work that was created by internal application engineering teams for their own purposes. I won’t say that it’s impossible for platform teams to innovate, but a lot of the innovation is much more incremental and evolutionary rather than novel and revolutionary.

But this doesn’t mean that there’s no need for strategy in your platform team; on the contrary, platform teams are often the fulcrum that drives important architectural evolution across companies. Pretty much every major change in technology that I have lived through has needed platform-level support: containerization, microservices, event-driven systems, big data, continuous delivery, observability, the cloud, elastic scaling. Many build on one another through the platform, such as containerization making it easier to move to the cloud and moving to the cloud making elastic scaling more realistic. 

This is what strategy starts to look like as a platform leader. You’re watching where the state of the art is going, and thinking about what makes sense to introduce or evolve so that you can take advantage of that over time. You’re not forcing everyone to move from bare metal hardware to kubernetes overnight, but you’re making the tools to support bare metal to virtualization/containers available, easy to use, and cost-effective, to encourage the natural evolution to happen. The larger the company, the longer these timelines will run, and the more that you’re going to have a number of leading and lagging strategies running, but this is the engine of baseline modernization that needs constant feeding to keep your technology stack from stagnating.

“Strategy” and “Vision” are so often conflated in peoples’ minds that this kind of boring but reliable forward progress is overlooked as strategic. But when leaders can execute in this way over years, the application/product teams have that much more flexibility and power to innovate and do interesting things without having to completely go out on their own. So, platform leaders, don’t feel bad if you’re not at the forefront of innovation! You don’t have to drive the next innovation to be strategic, you just need to make it easy for others to get there.

Enjoy this post? You might like my books: The Manager’s Path, and Platform Engineering: A Guide for Technical, Product, and People Leaders, available on Amazon and Safari Online. 

10 Years of Engineering Ladders

 On March 26, 2015, I posted a short blog post to the Rent the Runway engineering blog, Sharing Our Engineering Ladder, with a quick intro to the RTR engineering career ladder and links to both spreadsheet and long-text versions. This was one of the first public engineering career ladders that came with a clear distinction between management and IC levels, and meaningful details about the requirements and expectations at each level.

I published these resources because, at that point, most of the companies that were writing ladders were either a) getting some consultant like Radford to help them bootstrap something, b) copying a big company that they had worked for in the past, or c) stealing a template from a friend’s company and modifying it. For teams without the resources to hire consultants, prior big company experience to draft on, or friends to copy, they were basically stuck. I knew that what we had created at RTR was special, because it had many different sources of inspiration, contribution from a smart team of tech leads and managers, and a lot of care behind it. And as an open source person, I believe in the value of sharing not only ideas but actual work for others to use, build upon, and expand, for the greater benefit of the tech community. Publishing the ladders for widespread use was an easy decision, and one that has had an impact on the industry: I still get occasional thank-yous from people who have used it as a baseline all these years later.

These days, this sort of thing is almost passé. Almost every company has done this work, many inspired by the very ladders we published, but others inspired by far different approaches published over the years. I am proud to have stoked a simmering conversation among leaders in the tech industry. It proved what I always knew: most people want a starting point to play off of when designing organizational processes as much as they want one for technical work. Even if all the starting point inspires is “ew, not this!”, it gives you something to riff off of.

Advice For Writing

I’ve done this exercise again at least twice over at different companies in the past decade, and it’s always a challenge. So here’s some brief advice for those embarking on this process.

1. Don’t let (or make!) HR do all of the work. It’s really not their job to define expertise in your functions.
2. Details matter. Your ladder should be more prescriptive than a horoscope; it’s impossible to avoid all subjective language like “increasing complexity”, “large systems”, “high impact”, but pay attention to where you use that and try to provide ways of roughly measuring this where possible.
3. One great way to flesh out details is writing long-form text to accompany the spreadsheet-style ladder. I think it’s a shame people don’t do this more, even if they don’t publish it, because it helps you envision the work and catch things you might miss when writing bullet points.
4. You should not try to create a ladder that functions as a pure checklist or scorecard that guarantees promotion if people check enough boxes; promotions are as much about the needs of the organization as the skills of the employees.
5. Be honest: not every job family has ladders that start at the bottom and go to the top. Some should start in the middle and go up; some may start at the bottom and only go to somewhere in the middle. Don’t promise people that they can become the VP of X just because some people do job X, and don’t pretend that you should hire people straight out of school into jobs that are specializations that you only take on after years of working as a generalist.
6. Also, maybe you don’t need to create a job ladder for literally every job. There’s something to be said for the finance company catch-all analyst/associate/VP/MD scale to cover everyone, with ladders for large population jobs (such as engineering) where it makes sense.
7. Err on the side of more early-career levels rather than later-career ones. Assuming you are still hiring junior engineers (you really should be even in this AI era), the good ones will learn quickly and want to see career progress in their first few years of working. Once the path splits IC/management, just match the management levels and you’ll be fine.

Are Ladders Passé?

Even as I write this, I’m not sure anyone will care. The industry is in backlash mode, and I wouldn’t be surprised to see many companies try again to make the “flat” organization work. But even with the aid of AI, I’m not convinced that we’ll overcome the human instinct to gather in groups and create leaders of those groups, and fight one another for power of those groups. The Tyranny of Structurelessness has yet to be overcome, and for those who still care about creating strong, transparent, equitable organizations, this work matters. Just please don’t make me personally write them again!

Enjoy this post? You might like my books: The Manager’s Path, available on Amazon and Safari Online, and Platform Engineering: A Guide for Technical, Product, and People Leaders, available now!

(reposted from https://skamille.medium.com/10-years-of-engineering-ladders-329d309000cd)