‘Leading Dev Teams towards Product-Market Fit’ with Serdar Mustafa, Tech Startup Advisor and Founder, Phoenix Software Consulting

Kovid Batra: Hi everyone! This is Kovid, your host at Beyond the Code by Typo. Today with us, we have an interesting, inspiring guest. He has moved from sales to medicine, and eventually, to product and engineering realms. He has had 8+ years of engineering and leadership experience, currently serving as a fractional advisor to multiple startups. He has been ex-Twilio, Wise, contributing to their product and development. And that’s not all. He’s an author of an interesting growing newsletter on Substack, ‘From Code to Boardroom’. Welcome to the show, Serdar. Great to have you here today.

Serdar Mustafa: Hi Kovid! It’s an absolute pleasure. It’s nice to be on here, on your show today, and speaking about topics which are really close to my heart. So, looking forward to the discussion.

Kovid Batra: Perfect. Perfect. So, we start off with a quick fireside chat where we would love to know more about you personally, outside the scope of work. So, are you ready for it?

Serdar Mustafa: I will do my best and, and try to be agile, as they say.

Kovid Batra: Great! So, let’s get started. First thing – I am fond of people who write. So, I would love to know what made you move towards writing and becoming an author of ‘From Code to Boardroom’.

Serdar Mustafa: It’s an interesting one, actually. It’s really interesting for me because going back to my youth, I was very much a reader, I love to, to pick up books and always kind of add new knowledge, but I was never much of a writer. And, I actually put that down to my ADHD, I have a neurodiversity, I struggle to focus. But then, throughout my working career, I actually turned that into a bit of an ADHD superpower. I realized that my scattered thoughts in the early days were better when condensed then and put into writing. When I started documenting the things I was doing each day, keeping logs and journals, and documenting, kind of various technical operational aspects of my roles, it made everything better, not just for me, but for the teams I worked with. And, I brought that into the product engineering roles. I’m sure we’re all familiar with the type of documentation that we get in the industry. By me starting the blog fairly recently, I was able to kind of put down my thoughts in one place where I could kind of gather them and reflect on them and keep them updated as things changed, but also share them with my peers, try and help other people with the knowledge that I’d gained over the years and help them excel at what they’re trying to do.

Kovid Batra: That’s really cool. And I really am inspired already from the kind of journey you have started with. And it’s really amazing to see you contributing back to the community. Kudos to you, man, for that.

Serdar Mustafa: Thank you. Thank you.

Kovid Batra: All right, moving on to the next one. I think now I know the answer to this, but love to hear more from you. What gives you the energy to overcome those roadblocks that come your way?

Serdar Mustafa: I guess I was always a competitive person as a youngster. I was an athlete. I was practising martial arts, gymnastics, parkour, and naturally these things had various challenges. And, I guess when I first started out both in sport and then in work life, there was always some prescribed way of doing something to get the job done. And it was only really when I came into tech businesses that I found this relationship between what I had done as a youngster with my sports, and the way software development teams work with the need to kind of pivot and change on the fly, adapt to what we’re doing. I really related it to my martial arts, my parkour in particular, when I had these obstacles or roadblocks, as you say, which didn’t always have a predefined way of challenging them. There was no script. You couldn’t always plan in advance. You could try and prepare for them as much as you could, but there was always these unknown unknowns. So, I learned to be able to stay agile, I know a bit of a cliché word in our industry. But, I learned to adapt and do things in different ways. And, this mentality that I developed, when I installed that into the teams I was working with and, and saw other people excelling and doing better in their roles, it really gave me this huge motivation. As someone that’s been coaching in sports and coaching and mentoring in business, seeing other people succeed has been that catalyst to me, that’s been the fuel to my fire. And, I love seeing that success from the people I work with. So, that’s what led to the blog and that’s what led to me going back into leadership and why I’m here today.

