Today, we sit down with Denis Ermakov, a seasoned Software Engineer with over 15 years of experience in the tech industry. Denis has a unique background, having pioneered frontend development during the Netscape Navigator era and led development teams across a range of projects in both technical and managerial roles. His experience spans a variety of industries, including FinTech, telecom, and web development, with a strong focus on Agile methodologies, including Scrum, SAFe, and Kanban. Denis is also a Certified Professional Scrum Master (PSM) and an ICF ACC-certified coach. After years of managing teams, Denis transitioned to a contributing software engineer role at Techflow, where he focuses on product engineering from the ground up. We’re excited to dive into his journey, insights into the tech industry, and his evolution from leadership to hands-on development.
Interview Questions:
1. Can you walk us through your journey from starting out in the industry during the Netscape Navigator era to becoming a lead software engineer at Techflow?
Answer Here:
It was the very early 2000s when I was a junior in Computer Science at Samara State Aerospace University. I was looking for ways to earn some money and dove into my first job search. I played with HTML and PHP at that moment in my pet project related to the student community. Still, the local employers knew very little about scripting and automation, so the only job I was offered was HTML coder in the local brand agency. In the next two weeks, I was tasked with a 3000-page plain HTML website that needed to be updated with a new UI. I soon realised that I would work until ungodly hours and work myself to death, so I mustered up the courage and introduced PHP to my manager and CEO. They risked trusting me, and as a result, the whole work was completed in a couple of the following days. I was immediately promoted to a PHP developer and charged with building a new department to handle complex projects. Also, the salary was doubled, and it was motivating.
After graduating, due to family circumstances, I needed to return to my home town. Remote work was not popular among employers, so I decided to start from scratch at a new place. I was fed up with outsourcing development at the agency and looked for alternatives. Luckily, it was days when the first startup accelerator (best known as Skolkovo) ran, and there was a local hub in my hometown. I had some ideas, successfully pitched one of them, and got some funds to launch. It was a cloud-based CRM for small medical companies, mostly dental. Obviously, I needed to learn what it meant to run a business from scratch before a deep dive, but nobody told me at that time. So, in the following years, my days were filled with a crazy mix of hot and cold sales, business administration, hiring tech guys into engineering teams, participating both as an organiser, guest and speaker at professional conferences and, of course, code contribution and bugfixes. During this routine, I learned some new words like Agile, Scrum, Kanban, etc. Good grief. If it was not for them, I definitely would have driven nuts. After streamlining all the processes, I got a little bored. We had three mature teams of developers, tens of happy clients, and a good market fit. Everything worked like clockwork. But I was seeking new challenges. I wanted to apply my knowledge on a large scale and dreamed about joining a big enterprise. That is why I went to “Rostelecom” and shortly after closing the project I worked on I settled in “Otkritie” Financial Group, which was in the top 5 banking at that moment.
I took on the role of Engineering Manager in the SME department, overseeing 300+ engineers. We developed a brand-new CRM/ERP system, along with client scoring and decision-making tools for loan processing. This required me to close gaps in my people and process management skills, so I earned a Professional Scrum Master II certification from Ken Schwaber’s Scrum.org, obtained certifications in Kanban from David Anderson’s Kanban University, studied professional coaching at the International Coaching Federation (ICF), and became a member as an Associate Certified Coach. In the end, we did well and launched the product on time.
As is well known, history develops in a spiral, whether we like it or not. I got an offer from my boss I couldn’t refuse, so I joined a new startup with a brilliant team working on a product designed to help teams in Russia left without crucial software amid sanction restrictions. So here we are.
2. You’ve managed software teams for over 15 years. What do you think are the most critical skills for a software engineer to develop in order to be effective in leadership roles?
Answer Here:
Code is just a set of words we use to describe business needs in a specific form. Therefore, all code is simply the result of communication among developers, as well as between developers and business people. So, I guess the critical skill to develop is removing impediments to communication and facilitating it.
You also need to have the gift of the gab to sell your ideas to the team, and that’s the second skill you should develop.
The third is simple trust and the ability of the lead to build it. If you, as a manager, lack trust and cannot trust the team, it will lead to micromanagement with poor results.
Of course, sometimes you need to be tough and be able to slap someone on the wrist. Please don’t take it to mean that I have beaten my teammates. Still, you should be bold enough to encourage good behaviour and suppress unconstructive behaviour.
3. How did your experience as a certified Scrum Master and ICF coach shape your approach to team dynamics and software development?
Answer Here:
For me, the core principle Scrum taught is to focus on the single most important task at hand and to continuously reflect on how to improve my work and the team’s performance. Coaching, on the other hand, provided me with the skill of non-judgmental observation, which is invaluable in an unsteady environment. People can be angry, tired, or hyperactive, and all these factors influence communication and, ultimately, the quality of your product. Understanding the motives behind the team’s decisions is essential for maintaining a healthy codebase, ensuring business stakeholders’ satisfaction, and fostering a positive team atmosphere.
4. You’ve transitioned from leading teams to contributing as a software engineer at Techflow. What motivated this shift, and how has the transition been for you?
Answer Here:
It didn’t take much consideration. As I mentioned earlier, a product is the outcome of people’s communication and collaboration. There was a kind of magical chemistry between my business stakeholders and future teammates, so I chose to work with them. I am absolutely confident that starting from scratch with a good idea and the right people is more than enough to succeed.
There’s also a widespread belief about two types of people. The first type seeks challenges: they start with nothing and create something entirely new, like building a house on an empty plot of land. The second type craves stability and calm: they move into a freshly built house and live happy, settled lives. I see myself as a builder and a creator, someone who thrives in fast-changing environments.
Besides, I had long dreamed of working on a large scale in a vertical corporation, and, as my colleagues told me, I did well in that role. With that milestone achieved, it felt like the right time to move on.
Regarding the transition: once an engineer, always an engineer. The foundational principles of software development never leave you, but catching up with the latest tools and updates did take some time. Fortunately, my transition happened at the end of the year, so I had a couple of weeks full of holidays. That was enough time to dive deep into recent developments and feel like a student again as I explored the newest trends in software tooling.
5. Can you share a specific project you led where you introduced Agile or Scrum methodologies that had a significant impact on the team’s performance?
Answer Here:
Certainly, I have many stories to share, but one particularly memorable experience occurred at Rostelecom. I was working with a small, newly trained team consisting of five developers and a product owner. The team was tasked with building a tool for the B2B sales department, which managed the buying and reselling of data channels. The product owner prioritized the backlog, and the developers worked on pulling and delivering tasks as expected. At that time, we were developing a feature called the “marginality monitor.”
The purpose of the feature was to automatically identify and address underloaded and overloaded data channels and display the relevant information to an operator. It was a complex feature, and the sprint itself was challenging. After successfully shipping the feature, I decided to introduce the team to a practice I call “go-and-see.” The idea was simple: visit the actual user, observe their interaction with the system firsthand, and learn from their experience.
We traveled across the city to meet a user. The user logged into the system and began navigating to our newly delivered feature. What happened next was surprising. The user clicked on the menu, and the loader froze—for half a minute. They waited patiently until it loaded. Another click—another 30-second freeze. The user continued clicking, each time enduring the same delay. Finally, they reached the feature.
Perplexed, I asked the user, “Why didn’t you ever report these freezes?”
The user replied, “I didn’t think it was a bug. I thought it was supposed to be like that.”
This was a revelation. While we were focused on delivering new features, users were wasting tens of minutes daily waiting for the system to respond and sipping their coffee. No one had identified the issue—not the product owner, not the developers during the tests, and not the users. The bug wasn’t even in our backlog because no one had realized it existed.
From this experience, two critical lessons became clear:
- There are no unnecessary details in the Scrum Guide, Agile Principles, or Agile Manifesto. Every element matters.
- Team performance isn’t just about fast delivery. It’s about delivering the most valuable outcomes on time.
This experience fundamentally shifted how I approach Agile practices, emphasizing the importance of both user feedback and delivering value.
6. Having worked with both small teams and larger, more complex organizations, what do you think are the biggest challenges in scaling Agile methodologies?
Answer Here:
To answer this question, we first need to define the key difference between a small team and a large organization. I believe the core difference lies in the number of communication links between people. Let’s calculate briefly:
- Between two individuals, there’s a single link.
- For three people, the number of links increases to three: 1-2, 2-3, and 1-3.
- With four people, the number of links rises to seven: 1-2, 1-3, 1-4, 2-3, 2-4, and 3-4.
The formula to calculate these links is N = n(n-1)/2*. For a thousand people, the number of communication links grows exponentially to nearly half a million. This is why organizational design becomes critical and why teams’ structures need to be carefully planned.
The initial instinct in such cases is often to apply traditional principles from the science of war: create hierarchical squads of ten people, each led by a supervisor, with layers of leadership above them. This results in a classic hierarchical structure.
However, a more counter-intuitive and practical approach is to allow teams to self-organize around objectives. This means shifting the focus from managing people to managing workflows and optimizing information flows to eliminate bottlenecks. Making this mindset shift—from managing individuals to managing processes—is, in my experience, the biggest challenge in scaling Agile methodologies.
7. Over your career, how have you seen the role of a software engineer evolve, particularly in terms of work processes, tools, and expectations?
Answer Here:
When it comes to processes, let’s step back to the early 2000s, when Agile values and principles were first articulated, and examine why this happened. A group of respected software engineers came together to identify practical, helpful, and shared practices they used in their daily work with software projects. They documented these insights in what became the Agile Manifesto. Interestingly, there haven’t been many significant changes since then. Processes based on Agile principles continue to work as effectively today as they did 15 years ago.
On the other hand, tools have undergone rapid transformation, especially over the past two years, largely driven by the AI boom. As a result, there are significantly fewer monkey jobs and far more opportunities to engage in complex, strategic thinking.
As for expectations, I would say that knowledge of the business domain has become critically important. Stakeholders no longer want to simply tell engineers what to do—they expect expertise and well-informed decisions. You might have access to first-class AI-powered tools, but knowing where and when to apply them remains your responsibility.
That said, some fundamentals of software engineering, such as collaboration and rapid feedback loops, remain unchanged and continue to serve as the cornerstones of effective software development.
8. During your time as a Service Delivery Manager, you focused on reducing time to market and defect leakage. What strategies did you implement to achieve these outcomes, and how do you measure success in these areas?
Answer Here:
The strategy is simple to describe but complex to implement (just like a Scrum Guide, huh). The first step was an organisational redesign. At “Otkritie,” a large corporation, I had strong support from my stakeholders in the Small and Medium-sized Enterprises department, which enabled me to take the necessary actions. The key to success in this step was garnering support from key decision-makers in the department. In other words, I had to effectively “sell” them on the new ideas.
The second step involved teaching teams how to operate within the new organisational design. This was arguably the most challenging part. Most people crave stability and are naturally resistant to change, so significant resistance at the team level was inevitable.
The third step was ongoing support for the teams in their daily work. This included navigating conflicts, answering questions, facilitating discussions, and ensuring that everyone was aligned and comfortable with the new processes.
As for the goals of reducing time to market and defect leakage, these are numerical metrics that are relatively straightforward to measure. With a properly configured task management system, these metrics can be tracked without much human intervention. While this may sound simple, configuring such software correctly can be a challenging task—but that’s another story.
9. What are some key lessons you’ve learned from managing software teams and guiding them through complex Agile transformations, especially in environments like Otkritie and Rostelecom?
Answer Here:
The first key lesson is that people’s behavior is primarily a result of the organization’s design. You can teach people whatever you want, but their actions and decisions will always be confined by the organization’s restrictions on data flows. You can facilitate communication between the people in the room, but how do you ensure that all the required stakeholders are present? For example, how do we involve Information Security personnel in our team’s challenges when they act strictly according to existing instructions?
Therefore, the second key lesson is that there are rarely “bad guys”; rather, there are rules that can cause good people to misbehave. Of course, there are heroes who occasionally break these rules with good intentions, but you cannot rely on heroism as a system. Each act of heroism often highlights flaws in information flows. Thus, the priority should be to work on the organization’s design first and then teach people how to operate effectively within the new framework.
The third lesson is that good organizational design is not a silver bullet. There is an intangible element between people — something that helps them navigate uncertainty and act when explicit rules are absent. I call this “Culture.” The trick is that you cannot establish “Culture” simply by declaring the right words on paper. As a change agent, you must demonstrate it through consistent example. This is incredibly challenging, as it requires daily dedication and courage. Of course, “Culture” often originates with the founders and top management, which is why I always emphasize the importance of the right people in leadership roles.
10. As a contributing software engineer at Techflow, what’s your current focus, and how do you approach architecture and infrastructure decisions for new projects?
Answer Here:
We are a relatively small team—a true 2-pizza Scrum team—so I’m involved in almost every aspect of engineering, just like the other team members. My primary expertise is in front-end development, so my focus is naturally on the front-end. We’re building a visually rich toolkit for business analysts, as well as project, portfolio, and program managers within enterprises. It’s crucial to deliver a smooth user experience along with a responsive user interface. To achieve this, we’ve adopted a ‘local-first’ approach, which has proven highly beneficial in providing a seamless experience.
Additionally, we deploy our solution to the client’s infrastructure, which often means navigating the challenges posed by information security departments. These teams are known for being meticulous and detail-oriented, so we’ve embraced the engineering principle of ‘Less is More’: stable and proven libraries, tiny bundles, minimal network connections to handle latency, concise code, and reduced technical debt. However, I don’t see this as just a ‘current’ approach — it’s a timeless foundation laid down by the forefathers of software engineering.
