Hey!

Welcome back to another week of musings. We're in the middle of an atmospheric river in the Bay Area, so lot of rain for us, stay at home and drinking coffee.

I hope you had a restorative weekend! I know I'm getting ready for the Superbowl weekend.

Was this forwarded to you? You can subscribe here!

Things I discovered in the past week

• If you're a fan of Severance, you might like this video essay around office spaces!

• Lighting Then VS Now: Fire Before Electricity, another video essay on how illumination worked before and now.

I recently had a conversation with a peer, during which we discussed how organizational leadership sometimes wants to experiment, sometimes doesn't, and sometimes is unsure of what they want.

As engineers, we think we're open to change and ready to take on greenfield projects, new technologies, etc. At the same time, I generally see engineers complain about changes like chat software or building infrastructure. We take the most time to convince, even if we're open to change.

If you have experience working at a company with a mature enough product or a large enough user base, it will become harder to increase new user conversion or reduce customer churn.

The more we want to try and move the needle, the more we'll need to experiment with existing features. In some cases, releasing new features might be an experiment, so they should be short-lived and easy to dismantle.

I've seen and experienced fatigue from seemingly benign experiments that become successful. Sometimes, the code is released with a design that is not meant to scale. The solution was not meant to stick, and we're seeing more features added to the backlog.

If you're familiar with Hyrum's Law, you'll know that all code that's "out there" will be depended upon. This makes an engineering team face a hard choice: pushback and request to do the feature "right" or wait for some level of maturity or stability to refactor it, or, worst case, rebuild it.

Most of the time, these successful products mean that leadership will push hard to continue scaling them out to more customers, making pushing back less feasible (unless engineering has more power than product in your organization).

It is common to hear complaints about these experiments, such as creating churn to create, scale, and sometimes (most times) clean up. Sometimes, I struggle to articulate and provide an alternative, or "hard numbers," to back up the claim. But what I see missing most of the time are attempts to make it easier to experiment on the product.

There will always be a trade-off between making a product fully configurable and building it to spec. If you look around or know someone who works at YouTube, you'll know they use a server-driven UI framework that allows for high customization. Still, on the flip side, it's hard to see the impact of a change at the core level, or if you're aware, you'll need a higher degree of coordination to avoid affecting another team's product experience.

If you're not at a level to fund a team dedicated to building a UI framework, then you'll probably need to be resourceful to find pockets of your product where it makes sense to improve customization. Other times, it might mean that you'll need to refactor these experiments, either at a later stage or little by little, with a long-term vision in mind.

Other times, playing this long vision is costly because your org might change leadership, and who knows if you'll get priority next quarter. It's a game of trade-offs between long-term and short-term thinking. Can we do something this quarter? What could be deferred to later?

Your turn!

How do you deal with multiple experiments on your product? Do you have a robust infrastructure to experiment? Do you suffer large refactors later in the game? Let me know your thoughts by replying to this email!

Happy coding!