Building high-impact teams, promoting autonomy, navigating change | Mirosław Stanek, Engineering Site Leader, Papaya Global

Miroslaw Stanek is an experienced technology leader who has navigated the full spectrum of FinTech startup growth, from early-stage development to successful acquisition.

Currently serving as an Engineering Site Leader at Papaya Global , a SaaS platform automating global payroll, Mirosław brings a wealth of insights from building and scaling engineering teams through various stages of startup growth. Mirosław's practical approach to empowering teams offers valuable lessons for leaders looking to optimize their engineering organizations.

You can explore more of Mirosław's insights in his blog: Practical Engineering Management.

Highlights

• Hiring for remote-first teams.
• Less communication as a solution to disorder.
• Adapting leadership through growth stages.
• Leading your tech team through an acquisition.
• Becoming a better leader with AI.
• The future of the Engineering Leader role.

Yassine: What must-have qualities do you look for when building a tech team that can thrive in a remote-first environment? How do you spot these qualities while hiring?

Mirosław: There are some funny memes on the Internet comparing technical interviews with actual jobs. I recommend searching through them first 🙂.

If you ask people from the hiring teams I've established recently or in the past, many would say our processes look precisely like those memes. We have multistage interviews, assessing technical and coding skills, system design, SDLC practices, architecture, and cultural fit. The number of stages depends on seniority, but there are always at least two interviews with software engineers testing hard skills, and one focused on soft skills. For senior positions, system design is a must as well.

The reason for this thorough process is to always look for people who seem better than us, so we can continuously raise the bar of excellence within the organization. I want to hire people who will tell me what else we should improve, especially when I can't see it anymore (as an engineering manager, director, or above, it's impossible to stay on top of every technical advancement). This is critical because, over time, you either improve things or make them more complicated.

If we return to the meme comparison, I literally want to turn all the mess and chaos into a standardized, calm, and sometimes even boring environment where everything works like clockwork. Making hard things easy is a quality I value most.

The second critical quality is a focus on problem-solving rather than just task completion. In a remote-first environment, you need engineers who are partners to the product organization.

For example, in a system design interview, I don't just expect them to ask the recruiter for a list of 20 requirements (as engineers often expect PMs to have all the answers). I also expect a discussion where we explore tradeoffs, understand what the customer needs, and how to validate ideas quickly so we can iterate later.

So, in short, today, when interviewing, I look for product engineers—people who have decent hard skills but also understand that their role is to build working products for customers rather than just code. They know that sometimes there are no answers to all their questions. Hence, they must understand the product context—its hypotheses and objectives, the telemetry behind their feature, and how to iterate over solutions quickly.

Y: In your recent article “How to Build a Remote-First Culture,” you gave a somewhat counterintuitive advice; “eliminate communication rather than encourage it.” How do you balance this approach with preventing silos in a remote-first environment?

Mirosław: If you've ever worked on a monolithic system developed by multiple people in a distributed way (different teams, different locations), you know the problem. Each person has their own priorities, deploying changes to production becomes difficult, pull requests pile up, and tests fail due to cross-dependencies.

In the first phase, someone is often responsible for scheduling and micro-managing this work. But over time, the coordination overhead grows and becomes unmanageable. This may sound extreme, but I've experienced this process multiple times. There were days when people literally talked for hours via release channels or video calls. Everyone depended on each other. I hated it—one small issue could ruin the entire release plan, leading to tension and stress.

Leadership must find the balance between too much freedom and too much control. You need to build an environment with certain standards while allowing teams to make decisions independently—this is often called "aligned autonomy."

A good measure of success here is how little people have to communicate across teams. Suppose you have standards (NFRs, opinionated infrastructure, templates, tools, libraries), documentation and knowledge-sharing practices (engineering guilds, internal blogs, newsletters), and clear interfaces and domains.

In that case, teams will become self-sufficient, reducing the need for inter-team discussions.

Y: You've experienced various stages of startup growth, from co-founding to acquisition. How has your leadership style evolved across these different phases? Any key lessons would you share with engineering leaders navigating similar transitions?

Mirosław: Indeed, I've experienced many stages of a company's growth. I co-founded a small software house that was acquired by an early-stage startup (post-Series A). The company grew into a scale-up, went through four funding rounds, and was acquired by a company five times bigger. This gave me perspective on working in companies with 10, 100, and almost 1,000 employees.

Today, I document this decade-long journey on Practical Engineering Management through weekly articles for engineering leaders. I also wrote a dedicated blog post summing it up as "23 Lessons Learned After Multiple Years at an IT Startup."

