Here’s an interesting take by Sheril Mathews on why people often don’t trust their managers, or find them inauthentic:

Managers don’t come across as authentic because more often than not they don’t have an intimate understanding of the day to day realities of how their teams actually get work done.

Sheril goes on to discuss some some great advice on how to show up for our teams in authentic ways (spoiler: it’s about getting our hands dirty in the trenches). But I also wanted to share this 1973 (!!!) quote from Henry Mintzberg in The Nature of Managerial Work, because it really stopped me in my tracks:

The prime occupational hazard of the manager is superficiality. Because of the open-ended nature of the job and because of the responsibility for information processing and strategy-making, the manager is induced to take on a heavy load of work, and to do much of it superficially.

Hence the job of managing does not develop reflective planners; rather it breeds adaptive information manipulators who prefer a stimulus-response milieu.

Sheril’s article—and that quote—is inspiring me to take a real hard look at my own work, and where there could be opportunities to weed out the “superficiality”.

This is a bit of an addendum that I think is valuable enough to add here. I shared the above Mintzberg quote among some friends and the discussion ended up being really interesting. Vince pointed out that as for the assertion that superficiality is an inevitable outcome of management, he prefers Russell Ackoff’s take from 6 years later. Here’s what he said in 1979:

Managers are not confronted with problems that are independent of each other, but with dynamic situations that consists of complex systems of changing problems that interact with each other. I call such situations messes. Problems are abstractions extracted from messes by analysis; they are to messes as atoms are to tables and charts … Managers do not solve problems, they manage messes.

Pete (who I’ve been begging to start a blog, please go yell at him as well) also went the less cynical route with his comments:

As you move up the levels of a company, you move to higher levels of abstraction. Every level takes the output of the level below, and distills and summarises it, passing it up. It also takes direction from above and tries to nudge the processes below in that direction.

I think that’s the just way it is, the way it has to be. I can’t think of any examples where a different model has been applied successfully at scale.

The key to this working successfully though is to make sure that information is correctly analysed, distilled, summarised and communicated at every level.

The problem with superficiality is not abstraction. It’s dillution. If you throw away the good parts and keep the wrong parts when summarising, the system starts fraying. And you’re setting those above you up for making the wrong decisions, and thus setting up those below you for failure.

I’m sure we’ve all seen those “here’s how to work with me” documents (and the controversies around them), but I like this slightly different take. In her post 9 Managers in 4 Years: Creating Continuity in Chaos Genevieve Conley Gambill shares a framework for helping our managers understand our skills, our work, and our career goals:

• Foundation – What are my unique strengths and capabilities?
• Trajectory – How do I view my current role and performance?
• Aspirations – What am I working towards in the future? 
• Support – What do I need to adjust or build on to get there?

She also shares a great Google Doc template with more details. The post goes into more detail on each section of the framework.

In the latest Platformer piece Meta doubles down on layoffs we see a perfect example of why stable software development teams are more effective than “agile teams” where people are seen as interchangeable cogs in a machine. When leaders think that people can be moved around between projects and “initiatives” at will and without knock-on effects, they run headlong into the basics of systems thinking, as shown here by Mark Zuckerberg’s realization:

In retrospect, I underestimated the indirect costs of lower priority projects. It’s tempting to think that a project is net positive as long as it generates more value than its direct costs. But that project needs a leader, so maybe we take someone great from another team or maybe we take a great engineer and put them into a management role, which both diffuses talent and creates more management layers. […] Indirect costs compound and it’s easy to underestimate them.

As a side note, this is honestly a pretty frustrating thing to read. It seems like such a basic software development concept—was there no one in Mark’s orbit that could tell him about the indirect costs of building VR headsets? And now that epiphany is costing Meta another 10,000 jobs. Ugh.

From How to Be a PM That Engineers Don’t Hate:

You see it everywhere: Engineers complaining about the product managers that they work with. Hating on PMs is kind of like complaining about your utility provider or the TSA—so universal that it’s always good for a light chuckle in the right circles. The PMs don’t know how the technology works. All they do is send emails and take credit. They’re meeting generation machines.

