BONUS The End of Product Management? Three Experts Reveal the Unstoppable Rise of Product Engineers | Anton Zaides, Rafa Paez, and Max Piechota

Summary

Scrum Master Toolbox Podcast: Agile Storytelling from the Trenches

Episode Summary: BONUS | The End of Product Management? Three Experts Reveal the Unstoppable Rise of Product Engineers | Anton Zaides, Rafa Paez, and Max Piechota

In this compelling bonus episode of the Scrum Master Toolbox Podcast, host Vasco Duarte delves into the transformative shift within the software development landscape: the emergence of the Product Engineer. Joining Vasco are three industry experts—Anton Zaides, Rafa Paez, and Max Piehota—who collectively explore how this new role is redefining the boundaries of traditional software engineering and product management.

---

1. Introduction to the Product Engineer Concept

[01:03] Vasco Duarte opens the episode by introducing the central theme: the evolution of the software engineer into what he terms a "Product Engineer." This role transcends pure technical proficiency, integrating aspects of product management, business strategy, and customer engagement to deliver holistic value.

Max Piehota shares his background, emphasizing his transition from corporate environments like Dolby Laboratories to startup ecosystems. His role in building fintech platforms and his upcoming ventures illustrate the practical application of product engineering principles.

[03:24] Max Piehota:
"I'm writing the Business Value Driven Developer where I'm focusing on the topic that we are discussing today, which is the product engineer."

---

2. The Rise of the 100x Product Engineer

The conversation pivots to Rafa Paez's influential article, "The Rise of the 100x Product Engineer," which challenges the conventional notion of the "10x engineer."

[07:09] Rafa Paez elaborates on how modern software engineers are expanding their skill sets beyond coding to encompass product thinking and business acumen. He posits that the integration of AI tools and a holistic approach can amplify an engineer's impact exponentially.

Notable Quote: [07:09] Rafa Paez:
"The software engineer is evolving into a product engineer and nowadays it can be like a 100x engineer because of all these tools and all this kind of holistic approach and knowledge that engineers are applying."

---

3. Challenging Traditional Product Management

Anton Zides brings a critical perspective on existing product management practices. He argues that product managers often lack direct customer engagement, relying instead on top-down directives that may not align with actual user needs.

[11:03] Anton Zides:
"Product managers are making the decisions... they don't talk to customers. They just hear from stakeholders and create a roadmap."

Anton emphasizes that without engineers questioning and understanding the "why" behind features, the resulting products may fail to deliver true value, regardless of the technical prowess behind them.

---

4. Aligning Development with Business Outcomes

[13:30] Max Piehota recounts his journey from focusing solely on technical metrics like lines of code to prioritizing business outcomes. He highlights the limitations of traditional productivity metrics and underscores the importance of measuring customer value and business impact.

Notable Quote: [17:11] Max Piehota:
"Developers will have to actually change their mindset and start to think less about the technology, but more about the outcome and business value."

---

5. Practical Steps to Embrace Product Engineering

The panel discusses actionable strategies to foster the growth of product engineers within organizations:

• Understanding User Interaction:
  [23:08] Anton Zides recommends engineers engage directly with product usage metrics and user behavior recordings to gain insights into how their features are utilized.

• Connecting to Business Metrics:
  Linking engineering tasks to specific business outcomes, such as gross margins or customer acquisition rates, helps engineers see the direct impact of their work.

• Incentivizing Based on Impact:
  [32:04] Anton Zides suggests that connecting feature development to tangible business savings or revenue increases can motivate engineers to prioritize impactful work.

[34:15] Max Piehota:
"Why cannot software developer be incentivized as in sales, as a salesperson... if software developer can create a change to the product and drive this change from metrics, they should be rewarded for it."

---

6. Overcoming Organizational Challenges

Vasco Duarte shares a case study illustrating the pitfalls of neglecting business understanding in software development. The discussion underscores the necessity for software teams to be deeply integrated with business processes and customer feedback loops.

[30:28] Vasco Duarte:
"We need to start talking about software as a business model amplification tool. Not a technology only."

---

7. Future Outlook and Community Engagement

