David Hoang wades into the treacherous waters of the Should managers be technical? debate, and IMO comes out safely on the other side. I really like the 3 points he makes towards the end to articulate his point of view. I won’t spoil it because it’s worth reading the whole post. There’s one other bit I wanted to comment on, though:

The key roles of managers are to set expectations, ensure the team is operating efficiently, and maximize the output of the people on your team. In order to develop people, you must have a certain level of understanding of what skills are needed for people to be successful. However, as you progress in your career, there are going to be different org structures in place where it’s relevant. If you’re a Chief Product Officer, they likely have a more broad level of understanding of other functions outside of their domain and will put leaders in place who have the depth of knowledge in those areas.

I agree with the point that as you move into a leadership role, you can’t be as involved in the technical details of the product as much as you used to. But one mistake I see leaders make is to extract themselves completely from the product. And this becomes a bigger problem, especially in larger organizations. The further away the leadership team are from customers and the product, the more difficult it becomes to create product strategies that provide real customer (and business) value. Without the context of how the product works—and more importantly, how customers use the product—you cannot have a strategy that fully takes customer value into account. You end up with strategies that are too heavily skewed towards business value. A good product strategy balances both those things.¹

So, leaders: Spend time with your product at a deep technical level. Download Postman and interact with the API. Ask to be invited to a few customer calls each week, and attend at least one every two weeks. Don’t lose your proximity to the heart that keeps your business alive and well.

Via Chris Coyier I found this great post by Karl Sutt on How to communicate effectively as a developer. I especially appreciate him pointing out the importance of communicating clearly in short-form writing like Slack messages. His example of “low-resolution” vs. “high-resolution” writing in that context is a useful reminder for all of us:

In both cases, the example on the left is what I call “low-resolution writing”. There is very little context, too much reliance on pronouns and unclear references. The writing is not emphatic—the reader has to spend extra energy to work out what is being said. The examples on the right, on the other hand, try to make the reader do less work, even though it is more effort for the writer. The writer clearly has thought about how the message will be read.

This idea is similar to what Erin Meyer refers to as “high-context” vs. “low-context” communication in her (excellent) book The Culture Map: Breaking Through the Invisible Boundaries of Global Business. She explains in this HBR article:

I compare cultures along the Communicating scale by measuring the degree to which they are high- or low-context, a metric developed by the American anthropologist Edward Hall. In low-context cultures, good communication is precise, simple, explicit, and clear. Messages are understood at face value. Repetition is appreciated for purposes of clarification, as is putting messages in writing. In high-context cultures, communication is sophisticated, nuanced, and layered. Messages are often implied but not plainly stated. Less is put in writing, more is left open to interpretation, and understanding may depend on reading between the lines.

Choosing the right communication style for the right context is an important skill for everyone, but especially product (and other) leaders. If we assume too much context is known, people will misinterpret what we mean with our words.

I like Adam Thomas’s idea of identifying “survival metrics” at the start of a project. It’s a way to help teams stay grounded throughout the project and ask themselves whether they should stop the project, pivot in a different direction, or continue to invest in completing the project. From What Are Survival Metrics & How Do They Work?:

Survival metrics help a product team determine if an initiative is worth investing in more, pivoting or stopping completely. They are a forcing function to prevent product teams from suffering due to the sunk cost fallacy. Survival metrics put resource allocation and company incentives, both implied (think politics) and direct (think data), in front of the team before a project begins and again at regular intervals, giving permission to act quickly.

Adam goes on to discuss three questions that help teams identify those survival metrics.

Here’s a good analogy from Josephine Conneely to help figure out why growth might be stalling:

Imagine each of the 3 criteria pillars, Product, GTM and Org, as legs of a stool. Ideally each leg is of even height. This allows it to sturdily hold whatever is needed (in this case it’s increasing user volumes). Each leg can continue to grow (perhaps this is some sort of stool tree), and as long as the legs grow in tandem the success metrics of choice are safe. However, there may at times be an imbalance. Imagine an organisation with a great sales and marketing team who have created such demand that the product is struggling with performance issues as it scales to meet increased usage volumes. This leads to a lopsided stool, which while functioning, is not operating in manner which enables the org to capitalise on growth potential. If the product issues are not rectified, this could result in churn, reputational damage and a negative growth trajectory. Imbalance leads to lost opportunities.

Read the whole article for an illustration of the concept, and also how to use the framework in practice.

In Official myths Mandy Brown talks about how we are trying to solve the legitimate challenges of remote work by blindly (and incorrectly) assuming that the solution is going back to the office:

In many a remote-critical piece I’ve read, there’s a kind of mythical office that remote culture is being compared to, a place where everyone is welcomed, where collaboration and support is easy-going and automatic, where everyone is always whiteboarding or talking in the hallways. It’s kind of astonishing to see how much this presumed office utopia has become implicit, given we have literal decades of satire about offices as locales of poorly lit, soul-sucking, isolated work, where you are more likely to be abused by your boss than sponsored by them.

She goes on to explain the importance of supporting junior staff, and how office environments are often not ideal environments for that.