Alexander Lunyov

The speed at which a product is developed doesn't inherently make the product better or worse. The number of commits doesn't make the product better or worse. The number of people or agents working on it doesn't make it better or worse. The number of hours you’re pouring into it doesn’t make it better or worse. Working on a weekend, or late into the evening, doesn’t make it better or worse. Talking about these things sounds like it’s talking about the product, but it’s not talking about the product. Those are all development metrics and styles of work. They don't speak to the product itself. They're all back of the house. Important to those making the work, but not inherently important to the people using the work. Development metrics and style say nothing about fit. They say nothing about quality. They say nothing about clarity. They say nothing about usability. They say nothing about utility. They say nothing about performance. They say nothing about how customers feel when they use your product. It's like reviewing a restaurant by talking about how many cooks were in the kitchen, how long the shift lasted, how many orders they fired, or how late they stayed cleaning up. None of that tells you about the meal, the product, the customer’s experience. Mistaking making for the thing you've made is like confusing the kitchen for the meal or the blueprint for the building. They're connected, but they're not the same thing. One of them matters a whole lot more than the other.

When you don’t compare, no one has more.

Tips, tricks, and hacks are an industry, they aren't an answer. Busy is a symptom, not a solution. Want more open space and time? Have less to do. There's no way around it. And I highly recommend it!

High vs. Low Problems Problems are often described by their size. "Hey, that's a big problem". Or "Eh, that's just a little issue, no big deal." And if you do hear someone say “serious” you immediately think huge. It’s still about size. I sometimes still use those descriptors, but I'm trying to use them less. Instead, I’m reframing problems as High or Low. High problems seep. They stain. They coat what's below, like melted frosting dripping down a cake. Gravity always wins, and high problems eventually become low problems too. You see this in relationships. Little problems don't add up to big ones - it's the big ones that create the small ones. Something small really annoying you about someone? Good chance it's because something bigger is annoying you more. High problems leaking down, staining what’s underneath. You see this in organizations. People bickering about flaws in someone's work or style? It's not because all is right above - it's because something's spilling from above. Bad hiring, lax oversight, proper examples not being set. High problems are like water hitting dry sponges — they don't just soak in, they make everything swell and distort, turning small issues into bigger ones than they should be. You see this in product design. Big picture complexity trickles down into every crease and crevasse. It’s hard to be simple and straightforward locally when you aren’t globally. The right design right here can’t be applied because predetermined guidelines from above promote consistency rather than context. You can’t just link something up because all nav has to be a button according to a larger system someone else already defined. While it's possible for small things to pile up and color what’s above, that direction is rare. So when you encounter low problems - especially ones that wouldn't seem noteworthy to an uninvolved observer — it's safer to assume they're symptoms of something bleeding from above, rather than growing from below.