Kovid Batra: That’s amazing. Amazing. That, that feels really intense to me, and this is quite a journey, I definitely feel so. Let’s tone it down a little bit and let me understand from you, like how do you unwind your day? How do you end your hectic day? What’s your way out there?

Serdar Mustafa: Definitely a challenge for me. It’s one of my weaknesses, if ever there was one. Wearing the multiple hats that we do in startups, it’s hard to kind of press pause or stop and unwind. But, when I eventually do I’ve got two ways, really, if it’s something I need to do on my own and just clear my head, I’m a motorcyclist, I jump on my bike, I live near the countryside. So, I just go for a blast and pitch-up somewhere and just stare at the sky, stare at the trees, anything that’s not work-related.

But, other than that, it’s my family. I’m a father, a husband. I’ve got 3 beautiful daughters, and we love going out hiking and cycling. And, that’s enough for me to re-energize and reset before the next day.

Kovid Batra: Perfect, Serdar. I think that was great knowing you and there is more to come. That would be in the main section that we have. So, let’s get started there. Are you ready for it?

Serdar Mustafa: Yep. Let’s do it. Let’s do it.

Kovid Batra: Perfect. So, in this piece, we would love to know your experiences, your success and failures at different point of time in your career. So let’s just start with something like your journey, which has been across different departments of a business. How does your experience across different departments of a business impact your leadership style? Because you have been into sales, medicine, product ops, and then engineering, and then engineering leadership. I am really interested to know how does that make you different?

Serdar Mustafa: See, what most people see is the difference in job titles, job roles and industries, but there’s one similarity in most of the things I’ve done throughout my career that people often overlook, and that’s the people leadership.

Kovid Batra: Yeah.

Serdar Mustafa: It’s soft skills, it’s learning to collaborate and communicate with people to help boost their success and their achievement. So, I’ve never focused on being the best martial artist, being the best programmer, or being the best leader in isolation. It’s more about being an accelerant and, and lifting others up. And, by having this kind of experience in other roles and teams, I’ve looked at the different ways people do things. And then, when I look at the circumstances I’m in, any given role, I try to get the best bits from each of them and combine them to find new solutions or discover new problems that need to be solved, and look at how we can welcome them together.

Once upon a time, the manufacturing and car industry worked in a very rigid way. They were set in their, the way they did things, and then we started getting kind of lean principles and things from Japan, the way that they did these things. And, I’m sure they were laughed at initially. They were told that, no, you can’t do it. Like, there’s this way that we do things, and that’s it. But eventually, things called on and people adapted. And, we all know where we went from lean to agile and all the various methodologies. It’s been diverse and I have, I guess, a great variety of diversity across different roles and types of teams and working with different people in different countries, I’m just able to filter that down through the funnel and find a mix of things that helps the team that I’m in the best.

Kovid Batra: Makes sense. When you have been dealing with different teams, of course, the core motivation for people at work, most of the times remains the same, even when you’re in sales or in tech. So, just tell me one thing that you took from your, probably the sales experience or the medicine experience that you are able to apply here in engineering, and that has really helped you.

Serdar Mustafa: So, I mean, the sales experience, there was something that we used to do when I was a General Manager at Phones4u, a company that sadly doesn’t exist anymore. They were the largest retail mobile phone company in the UK for many years. We had this way of selling that was unique. We used to sit our customers down and establish their demands and needs. They would come in with their problem statement. They would say they need a new phone, and they would already have an idea of what phone or tariffs and things it was that they, they thought they needed. But, by sitting down with them and understanding their problems, understanding their budget and the other variables, we were often able to find them a better combination of these products that suited their needs more. When I relate that to Product Engineering, when we do user interviews and do all this user research, users often tell us what they think the problem is. But, unless you know what kind of open questions to ask and really understand what the problem is they’re trying to solve, what you can end up doing, and it’s common problem for even the largest of companies is building the wrong thing or building it in the wrong way. So, by using the kind of techniques that we developed in my previous sales background, we’ve been able to enhance the engineering teams that I’ve been working with.