As the episode wraps up, the experts emphasize the inevitability of this shift towards product engineering. They advocate for continued education, mindset changes, and organizational support to cultivate this new breed of engineers.

Community Resources:

• Max Piehota: Available on LinkedIn and Substack for his "Business Value Driven Development" newsletter.
• Anton Zides: Accessible via manager.dev and email at [e-mail].
• Rafa Paez: Connect on LinkedIn and subscribe to his newsletter.

---

Conclusion and Takeaways

This episode of the Scrum Master Toolbox Podcast presents a persuasive argument for the emergence of the Product Engineer—a role that marries technical expertise with business strategy and customer-centric thinking. By leveraging AI tools, understanding business metrics, and fostering direct customer engagement, engineers can significantly amplify their impact, potentially achieving up to 100x the traditional productivity metrics.

Key Takeaways:

• Holistic Skill Development: Engineers should cultivate skills beyond coding, including product management and business strategy.
• Direct Business Impact: Aligning engineering tasks with business outcomes ensures that technical efforts translate into tangible value.
• Organizational Support: Leadership must incentivize and support engineers in their transition to product-focused roles.
• Continuous Learning: Embracing frameworks like Lean Startup and utilizing AI tools can accelerate product development and iteration.

This insightful discussion not only redefines the future of software engineering but also provides a roadmap for professionals eager to enhance their roles within product-driven organizations.

---

Stay tuned for more inspiring conversations and actionable insights by subscribing to the Scrum Master Toolbox Podcast and attending the upcoming Global Agile Summit in Tallinn, Estonia, this May!

Transcript

[Vasco]

Have you ever wondered what it really takes to make Agile work well? At the Global Agile Summit, we're bringing you real life first person stories of Agile succeeding out there in the real world that will inspire you to take action. Whether you're a leader, a product innovator, a developer, you'll hear practical insights from those who've done it. They'll be telling their own stories from the stage. I'll tell you more about this at the end of this episode. So stay back and listen to the full detailed description of what we have in store for you at the Global Agile Summit. But if you can't wait, you can go right now to globalagilesummit.com and check out our full schedule for now onto the episode. But I'll see you at the end of this episode with more details on the Global Agile Summit. Talk to you soon.

Hey everybody. Welcome to this very special bonus episode. This whole week is a very special week, but this one is even more special. Today we're going to tackle the concept of the product engineer. Now we all know what a software engineer is, but the goal of this conversation is, is to go beyond the software side of software product development and talk about also customer, product, business model and more. The product engineer is a concept that might be described maybe as an M skilled person. So like different areas where we go deep and then a broad area that we all cover. Not just a tech or a full stack, but also product. And to share their own experiences and thoughts on this product engineer concept, we have with us Anton Zides, Rafa Paez and Max Pie Cotta. Max, did I pronounce your name correctly there?

[Max Piehota]

I think you wouldn't be able to pronounce it okay the correct way. So it's fine.

[Vasco]

How do we pronounce your name correctly?

[Max Piehota]

The name is. Okay, it's just Max. The Max. I mean the first name is just Max and the Piehota. All right, so yeah, this time it was you managed to do it correctly.

[Vasco]

So let's do a quick round of interest and starting with you, Max, give us your 30 second intro.

[Max Piehota]

Okay, so first of all, thanks Vasco for inviting me. It's a great pleasure to be part of this, a great company with Anton and Rafa and you of course. So yeah, I'm Max. Behold. I'm from Poland. I've been a software developer for 10 years now around and I used to work for corporates most of for the first part of my career for Dolby Laboratories and then I switched gears to work with startups. I Built a fintech platform for us based startup as a first engineer and then I built a team around it. And starting next month I'm moving to another startup in insurance industry looking for new challenges.

[Vasco]

And you also write the Substack newsletter, right? What's the name of the Substack newsletter?

[Max Piehota]

Yeah, so recently I started to try to share my expertise and experience. I am speaking as lecturer on different meetups and so on. And the substack is also part of that. I'm writing the Business Value Driven Developer where I'm focusing on the topic that we are discussing today, which is the product engineer.

[Vasco]

