‘Impact vs. Velocity’ with Stephan Schmidt, CTO Coach at Amazing CTO

This blog was originally published in the Typo blog.

In the recent episode of ‘Beyond the Code’, Host Kovid Batra welcomes Stephan Schmidt, CTO Coach at Amazing CTO. His vast experience includes valuable contributions to renowned companies such as brands4friends by eBay Inc., ImmobilienScout24, and 7Mind GmbH. The discussion centers on ‘Impact vs. Velocity’.

The podcast begins with a fun fireside chat with Stephan, allowing the audience to see his candid side. Later in the main section, He explores the challenges CTOs face in large-scale companies. He also provides insights into steering the team towards impact over velocity as well as navigating the challenges of balancing fast-paced growth with handling technical debt during hypergrowth cycles.

Stephan concludes by discussing what separates a leader from a manager, along with measuring success for engineering teams.

Timestamps

• (0:06): Stephan’s background
• (0:53): Fireside chat
• (4:19): What are the significant challenges faced by CTOs in large-scale companies?
• (6:24): Why CTOs find it challenging to align tech strategy with business strategy?
• (9:02): How to guide your developers to prioritize impact over velocity; when they may not be closely connected with the business side?
• (17:01): How to balance fast growth with managing technical debt during hypergrowth cycles?
• (22:24): When is the optimal time for a manager to transition to an engineering leadership role?
• (28:23): How to define success for your engineering team?
• (32:52): How to ensure performance expectations for your team?

Links and mentions

• Stephan on Linkedin and Newsletter
• Kovid on Linkedin
• Listen on Spotify and Apple Podcasts

Episode Transcript

Kovid Batra: Hi everyone! This is Kovid, back with another episode of Beyond the Code by Typo. Today with us we have an interesting, amazing guest who is super knowledgeable, 30+ years of engineering and leadership experience. He’s an ex-CTO of an eBay company. He’s been the founder of a startup. He’s currently working as a CTO coach with Amazing CTOs. And, the most amazing thing about him is his humbleness. Welcome to the show, Stephan. Great to have you here.

Stephan Schmidt: Hello, Kovid. Thanks for having me.

Kovid Batra: Pleasure. Pleasure. All right, Stephan. So, before we jump into your experiences and knowing what all wonders you did in your career, we would love to know more about you, outside of tech maybe, so that our audience gets familiar with what kind of person you are.

Are you ready for a quick fireside chat with us?

Stephan Schmidt: Yeah, sure.

Kovid Batra: Perfect. Perfect. First question is very simple. Are you a beach person or a mountain person?

Stephan Schmidt: Oh, I enjoy both. I grew up in the mountains, but, some years ago, I moved to the sea, so I like both. But, if I needed to decide, probably the beach.

Kovid Batra: And in one word, tell me, what do you feel when you’re at the beach?

Stephan Schmidt: I’m amazed by the sea. I feel amazed. I feel..

Kovid Batra: Perfect. All right. Next question. It’s been 30 years of experience, but you have to go back, you know, memory lane down to the point where you had your first coding experience. Tell us about it.

Stephan Schmidt: My first coding experience, like for so many was as a kid. I played video games at the end of the 70s and I thought, “Well, I could do that too. I want to do that too. I want to write video games.” So, I went to a department store. There were other kids who did some programming on the computers in the department store. I watched them doing their stuff, learnt from them, imitated them, and that’s how I got into coding. And, since then, I’m a coder and what I love about coding is essentially creating something from nothing. Like, there is a blank screen and then you can do the thing, the computer, whatever you want it to do. It’s like you create something out of nothingness. And, that’s still something that I really, really find amazing.

Kovid Batra: So, for all the parents out there, video games are not that bad.

Stephan Schmidt: No!

Kovid Batra: All right. All right. Moving on to the next question. I think this is very close to me also. What would you choose? Like, what do you prefer, being a founder or being a CTO at a company of eBay? What journey was more fulfilling? I feel both of them are very good, but what’s your piece of cake?