And, slightly shorter story, but similarly with the medicine aspect, it was biomedical science that I studied which is a lot more research-driven than clinical medicine. But, the things I learned that really help is about hypothesis testing, statistical analysis, and understanding the context when you’re looking at raw data, we see so much data in our industry, all these developer metrics and user data, but what did it actually mean? When we look at a line graph or some pie chart or something, it’s usually presented in a positive way with certain colors and points on there to give a certain perspective to a certain audience. But, what I’m able to do with my medical knowledge is apply context to that to show are we really working towards our acquisition, activation in the way that we need, or is there something hidden in this data? Are there kind of outliers and things that we can analyze further to make better business decisions? So, that’s where that experience in those two different industries has really helped me in my roles over the last few years.

Kovid Batra: Cool, yeah. That’s, that’s really interesting. And I think very insightful. Perfect. Perfect.

Moving on to the next piece, what do you think it takes for a startup to find a product-market fit? Like, you have been working with multiple startups as an advisor, as a fractional advisor. I would like to know from you, like this initial journey of zero to one, this is really interesting. I have been into that multiple times, but I would like to know your perspective. Like, what does it take? What are those core things or maybe a framework that you have in your mind people follow?

Serdar Mustafa: I mean, at this stage, when you’re looking for product-market fit, whether you find an SLG approach or PLG approach, I think the key thing is to keep things simple. It doesn’t matter if you’ve got a complex product, the way users find it and your approach to development and things should not be complicated. They should be in the simplest form possible to help you build… instead of an MVP, I prefer to call it an MLP, a ‘Minimal Lovable Product’. Ask those questions, do the right type of research to really understand who your users are, how they’re going to use it and what problems it’s solving for them. And, a key example of this is, with our kind of empty state screens and things that we get on our loved SaaS products, one of the first things that you usually see is, “We can save you money.” “We can increase your profits.” “We can increase your brand recognition.” And all these kinds of things. But, that’s not actually the solution to the problem statement a lot of the time. They are usually commercial targets or objectives people are trying to reach. You need to really dig in your product to understand who these people are and how do they use it. Once you’ve provided and advertised that solution, word of mouth will do the rest. And there’s even businesses out there which have relied solely on word of mouth with no marketing and advertising budgets. Once you do those basics, you’ll establish product-market fit.

It’s a complex multivariable equation that requires a nuanced approach. There is no, kind of one t-shirt that fits all. There’s no point reading the latest blog on PLG or any of these strategies and try to apply it universally to what you’re trying to do. You need to really look at the intricacies of what you’re trying to achieve and, and adapt things. And you can only do that successfully by keeping things simple. If you start exploring overcomplicated technologies, overcomplicated system designs and architectures and things, just because they’re cool or that they’re the latest fad, you’ll often find yourself spending too much money in development and in hiring things before you’ve established that product-market fit.

And, bear in mind the climate changes as well. What you’ve identified now may be slightly different in six months time. So, as long as you’re not overcomplicating things, you can adapt faster. Hence, why I use the word agility a lot.

Kovid Batra: That’s, that’s totally bang on, I think. I have a question on this. Like, while being on this journey, multiple times myself too, I have always struggled to strike a balance between doing this user research, coming up with insights and then implementing something. And also at the same time, where I had my Co-founders, who believed in doing and failing and then learning from it, and then iterating. So, there has to be a balance between the two where you just go on the research journey, find out something, and then you execute, fail, and then learn from it, and then improve. Which one do you prefer, and how do you strike that balance?