Absolutely. And check out the Substack newsletter, the link in the show notes, make sure you easily find it. And next on our roundtable is Rafa Paez. Rafa, tell us a little bit about yourself.

[Rafa Paez]

Hi Vasco. Yeah, thank you so much for inviting me in this episode. It's a pleasure for me to be with you. Anton and Max. Yeah, I'm Rafa. I'm based in Mallorca, Spain. I've been working in the software industry for about 20 years. First as the software engineer and during the last seven, eight years as a senior engineering manager. So yeah, as I mentioned, based here, my job, working from home. So I work fully remotely, fully async. And yeah, in my free time I really love doing calisthenics and writing a newsletter and the newsletter that some of you might know, which is the engineering leader newsletter where I basically share all my thoughts, learning from my experiences, my stories and my readings basically. So yeah.

[Vasco]

And Rafi also wrote the article that got us to get together this roundtable to talk about it. He wrote the rise of 100x product engineer. But we'll talk about that in a second. Before that, let's hear from Anton, our last but not least guest in this roundtable. Anton, tell us a little bit about yourself.

[Anton Zides]

Hey, thanks. So I'm based in Tel Aviv of Israel. I've been in tech for the last 15 years or so, doing development, then management, back to development. In my last role I was director of engineering and currently I took a six month break to actually work on my own thing. Codemanager.dev I just released it a couple of weeks ago and relax a bit. And I also writing a newsletter specifically for engineering managers. That's my [e-mail] vo the domain. By the time the episode is published now it's called Leading Developers. Yeah, happy to be here.

[Vasco]

Absolutely. It's a pleasure to have you all here. And as I introduced a second ago what got us to start organizing this episode and this roundtable was an article that Rafa published a few weeks ago called the rise of the 100x product engineer. Now, many of you out there have heard of, I'm sure, of the 10x developer. It's an old myth. It still persists. A lot of people still believe that you can have a 10x single developer. My usual comment is that in order for you to have a 10x engineer, you probably need a 0.1 team. But that's a whole nother conversation. But we do have Rafa's point and I want to give the kind of the intro to him to introduce to us the main points that he makes in this rise of the 100x product engineer. Because I think there's a lot of insights and learnings about software development and product development from that article that might be very useful for our listeners. So Rafa, give us a quick overview. What were the main points you made in the rise of the 100x product engineer?

[Rafa Paez]

Yeah, exactly. So I wrote that article because I'm realizing the role of a software engineer is kind of evolving recently. During the recent years, software engineers are not just longer focusing on the code part or on the technical aspects. They are evolving into a role which is more holistic, like thinking about the product, thinking about the business, and how they can actually focus in less on actually building the code itself. Because nowadays we have AI tools to do that for us. But understanding what the business or the user really needs and building all of that in a way that is efficient with stream ownership, taking accountability approach to making sure that they understand what to build and why they are building, thinking about all of that and thinking about all the LLMs tools that we have nowadays to actually deliver it faster. I came up with that idea. Okay, so the software engineer is evolving into a product engineer and nowadays it can be like a 100x engineer because of all these tools and all this kind of holistic approach and knowledge that engineers are applying. So the main points I don't mind asking is a product engineer is one engineer that is not only thinking about, as I mentioned, not only just involving the code itself in the technical implementation in the software architecture, but can actually think like a product manager, can actually think like a business owner. Is there something start asking why, why we need to build that. Which metric is going to move, is going to move the needle. It's going to actually have an impact in their final user or not can think critically and question some of these assumptions or the requirements that in the past was given by the product manager or the business analyst together, talking with different people, they might have conversations with customers, with marketing, with sales, thinking about the why and collecting all these requirements and talking to different people. And they might be able to actually build what's the right thing to build, what the business really need to build needs. And yeah, leveraging, as I mentioned, on different tools, leveraging on their knowledge, expertise, they can actually produce like extreme much kind of faster and better. That's why the title, right. It's not about 100% per se. It's about like, okay, in the past we used to talk about the software engineer, which is 10x engineer. Nowadays I believe that could be amplified much more, up to 100 even, you know, thousand times. Because there are people that are really, really good technically. They are, you know, super strong technically. And nowadays, because of the AI tools and because they, you know, the work they are doing behind this thing to, to understand everything, they can actually deliver something that is, you know, 100% x even more kind of value to the final customer. So that's basically the idea about it.