Stephan Schmidt: I think the nice thing about eBay, and I was also working at a large company in Germany, which is called, ImmobilienScout24, which is a real estate website, the largest real estate website, I think in Europe. And, what’s nice about working in a large company is that you feel some impact. It’s large, people know the company. So you see people who use your product in everyday life. So, you can go around somewhere and say, “I work for eBay.” And then everyone says, “Yeah, I know eBay. I use them.” Or ImmobilienScout24. “Yeah, I’ve used ImmobilienScout24.” So, everyone knows it. So that’s, I think it’s a nice thing of working in a large company. And also, you have a lot of money around and you can do a lot of things because you have a large budget and all of this stuff.

Being a founder of a startup enables you then, but enables you to better, I think, follow your ideas and your vision. Because in a large company, you might be constrained by the company and by the company strategy. And so there’s limits on what you can do in technology. As a founder in a startup, there is no limit, on what you can… have legal limits, but there is essentially no limit on what you can do. So in doubt, I’d go the founder route. But I learned a lot in large companies and I enjoyed my time there.

Kovid Batra: Perfect. Thanks for answering that. All right. I think that was an amazing quick fireside chat with you. Now, we would love to move to the main section where we get to know all the wonders that you have done in your career. And I would simply start with something that you have been doing right now at amazing CTOs while coaching the CTOs.

What do you think are the biggest challenges CTOs face in companies like eBay, which are obviously at that scale? What do you think, on day-to-day in their responsibilities, in their role. What are those challenges that you see these CTOs facing?

Stephan Schmidt: I think the challenges one of the challenges that a lot of CTOs are facing and, and it gets more difficult the larger the company, I think, it’s aligning strategy with business strategy. I think that a lot of challenges arise in software engineering when the business strategy and the business vision is not aligned with the tech strategy and the tech vision. And, I think it’s paramount for the CTO in a company. And it’s more, more important to bigger the company to align the tech vision and the tech strategy towards the business and be supportive, because otherwise you move in the wrong direction. If you are not aligned, you move in the wrong direction, you make the wrong architecture choices, the wrong technology choices. And then, there is a rude awakening at some time because there is too big of a rift between you and the business. So, I think it’s very important to be aligned on business vision, business strategy, and execute on them. And where do, where CTO struggle is, first, I think is bridging the gap, thinking from the business side, bridging the gap. And, the second thing is they usually don’t think there needs to be a tech vision, a tech strategy. They are too focused inside. They think it emerges by their actions and by their decisions about technology, but it’s not. So, they don’t have a strategy. They don’t have a clear strategy. They don’t have a clear vision for technology. And that creates a lot of rift and problems.

Kovid Batra: But, why do you think, like, I’ll ask a question, follow up question on that. Why do you think the CTOs really struggle with formulating this vision in their heads and then aligning a tech vision or a tech strategy for that? It may be these events arise, these problems arise, but at the core, what exactly doesn’t make them move towards this direction of building a good strategy? Is it the lack of understanding of the business needs? Because probably CTOs come from a tech background and they have more inclination towards coding and being individual contributor a lot of part of their lives. What exactly it is? Why do they miss out on this bus?

Stephan Schmidt: I think there are several things. And the first thing is, is really what you mentioned. I’ve had a lot, so the team, not me, but I, as someone who takes ownership not of the good results, but of the problem. I’ve had a lot of hard tech problems with my teams and but usually this was not something very high on the, on the agenda of the CEO. So, I did not get a lot of thanks for solving hard tech problems, but I always got positive, very positive feedback on my understanding of business and my trying to bridge the gap, trying to understand business, support business and stuff like that. That’s something that the CEO said, “Stephan, that’s, that’s good that you’re not a techie. I can talk to you. You talk in a way I can understand it and you try to explain things.” And so, I think that’s, that’s very important. And, and CTOs don’t do that enough, I think. But that’s the role, that’s part of the role.

So yes, from that side, I think strategy is lacking. And on the other hand, I think a lot of CTOs think they don’t need a strategy or they don’t know what it would be to have a tech strategy, what it would look like. And they, they just go from decision to decision and say, okay, they have some kind of strategy, like, okay, we want to move to the cloud or want to move to the, to microservices or something. But they, it’s not embedded in a grand scheme, in a grand strategy and a grand vision, which is aligned to business. So they are, they have random kind of random strategy steps they are doing. Like, move to the cloud, move to microservices or move to mobile native apps or something. But these are kind of random strategy steps. And they think that’s enough, but I think it’s not enough. It needs to be a wholesome strategy, which gets you somewhere. And that somewhere is a vision where you want to be.

