Will Larson shares some interesting perspectives on teams in the interview How to Size and Assess Teams From an Engineering Lead at Stripe, Uber, and Digg:

Larson believes that the fundamental challenge — and cornerstone — of organizational design is sizing teams. “The most powerful unit of work is a gelled team. People who know how to work together and are practiced at working together can accomplish truly remarkable things,” says Larson. “When managers design too literally around the current product or architecture, they churn people and lose what I think is the only truly renewable source of energy in the world: people who really love — and know how — to work together.”

He goes on to describe four states a team can be in — falling behind, treading water, repaying debt, and innovating — and the best way to improve teams that are in each of those stages.

Karolina Szczur makes some excellent points about using “technical debt” as an excuse for subpar products in The Technical Debt Myth:

Technical debt becomes a convenient blanket statement entailing frustrations, rushed decision-making, lack of process or architecture, and tedious maintenance tasks — the get-out-of-jail-free card for delivering a subpar experience.

It’s crucial to understand that as software and design grows older, that doesn’t necessarily mean we’re dealing with debt. We must look deeper under the surface to find the root cause of bottlenecks we’re facing. Only when we carefully assess the symptoms can we find solutions to building products that last.

While we’re on the topic, the most useful article I’ve read on technical debt is Henrik Kniberg’s Good and Bad Technical Debt (and how TDD helps) from way back in 2013. He discusses good debt, bad debt, and the importance of having a “debt ceiling”. Highly recommended post, and still very relevant.

Jeremy Keith writes about the developer community’s need to always talk about new things in Dev perception. I think the same can be said for every other profession, including product management:

It’s relatively easy to write and speak about new technologies. You’re excited about them, and there’s probably an eager audience who can learn from what you have to say.

It’s trickier to write something insightful about a tried and trusted (perhaps even boring) technology that’s been around for a while. You could maybe write little tips and tricks, but I bet your inner critic would tell you that nobody’s interested in hearing about that old tech. It’s boring.

The point he makes in his post is a very good one — that we should always evaluate any technology (or, in our case, methodology or framework) based on appropriateness, not newness. It reminds me of Kellan Elliott-McCrea’s excellent list of questions a team should answer before they decide to adopt a new technology in their software development process.

Phil Johnson has some good advice for product managers in The Goldilocks of Process:

Blindly following process is a project-killer—not just in terms of efficiency. The real poison is the mentality: in these cases process became a crutch to lean on, with these individuals no longer thinking critically about their tasks. In many ways, the process became the job, where process really should be what enables the job. This rings doubly true in the software development world.

On any team, you want your process like you want your porridge: just right. If you have too little, the team may not know what the priorities are, or who is responsible for the next step. Too much, and your team will end up doing more process than actual work. The right strategy should be flexible enough to fill in the cracks of the team’s blind spots while enhancing their strengths. It’s up to the PM to find that sweet spot.

This also reminds me of Michael Lopp’s essay The Process Myth, and these words that will forever be etched in my brain:

Engineers don’t hate process. They hate process that can’t defend itself.

Herb Caudill’s Lessons from 6 software rewrite stories is an extensive analysis of the rewrite projects of companies like Basecamp and Trello, why they succeeded or failed, and what we can learn from them:

Once you’ve learned enough that there’s a certain distance between the current version of your product and the best version of that product you can imagine, then the right approach is not to replace your software with a new version, but to build something new next to it — without throwing away what you have.

Eventually all product managers face a decision like this, so I found these case studies invaluable.

In the article From Four Wheels to Two RJ Marsan talks about the Lyft engineering team’s principles for quickly and safely adding major features to a mobile codebase. It’s full of interesting learnings as they went through the process of adding scooter rentals to the app. Here’s a good point about trying to avoid doing everything in the first release of a new feature:

Every new feature is a chance to start with a clean slate, and it’s often tempting to immediately build for scale. We all want our products to launch to massive fanfare and usage, but more often than not, the path to success for new features is slow and steady. With steady growth in mind, we designed our first architecture to support exactly what’s needed for our first product iteration, and nothing more. For Lyft Scooters, we cut out many features one might expect from a classic ride such as sharing ETA or setting a destination.

Kellan Elliott-McCrea has an excellent list of questions a team should answer before they decide to adopt a new technology in their software development process. For example:

If this new tech is a replacement for something we currently do, are we committed to moving everything to this new technology in the future? Or are we proliferating multiple solutions to the same problem? (aka “Will this solution kill and eat the solution that it replaces?”)

As he mentions in the post, these questions are not subtle… but I think they’re absolutely essential. It reminds me a little bit of Marty Cagan’s Product Opportunity Assessment questions.

In The Misunderstood World of Product Growth Joe Van Os makes some great points about the importance of focusing on making your product resilient to negative impacts:

Since it is impossible to forecast when positive opportunities will appear, it is important to be in a position to take full advantage of them when they do. If a product team is in fire-fighting mode (dealing with the fallout of negative circumstances), opportunities with plenty of upside may be missed.

Limiting downside (technical debt, red-tape, etc) allows a product or business to quickly recover from negative impacts, as the negative impact will be contained. It is building a tough product.

This essay about the building blocks of the web by Rachel Andrew is really important. From HTML, CSS and our vanishing industry entry points:

There is something remarkable about the fact that, with everything we have created in the past 20 years or so, I can still take a complete beginner and teach them to build a simple webpage with HTML and CSS, in a day. We don’t need to talk about tools or frameworks, learn how to make a pull request or drag vast amounts of code onto our computer via npm to make that start. We just need a text editor and a few hours. This is how we make things show up on a webpage.

Web agency Postlight wrote about their engineering culture, and what a breath of fresh air it is to read this list in the midst of the current “hustle til you drop” culture:

The positivity of our internal communication fosters a team that is warm and easy to engage with for our clients. Our clients are shocked by how easy it is to communicate with our engineers. No knee-jerk reactions. Just a friendly, two-way, conversation with professionals.

Or, as we phrase it in our Wildbit values, “As a team, we support each other to do the work of our lives.”