Balancing Engineering Excellence with Business Value
Leaders' Stories: Tomasz Zaraś on Leading Engineering Team
If there is only a single lesson I can share after almost 2 years of writing Practical Engineering Management, it would be:
The role of engineering in a product company is to solve customers' problems.
Sure, our primary activity is writing code and creating technical solutions. However, the ultimate goal is to build what users need and are willing to pay for. This is why product companies exist.
This statement is backed by DORA research: “Organizations focused on user experience produce higher quality products and have more productive, satisfied developers who are less prone to burnout.” DevOps culture’s “Three Ways” focuses on continuous improvements through experimentation and learning, so our product constantly improves. The Product Operating Model, the way the most successful tech companies work, teaches us that engineering doesn’t work for the product - it is the product team.
It’s apparent that if you want to be successful as an engineering leader and make your team high-performing, you should focus on becoming a product engineer. It’s easier said than done.
That’s why when I saw my work colleague Tomek Zaraś's latest article, in which he highlights his work principles, I invited him to share it with PEM’s subscribers.
I have always admired Tomek’s pragmatic approach and leadership style. From a long-term perspective, these have always led to building high-performing teams with a genuinely iterative approach and solutions centered primarily on customers.
Here are his main points, which also resonate very much with me:
Shifting Focus: Value Over Code
Iterative Work is Key
The Power of Throwing Work Away
Engaging the Team in the Process
A Culture of Adaptability
I invite you to read the full article, written by Tomasz Zaraś, the Engineering Manager of Papaya Global, and my dear colleague with whom I’ve worked for several years.
Balancing Engineering Excellence with Business Value
One thing I’ve learned over the years is that engineering excellence only matters if it creates real business value. Too often, we, as engineers, get caught up in the craft itself—building elegant solutions, optimizing for perfection—without stopping to ask if what we’re doing actually helps the business succeed.
I believe that a team’s success lies in mastering the art of trade-offs, working iteratively, and ensuring that technology serves the business, not the other way around.
Many times, we celebrate the act of creating software, but shouldn’t we be celebrating the value our outcomes bring? Shouldn’t we focus on how much our consumers and users enjoy the products we build?
Shifting Focus: Value Over Code
Early in my career, I often felt a sense of attachment to the code I wrote—it was something I wanted to last. Over time, though, I realized that code is just a tool. What really matters is the outcome: does it solve the problem? Does it help the business grow? Does it make life better for the customer?
These days, I encourage my team to view code as disposable. That doesn’t mean we don’t care about quality—far from it. But we don’t need to over-engineer things that might not even stick. If we’re building something experimental or exploratory, we should be comfortable with the idea that it might not last. And that’s okay, as long as we’re delivering value along the way.
Iterative Work is Key
Over time, I’ve realised—thanks to Agile software development concepts—that delivering bulletproof solutions designed carefully upfront isn’t always the answer. Even in industries like space exploration, we see how rapid, iterative approaches can lead to success.
It’s not about delivering everything at once or waiting until something is perfect; it’s about taking things one step at a time.
When we break deliverables into smaller chunks, a few important things happen:
We deliver value sooner. Even a small piece of functionality can provide insights or help the business move forward.
We reduce risk. If something doesn’t work, we’ve only invested a small amount of time and effort, so we can pivot easily.
We involve the business. Iterative delivery creates opportunities for feedback at every stage. By collaborating throughout, we ensure the deliverable aligns with actual needs. And, more often than not, we uncover better business use cases to handle.
The Power of Throwing Work Away
I’ll be honest: it’s not easy to throw away something you’ve worked hard on, something you’ve tried to make a piece of art. People naturally feel attached to their work, and discarding it might feel like admitting failure.
However, if we’re truly focused on delivering value, we need to be okay with letting go of things that no longer serve their purpose.
Sometimes, that means abandoning a feature we thought was important. Other times, it means rethinking an entire approach because we’ve learned something new. It’s not failure—it’s progress. And when teams embrace this mindset, they become more agile and adaptable, which benefits everyone in the long run.
Engaging the Team in the Process
One of the most important lessons I’ve learned is that you can’t lead effectively if your team isn’t engaged. Engineers need to understand not just what they’re building but why. They need to see how their work connects to how the company earns money, serves customers, and creates value.
When the team understands the bigger picture, they stop being just task-doers. They become active participants in shaping solutions. And when they see the impact of their work, it motivates them to go above and beyond.
But it’s not just about motivation—it’s also about making better decisions. When engineers are involved in discussions about trade-offs, they can provide insights you might not have thought of. After all, they’re the ones who’ll be supporting what we build, so their input is invaluable from the start.
A Culture of Adaptability
I’ve found that the most successful teams are the ones that embrace adaptability. Things change—priorities shift, new information comes to light, markets evolve. If we’re too rigid, we’ll struggle to keep up.
That’s why I believe we should foster a culture where it’s okay to experiment, learn, and pivot. It’s okay to say, “This isn’t working—let’s try something else.” And it’s okay to throw work away if it means we’re moving closer to delivering real value.
Transparency is key here. I make a point of sharing the why behind decisions with my team, not just the what and how. When they understand the reasoning, they’re more likely to buy in and take ownership.
My Takeaway
If there’s one thing I’ve learned, it’s that delivering value isn’t about writing perfect code or sticking to the original plan no matter what. It’s about staying focused on the outcomes, working iteratively, and being willing to adapt.
As leaders, it’s our job to help the business shape deliverables step by step. It’s our job to create an environment where the team feels engaged, involved, and connected to the bigger picture. And it’s our job to make sure we’re delivering value—not just code—every step of the way.
—
Tomasz Zaraś
Mirek:
I’m grateful to Tomek for his thoughts on engineering leadership. “Staying focused on the outcomes, working iteratively, and being willing to adapt” are the values I also try to embody in my work as an engineering leader.
Share Your Story
With this article, I also invite you to share your story on Practical Engineering Management. Even though there are endless theories and “good practices,” nothing beats real-life experience in the challenging environment of software engineering management.
If you want to share your story with thousands of engineering leaders worldwide, drop me a note here on Substack or via mirek@practicalengineering.management. I’m more than happy to help you write the final piece so we can spread it with our leaders’ community.
PS
Happy New Year 2025!
Let’s make it successful for you and your engineering teams.
 | A guest post by
|