Kovid Batra: Definitely. I think that’s interesting. Thanks for highlighting that. All right. So, one more thing then last time when we were talking before this podcast, I remember you telling me that it’s not about doing more or it’s not about achieving high velocity, it’s always, always more about delivering more impact, right? So, as a CTO, when you step into that shoe, how do you exactly ensure that the impact is getting created? Because as a CTO, let’s say, you understand what would be the business impact. You at least have direct business counterparts to whom you are talking on day-to-day basis to understand what they need. But, what about the team who is not interacting, and is probably a little bit unaware or a lot unaware of what’s going on, on the business side? How do you make sure these people are more aligned towards delivering impact rather than focusing velocity?

Stephan Schmidt: I think developers, particularly developers want to work on impact instead of velocity. I think they want to do things that have impact, so it’s not about the tech team. I think it’s about two things. First, I think it’s about business, where I need to do a lot of explaining to get them into the impact mind frame, in the mindset and into an impact frame, because they often think we need to deliver more and see what sticks.

Whereas when I look at, I don’t know Tim Cook, but I imagine Tim Cook from Apple wants to have a blockbuster iPhone each year. And, he doesn’t care if the iPhone is one release, one month earlier or something, or two months earlier, that’s not the focus. The focus is to have a blockbuster release, iPhone release, sell hundreds of millions of them. And, business needs to get in that mindset and that’s a lot of effort because usually they are more in the, “We need to do a lot of things. We need to do a lot of things. Do things fast.” And stuff, instead of, “We do things that have impact.” So, that’s the point. And, their interaction with product or with someone who defines features or defines user stories, epics, or whatever you want to structure your software engineering around. I think the important thing there is they need to have impact metrics. You know, they need to, every story needs to have an impact metrics. What impact do you want to have? Like, it might be usage, minimal, might be usage, 50% of users are using this, but it might be more of an outcome, not only an output, but more of an outcome metric. And an impact metric, that’s very important, and to follow up on these. So, I see organizations who do not define impact metrics, they define revenue metrics, which is a very, very bad idea for various reasons. They, they don’t define impact metrics, but if they define them, they don’t follow up on them. So like, you do this. Okay, didn’t work. Next. And, you need to really follow up on metrics. That’s, I think it’s a challenge, like the interaction with the persons who are writing the stories or the epics. With the business side, that’s a story, about the strategy. I feel like developers really want to work on things that have impact, you know? And, they don’t want to create as many features as possible, from my perspective. They want to have work on things that have impact.

Kovid Batra: No, I believe that. I mean, I, I might be coming from a very narrow experience where I might not have encountered that. Thanks for an eye-opener there. Probably developers have that mindset that they want to create an impact. But, at the same time, I have one more doubt. And again, it could be something which is very specific to my experience with developers. I don’t see that tendency where they want to really get in touch with the customer, like getting in touch, not literally. Maybe a salesperson would be doing, or even a product or a user research person would be doing. But, taking that information from these business departments to understand what exactly the user feels like or getting into the shoes of the users, and then thinking of coding and developing, I feel that there is a resistance. Is that right or wrong?

Stephan Schmidt: Yes, I think that there is some resistance there for various reasons. One reason is essentially that developers are very fact-driven usually. And you know, the best fact wins, the truth wins. Let’s discuss this on facts. Whereas other departments are not that fact-based or not that detail-based. They are fact-based, but they are not that detail and analytics-based as developers are. So, some other departments want to talk about feelings and about emotions, about how we can do this and do that. And, and just glance over the details. They don’t want to talk about details. You know, they want to, marketing, sales, some other departments and customers. They talk about the big things perhaps, whereas the developers want to talk about the minor things and the details of things, they are interested in the small details of things, because in the end, they need to make it work, you know, and it breaks in the details. And there are some differences between cultures and between understanding. And, that sometimes makes it difficult for developers. And then this gets friction and that friction takes effort and, and is, you know, and it’s, it’s annoying. And out of that, I think, arises something that developers do not particularly want to discuss things. They say, “Tell me what I need to do.” You know, they’re often unhappy if some, if you tell them what to do, because they think it’s a bad idea or it’s not detailed enough, you know? So, on the one hand, they’re annoyed by if you tell them what to do. On the other hand, they say, “I don’t care. Tell me what to do.” So, there’s some, there’s some, “I want this, but I also want that.” kind of thing.