[Vasco]

Yeah, I really like the idea. In fact, when I, when I read the I must get Rafa on the show, and then I was thinking about, wait a minute, but I've heard this before and I remembered Anton's article for which there's an actual episode we recorded with Anton about this. So I'll put the link to that episode in the show notes. And Anton's article was Product management is broken. A Change is coming. But in that article, he actually talks about similar ideas to what Rafa talked about. So Anton, introduce that concept to us, what you wrote in that article and what was your key message.

[Anton Zides]

Yeah. So it connects very well to what Rafa says. And I think there are two things coming together. First, right. That in most companies, product managers are making the decisions, not the engineers. Right. You have this common PM tells me what to do, I would say how to do. And that one problem outlined is the product manager. In many cases, they don't really know what decision to make. They're just following a roadmap that some executive told them to do. They don't talk to customers. I call it zoom based product manager. They don't fly to visi. They just hear from stakeholder and create a roadmap. And the other part, that's rough assured the engineers, they don't challenge this roadmap. Right. Because they're focused on the code, they're focused on working with themselves. And they don't really care what they work on. And if you combine them together, this is a recipe for disaster, Right? Because nobody creates value for the customers. And I wanted to emphasize what Rafa says, that by the 10x or 100x value, like when engineers hear it, they feel like a developer creating 10 times more features, right? It's not about that. You cannot code 100 times faster. That's not the point. It's creating the impact for the customer. Like a very strong developer can create tons of code that nobody will use. But a developer that is product oriented, right. The product Engineer might create 50% of these features that will have 10 times impact because he will challenge or she will challenge. The PM will ask the questions, will actually care about that involvement. So I think those are the points of the article.

[Vasco]

Yeah. And I really like the approach that you took because you started with the idea that hey, there's this gap, right? Like product managers should be talking to customers, but they are not. And you even talked about your own example, how you went as an engineering manager and started creating that connection to customers. Because it is necessary for us to eventually become what Rafa talks about, product engineers, right? Like we need to have that, that end to end connection. And I know that Max has also been thinking and posting about this idea of the product engineer. We even had a conversation on substack about this. So Max, give us your thoughts. I mean, you heard Rafa's points, you heard Anton's points, and of course you have your own perspective. What are your thoughts on this concept idea of the product engineer as the basic skill set for future engineers in product organizations?

[Max Piehota]

You know, I think it's worth to point to the fact that I didn't know Anton and Rafa before. We didn't speak any. Like never. We, we never spoke before. And we all of us like organically, we got to the same idea and that's how we start to like discover each other, right? So there is some something to that. And my, my journey was a little bit from another angle. I was like discussing a lot with my CEO of my startup about the performance of the software engineers. And it was like kind of vanity discussion because I was like, I think we are moving fast enough. And his gut feeling was, no, it needs to be faster. And the fact was that we might have been losing some market because of the software development team didn't move fast enough or we didn't have enough resources to move faster. And I was like, okay, now I will start. It was like few months ago and I started to Research the area of measuring software development, productivity and so on. So of course the old approach is measuring man hours. Then it was replaced with scrum story points, right? And then I discovered the DORA metrics and all that movement and all of those metrics were, are useful. But I felt all the time that it is missing something that, okay, I can move fast, I can produce a lot of lines of code, I can produce a lot of PRs, or I can have great lead time to change the DORA metric, but it doesn't mean that I deliver the feature fast because I can commit over and over and the feature is not delivered. So I started to think about, and then I started to to see some articles about this product engineering and so on. And another fact was that whole paradigm shift and the whole fact of AI emerging, like what will developers do if there is no more need to code? Right? And it all synthesized. And I started to think that we need to measure the product outcome, I mean the value of the customer value that the product delivers and so on, and incentivize the developers based on that to motivate them to think about it. And that's how I got. And it forced me to think that, yeah, but developers will have to actually change their mindset and start to think less about the technology, but more about. About this, about the outcome and so on and business value. And that's how I got to the same, I mean the same from different angle, but into the same conclusion as guys did, that the shift in the developer mindset is emerging, is required and I think it's inevitable.

