I am a big believer in “moving at the speed of trust” with teams. You cannot shortcut the work to build strong relationships—and I’m afraid there is no roadmap or deadline for that. Sometimes it’s easy, sometimes it takes longer. But don’t skip this work. Move at the speed of trust.

Ben Kuhn shares some good tips around this in Trust as a bottleneck to growing teams quickly. I particularly like these two:

• Overcommunicate status. This helps in two ways: first, it gives stakeholders more confidence that if something goes off the rails they’ll know quickly. And second, it gives them more data and helps them build a higher-fidelity model of how you operate.
• Proactively own up when something isn’t going well. Arguably a special case of overcommunicating, but one that’s especially important to get right: if you can be relied on to ask for help when you need it, it’s a lot less risky for people to “try you out” on stuff at the edge of what they trust you on.

And speaking of communication… Also see Arne Kittler’s Part 4: Clear Communication, part of a series on “Clarity for Product Managers”:

Lengthy texts dilute your message or even discourage your counterparts to deal with them in the first place. Focus on the main points you want to make and provide the context that’s necessary to understand them as quickly as possible. When asking for information or a decision, be clear about what’s unclear.

Lorin Hochstein shares a characteristically solid systems-thinking take in CrowdStrike: how did we get here?:

Systems reach the current state that they’re in because, in the past, people within the system made rational decisions based on the information they had at the time, and the constraints that they were operating under. The only way to understand how incidents happen is to try and reconstruct the path that the system took to get here, and that means trying to as best as you can to recreate the context that people were operating under when they made those decisions.

The “no root cause” concept is something I’ve been thinking about a lot as I’m working on a particularly complex project at work. Somehow we constantly forget that things usually are the way they are not because of a single “mistake”, but because of a the culmination of a bunch of legitimate reasons.

Systems get the way they are because of decisions made in good faith based on the data available at the time. And the worst thing you can do as a new person coming in to improve things is to hunt for a single “root cause” to fix. That’s just not how software (or people!) work. So take the time to understand Chesterson’s fence. Go ahead and draw boxes and arrows until no one disagrees any more about how the system works. And then figure out which parts can be improved, and in which order.

---

PS. Also see How Complex Systems Fail:

Because overt failure requires multiple faults, there is no isolated ‘cause’ of an accident. There are multiple contributors to accidents. Each of these is necessarily insufficient in itself to create an accident. Only jointly are these causes sufficient to create an accident. Indeed, it is the linking of these causes together that creates the circumstances required for the accident. Thus, no isolation of the ‘root cause’ of an accident is possible. The evaluations based on such reasoning as ‘root cause’ do not reflect a technical understanding of the nature of failure but rather the social, cultural need to blame specific, localized forces or events for outcomes.

Some solid points in this article from Jason Knight. On product-led vs. sales-led (but could also refer to engineering-led) organizations:

To be honest, my strong opinion is that if you have to worry about who’s “leading” anything, then you’ve got bigger problems to worry about than who’s leading. If your entire company is aligned around what’s important and how to get there, then anyone could “lead” you there. This is supposed to be a collaboration, not a dictatorship. If one team “leads” and others don’t agree with where they’re being led, fix that! I generally find that misalignment is one of the most important problems to solve in any struggling company.

Hard agree with that one. I don’t believe in “healthy tension” between product and engineering. Just like I shy away from the traditional hierarchical view of “bosses tell employees what to do”. Whether it’s Product and Engineering or Manager and Teammate… it’s about partnership and helping each other (and the company) grow. We have to reframe this idea that adversarial relationships somehow create better teams and products.

I’ve been pretty bad at sharing what I’m reading over the past couple of weeks, so I wanted to do a quick roundup post of some articles I have found helpful recently. I keep wanting to write longer posts about each, but it’s just not happening due to time constraints, and I need to clear out that queue, so here goes!

Unexpected Anti-Patterns for Engineering Leaders

Insightful post by Will Larson with some great advice for all leaders, including a reminder that it’s not a good idea to extract yourself from the details completely:

New engineering managers are often advised to “step away from the code.” But an extremely high-functioning exec understands the domain they are operating in at some level of detail. As you get too far out of the details, you just become a bureaucrat. Too many well-meaning engineering managers end up as bureaucrats.

The Busy Trap: How to Distinguish Being Busy from Being Productive

This one deserves a thorough read, because it talks about maximizing throughput in systems—and it’s not about making sure everyone on the team is at 100% capacity:

The real bottleneck isn’t in doing the work but in the waiting—queues that turn days of development into weeks of delay. This insight shifts the focus from individual busyness to process efficiency and the smooth flow of work from start to finish. Our findings debunk the myths that more planning, parallel tasks, and pull requests guarantee better outcomes. Instead, they emphasize the need for streamlined processes and effective collaboration to enhance true productivity. Let’s prioritize making each moment count towards faster, more efficient delivery, moving beyond mere activity to meaningful progress.

How to Communicate When Trust Is Low (Without Digging Yourself Into A Deeper Hole)

Lots of things in this post that I found very relevant and helpful. I especially have a… well, “growth edge”… in this area:

To the best of your ability, try to resist reading layers of meaning into textual communication; keep it simple, overcommunicate intent, and ask for clarity. And if someone is asking you for clarity, help them do a better job for you.

And related…

You vs. the forgetting curve

My friend and former colleague Fio with another excellent newsletter edition about why we should be ok with having to repeat ourselves a lot:

And it’s not that other people forget because they are selfish or don’t care—it’s because we plonked a bit of information at the top of their forgetting curve […] Because the forgetting curve exists, being an effective communicator might well require us to share the same information multiple times, at the right intervals, across different channels, without ever assuming that our teams and stakeholders will magically remember everything after the first iteration.

Principles of Engineering Culture at Wealthfront

I love (most of) these principles, but especially this one:

We believe our organization is most healthy when engineers, not management, propose and drive platform improvements. New products and problems are often brought to engineering teams to solve, but then technical leadership of these teams interweave these priorities with necessary infrastructure as part of their platforms’ continued advancement in engineering quality. While it is the team’s job to propose and defend these improvements, it is then management’s job to internally align and clear the path for the improvements to happen. The alternative would be for management to command infrastructure projects that teams then find time to execute. Such management decrees are avoided as they lead to poor trade-offs and unhappy teams.

Clarity for Product Managers: Part 1, Directional Clarity

Great series by Arne Kittler. This quote stood out to me because I’ve been surprised at how many people I’m currently interviewing for roles on my team cannot succinctly describe what value PMs bring to an organization:

Imagine you meet your CFO in the elevator: How well can you briefly and convincingly tell them what you are doing and why, and what the company will gain from it?

The Moral Economy of the Shire

On the non-work side of things, I adore real-world critiques of fictional worlds, like this one:

The implication in both books and movies is that most Hobbits spent their time either farming or enjoying leisure time, but this makes little sense, when one considers what we know about premodern agriculture and what little of life and culture in the Shire.

We have to realize that Bilbo and Frodo were independently wealthy…

Bilbo and Frodo are both gentlemen of leisure because the Baggins family is independently wealthy, and that wealth almost has to come from land ownership, because there isn’t enough industry or trade to sustain it. They can afford to go on adventures and study Elven poetry because they draw their income from tenant farmers renting their land.

I’ve linked to and written about the importance of 1:1 meetings before, and here’s another reminder:

The long game of building a thriving team is in showing up for your people week after week, and intentionally holding that space. You will not always see the value in each 1:1 right away. Your people might need help, too, to understand how to use them effectively. But over the long run, the benefits of an engaged and thriving team are immense.

I’ve been guilty of this before, but I’m making a new commitment to myself and my teams. Even if you “don’t really have anything this week”, keep the meeting. It’s in the consistency of showing up that trust and relationships build.

Melissa and Johnathan Nightingale have some hard truths about what happens when leaders take on too much of their team’s workloads in If you’re doing their job, who’s doing your job?

But now we have an overwhelmed team working for an overwhelmed boss. This is where cheap problems go to get expensive. You are chronically unavailable because you’re slammed. Your team can’t get your attention on a thing so they make their best guess. Their best guess turns out to be wrong. All the work needs to get redone. […]

As a manager at any level in an organization, a key part of your job is figuring out how to get the most important things done for the organization. Yes, the hard part of that job is sometimes the doing, and you can pitch in. But when your team is overwhelmed, when there is structurally too much to do, it’s your job is to figure out what’s most important. Where is that work happening?

Will Larson really got me thinking with his advice on the best ways to push your organization to improve. It’s essential work, but “organizations can only absorb so much improvement at a given time before they reject the person providing the feedback.” We have to balance the feedback about how to improve with guidance on how operate within the existing environment:

When I focused on how the environment could change to make my team more successful, I was usually technically correct, but usually didn’t help my team very much. Because work environments change slowly, it benefits your team more to give them feedback about how they can succeed in their current environment than to agree with them about how the current environment does a poor job of supporting them. Agreeing feels empathetic, but frames them as a bystander rather than active participant in their work.

Bit of a clickbaity title, but there’s some good advice for product managers in this article about making sure the organization understands that product is a profit center, not a cost center. This is the most important point:

Directly tie product to revenue. One way to do this is revenue attribution. In most companies, revenue and revenue growth is tied to marketing or sales. Making the point that product provided the thing to sell and the features that draw in customers is difficult to make. Product, in this regard, looks passive, and marketing or sales are actively doing something. It is easier to attribute recurring revenue to product because it prevents churn and increases upsells and add-on products.

This can be harder to do with some products—like a platform product with lots of internal customers. But the work is important. As Mike Fisher points out in Language of Business:

The lingua franca of business is finance. Each discipline speaks its native language, be that engineering, marketing, product, etc. but when they get together the common language that everyone should understand is finance.

And what that means for PMs:

The core message I want to convey is that understanding the language of finance is not just about adding another skill to your repertoire, although that is worthwhile; it’s about bridging the gap between technical expertise and business acumen. It’s about translating the complex, technical projects we work on into narratives that resonate with stakeholders across the board, narratives that clearly articulate value, risk, and return. This skill set enables technologists, engineers, and product managers to not only defend their projects and ideas but also to align them more closely with the strategic goals of the business.