Serdar Mustafa: I mean, it really depends on the nature of your business and the kind of people that you’ve got behind you in leadership or as Co-founders and things like that. One thing that’s imperative is that you’re all agreed. You should have one North Star metric that you’re focusing on at a time. Any kind of OKRs or whatever goal-setting methodology that you’re using should be aligned to that North Star, and everybody should be working towards that at the same time. As far as the approach to get there, it doesn’t matter if you’re following some kind of growth engineering type reports, some experiment-driven design or development, and you should always rely on as much data as you can get practically, and within a reasonable period of time. 

It’s about changing direction. I mean, the quote from Bruce Lee, “Be like water.” Water can… I’m not quoting this verbatim, by the way. So, any Bruce Lee fans, please don’t shoot me, and… Be like water. Water can flow hard. It can flow fast. It can be soft, and so on and so forth, right? It adapts to its environment, and that’s what you should be doing. So, if you choose on day 1 to follow some kind of data-driven development and you’re looking at stats and you’re looking at all this user research focus groups and things like that, you need to know when to either adjust or mix the method with a different type. I would always advocate for using some kind of mixed methods, some quantitative and some qualitative. Just be ready to change direction as the business sees fit.

Kovid Batra: Makes sense. Great! I think that’s really interesting. And, I think it’s more about being in the situation, having that feeling what’s right in that moment, because you might not always have the data to take a decision on that, but what we can do is actually timebox things to really keep moving fast and change directions, and then experiment with that.

So, cool. I think…

Serdar Mustafa: Mm hm.

Kovid Batra: Yeah, please go ahead.

Serdar Mustafa: No, I was just going to say, you know, you’re absolutely bang on it. It doesn’t matter which kind of goal-setting methodology you use, the age-old smart goals are always relevant. You should timebox things. You should have some mechanism to evaluate and review how things have gone and then make the necessary changes moving forward.

And the other thing I would say on the topic is make sure that you’re getting as much advice as you can from the professionals. If you don’t have those people in the team as you’re starting up or as you’re growing, there’s consultants out there, advisors, and fractional people like myself. There’s all of these different resources available these days. Try some different options, take that advice in. And at the end of the day, you’ve got to make the judgment, which one you follow. So, no one knows the answers for sure. But, they can at least guide you in the way that their experience has shown previously.

Kovid Batra: Definitely. Got it. Well, this is something around the startups and for our audience who are into this journey. We have people across the world who are leading bigger teams, well into the phase or who have crossed the phase of zero to one and are into the growth and scale mode right now. For them, the day-to-day challenges would be around being more efficient, being more productive. So, when we talk of this efficiency and productivity and effectiveness in the teams, how you have been doing it with your engineering teams as a leader to measure the efficiency and finding those inefficiencies and then improving on those, how do you usually deal with that? And of course, when we talk of efficiency, productivity, we really can’t give up on the well-being of the development team or the developers. So, a combination of this. How do you take care of it as an engineering leader, the efficiency and the well-being?

Serdar Mustafa: Efficiency and well-being. I mean, again, specifics depend on the type of business. If you’re a small 5, 10, 20-person startup, it’s going to be very different to a large organization that has a thousand people in engineering. Things scale differently. For me, most of my experience has been on the smaller side of businesses, up to 50-person engineering teams, and they’ve all shared a lot of similarities. I’ve been in the business where they were initially trying to use kind of more enterprise-type approaches to standardize everything they do. They would pick some kind of agile methodology or framework, use well-known engineering metrics, things like cycle time and velocity. And to support that, they would have sprints and story points and things. But, one of the issues I have with this is they’re using essentially qualitative data, and trying to get a quantitative output. Things like measuring efficiency with cycle time and velocity, you’re relying on story points, t-shirt sizes, things like the Fibonacci sequence and that, which are all numbers, obviously. They’re all quantitative, but the source of that number or that, that data point is qualitative. You’re basing something on ‘how much time does it take to do this type of ticket’ or ‘how difficult is it’, ‘how complex’ and stuff like that, right? So, how do you convert something qualitative into quantitative and then standardize it when there’s so many other things which can impact it? There’s people taking time off, there’s people leaving the business, people joining the business, there’s national holidays, there’s unknown technical problems which may occur that divert your resources and attention. If you’re in a young startup, you may even decide to pivot everything that the team is doing or certain teams within. So it’s, it’s hard to plan and measure these things in that way. So, what I prefer to look at is more on the efficiency side of things, the outcomes. What is it that we’re trying to do? Going back to that North Star metric and those OKRs or similar system, what are you trying to achieve? Is it acquisition? Activation? Are we trying to improve customer satisfaction? Reduce the amount of bugs? Pick a thing that is your goal, establish a baseline of where you are and where you want to be, have the measures in place to be able to do that, and then measure it over a given timeframe. So, like you said earlier, you need to timebox it and look at how it’s done, and then you can dissect it, disseminate it, and analyze it afterwards to see the what’s, the why’s and, and things like that, before you improve it.