When I interview engineers my first question is always, “Tell me about your experience working with PMs.” I do it to calibrate what kind of PMs they are used to working with, or to put it another way, how much I should apologize for our profession before we continue…

Anyway, the linked post is less about that, and more about some things PMs can do to work more collaboratively with other teams—not just engineering. Lots of good, practical tips and examples here.

The World Nature Photography Awards 2022 winners have been announced.

What Does Workplace TikTok Look Like During Layoffs? It Gets Weird. Always Be Contenting, I guess. “It’s uncanny to watch clips of boisterous lunch buffets next to teary videos about being exiled from them—sometimes from the very same creators just months apart. You come to see how workday and layoff TikToks are mutually intelligible, odd sides of the same coin. No matter what happens, they say, workers will post through it. Work will be forged into content, no matter what.” (NYT gift link)

How to Take Back Control of What You Read on the Internet. Even The Atlantic is getting in on the RSS love! Could 2023 really, actually be the year? “But despite the syndication format’s cult following, most internet users have never heard of it. That’s unfortunate, because RSS provides everyday internet users with an easy way to organize all of their online-content consumption in one place, curated by the user, not an algorithm.”

I doubled-down on RSS. More RSS content! Here are a lot of words about the good and the bad of it. And some interesting observations too… “If you judge someone solely from the content they blog about, most folk will seem stodgy and humorless. I’m painfully aware that I’m no exception. The problem is that if you position yourself as irreverent, you’re likely to be dismissed.”

How The Last of Us re-created a 2003 arcade with the help of true enthusiasts. This article is so great. “We’re stupidly proud of this. All of it. We knew that anything less wouldn’t cut it and we’re nothing shy of grateful that HBO and the rest of the production encouraged us to go to these lengths.”

How the ring got good. A wonderful reflection on how Tolkien stumbled his way to what became Lord of the Rings. There’s some strong words of encouragement for all of us: “If Tolkien can find his way to the One Ring in the middle of the fifth draft, so can I, and so can you.”

De La Soul Is Streaming. A very important public service announcement on where you should start listening.

Some fairly standard advice here from Peter Yang on How to Run Meetings That Don’t Suck, but this point in particular is so important:

Try not to cancel or move 1-on-1s. If you’re a manager, it’s easy to move or cancel your 1-on-1s for other “important” meetings. This is disrespectful to your direct reports. Even if you see them everyday, nothing beats a private half-hour conversation where they can be open about real issues.

How we show up in meetings as leaders is very telling about how we view our team’s time. The most important rule is this: do not be late. I know this is hard to do in our culture of back-to-back meetings, but nothing says “I don’t respect your time” like consistently showing up 5 minutes late to meetings with no explanation. Here’s a quick tip: if you need a minute to go to the bathroom and/or get some more tea or whatever, make sure you join the meeting first and tell the person/people that you just got out of another meeting and you will be right back. Oh, and do not forget to mute when you leave…

In This will only take a minute the Raw Signal team shares some much-needed advice for leaders who feel like they never have time to think and reflect. This state of constant hypervigilance is not a sustainable lifestyle because:

On one level, you’re a human being. Regardless of your title or role, you are worthy of work that doesn’t wreck your health, or your happiness, or your ability to enjoy lunch away from your webcam. On another, if you’re a manager, you’re responsible for the work of a team of other human beings. If you don’t have the time to be thoughtful about your own work, the odds are very high that your team doesn’t either.

They go on to share some ideas for how to make this time to step back a priority, once you are “past the point where working a little bit more is going to clear your plate”.

Jade Rubick resurrects an old engineering concept (and dead Wikipedia page!) in Steel threads are a technique that will make you a better engineer:

A steel thread is a very thin slice of functionality that threads through a software system. They are called a “thread” because they weave through the various parts of the software system and implement an important use case. They are called “steel” because the thread becomes a solid foundation for later improvements.

With a Steel Thread approach, you build the thinnest possible version that crosses the boundaries of the system and covers an important use case.

He explains this in detail in the full post, with lots of helpful examples.