[Vasco]

So I think it was great that Max mentioned the story of how we got together on this. Right? Because I've been thinking about this for a long time and I talked with Anton on the podcast already about this. Then rafa published the 100x product engineer article. Then I found Max talking about the same things on Substack and then we started talking. So it's clearly a trend that is emerging. And if nothing else, we're thinking about this as a community. And I'm sure we are not the only four people thinking about this. A lot of people are thinking about this already out there. So what I'm thinking is, okay, but what have we learned, you know, the four of us, @ least for now, what have we learned that can help get people first, the ones that are already willing to do it, and then later on everybody else? Right, but what have we learned that can help people start moving in that direction of less tech focus, less lines of code focus, as Max Used a very dysfunctional productivity metric, by the way. We could talk about lots of anecdotes of why that is, but how can we get these people moving this wider community feeling that yes, this is possible and then let's start moving with these small steps. Max, you wanted to go first?

[Max Piehota]

Yeah, I mean I can share my story. I used to work, I mean I am working in startups, but beside that I used to work with as a consultant for people that wanted to build their own software products. And the thing that helped me a lot to shift my because I used to be a developer, like we all did, right. So I had the same mindset. I was focusing on the newest frameworks, on the technology and I loved coding and so on. But then working with those people and understanding that they don't really even know how to go to market with their product, like put the responsibility on me to help them. And that's how I started to study the lean startup and that changed my perspective as a software developer. I'm still software developer, but I have totally different mind and I think that's why I want to share with that because that was a good starting point for me to write about lean startup. Understanding how startups are built and how the growth engines work, how the customer factory works, how the customers are acquisited activated and stuff. All that stuff that builds the business model actually. So understanding those factors, let me understand that, okay, if I can build the best tool, the best software and the system in the world, but if the landing page doesn't convert, that might be space for me to actually step in as a developer. And now I don't really need to build another high performing code somewhere there in my system, but rather it would provide more impact if I just go there, measure what is the landing page conversion and how can I improve that and try to improve that and improve the factor for the business model to help the business grow.

[Vasco]

Quite a few keywords there that you mentioned that I think need to be explored further. But I think Rafa wanted to come in.

[Rafa Paez]

So. Yeah, you know what Max said, it's very good point. It's about, so for me as a software engineer, as a product software engineer, it's about understanding the why, why we need to do something, why we need to do that. So instead of focusing on the how, understanding the why, so talk to the customer, talk to the users, understand the business. Because if you understand the business, it's going to be really hard to come up with great solutions, right? So you need to really understand the business. And then you need to talk to the customers to understand also what they want. Right. It doesn't mean that you have to do what the customers want, because that's not usually the right solution. But you need to listen to them. Right? And then it's about leveraging, leveraging on AI tools, leveraging on data knowledge, leveraging your understanding holistically of the situation and making sure you can ship faster and iterate and learn from it. Right. So in the past, software engineers focus a lot of having a clean, perfect code solution, a really nice architecture. So they might spend months building something that maybe the user at the end is not what they really need. So instead of that, you can actually deliver great code, but in a different way. And then they mentioned like lean startup iteratively and learn from it and trying to get early feedback on. Right, Trying to get early feedback and see this is the right kind of you're going to in the right direction or not. So combining all of this, you can actually deliver 10, 100 or thousand x faster.

[Vasco]

Exactly. And I think that that's the, the key in your article, right? Because the 100x that you talk about in the article is not about writing code faster, it's about deciding what not to do. Because in the what not exactly, there's even a 10,000x in some cases, right? Like Mark's point about the landing page not converting. How about you, Anton? How would you tell people, hey, these are the steps we can follow in order to start understanding what this product engineer means and embracing what it means.

[Anton Zides]