Kovid Batra: So, why I’m asking this question is because this is this whole loop. Like if I, as you said, like the developers would want to create an impact and they would want to develop something that creates an impact. It cannot happen if they don’t have the right information, if they are not contributing in terms of the discussions with the Product Manager, right?

Stephan Schmidt: Yes. Yes.

Kovid Batra: And, to actually first get involved there would make them innately accountable for what they are building, right? If you, again, if you just go tell them what to build, they would not be happy. They would not feel involved in the process, and ultimately, they would feel getting tied to the business metrics of the product metrics, the usage that you were particularly saying. So, I think it has to start probably from the point where the developers have to be put into a mind frame, as you said, they need to deliver a blockbuster product or a blockbuster feature. And to do that, they need to realize that they have to come out of that little bit of a shell and understand what’s there on the customer side. And then start getting involved in the development process with the product.

Stephan Schmidt: Yeah. Yeah. I sometimes, I sometimes shorten this to ‘developers need to become creators again.’ You know? My heroes in the 80s were people who wrote video games by themselves, or two people wrote a video game, city design, great video games like, Elite or Iridium, Paradroid. There are a lot of good video games written by only two people or one person. And there are also good, great software like Lotus 1–2–3, WordStar, VC card. But there, back then, developers were creators. You know, they created things. And today, a lot of developers are executioners. They execute things. They create things other people have thought of. They build for other people. And, what I want is that developers get back into the creator mindset and feel as creators, because that’s also something that brought me into development. So, this is something I try to tell developers is that they would be happier if they could get into creator mindset. And then sometimes, for example, if you send them off to a design thinking workshop and they get into design thinking and then they get involved in the product management, they are often happy then with being there and making the decisions, even if there is some resistance at first. But, a lot of them, not everyone, it’s not for everyone, but a lot of them are very happy getting back into the creator mindset and being a creator again, instead of just doing other people’s stuff.

Kovid Batra: Perfect. Yes. I think that’s, that’s what probably I was thinking. All right. I think this was interesting.

So, that was on delivering more impact, how you would actually drive. Now, there is one more thing that we feel that it has to come with alignment. When you’re leading with a strategy, then you have to, like create a balance between a fast-paced growth and also handling the technical debt. I mean, this is kind of inevitable and almost every engineering team has to go through this loop where they are under the hypergrowth cycle at some point and they create technical debt at that point. How exactly in your view should that be handled? What as an engineering leader or as an engineering manager, should you consider while taking on that call, whether to build it this way or that?

Stephan Schmidt: I have a, a simple, I don’t say I’m right. You know, I, it’s just my opinion. It’s just my experience. So, that’s my model that I have in my mind. I might be helpful, might not be helpful. But, how I see it is there are several phases and you need to act according to the phase in a startup.

And so, the first thing is for me, from a product perspective, startup product perspective is you build a prototype, you know? So, you go in, and you did a, we build a prototype where you can evaluate the idea, how it would look like in general. And, you can show around the prototype to investors, to employees, to people, to friends. That’s the prototype phase. And, you can do no code development. You can do whatever you like. You can do a click dummy. You can do PowerPoint slides. It’s not important. That’s the first phase. A prototype with a clear goal of getting people interested, evaluating the general idea, how would look like.

Then, you get into MVP and see what would the minimal product would look like that you could bring to market, you know? What’s the entry product? What’s the market entry product? You need to build the MVP. That’s the second phase for me.

Then, you have the third phase. And, the third phase is about finding product-market fit. So, you need to iterate and really work hard to find product-market fit. And, when you have product-market fit, you will feel it. Some of my coaches get into that mode and they feel it. Everything gets easier. People come to you, want to buy from you. So, this is product-market fit.

