I finally read this very long essay about Rewilding the Internet that’s been making the rounds. It’s about 30 mins of your time and in my opinion it’s time well spent.

It’s about what internet-builders can learn from the field of ecology, where the word “rewilding” has a very specific meaning. It’s essentially about systems thinking, which I know a lot of us care about deeply.

Rewilding the internet is not a nostalgia project for middle-aged nerds who miss IRC and Usenet. For many people across the generations today, platforms like Facebook or TikTok are the internet. They’ve long dwelled in walled gardens they think are the world. Concentrated digital power produces the same symptoms that command and control produces in biological ecosystems; acute distress punctuated by sudden collapses once tipping points are reached. Rewilding is a way to collectively see the counterintuitive truth; today’s internet isn’t too wild, even if it feels like that. It’s simply not wild enough.

In the end, I can’t help but think that though I love these ideas, it’s just… too late. I hope I’m wrong though.

In Crazy Charlie’s Window Michael Lopp says something that has stuck with me for a couple of weeks now (emphasis mine):

The reason, decades later, I frequently think of this unpaid weekend adventure sifting through a year of garbage, hardware, and knick-knacks is because it is when I discovered the compounding non-obvious value from doing exceptional work.

It’s a great story, well worth reading. Matthew Ström makes this point in a slightly different way in The polish paradox (again, emphasis mine):

The polish paradox is that the highest degrees of craft and quality are in the spaces we can’t see, the places we don’t necessarily look. Polish can’t be an afterthought. It must an integral part of the process, a commitment to excellence from the beginning. The unseen effort to perfect every hidden aspect elevates products from good to great.

Doing good work and getting the details right result in better outcomes, yes. But it’s about more than that. It’s not just about the job, it’s about us. The sense of accomplishment and purpose that comes from doing great work is an intrinsic reward that is life-giving far beyond the confines of our immediate job duties.

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.

I like Mike Hall’s tips for interviewers in his notes about behavioral interviews. The crux of the behavioral interview style is this:

I’d rather know what you’ve done than what you think, and I have adjusted my style a little to help candidates. I try to explain my process up front. “I’m going to ask you about times you did things because I really want to get down to how you work and what your experience is.”

It is, however, very important to realize that adjacent or related experiences are completely valid and should be encouraged:

If you want to build a diverse, vibrant team, or if you’re not one of those disasters of a manager who doesn’t understand that you need people at several levels of experience on a well-rounded team, then you need to think of a behavioral style not as a way to narrowly insist on stories that describe the exact thing you need done. Instead, you need to think in terms of the competencies the thing requires, and think of examples to ask for that reflect those competencies, not an exact task.

This is a good tip for candidates as well—don’t talk in generalities. Be specific about the ways in which you have solved a particular challenge in the past, what worked well, and what you have learned/would do differently next time.

I’ve followed danah boyd’s work for a long time so when she says something I listen. Danah has been researching teens and technology her entire career. In Struggling with a Moral Panic Once Again she weighs in on the “is social media causing the teen mental health crisis?” debate:

I wish there was a panacea to the mental health epidemic we are seeing. I wish I could believe that eliminating tech would make everything hunky dory. Sadly, I know that what young people are facing is ecological. As a researcher, I know that young people’s relationship with tech is so much more complicated than pundits wish to suggest. I also know that the hardest part of being a parent is helping a child develop a range of social, emotional, and cognitive capacities so that they can be independent. And I know that excluding them from public life or telling them that they should be blocked from what adults value because their brains aren’t formed yet is a type of coddling that is outright destructive.

That last point is pretty important I think. Maybe one reason all the arguments about teens and social media resonate with so many parents is that we are the ones with the deeply troubled relationships with it… Anyway, there’s some great advice for parents in the essay as well. Also see The great rewiring: is social media really behind an epidemic of teenage mental illness?

Most data are correlative. When associations over time are found, they suggest not that social-media use predicts or causes depression, but that young people who already have mental-health problems use such platforms more often or in different ways from their healthy peers.

I recently mentioned how I like to draw it until it works when I’m ramping up on a new system. Clint Byrum says it so much better in his post System Diagrams are Performance Caches for Cognitive Load. First, this bit resonated with me because it’s exactly the situation I currently find myself in:

Having joined just a few months ago, I was overwhelmed about 5 minutes into the meeting. The individual words and concepts all made sense. JSON parsing slow. Network transit treacherous. Changing things at the source hard. I got all of those components of the discussion, but through the whole thing I was just barely able to follow the overall system conversation and ask very basic questions to understand what was going on. I came away with a bunch of exploratory personal action items, and a very clear hole in my mental model of the system that needs to be filled.

Clint goes on to use a systems analogy for the individual people that make up a team—people and knowledge as components of caching, computation, and storage. This leads to a perfect explanation for why system diagrams are so important:

A single system diagram is where those primed nodes can push the most relevant bits of their information out of their local brain-caches, and into a high-performance distributed cache from which everyone can read. This will preserve precious cognitive load for those critical low-latency tasks. Of course, all of these caches may be stale. The local in-memory ones are particularly hard to test, but at least the system diagram is observable. Everyone can look at it, and if there are nodes with updates, they can update the cache.

So, prime those caches. Draw it until it works!

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.