I think that one of the biggest challenges is you cannot really transform the engineers, right? You need to help them want to do that. It's not something you can force if engineers are not used to it. Our challenge in the leadership roles is to move them there. And in my experience, my framework is in three steps. First one is really just you can go see metrics and recording of how user interact with the product. So many engineers don't do that. They like finish a feature, release it and then go to the next one and the product manager, the one going to Mixpanel and Posttogen. When engineers see usage of the system, for most engineers it gets exciting, started, it gets the questions asked and then they see like, okay, I scheduled for example, a simple way 30 minutes weekly with your team. We can just watch recordings. Every company has a recession recording. Just see how people behave, right? See how the this goes. This is the first one, just understanding your product better. And the second step is to understand the business better as max Talk about the landing page, right? You have this ARR framework. I'm sure you talked about it a lot. So if you're currently stuck in activation, there is no need to work on retention. Right. So you need to connect your teamwork to the specific business outcome. In my example, my team was an internal one, so we didn't affect the actual customers, but we really affected the gross margins of the company. We had 50% gross margins and we need to grow to 60. For most engineers, when I say gross margin, they have no idea what I'm talking about. They have no idea how it connects to the business. And we are a startup. It's critical for us to extend the Runway and stuff like that and raising a higher variation. So I will not get too deep into it. But once we connected how a specific feature increases the ghost margin by reducing cost and stuff like that, suddenly people start to feel more excited because they feel the impact. So for me, these are the two, I would say quick ones. The third one is connecting to the domain and industry. I think it's much harder to do, but so I'll stick with the first two for now.

[Vasco]

Yeah. And I think they are brilliant. I just want to come in here and share a story. So I was working with a startup, they're a small consulting, so they develop software for others. So third party software development consulting company. And they came to me with this problem. Hey, we have a few examples of projects we did with our clients. We did what they asked us to do, but that didn't work out. We ended up releasing products that nobody used. Then we had to scrap those and start again. And the client wasn't happy, we weren't happy, nobody was happy. Of course the customers weren't using the product. And the solution they had thought about when I had the first session with them, the solution they had thought about is we need to be better at writing PRDs. Or their PRDs stand for product requirements document. But sometimes just to make fun of them, I call them the perfect requirements document. Right. So they said, hey, we just need better PRDs. And then I started going through the case study. They had a real case study. I started going through the case study with them and then they realized that actually the problem had not been that the customer was telling them the wrong things to do. The problem had been that they had spent zero time trying to understand the business of the customer. And as Max has done this, so he knows this for sure as a software developer for third parties, whether it's an internal third party like a Product owner or whatever, or an external third party, like a customer. As a software developer for third parties, if we don't understand what they are trying to enable, we can't provide a solution. Because the way I usually phrase it is that we are the experts in the solution domain, but we have no clue on the problem domain. Right? This is something we either need to learn or we need somebody to come and bring it to us. In product development, that's typically the product owner, product manager. But then when you're doing third party software development, we have to do that with the client, right? Like a term that perhaps is not very sexy. Like Anton said, the gross margin. If you don't understand the impact of a gross margin in your business, there's very little you can do to affect that business, whether as an engineer or even a product manager. Right? So like, we need to go deep enough to understand. I use a tool called the Business Value Equation. I do workshops with the teams where we try to create a model of how the business works so that we can then ask, how does the product enable or amplify that model? Right. So that's kind of the question for me is let's start talking about software as a business model amplification tool. Not a technology only. It is a technology. It will always be a technology, but it's not only a technology, right? It's something that amplifies a business model, makes that business model, as Rafa puts it in Here, is article 100x better and sometimes even a thousandx better. Max, you wanted to come in?

[Max Piehota]

Yeah, I can refer to that, what you just said as external consultant. I was building software for my customers and the issue was that I actually, it was, it became my responsibility to actually drive their business because they didn't know they were from outside technology world, so they didn't know how to build and deliver good products. So me as a software developer, I was responsible to actually teach them how to talk to customers and so on and so on. And that's how my journey with Lean Startup, like I mentioned before, started and so on. And that's the issue. Like the stakeholders, they very often don't know themselves how the business works. And that's one thing, that's one issue that we need to overcome with, like there is tons of education, like, both for software developers. But becoming a product engineer is not only a software developer challenge, it is also the management challenge, because, and here I want to refer to Anton, what he said, that it's leadership role to facilitate this change. Because software developers care about how to build stuff because that's how they are incentivized within the organization. They are not encouraged to take part in the business processes. They are not measured by the business outcome and so on. That's the role of the management tool, to create metrics and incentivize developer teams based on the business outcome rather than on lines of code or otherwise.