And, after product-market fit, last phase, last relevant phase, there are some others in the future, but last relevant phase is scaling, you know? So, you have prototype, MVP, PMF, and scaling. And, what I see about technical debt, what I see is, in the beginning, it’s okay to have technical debt. So, I would not care about technical debt in an MVP or until getting PMF, product-market fit. I would really, totally concentrate on these two things. And if I accrued technical debt, that would be fine with me, you know? I try to minimize it by having the right engineering culture in place, not doing stupid things, but overall, total focus, getting PMF, getting MVP, perhaps to get an investor, to get into the market and PMF to find traction. And then, I would think about tech debt and have a clear strategy to get off tech debt and remove it.

A lot of tech debt, essentially, I think is accrued because of two reasons. First reason is tech is not aligned to business. So, business moves here, tech moves here, and the ever widening gap is kind of a technical debt because it’s like, we can’t move there because we’re here and, you know? And, the other thing is that a lot of companies want tech engineers in startups, want to scale too early. And, they put things in it, and they add abstractions and they try to scale before they need to scale. And what happens is they get a lot of technical debt not in the form of bad code, but in the form of bad abstractions, you know?

Kovid Batra: Right. Makes sense.

Stephan Schmidt: And, I would, I would be cautious about, I, whenever they tell me how I need to prepare for scaling, I say, “No, why?” I mean, first, you can’t anticipate the future. So, probably we built the wrong things. So, always don’t do stupid things, like too easy stuff, have several servers and, you know, don’t do, I have some clients who have one server, don’t do that, you know? But, don’t scale too early because also on the other hand, you will find out things, at least I found out things when I was in hypergrowth startups, that things break that you did not think about, you know? The things that are breaking are things you’d not have thought about. So, I think it’s don’t do something stupid, but don’t try to scale too early.

Did that a little bit answer the question about technical debt?

Kovid Batra: Absolutely. I think it puts a lot of perspective in place. We are also going through that journey right now, and I totally understand you are trying to emphasize them. And, I think it’s a very good piece of advice because the need of the hour is to build, find that fit, not to build something perfect today, because for that we’ll have time. We just need to build something which is just good enough and serves the purpose. So..

Stephan Schmidt: It’s very, very difficult to achieve product-market fit, you know? A lot of companies fail there because they think they have it, but they haven’t. So, and I would not think about technical debt until I have traction.

Kovid Batra: Makes sense. Makes sense. Absolutely. Thank you so much for answering this.

With that, I would want to move on to something where I’m sure you would be coaching a lot of people on, where they transition from a manager to an engineering leadership position. I mean, the first transition is of course, from an IC to a manager, but then the journey from a manager to a leader, I would love to hear from you. What should be the reason behind it? When is the right point? The inspiration. Just tell me about what according to you is the right point for somebody to move from a management position to a leadership position.

Stephan Schmidt: I’m not so sure there is such a huge difference. And I also, I felt like I was always kind of a leader because of like in and I don’t want to be “Stephan knows everything and does everything right” and blah, blah. It’s not about that. But as a kid, running around in gangs, doing stupid things, 10-year-old kid, I always thought, like I was often the one telling people what to do, where to do, what to, what stupid things to do next, you know, or what intelligent things to do next. So, right from the beginning, I felt like, natural to me to standing in front and showing directions. And, I think that’s about leadership. And, the most important thing about being a leader is giving directions, you know? Like, “This is where we want to go to.” So you need to have a vision and you need to tell people we want to go there and remind people that you want to go there because a leader is someone who leads. And, you lead people by leading them somewhere. I mean, you can lead them in a circle, but you can’t lead people in a circle. So, you will lead people somewhere. So, a leader is someone who leads people somewhere. And to me, that’s having a vision and leading people towards the vision, which is kind of a goal in the future. And that’s leadership to me. Whereas manager is a lot of, about administrative stuff and taking care of people and being people manager and all of these things. The difference to being a leader is to me is having a vision and leading people, have a clear opinion where to go and lead people there because you believe that’s the right direction to go.

Kovid Batra: Makes sense. Makes sense. Perfect. I think, when we have that feeling, so what I would love to share what I feel that being a leader comes with something which is very core is being able to comprehend yourself, like explain yourself to others in the best way possible by being humble, not by being somebody who’s a hero or being alpha in the team. And most of the times we feel that. I mean, this is a quality that you have, I’m sure. I feel it. I just mentioned in the beginning also, I think this comes very obvious to you, but I think one of the things that I feel the leaders should have is the humbleness, the groundedness, and being one of those people with whom you’re working. It’s just a responsibility that you have taken up to give the direction to the team, but that doesn’t give you the power or the, the superiority in that plan, in that team. Yeah, so that’s something that people should be consciously aware of.