Kovid Batra: Exactly. So, I think you are completely aligned on the thought where how important the business objectives are, business outcomes are, and I totally second that thought. But the point of measuring efficiency comes in when you face problems in metrics like customer satisfaction, right? Just for example.

Serdar Mustafa: Mm hm.

Kovid Batra: And this customer satisfaction could be going down just because your app is not working right, which ultimately trickles down to the fact that why is it happening and you need to know an answer to it. So probably, what I personally feel is that these engineering metrics could really help you understand that, “Okay, this is the root cause.” So, let’s say the customer satisfaction is going down because of the bugs or the issues that are there on the app. How would you understand that? You would be able to see that in the engineering metrics. For example, if there are very less comments going on the PRs that are being merged to the main branch, just for example, you would know that the teams are probably not having a strong review process in place because of which the quality of the product which is going out is not right. And so, the point is absolutely right in a way which you said, the most important thing is to look at the business metrics, and then from there, if you identify problems, you need to deep dive onto the engineering metrics to understand where things are going wrong. So, what I feel, not to say that you are doing the wrong thing, but to basically put in line that how these things connect with each other, like product and engineering connecting together to ultimately deliver the product, right? So that’s something which I personally feel is important for engineering teams to look at time-to-time that how they’re doing on their bugs rate, how they’re doing on the code review process, how they’re doing on their comments per PR. There are a lot of such metrics that are there into the picture, but yeah, that’s what my thought is. What do you think about that?

Serdar Mustafa: So, I guess it has to work, I think. A lot of what you’ve just said is on the assumption that you’re doing traditional code reviews and pull requests, when there are a lot of ways of working, shall we say, aligned with various agile methodologies, like XP (Extreme Programming), which work in a different way where people are working more collaboratively, either paired coding, group coding, and mock coding and so on, where you’re doing things kind of more proactively, you’re shifting things to the left. And, you’re not writing the code and relying on someone to catch it in a code review after. Even if you’re having regular small commits and small PRs, there’s room for error and there’s certainly room for improvement. But, I think we need to rewind a little bit before that.

Technical debt, huge topic, but actually I think a lot broader than most people give it credit for. Technical debt can cover the product side of business, commercial sales, marketing, so on and so forth, not just engineering and the code that we write. In short, there’s, I believe, two types of technical debt. There’s the intentional technical debt and the unintentional. The intentional technical debt are decisions, business decisions, engineering decisions. Somebody who’s chosen to build something a certain way… now, for that decision to be made, we can discuss another time, the kind of steps that may be involved and peer groups and workshops and things, but let’s say that, that bit’s safe, that bit’s being done well. It’s the unintentional stuff. The unintentional is we had a goal of building something that was going to end up a certain way and it hasn’t ended up that way, whether it’s a defect, a bug, an error, whatever we want to call it, it’s not the way it was intended. Now, a certain amount of this, we have a tolerance for. Technical debt is like a financial or credit card debt. When used responsibly, you can improve cash flow and get you by until you’ve got more income coming in. In terms of the technical aspect, we can introduce a certain amount of technical debt. And, I don’t like the phrase ‘cut corners’, but we can do things intentionally in a way where risk is mitigated, but we are delivering the MVP. We are getting the next iteration out there in a condition that we are happy accepting.