[Vasco]

And to be able to translate that. Right.

[Max Piehota]

So first, that connects to the first statement I made, which is very often they don't, unfortunately, they don't know themselves how to do that. So here is.

[Vasco]

This is why we need the product engineer. Okay, So I, Rafa and Anton want to come in. First Rafa, then Anton.

[Rafa Paez]

Yeah, so that point remind me of an article I wrote recently about. I think it was called Stop Solving the the wrong problem. Right. Because most of the times we build or we just focus on the solution without understanding deeply the problem. Right. And that was kind of, you know, wrote that article because this is so common and this is where, you know, the majority of the time is waste on trying to jump into the solution without really understanding what we need to build. Right. This is basically what we call the XY problem. So the XY problem is when the user say, okay, I want to grab the last three letters of the file name, and then you say, okay, you can do that. And then they realize this is not what they needed because what they need is to get the extensions. Right. So the engineers should be asking, okay, what you need to get the last three letters? Oh, because I need that. And why do you need. And you understand that actually what they want to solve is to get the intention of a file, the extension of a file, which might have four letters, two letters, three letters, or it could be very tricky. So, yeah, next, why problem is super important to have in mind when trying to solve something. Keep asking why? Why? You can ask up to the five whys, right? This is a nice framework, the five whys. To understand the root cause, to understand what they really want to do. So yeah, that was. Something came to my mind when you described that understanding deeply the problem and not just jumping to the solution.

[Anton Zides]

Anton, I really like what Max said about incentivizing. I think it would be like. It's not like in sales, we cannot pay developers based on the business outcomes, right. Otherwise they would just quit us. But the direction is to actually create some incentive. I think when people see dollars and money, a lot of people actually connect some dots. For example, if you can. I had a developer who didn't really care about technical debt at all. But once there was a feature that saved cloud costs and he saw how much it saves, it was like all in developing it because of the connection to the DORA signs. And if you connect features to impact, it can be metrics or whatever, but people like that connection. So ideally it can be incentives, right? If you can get promoted, if you push some outcomes, stuff like that. But even if you can't, and it's hard to do, I would start with just connecting the dots and showing those dollar signs somewhere.

[Vasco]

Go ahead, Max.

[Max Piehota]

And that's where I would actually. I mean, I thought a lot about that and that's where I am coming from actually. Because my dream was like, why cannot software developer be incentivized as in sales, as a salesperson. It's like if salesperson brings 1 million revenue, they get 100k and 10% of. How we call it. I forgot the word. But the revenue, 10% of revenue, which is their bonus, let's say anyway, and that's my dream that if software developer can create a change to the, to the product and will show that I drove this change from. I figured it out, I saw the metrics, I made the change, it increased the revenue, like let's say conversion rate, which turns into revenue by 10% which made us $1 million this year. Then I want my 10% to like, why cannot.

[Vasco]

I mean, that's exactly what I told these guys that I was working with is like, look, if you can go to your customer and offer a solution that makes them a million, you can charge 100k for that because easily they will pay you 10% if you bring new business or in this case more revenues or more user activation or more conversions, whatever that is. And I think that also what you talked about, Max, the lean startup might be a great framework for us to look into. Exactly. Because of that. Because of that focus of connecting technology with business as quickly and as often as possible. Now guys, unfortunately we're getting close to the end. This would be a much bigger topic. So of course I recommend everybody go check out Anton's, Rafa's and Max's newsletters on substack. The link will be in the show notes. But before we go, where can people find the work that you're doing and connect with you? Max, let's start with you. Where can people go to get in touch with you?

[Max Piehota]

So I'm available on LinkedIn, of course, as, as everyone. So find me Max Behota. Just connect and I will be happy to talk to Everyone and of course like we mentioned before, Substack, I found this space recently and I think it's best everyone who finds substack is the same have the same mind about it. That is the best space to discuss. So I run the Business Value Driven Development Developer newsletter. So yeah, you can subscribe there. You can reach out to me in DMs so we can discuss this idea further.