If I could share only one thought about this experience, it would be the famous quote: "The only constant is change."

Here's the key lesson for me: very (very!) rarely does a single ticket or feature matter much to the organization. What matters is how quickly your system, tech stack, SDLC, and team can produce a new feature, push it to customers, learn from it, and iterate. The process is very different in an early-stage startup, where a small engineering team moves fast and accumulates tech debt, compared to a more mature company, where five autonomous teams deploy 20 changes a week while keeping the platform stable.

But the leading thought remains the same. Never stick to a single idea—always focus on learning and iterating.

Y: How did you prepare your engineering team for the transition to a different market and culture during Papaya Global's acquisition of Azimo?

Mirosław: Let's start from the beginning. During the acquisition, you (as someone who works for the company being acquired) effectively become a new employee in a fresh workplace. It would be simple to process if you had changed jobs intentionally. But it's difficult when you and dozens, or even hundreds, of your colleagues are "forced" into it.

Your company becomes history. The culture, processes, teams, and ways of working will soon fade out. But no one likes change, and many will desperately cling to "the good old days" in their memories and routines. The acquiring organization has its own culture, values, and habits too, which leads to tension between "us" and "them" on many levels.

This means it's your job to find a place for yourself and your team(s) within the new structure. The worst thing you can do is to either do nothing or drown in bitterness. You will surely notice the flaws in the new organization—broken processes, tech debt, politics, and problems that you may have already solved long ago in your previous company. But complaining won't help.

Instead, see the acquisition as an opportunity and a wind of change. Make sure your people get noticed. Find the best fit for their skills. Sell your skills and experience—or better, use them to solve the most demanding problems. It doesn't matter that you did better or differently in the past. It only matters how much you can help now.

If that doesn't work, perhaps this is an opportunity to change employers. Don't complain, and worse—don't be passive.

Y: You often highlight the importance of empowering team members. How do you balance giving individual contributors freedom to innovate and own decisions with ensuring alignment to overall product goals?

Mirosław: Here's how I approach it from a practical perspective: Let's say a product organization comes to me with either objectives or specific features to build. I see it as a problem that engineers are expected to solve.

Assuming we have the necessary skills within the team to make decisions about system design and architectural patterns, I don't mind whether it's a single or multiple services, this or that database, a new module, or changes within an existing app.

But I do expect the solution to meet our non-functional requirements and SLOs. I expect it to be covered with tests, telemetry, and alerts. Most importantly, the solution you build must be easily transferable. Your code should follow our internal standards (language, framework, architecture, observability, testing, deployment) so you can easily onboard someone to this solution and move to another project—or even another team.

I try to manage teams so that it's easy to transfer engineers between teams. This is also a nice opportunity for them to change perspective and gain new experience. The only way to do this is to ensure that no app or feature is strongly dependent on any single person.

Y: How do you see the role of engineering leaders evolving in the next 5-10 years, especially in the context of remote work and rapid adoption of AI?

Mirosław: First of all, let's clarify what AI means to me in the context of software engineering. It's just another tool that can boost our productivity. Things that took weeks a decade ago can now be achieved in minutes. AI will also contribute to this. It's like autocompletion, refactoring tools, automatic import, or auto-formatting that were revolutionary in our IDEs over the last decade. Or virtual environments, containers, and online environments like Replit or Codespaces. Or CI/CD solutions in the cloud. Or open-source libraries.

Of course, we'll still need computer scientists, people who optimize algorithms, build libraries, and frameworks. However, for most tech companies, where the job is to connect APIs, process some data, and build great UI/UX, the roles of dedicated backend or frontend engineers may become more niche.

What will the role of engineering leaders look like in this world? I believe AI will make it easier for us to be more hands-on and contribute directly to product development. This means we'll be able to focus more on what matters—creating real value for customers. The act of creation, something I love about software engineering, will reach a whole new level. And first-level engineering leaders (team leads, tech leads, engineering managers) will become some of the most impactful people in tech organizations. They and their teams will literally build fully working products for customers.

I'm very optimistic about our future. :)

Thank you Mirosław for your time and insights!

This interview is part of the “Exec Engineering Dialog” series where I interview seasoned tech leaders on the topics of talent, product, management and culture.

If you liked the insights shared in this interview, consider giving feedback and/or sharing it with your network, it’s the best way to help this segment improve and grow.

P.S. If you prefer your content on Substack, I'm also there.

Yassine.