Stephan Schmidt: I think to me, as I said, crucial is leadership says, “This is what we’re going to do. This is where we want to go.” And that’s leadership to me. And it, it does not need to be that you’re standing on the table, shouting people, “Go there!” Or “Faster!” You know, it’s not, that’s not, you can be part of a crowd. And, that’s also something that I always had as a manager and leadership ideal, I was always part of the group. So, I was not standing on the sidelines. I tried not to stand on the sidelines and give directions. I was always trying to be part of the group. Like in this, I don’t know, like in the movie, you know, like being a leader, but being part like ‘The Glorious 7’ or something. Being part of a group, you can be a leader by being part of the group. It’s not something that you are directing the group around, you know? It’s not. That can always be a leadership. If this is your style and if it’s fine, then, but it was not mine. You know, leadership can be part of the group. I think you can be a leader without having a title, you know? There are a lot of great developers who are obviously the team leader, the team lead, but are not the team lead, you know, because they take ownership and, and if it works fine for everyone, then that would be also fine for me, you know? I don’t have to have the title to be a leader.

Kovid Batra: I think that thing would have a little bit of a problem in terms of people having that bias to follow what you’re saying and, and you need it at times. So I, I feel that you should be entitled in some way, like either it should come from the group itself that, “Okay, he is, or she is the best person to be there to take decisions for us.” Or the authority, or not exactly the authority, but the upper management or the existing leadership should define that, “Okay, this is the person whom you should be following now.”

And then, even if you become part of the clan and then work that way, it works pretty well. But yeah, I mean, everyone to its own but your thought is also correct.

Stephan Schmidt: Yeah, no, actually one, one minor thing I think is, is like, I didn’t go into the question why people should follow you, you know? You know, there can be various reasons why people should follow you and it can be because you’re the boss and you say so, but it can also be because people trust you, you know? People usually follow you, I’d say, if the vision you want to lead people towards is self-evident and great, and all the people say, “Yeah, that’s a goal in the future. I want to be there.” And people trust you that you will be the person leading them there, you know? If they don’t trust you, you can have the best vision, but if you don’t, if people don’t trust you to go get them there, you know? So, there can be very, very different reasons why people follow you, can be you, the boss or you, you know, but, or you have the title, whatever. But, it can also be because people trust you and you have to create a great vision where they want to be.

Kovid Batra: Sure. Absolutely. I think, one thing that comes to me is that when you move into that step and you want to be part of the clan and you want to be humble, it becomes difficult in one way is how you, like push people to move faster or let’s say, deliver more impact, measure their efficiency and then tell them, “Okay, this is where you’re working on.” How do you do that? How you have been doing that as a leader, defining success for an engineering team and then measuring it? And while doing all this, taking care of the team, their well-being, how do you exactly do that?

Stephan Schmidt: I think the first thing that a lot of CTOs are not doing, a lot of leaders are not doing is expressing their expectations. People have expectations of the team, of the company, of the individual, but they don’t, do not talk about them. And then, the person, the team, the organization fails because it does not succeed towards the expectations. But, the leader, manager, whoever has not spoken about those expectations. So, a big failure in organizations and in managers I see is that they do not talk about their expectations and then are unhappy because people do not follow their expectations, fulfill their expectations that they have not talked about, which is obviously, you can’t, I can’t, I can’t fulfill your expectation if you don’t talk about them. But, that’s what I see too often. So, the first thing, very, very, very first thing, if we talk about performance is talk about your performance expectations and talk about that performance is important to you and what performance means for you. How does performance look like? What is performant behavior? What is underperforming behavior? And, performance is important. So, what’s your expectations? How do you judge people? How do you judge performance? How do you evaluate things? That’s the first thing. Make it clear that performance is important or very important to you.

And again, little bit of a sideline, side quest, employees, developers hear so many things, so you need to repeat important stuff. If they have heard from you five times that performance is important, they will think, “Okay, it looks like performance is important to Stephan.” You know? But, if you tell them only once, they hear so many things, they need to judge by themselves, what’s important, what’s not. And, if you tell them only once they think, okay, that might not be the, you know? So, it needs to be clear expectation, performance is important. That’s a cornerstone of everything.