[Vasco]

We'll put the link to all of those in the show notes for sure. Anton, how about you?

[Anton Zides]

So right now everything will be at manager.dev. very easy domain. Check it out. You can reach [e-mail] in the email. Also LinkedIn. But manager.dev is the place to go.

[Rafa Paez]

Absolutely.

[Vasco]

And I'll put the links and even the email on the show notes so that people can find it easily.

[Rafa Paez]

And Rafa, yeah as they mentioned I also pretty active in LinkedIn as Rafa Pyth, you can find me LinkedIn also on Superstack. And yeah, you know my kind of email address or maybe you know, website is rafapy.com so newsletter.raffapi.com this is where my newsletter is. So yeah, you know, creating great community nowadays in LinkedIn. And Superstack is my favorite social media platforms right now.

[Vasco]

Absolutely. And also on the podcast right now like you all did. Thank you very much everybody for being here and for being so generous with your time and your knowledge.

[Rafa Paez]

Thank you so much. It's been a pleasure to discuss with you this important topic for the software industry.

[Anton Zides]

Thank you Vas.

[Max Piehota]

Thanks guys.

[Vasco]

Hey friend. Thank you for staying here is all you need to know about the Global Agile Summit. If you've ever suffered or know people who are suffering from agile fatigue, this event is for you. Agile fatigue is that feeling that settles in when we can't really see a light at the end of the tunnel. We get discouraged. Especially when conversations revolve around the same old frameworks, the same old buzzwords and theories. We don't feel that energy anymore. Well, the Global Agile Summit is a different kind of event. We're bringing you real life first person stories of Agile succeeding out there in the real world that will inspire you to take action and transform the way you work. The Global Agile Summit will happen In Tallinn, Estonia, May 18th. That's the workshop day. Then 19th and 20th, the conference day. And Tallin Estonia is one of the most innovative tech hubs in Europe. The Global Agile Summit is hosted together with Latitude 59, which is kind of a citywide celebration of software, software, startups, and groundbreaking ideas and we'll have a share ticket for you to attend those events as well. So who will be speaking? Well, we've got an incredible lineup of thought leaders in software and agile. For example, Clinton Keith, the person who wrote literally wrote the book on game development with Scrum and is busy bringing Agile to the world of game development. You must check his session. The very famous and well known Jurgen Apello, author of Management 3.0, will be talking and exploring about AI's impact on leadership. We also have Goiko Adsic, who's taking an unconventional look at product growth with his Lizard Optimization keynote. Other speakers include, for example Sixven Dietz, who's challenging everything we know about software development by ditching, literally ditching contracts and estimates. Can you imagine his teams deliver software before their competitors are even done with a contract negotiation?

How agile is that?

But there's more. We'll cover engineering practices in our developer track with talks on, for example AI assisted test driven development, developing products in minutes with a different approach to how we develop, configure, deploy platforms, and much more. We also have a product track where we cover cutting edge ideas around product discovery, delighting customers with product delight frameworks. We'll have a talk about that. And we also have an Agile Business track where we will talk about, for example Open strategy, a very agile approach to managing organizations and delivering software faster to clients faster than you can even write a contract. Literally. I mean, I already told you about Svendeet's story is amazing. It definitely is a must see. I'm sure you'll be inspired and get a lot of ideas for your own software projects and software delivery. Now whether you're a business leader, a product innovator or a developer, you'll definitely find value in our three focused tracks. That's Agile Business for those working with businesses and organizations, Agile Product for product managers, product owners and innovators and Agile Developer for for the builders making Agile work in practice. The coders, the testers, the designers, the producers, the Scrum masters, you name it. If you join, you will meet over 200 agile professionals from all over the world. People who just like you, want to grow, want to share and want to learn by challenging the ideas that don't work anymore. At the Global Agile Summit, you'll get new connections, fresh ideas and the energy to take your own Agile to the next level. And who knows, maybe even find your next career opportunity. So don't miss out. Check out the full program and grab your ticket [e-mail]. i'm really looking forward to seeing you all in Tallinn, Estonia, in May. I'll see you there.