Owning business outcomes versus contribution

Today, we are continuing our series, entitled Developer Chats - hearing from the large scale system builders themselves.

In this episode, we are talking with Oleksandr Piekhota, Principal Software Engineer at Teaching Strategies. Oleksandr helps to show us at what point of scale platform approaches are required, when to run experiments and when to stop, and perhaps more importantly - engineering ownership beyond the code.

Questions

• You’ve moved from hands-on engineering into principal and technical leadership roles, working on architecture and platforms.At what point did you realize your work was no longer about individual features, but about the system as a whole
• Across several projects, growth didn’t break functionality — it exposed architectural limits.Can you recall a moment when it became clear that shipping more features wouldn’t solve the problem, and a platform approach was required?
• You’ve designed and supported APIs end-to-end, from architecture to real customers. How do you distinguish between an API that simply works and one that can truly support business scale?
• Internal systems like invoicing and HR workflows began as automation, but evolved into real products.What tells you that an internal tool is worth developing seriously rather than treating as a temporary workaround?
• In R&D, you explored CI/CD automation, server-less, and infrastructure experiments — not all reached production. How do you decide when an experiment should continue, and when it’s no longer worth the engineering cost?
• You’ve hired teams, set standards, and shaped long-term technical direction. At what point does an engineer stop being a contributor and start owning business-level outcomes?
• You contributed to open-source tools that later became part of your company’s infrastructure. Why do you see open source contributions as part of serious engineering work rather than a side activity?
• Looking across your projects, how do you now recognize a truly mature engineering system? Is it code quality, process, or how teams respond when things go wrong?
• If we look five to seven years into the future, which architectural assumptions we treat as “standard” today are most likely to turn out to be naive or limiting?

Sponsors

• Unblocked
• TECH Domains
• Mezmo
• Braingrid.ai

Links

• https://www.linkedin.com/in/oleksandr-piekhota-b675ba53/
• https://teachingstrategies.com/