And then, add two things. The first thing is, is something like support the people, support the developers, you know? Give them what they want. Like I have this famous story. I got into trouble because everyone in my department got $300 headphones. But, it was too loud, people could not concentrate. So, everyone got a $300 or $350 headphone which got me in a lot of trouble because, like company did not understand why I was buying so many, like for 10,000s of Euros buying headphones. But, if this is what they, what you think they need, then do it. And, so I was very close of letting, I was, a lot of people were angry in top management. But, if you think that’s, that’s the thing that people need to deliver top performance, that’s what I said, you want, company wants top performance, pays a lot of money for these developers, and then I can’t give them a $350 headphone? Does not make sense, you know? So, give them what, what developers need, environment, tools. So, support them in every way you can to be performant. That would be the one way. That would be the one part.

And, the other part is hold them accountable for performance. So, if you expect performance and you have the feeling that someone is not performant enough and is underperformant, tell the person. And again, tell your expectations, describe what you see, what you think is happening and that you’re unhappy with this. And then, sometimes, more often than not, you’re wrong, you know? I was wrong when I said someone to them. So, this is someone, the person said, “Yeah, because this is because this is of this and this and this, and we hadn’t anticipated that. And, that’s why this project is underperforming.” And then I said, “Oh yeah, sure. You’re right. Hadn’t thought of that.”

Kovid Batra: Yeah.

Stephan Schmidt: You know? So, I might be wrong with my perception of underperformance, but nevertheless, I talk about it. And I hope people are accountable for performance, with all the support I can give them, you know?

Kovid Batra: When you say that you set the expectations, I tell them what performance looks like, how exactly do you do that? Just give me an example. Is it some metrics that you’re following? Is it some engineering KPIs that you would like to put up front that, “Okay, this is what we are going to look at when we are evaluating your performance.”? Is this what you’re talking about? How do you bring objectivity to this process? That’s the broader question I just wanted to understand.

Stephan Schmidt: So, the first thing is I always try to steer everyone to an impact framework instead of a velocity framework, because otherwise, performance is just more features and faster features which is not my understanding of performance. So performance is do things in a reasonably fast way. That’s engineering performance, with the right trade-offs between gold plating things, overthinking things on one hand, and creating engineering hacks on the other. So, hacks in a bad way, not in the, in a traditionally good way, but in a bad way.

Meaning so you need to make the right decisions. And if, for example, again, if, if someone takes two weeks for a development effort, and then I say, “Well, that’s too long.” I feel that’s too long, and then I let, let explain why it took two weeks. And then, I might be wrong because it really makes sense.

Kovid Batra: Yeah.

Stephan Schmidt: So I push for performance. So if, whenever I see or team lead sees performance in a way, speed in a way that does not look right, I go into it. But more, normally it’s more about making the right decision when to stop. So, how much engineering to put in and why not gold plating, having good quality code, low bug count, high testing, coverage. For me, performance is more about exercising good decision-making, good decisions as an engineer adhering to good engineering practices. And then, working on stuff that has impact instead of being the fastest, you know? It’s not..

Kovid Batra: Makes sense.

Stephan Schmidt: I said again, if I see someone who takes two weeks for something and I think it should take two days and it takes two weeks, I ask why it takes two weeks. It’s not.. It doesn’t make sense to me. And then, sometimes I’m right. The person is just not fast enough and needs to speed up and needs to get other skills or more training or sometimes a little bit being pushed a little, but sometimes I’m also wrong. There’s quite good reasons that it takes two weeks. And then if, if product comes to me, VP of Product and says, “That’s taking too long.” And I’m convinced that two weeks was totally fine. Then I say, “Oh yeah, totally fine. That’s how we fast, how fast we are.” You know? So, yeah.

Kovid Batra: Got it. All right. I think, thanks a lot for all the knowledge that you’ve shared, the insights that you shared with us. It was an amazing, amazing talk. Would love to do it one more time on different topics. Thank you so much.

It was really a pleasure having you, Stephan. Thank you so much.

Stephan Schmidt: My pleasure, Kovid. So, see you next time.

Kovid Batra: Thank you.