Alex Antonuk:
– Features ship, metrics look good… but the product ends up fragmented, fragile, and weighed down by fixes and tech debt. And users feel it.
Why does this happen?
Do processes and KPIs shift the focus?
Or is the ticket factory – blind to the bigger picture – just a mindset that’s hard to avoid?
Probably, it’s a bit of everything.
The good news is, we’ve got someone who knows this problem from the inside. So, let’s not rush to conclusions.
Please welcome Maxim Leykin, Head of Engineering at Bamboo Agile, PhD, lecturer, and a practitioner with real engineering depth.
And I’ll add: a great conversation partner.
Maxim, great to have you on the podcast!
Maxim Leykin:
– Hi Alex, thanks for having me.
Alex Antonuk:
So today’s topic is the lack of a product engineering mindset among developers and the ways to address it.
No moralizing – just experience, cases, and countermeasures.
This is Agile Redemption. I’m Alex Antonuk. Here we go!
[Musical intro]
Alex Antonuk:
– Maxim, before we dive in, could you tell our listeners a bit about your background and what you focus on at Bamboo Agile? A short question.
Maxim Leykin:
– Sure! I started my IT career more than 20 years ago as a C++ programmer, then switched to Java and Android development. Since then, I have participated in more than 15 mobile projects of various sizes in different roles: from a programmer to a team lead and project manager. Since 2015, I have been working as an engineering and delivery manager with a primary focus on mobile and cross-platform projects for IoT, Automotive, and Fintech domains.
As a Head of Engineering in Bamboo Agile, I’m responsible for the company’s technical strategy and expertise growth, estimating and architecting new projects, consulting and assistance with complicated technical issues, prototyping, and management of pilot and internal projects.
Alex Antonuk:
– Thanks, Maxim. Let’s get to our main topic. As mentioned, we often hear about teams that don’t really think about value beyond the ticket. If you see this as a problem, where do you think the root cause typically lies? Is it missing access to full product context, a lack of breadth and critical thinking, or a reluctance to take ownership?
Maxim Leykin:
– Developer teams are not monolithic; they consist of people with different skills, seniority, mindsets, and levels of responsibility.
If we speak about junior or mid-level developers, probably it’s okay for them “to close tickets” as they are just not capable of optimizing something for the broader context, and attempting to do so with insufficient skills can be even harmful. Also, there are people who don’t feel comfortable taking too much responsibility, not because of insufficient skills, but because of their mindset, and it is also normal.
Senior and experienced developers who are ready to take more feature and product responsibility should be encouraged to do so by giving more product context, participation in planning and refinements, and user interviews.
It is important for management to persuade developers that their thoughts and opinions are very welcome and can be of great help.
Alex Antonuk:
– Okay, that’s solid theory. So, let’s get practical – ideally from your own experience. Can you recall a case where the team delivered exactly to plan, yet the product metrics barely moved? What went wrong, and what was done next?
Maxim Leykin:
– This is a very common situation.
There was a fintech application with web and mobile versions. One of the features of the web version was to display complicated charts with stock prices and currency exchange rates. At some point, the product management team decided to duplicate this functionality for the mobile client. Much effort has been spent by the dev team, and the feature has been delivered on time. But then it turned out to be one of the most inconvenient and rarely used features of the mobile client. On a smartphone’s small screen, the charts looked tiny, unattractive, and practically unusable. After it became clear, it was decided to rethink the UI concept for the mobile client and display data in a different way compared with the web version.
Alex Antonuk:
– Yeah, that’s doubly frustrating: when a manager sets a task, it gets done well, but for nothing. And no one notices, because everyone just keeps doing their job correctly. Based on this… What should engineers do before coding to make sure a feature is worth working on? And at which stages should this happen?
Maxim Leykin:
– At least one representative from the dev team – typically the development lead – should step in as early as possible. On a stage of discovery and requirements analysis, the developer’s role would be to flag feasibility and challenge assumptions.
On a stage of prototype and design reviews, to surface hidden costs or complexity early.
On a stage of sprint planning, to confirm technical readiness and that the success metrics are instrumentable.
Absence of “engineering voice” on any of these stages causes negative impact – like overbudgeting – or even complete project failure, if technical limitations of the target platform were ignored.
As an example of the latter situation, I can recall a case when the team tried to implement an iOS application with the service constantly running in the background, which is, in fact, prohibited by iOS.
Alex Antonuk:
– Okay, and from early checks to the actual process: which practices at the product–engineering interface help engineers make sure their work really addresses user pain points during development?
Maxim Leykin:
– In my opinion, it’s a very good practice to involve engineers in user research, discovery calls, and roadmap discussions – so they can directly hear actual user needs.
Another useful practice for developers is “to be in users’ shoes”. Let me give you one real example.
Some years ago, I was involved as a tech lead in the development and support of a rich-functional mobile navigation app with a large customer base.
Such applications are very much about user experience, as they are used while driving, and thus should be clear and reliable. I asked all engineers from the team – both developers and quality assurance engineers – who had cars to use our app every day when driving from home to work and for other regular driving. I did the same.
You can’t imagine how many useful improvements were introduced and how many small bugs or shortcomings were fixed thanks to this practice.
Alex Antonuk:
– Yeah, well, that’s clever. Okay, what other concrete tips can truly motivate developers to think about the long-term success of the part they’re working on? And how can we foster this critical thinking within a project?
Maxim Leykin:
– I would mention several tips.
It is very important to help developers see how their code impacts other parts of the system and business outcomes, regularly expose the team to real user feedback and pain points: bugs that became nightmares, technical debt that slowed the team, or clever design choices that saved time later.
Another thing is to encourage developers to think, to ask, and to doubt. Developers are often afraid to suggest an alternative solution or question a requirement because they fear being seen as uncooperative or slowing down the project. To create a safe, comfortable, and blameless space for discussions is a sole leadership responsibility – and that is the foundation of a product mindset within the team.
Another challenge is that the effectiveness of this mindset is hard to measure. One way to tackle this is through a goal-setting framework that aligns individual and team efforts with broader company objectives. Such frameworks are called OKRs – Objectives and Key Results.
When implemented correctly, OKRs can effectively steer developers toward creating user value. A typical OKR consists of an Objective, which is an ambitious, qualitative goal, and several Key Results, which are quantifiable metrics that measure progress toward that objective.
Just an example. A team’s objective might be to enhance the user onboarding experience. The key results could be “increase new user activation rate from 25% to 40%,” “decrease the average time to first value from 5 minutes to 2 minutes,” and “reduce support tickets related to onboarding by 20%.” These metrics directly reflect user experience and satisfaction, guiding developers to focus on the most impactful work.
Alex Antonuk:
– So in that case, who should be responsible for setting the team’s OKRs, and how do you evaluate individual developers against them when several people are involved in delivering broad objectives?
Maxim Leykin:
– Depending on the team structure, it can be a Delivery Manager or an Engineering Manager, the person who combines technical expertise and responsibility for delivery. Also, product people can help to define the high-level objectives that align with business goals.
Evaluating developers against OKRs is a tricky thing. OKRs are mostly designed to measure team success, not individual output, so they should not be directly mapped to individual performance reviews. Instead, we can measure individual contribution to the overall team key result, which sometimes can be great even if the overall OKR is missed, and complement OKRs with behavioral metrics, like initiatives, communication, mentorship, and problem-solving skills.
Alex Antonuk:
– I see. And could you give an example of a concrete project where you applied product engineering practices at the team level, and explain how it impacted delivery? What results did it bring?
Maxim Leykin:
– It was several years ago when we had an IoT project. The mobile application should control SmartHome devices like motion sensors, smart lights, and so on. The initial ask from the client was to add several features to the application and improve performance, as it was insufficient and frustrating for users.
After careful investigation and much testing, it was clear that the root cause of poor performance was that the app was a hybrid and developed using the PhoneGap, JavaScript-based framework.
The most consistent solution would be to rewrite the app from scratch as pure native, but the client had neither the budget nor the time for that. We had a brainstorming session with the whole development team and product managers, and during this session, one of our senior engineers proposed an elegant solution that combined a hybrid app with pure-native libraries.
The idea was innovative and bright, so we persuaded the client to give it a try and implemented it in less than a month, while rewriting the app would require 6 or 7 months. App performance improved significantly, the author and main developer of the idea got much respect from the client and from internal management, a substantial salary bonus, and a good topic for a conference talk.
[Musical intro]
Alex Antonuk:
– Maxim, we’re getting to the end, so I’d like to run a short lightning round – just three quick questions, and I’ll ask you to give brief, practical answers. Does that work for you?
Maxim Leykin:
– Yeah, of course!
Alex Antonuk:
– Okay, let’s do it. First one. When fast delivery is critical, developers often find it hard to think deeply and make long-term product decisions. How can we avoid risks in situations where projects are frequently done under deadline pressure?
Maxim Leykin:
– Firstly, the main and most important architectural and product decisions are usually taken on an initial stage of the project, where the pressure is not so hard.
Secondly, the way of thinking and communication makes a difference. Each engineer should not be afraid to think deeply and to share the results of their thinking with the team, including management. Even if something reasonable is not taken to the project immediately because of deadline pressure, it can be recorded and kept for the future.
In general, the proper way of thinking and the proper way of communication are important elements of engineering maturity.
Alex Antonuk:
– Okay. Martin Fowler talks about a shared roadmap, while Fibery suggests splitting product and engineering roadmaps. Which approach engages engineers best, in your opinion?
Maxim Leykin:
– I’m against splitting roadmaps. I would recommend leaving a single shared roadmap, but creating special user stories that accumulate tasks like tech debt, code health, innovative frameworks, and so on. We can also try to plan sprints using the “3+1” methodology, where three consecutive sprints are the product outcome and the fourth sprint is the engineering outcome.
Alex Antonuk:
– Some say that before QA became a separate role, developers built quality in themselves, or paid later by fixing bugs. Now, it may seem to some that responsibility has weakened, and they argue it should return to developers. What’s your take on this?
Maxim Leykin:
– Frankly, I’m sceptical about this, for three reasons.
First, developers know the code too well and subconsciously avoid edge cases, while QA looks exactly for those failures.
Second, the developer’s mindset is to build, while the tester’s mindset is to break.
And third, there are specific testing practices and tools that no developer has studied.
Alex Antonuk:
– Maxim, we had no doubt it would be insightful to have you on the show, and I’m sure our listeners will agree. Thanks a lot for sharing your expertise and practical insights today! It was a great conversation – thanks for taking the time to talk with us.
Maxim Leykin:
– Thanks for the good questions, Alex. Good luck!
