System Thinking For Product Engineers - with Michele Sollecito (live)
I asked our community a simple question: what is system thinking in one sentence?
The Butterfly Effect in Your Codebase
Have you ever seen a small, well-intentioned change create chaos across an organization? Michele has seen it plenty of times.
"The classic one is when you focus on measuring productivity, perhaps by counting lines of code or number of PRs. And then fast forward a year or two and you see that the entire culture of the company changed and people behave differently. Because fundamentally you create an incentive for them to do so."
Luis added a story that hit close to home for many of us: the mandate to reach 80% code coverage.
"There's lots of ways for you to reach that number. You could write a test that exercises the code but doesn't actually test anything, doesn't assert anything, and boom you get the 80%. But you're not actually doing anything."
The downstream effects are worse than the original problem. Teams that don't understand why they're testing end up coupling tests to implementation details. When someone wants to refactor, the tests break, so nobody refactors, and the architecture degrades over time. All of this from a well-intentioned mandate to improve quality.
Your Department is Not a Universe
One pattern I keep noticing is that every department lives in its own bubble. Developers obsess over agile and continuous delivery. Designers talk about design thinking. Managers have their own vocabulary. Everyone optimizes for their own metrics without considering how the pieces fit together.
Michele gave a concrete example:
"Some teams might pride themselves for doing continuous delivery. You can release to production 50 times a day. We're all happy. And then you're like, hey, if we release major features in production without giving marketing and product folks the chance to create the right expectations and audience and marketing campaigns, we'll only find the outcomes that we would have gotten from those changes because we're not playing in sync."
Luis has seen even tighter feedback loops break down within teams:
"I've seen this happen where you have people who work technically inside the same team, but they work in isolation. The designer does something, throws it over the fence. A day later, the developer gets very frustrated by the designer's wild imagination. He says no, this is impossible to do. It requires me to refactor. Sends it back. And a day later, the designer comes up with a revision."
The resentment builds, people start blaming each other, and the root cause is that they're not working together because nobody designed the system for them to work together.
Code is Not the Bottleneck
With LLMs writing code faster than ever, everyone keeps saying "code is not the bottleneck." Michele pushed back on the entire framing:
"Software development is not manufacturing. There's a lot of focus in the industry on throughput, productivity. How do you define productivity? There has to be time at the denominator. What do you put on the top? Is it lines of code? If you analyze it formally, it kind of cracks down."
The deeper problem is that we're treating product development as if it were an assembly line, where speeding up one part makes the whole thing go faster. But that's not how complex systems work.
"Even if we were able to accelerate software development by 10x, I mean, you're running to nowhere. The point is you still need to understand those things. That's the hard part of product development, not 'we just need to build it all.'"
Luis connected this back to the delays inherent in our work:
"Even if you write code 10 times faster, you're shipping all these features, but then you're ignoring the fact that there are people that use the software. Because they're human, they need time to adapt, to understand. That delay is exactly what we need to make the product better, to make decisions."
Building fast without understanding what you're building just gets you to the graveyard faster.
Why Organizations Create Wrong Incentives
Michele traced the root cause back to how companies are structured from the very beginning:
"A lot of companies start by hiring a panel of executives. I might hire you Giuseppe, you're the executive for product management. And Luis, you're the executive for sales. Now fundamentally, what that message says is: you're going to be entirely and fully responsible for product. You hire your own people and do whatever you want."
This cascades all the way down as VPs hire directors who hire managers who hire teams, and everyone ends up reporting to different hierarchies with different goals and different incentives.
When things go wrong, the blame game begins:
"If we fundamentally believe that the outcome is the sum of the parts, and that's the belief behind splitting the responsibility across the executives, then when things don't go well, I'm like, hey, I'm doing my part. Who's not doing their part? You don't see it as: we might all be doing our part well, but we're doing it in a way that doesn't really fit together."
The Social-Technical System
What makes software development particularly tricky is that it's both a machine system and a social system at the same time.
Michele explained the difference:
"Machines are made by inanimate parts. These parts don't have their own goals. You cannot create the wrong incentives in a codebase because a codebase doesn't do anything on its own. But developer teams are different kinds of systems, social systems, where each member has their own goals."
When you create incentives that force people to choose between what's best for themselves and what's best for the company, we all know how that choice typically goes.
Luis added another layer:
"Developers have emotions about the state of the codebase. That ends up making things worse and creates this kind of crazy dynamics."
That's what makes this a social-technical system, where the code affects the people and the people affect the code in ways that are almost impossible to fully predict.
What Can You Actually Do?
I asked Michele and Luis what individuals can do when they don't control the structure around them. Michele was both optimistic and pessimistic:
"Thinking things through, mapping them out, talking to people. That helps a lot. If you tell people, hey, there's a chance that this is going to happen because by doing this, that's how people are going to react and that's going to cause this, which is going to cause that. Sometimes people will fall for it."
But he was honest about the limits:
"Most of the time it really doesn't work. You will find a band of people where you're going to go to the pub and have a lot of fun talking about this stuff. But then you're still going to crash by the wrong incentives and structures in place."
Luis preferred demonstration over evangelism:
"I would probably demonstrate system thinking rather than try to push any books or videos. Show that two things that seem unrelated are actually connected, and point out that something might have an impact on this other seemingly unrelated thing. People might listen to me or not, but you keep trying."
Why Product Engineers Matter
This is where the product engineer mindset becomes crucial. When you care about more than just the technical part, you start seeing the gaps between elements.
Luis put it perfectly:
"Having this wider view is really helpful to get people to care, or at least start to think that it's possible to care beyond your little bubble. Because you're looking out across all sorts of barriers, front end, back end, design, engineering, product, you see the gaps between the elements. You think a lot more about the interactions of these components."
Michele went further, calling it a baseline expectation for seniority:
"If you come in at a level of experience where you're considered somewhat senior, I would take it as a baseline expectation. Otherwise, you're counterproductive, de facto, and people who know anything will probably not hire you at all."
That's a strong take, but I think he's right. The problems we face aren't technical in isolation. They're about how technical decisions interact with organizational decisions, which interact with user behavior, which feeds back into what we build next. You can't navigate that without thinking in systems.