Kovid Batra: Yeah.

Serdar Mustafa: It is when not managed responsibly, that this debt can spiral and accumulate, until one day it bites you in the proverbial bottom. In engineering, that’s when we make out our software and code and things too complicated, unmanageable, unscalable, and too specialist and things like that. We create silos and all these things. What we need to do is focus on making sure that we are building things that are simple and solve problems. We need to keep even the operations and systems and ways of working simple at first. There’s no point investing too much time measuring these kind of metrics in the early stages. And when we do decide to start adding things, we need to do it incrementally and review them to make sure they’re actually providing value.

Kovid Batra: Absolutely.

Serdar Mustafa: I don’t want to say get rid of things like cycle time and velocity and these traditional metrics, but instead, introduce them at the right time, the right amount of them, understand the return on investment from doing this, do it in collaboration with the people that it’s going to impact. So, discuss these things with the engineers, with the product people, QAs, and so on, to see what they think, because this affects the second part of your original question about kind of developer experience and things.

If you introduce these things, they can be misinterpreted. They can be seen as kind of performance management metrics. They can be seen in a very negative light. And ultimately, there’s no point having great developers, a great team building fantastic things of solving user problems, if you’re just going to have a high turnover of stuff, because they’re not happy about the performance management metrics and things.

So, there’s a whole load of stuff in this realm that could be discussed. And I know we don’t have the time today, but, what I’m saying is really think about the kind of metrics and the value they’re going to give your business. Why are you doing them? Is it just because engineering managers typically have these metrics? Who are you showing them to? And, what are they doing with them? I actually asked these questions in a previous role. I inherited a leadership role as I got promoted and someone else left. And, I was expected to continue filling out these dashboards and looking at these metrics, and I actually stopped after the first week and went back to senior leadership and asked, “Why do we have them?” “Who are they for?” And, I actually asked the CEO explicitly, “Is it for you?” “No.” “Was it for the CTO?” “No.” The answer was, “Because your predecessor was doing them, we just assumed that you would continue.” But, they weren’t going anywhere.

Kovid Batra: Got it. I think I totally agree. I think, to conclude on this point, what I would say is that as you scale, you just need to understand the need of the right metrics that you want to introduce, and they have to be introduced with the right culture in place where people are, the developers are feeling psychologically safe and they’re not taking it the other way around, where it is ultimately for the benefit of everyone in the team. So, I totally get that point that with scale, the need of such metrics would come in. And, we have to like, as an engineering leader, we have to figure out which metrics to look at, how they should be deployed and used for the improvement and good for everyone actually.

With this, I think we have exhausted all the things that I wanted to ask on this, on this podcast. And, it was really, really interesting talking to you. I think we can have another podcast on the last question where we left and like, discuss more on that. I really found that piece interesting where you touched on the technical debt part. Would love to talk more on that, but probably on the next show.

Serdar Mustafa: Absolutely. No, I’d be more than happy to. I hope that your viewers and your audience get some value from the discussion today. And, even if there’s one little thing that they take away from it to help them improve themselves or their business, I’d be satisfied.

Kovid Batra: Absolutely, Serdar. So, one last message for our audience that you would like to say?

Serdar Mustafa: Keep your head high and stay positive. I know it’s a, it’s a turbulent industry, but it’s extremely rewarding, if you ask me. The, the satisfaction from seeing yourself succeed, your team succeed, or your product or your business that you’re in is just second to none. So, keep it going.

Kovid Batra: Thank you so much. Thank you so much for this.

Serdar Mustafa: Thank you, everyone.

Kovid Batra: All right, Sid. See you!

Serdar Mustafa: Bye, everyone. Bye, Kovid.