Everyday we posit absolutes we believe with utmost certainty, and just like we do for any quips that pique our curiosity, we grant them overreaching engagement that they neither deserve nor ask for, to make them part of our collective attention: pondering over them, internalizing them, repeating them and making them our own. Up and until time inevitably teaches us that there are in fact no absolutes.
There is only one rule to adhere to when re-organizing your team -- design what your team needs to look like to be successful, before deciding where specific people fit.
A remarkable number of leaders get this wrong by doing the reverse: elevating specific people first and designing the rest of the org around them. I understand why people might think this is a good idea: a reorg will inevitably create new focus areas, and investing first and foremost in the highest performers is an excellent retention lever. While this might be true, resist this urge at all costs. You might promote someone for exhibiting behaviors at the next level. Then separately, as a new opportunity opens up for someone at this level in your new organization design, this person might fit right in. But these should remain separate events. Thinking about both simultaneously creates all sorts of perverse incentives and bias, which often create blind spots that are at odds with diversity and inclusion.
Anyone in a creative field that has high standards of craft, likely has an indelible urge to refine what they're working on to perfection, even when their idea is simply a seedling and in its very early stages. While this urge is the strength that helps them make some of the nicest things ever to exist on this planet, it can also be a curse because that delays getting started.
Andy Matuschak describes a trick to turn off your editing brain:
One thing I really like about audio notes is that they remove my editing instincts. If I'm trying to write something even here, not on a walk and I'm struggling to figure out how to say what I'm intending, then I will often start dictation on my computer and then turn away from my computer, and walk out here with an AirPod in my ear and just walk in big circles. And I'll come back and a thousand words of texts will have been generated, I will probably use none of them, but at this point I'm ready to sit down and start typing.
I do something similar and can attest that choosing a format which reduces your ability to edit is effective at helping you making progress when stuck. I personally use Google Docs audio transcription (as it auto-corrects based on context and understands my Indian accent much better than alternatives) or pen-on-paper, when I sense I have an urge to edit thoughts I have barely begun to formulate. This usually frees my mind enough to enumerate all the subject matter, even if in the form of largely disconnected blocks. The next round of writing is 70% faster, because I can draw from what I know is already pretty comprehensive.
The most natural force in product development is to deliver additional user value in the form of new features. This is generally good. By not riding on a previous wave, you're proactively looking past the status quo and making something that's more likely to withstand disruption.
By saying yes to more features though, you are accepting the tradeoff in additional product complexity - both for usability and maintenance. In the short term, adding new details and surfaces into the product feel obviously useful and worth it. Your most loyal users thank you for listening. Your organization’s leaders celebrate you for realizing incremental gains that are harder to come by for a mature product. Maybe they even praise your outsized impact relative to investment. In the long-term though, you’ve inadvertently said yes to hundreds of small new local improvements and new surfaces. Very quickly your simple and approachable product becomes highly complex and oriented towards power users who have built up their understanding over long-term usage. New users can only ever use your product if they are motivated enough to overcome the learning curve to become power users. This puts a bottleneck on growth, with some short-term relief provided by investments in user education and onboarding flows. The upside here is limited, because you haven't tackled the real problem of product complexity.
This is a debt most teams know they are accruing but are rarely conscious about. They know this debt exists but they can't see it. The cost to tackle it proactively isn't one they're willing to fund since it is harder to measure their impact on the more immediate KPIs. Once it has accrued to the point it hurts, a fix usually comes in the form of a major refactor or redesign, that takes far longer to launch than you can anticipate, because existing revenue streams are sensitive to them and they are funding your efforts after all. For a host of products, it's often too late to navigate this change when it is in reaction to growth plateaus or dips in usage, which are often trailing indicators of complacency. Usually by this time, you'll already have a few disruptors in the market that you're actively combating. Your competitors offer something compelling while far less sophisticated -- simplicity and a low barrier to entry makes them as approachable as your product once used to be. In response, you're unable to remove features from your existing product, because your existing users depend on it. You're unable to add competitive features before your major redesign, because it increases your debt further and might end up alienating even your existing users. The situation feels impossible and you wish you'd responded sooner.
Having personally witnessed this in more than one situation across multiple companies, I've made sure my teams are chipping away at product debt proactively. The simplest solution I've found is to sign up only a proportion of bandwidth we have available as a team to support upcoming product work. We intentionally maintain slack on the team (10% bandwidth might be a safe lower bound) to tackle product complexity we cannot see yet. We usually spend at least half this time playtesting. This allows us a chance to retroactively identify the issues of people who are more dependent on our products, many that don't look anything like us. The other half of the time is spent simplifying complexity or fixing issues we've found as a part of this process.
Further, as a part of any new product work, I've found it helpful to bake this into our process proactively. To ground ourselves, we first ask: What are the core jobs that our new products/features will be hired to do?
Then, we ask a few more questions to isolate the real issues:
If we're intellectually honest, both of these are excellent at reducing debt on your team. When there are competing incentives, it's sometimes important to ask the extreme questions:
Kurt Vonnegut, written originally in The New Yorker, May 16, 2005:
Joe Heller
True story, Word of Honor:
Joseph Heller, an important and funny writer
now dead,
and I were at a party given by a billionaire
on Shelter Island.
I said, “Joe, how does it make you feel
to know that our host only yesterday
may have made more money
than your novel ‘Catch-22’
has earned in its entire history?”
And Joe said, “I’ve got something he can never have.”
And I said, “What on earth could that be, Joe?”
And Joe said, “The knowledge that I’ve got enough.”
Not bad! Rest in peace!”
via Robert Sutton
Bill Gates's definition for platforms is a good way to test if you're using the term correctly to represent the work your product is doing:
A platform is when the economic value of everybody that uses it, exceeds the value of the company that creates it.
Companies often create blindspots for themselves when they use research or data science with the myopic view of market validation, since this info is inherently biased towards what people already understand. They chase the short-term value of building a better commodity and cementing their existing position, because they dislike being in the ambiguous position of investing resources in a product that might never ship or see a payoff. Other companies with market leading positions sometimes console themselves by thinking it would be too costly for customers to uproot them and switch to a competitor. This can be a trap, because whereas the disruptor is able to move fast to close gaps in their product, the larger incumbent's delayed reaction risks them not having enough time to catch up because they have many more dependencies to resolve.
Engelbart's talk Improving Our Ability to Improve, covers this topic in detail, and has a lot of seemingly obvious advice that more companies ought to follow. While worth reading in its entirety, here are some parts that resonated with me that I think are important for product teams to value to extend their half-life:
Listen to the market to make your product more attractive for customers or to hold your position (make your commodity better), but to remain relevant in the future, you need to also consciously invest in parallel to build what your market doesn’t understand yet (expand outside the commodity that’ll likely be disrupted by something cheaper/better).
Oxymoron: "Market Intelligence." [...] The "market" assumes the dimensions of faceless, impersonal deity, punishing economically inefficient solutions and rewarding the economically fit. We believe in the wisdom of the market and belief that it represents a collective intelligence that surpasses the understanding of us poor mortal players in the market's great plan.
[...] In any case, it is quite clear that whatever it is that the market "knows," its knowledge is fundamentally conservative in that it only values what is available today. Markets are, in particular, notoriously poor judges of value for things that are not currently being bought and sold. In other words, markets do a bad job at assessing the value of innovation when that innovation is so new that it will actually rearrange the structure of the markets.
While you might chase the benefits of ease of use, don’t discount the common-sense payoff that users get in terms of performance when they have to learn some things every once-in-a-while, that translate to muscle memory/ superpowers thereafter.
Going back to my tricycle/bicycle analogy, it is clear that for an unskilled user, the tricycle is much easier to use. But, as we know, the payoff from investing in learning to ride on two wheels is enormous.
There's a gradient of ideas lost when we take extreme sides in discourse. The people we stereotype in our heads are more like us than we think. All it takes is having a conversation; maybe we resist it to avoid finding that our neighbors are quite likable, just like Sahil Lavingia did:
I had assumed that Provo was happy being Provo — white, male, and Mormon-dominated. I hadn’t thought to consider that they wanted change just like I did.
They were envious of San Francisco’s racial diversity (while I complained about how much further we had to go). They lauded the focus on women in the workforce (while I talked about how sexist the tech industry was). They spoke ill of their reliance on cars and the negative effects on the environment, while I spoke ill of San Francisco’s public transportation.
Also:
I visited San Francisco last Christmas, and I tried advocating for conservative politics at bars. There is a stigma that certain ideas aren’t taken seriously in San Francisco anymore. I didn’t see that. Just like conservatives embraced me and my ideas, liberals gave me the same grace.
I now believe that both sides are composed of mostly open-minded people that aren’t represented in the NYTimes nor on Fox News nor in the latest viral political Tweet. They’re at home and at school and at work trying to make ends meet. They don’t care about that level of exposure. They are working privately to solve those problems. Maybe you’re one of them! If so, hi!
The term Work-Life Balance suggests a tradeoff between time spent on work and on life, with one borrowing from the other and a balance providing the silver bullet of happiness and contentedness. This is at least a little bit misleading, because while the tasks at work and home are different, how we feel at any moment in time is harder to compartmentalize to a certain part of the day.
What I've found more effective to strive for is better Task-Satisfaction Balance. If you don't enjoy what you're doing, it is much more likely because of the type of tasks you're doing, rather than because of the number of hours you're putting in. At work, doing the types of work you really enjoy are likely to help you do the work faster, whereas that which you find less enthusing or fulfilling consumes all time you have available. The is also true at home. To stop walking the path to burnout, I've found myself needing to catch myself spinning my wheels on mundane tasks and pivot fast.