Building Unstoppable Tech Teams with Vasileios Fasoulas

Hello, Wes. Welcome to the show. How are you feeling?

Hi, Mike. I feel very well. Thank you very much for inviting me. I'm very happy to be here.

Good. We're very glad to have you. I mean, the topics we have right now, it's going to be amazing. So before we kick off, Wes, do you want to tell us you know, who you are, who's Vas, how you started the journey in the tech industry.

Uh, that's a long story, but I'll, I'll keep it short. So I was a techie since I was single years old with old computers, grew up in computing. I did my bachelor's and my master's here in the UK, and somehow I landed up in the last 15 years working in digital media agency space, always in tech platforms backend. And throughout this journey, the last few years moved more towards, uh, product and platforms, worked for F1, and lately I found myself in more in the startup and scale-up world. So today actually is my second week in my last organization, Heat Geek, which is a company that's creating a digital marketplace for heat pump installers and homeowners. And our mission is to do our bit for the planet, and essentially reduce carbon emissions at national scale.

That's a very noble mission, and congratulations on the new role, Vas. You know, I hope it will go well. And as well, I know how these first 90 days goes. There's so much information always to take in, you know, and you're inheriting a team and a new business. So all the best with this one.

Thank you. Thank you so much, Mike. I think change and learning new things comes hand in hand with growth and being in tech. There's no way around it. If you don't like it, I think somebody shouldn't be in this business.

Good shout, good shout, Vas. And we just have, you know, good topics to discuss today, which, you know, hopefully aligns with your new role. So we're talking about this trio which we all as tech leaders have, which is our package or our knowledge of engineering, which we bring to every role. And that's, you know, always growing. We have communication on the other hand, and as well You know, there's just pure management of, you know, people and a product and everything which comes with the role. So that triangle, you know, it's always challenges to find a good, you know, balance in all of that. And it's always a trade-off, you know, you're not getting the best in every situation. So sometimes you need to sacrifice something, you know, depending on your priorities. So let's dig into this. Well, so let's just concentrate on your maybe engineering background and how that plays into your role. If you would share, you know, an instance where your pure knowledge of like coding and infrastructure and, you know, that tech knowledge actually helped you to directly contribute to like strategic decisions within any of your businesses you work for.

Absolutely. There's a couple of instances that pop to mind. I think probably the most monumental one, and I picked the word carefully, was an instance where it was a a company organization working in a big B2B replatforming project. There were multiple partners and clients who have distributed teams across multiple countries in a microservice architecture. And you can imagine there was questions about ownership of domains, about technical designs and so on. So part of that is designing a transaction and booking system for orders, but it wasn't the typical ordering system. So you go to Amazon, you put 10 items in your basket. Here the domain was such that you have an order that have 10,000 items in your basket, and this had fluctuating prices, dynamic prices that you need to validate. And long story short, uh, the proposed design by one partner was this was done in an async and blocking way, at least to begin with, and then change it. And, uh, myself and my team leads, when we heard about it, and we looked into it, we said, this is not going to work. It's not something we could improve later. It's just fundamentally the wrong design. And it's not about being right or wrong. It's about what is the implication to the business. If we had done, if we had gone down that road, I estimate we have wasted a month to 6 weeks of additional development for everyone in the team, or should I say the number of squads. And I fought really hard to sell to the business and to the end client the way why we had to go with a different design right from the start. We did went with the alternative design. We had trouble with implementation and making sure that it's fully optimized, etc., even with the revised design. And although you can't possibly know 100% what would have happened, again, And again, my estimation is this decision, this strategic decision based on engineering background, probably saved us maybe 6 to 8 weeks worth of development, which, you know, correlates directly to a lot of money.

That's so close to my heart as well. Making the wrong technical decisions and paying later, it's such a common picture in engineering. So that was where effectively your pure technical knowledge helped to, to make a better decision. Do you believe this is necessary for a, for a tech leader to actually come from this hands-on engineering domain to be able to understand these situations, or would you say that it's enough to sort of—

it's a good question. I think the answer is it depends on the nature of the question and the people you surround yourself. So you might don't have the knowledge yourself, but you have strong technically people that you advise and they give you counsel. I think to use this as an example, I think as a leader, the, the main thing to understand in that context is, is this a Type 1 or a Type 2 type decision? Type 1 decisions are the ones that have to be very considerate. They're the ones that they can be essentially going down one-way street. It's very difficult to reverse. So you need to approach them differently. Type 2 decisions are things that it's easily reversible. And one of the biggest mistakes I see in organizations is people treating Type 2 decisions as Type 1. And that leads to inaction, that leads to overthinking, that leads to analysis paralysis. So sometimes it is okay to pause, take a step back, analyze a bit extra, collect information before you take these strategic decisions. But even then, you will never have the full picture, you'll never have the full information. So I'm a big subscriber of the theory that once you get about you know, 70, 80% of the information you need at this point, you need to make a decision because not making a decision— indecision is a decision in itself. And I've never seen it working very well.

Yeah, it's not. And very often when I go through organizations as well and when we talk with leaders, they have a KPI or almost like a cultural element which is called decision velocity. So it's trying to tell people that, you know, don't dwell on too many details. Like, you know, make a call and make sure you stick with it and, you know, you go with it. So coming back to Type 1 and Type 2, do you— like, how do you distinguish between— like, let's say you get your, your details, like, what's a Type 2 and what's a Type 1 for you? Just giving an example.

Well, Type 1 decision, let's say, bring it back in the world of startups, for example, choosing some— something fundamental, choosing your stack or choosing your cloud provider. It's very difficult to reverse. It's not impossible, but it's very difficult to, to reverse. And you might want to consider what comes next and having a path to, to change. Also, a lot of decisions are not mutually exclusive. It's not A or B, but it's A and B. And I've seen this a lot when there's considerations about Do we buy or do we build? And people treat it as mutually exclusive, while the reality is software development is integrated over time. And what is right for now is not going to be right for down the path. So if you think that I've done a decision, I've done and dusted, and I'll never have to revisit that again, I think you might be surprised. So, uh, I think total cost of change and What-if scenarios are good tools to, um, to understand what type of decisions you are. So if you're asking, what if XYZ happening, do a little bit of forward planning and find out that, you know what, for those 3, 10, 50 scenarios I identified, if they happen, my tech decision, my architecture would probably be able to cope with that. Then I think you understand that you're okay. But if you find out that it cannot, then you should ask yourself, how easy is it to change? And that will kind of inform you, are you more towards Type 1 or Type 2 decision?

It is a risk management in a way, isn't it? Like, effective.

100%. It is, it is a risk management. And that's another way of looking at it. How risky is it to make the wrong call in this decision versus how risky it is to do a different call? I mean, what you're going to have for lunch, right? It's Type 2 decision or trying a new restaurant. It's a Type 2 decision. You don't like it, you don't go back again. You know, pretty straightforward.

Yet building a family, that's probably Type 1.

Definitely, definitely. You know, choice of partner, family, all those big decisions, they're definitely Type 1 decisions.

Okay. So let's say I'm in this situation now where I made this Type 1 decision and it's actually not what was on the table. So now I need to go out and communicate this and get the buy-in from our stakeholders, from my team. Any tips from your perspective, Waz, of how you communicate effectively in the sense that, you know, the team understands what you're saying and they go like, yes, I feel like your decision or your chosen path is actually, you know, better or more suited for the situation than what we proposed?

Yes. So just to clarify, are you asking if someone made a Type 1 decision that proved out to be wrong and they want to reverse it?

Yeah, let's say that.

Yeah, let's say like that's an interesting one because it can happen, right? No, no, no one can be right 100% of the time. I think in those cases it starts with humility and acknowledgement. The worst thing you can do especially if you want to engage with stakeholders and get buy-in and get the support, is to try and muddle the water and say, well, yes, we did this, but it wasn't my fault, it was someone else, we had incomplete information, etc., etc. It's better to say, uh, we, we made a bad call, or the circumstances have changed. That's the other thing, because just because a Type 1 decision doesn't work out, that doesn't necessarily mean it was a bad decision in the first place. It might just mean that you need to evolve. So I think that framing on why this decision does not serve the organization any longer is very important. And differentiate, yes, it was a bad call because X, Y, and Z, and what we can learn from that. That's hugely important. Otherwise, you'll find yourself in the same situation again and again. And the second thing is, yes, we did the right decision, but it didn't work out because the world has changed, circumstances changed. What do we need to do now? And having a path to do that. I think if you go to any stakeholders and say, we have a problem, we need to do something, and you don't have any hint of a plan, any hint of what's the alternative, any solution, I think it's difficult to build trust. But if you want to buy, uh, to get support and, and sell in and saying, look, don't worry, this is an issue, but we already have a plan. This is what we, we're going to do for, let me talk you through why is the right thing now? What assurances do you need to bring it back to the risk management point that you raised and how can we all commit and support and make that happen?

Okay. So effectively, a set of things you would do in that communication piece. How do you like to approach this from your perspective? Is this like, you know, you would write a big email, you know, send a memo? Would you bring people in a room and make a presentation? It's like, how do you make sure that, you know, the message is effective? Like—

A very, very good question. In many ways, it will be kind of all of the above, but in different sequence and subject to the organization, right? So it's hard to obviously to talk very specific without having a specific example and organizations' cultures and mileage will vary. But I think always in important communication is good to be done with empathy and done in person so people can understand. I definitely also think that This should be followed up with an email or any system that you use. So you're saying, this is the conversation, this was agreed, or present the facts. Ideally, write a document with problem definition, like, this is the problem definition. So even if you have the conversation and people potentially misunderstand or do not fully grasp what you are trying to convey, then they have something to refer to. And ultimately, I believe it's It's your responsibility, my responsibility as the person who broadcasts the message to make sure that the right message goes to the audience. It's not their job to understand, you know, what needs to happen and why.

I love that. So you basically will get people in the room, you will present, you follow up and just make sure, you know, things are getting—

Exactly. And you might have to do it in different levels of organization depending on the type of problem. You might want to do it one-to-one with some people from the executive team, Maybe it then cascades down to tech leads and so on. And at some point, which is also very powerful and should not be neglected, it might be an all-hands. You might, you know, reveal the issue and more importantly, what you're doing about this as an organization to all people affected, the whole organization, if appropriate.

I like that about what you're doing. I feel way too often We're getting problems handed to us without any potential solutions or, you know, solutions in play or even theories about solutions. So when you have one-to-one or let's say someone's coming with a problem, you know, it almost becomes like, hey, here's my challenge, you know, I'm going to give it to you. So can you just sort of go and fix that for me instead of like, here's my problem, this is what I'm proposing as a solution.

Exactly. I mean, if you're just giving, here's a problem, there's, I don't remember the name of the theory or the analogy, which is essentially everybody comes and leaves a monkey in your office. And then at the end of the day, you end up with 10 monkeys. So that's not quite what you want. And also, it's not very helpful. I think if people try, and even if it's wrong, even if it's not the full solution, but at least show that they've done something, they've attempted, that gives you some common ground to help as a leader. And support them and say, well, okay, this is a good starting point, but have you thought of X? If they just tell you, this is my problem, and you give them the solution, and I guess that takes us into a bit of the mentoring space, that is not beneficial for them. Yes, they'll solve the problem today. Yes, you gave them a fish, but they'll never learn how to fish.

How important is the mentorship for you, Vas, and as well, you as a leader, how do you make sure that you mentor your tech leads or just people, you know, who report directly to you to, you know, get these skills. You know, even this framework or ways of communicating which you just discussed, that, that for me is a skill. Like, you're not getting born with it. Like, you need to go through the situations. Maybe you read the book, maybe you go through the courses, but you need to learn effective communication. And then you, you know, you likely want to pass that to someone else, so you're getting the whole culture just getting better. In your view, like, mentorship, how important is that?

It's, it's very important. I'm very passionate about it, and I'm also passionate because I have benefits from that myself. So it's not about mentoring people. Sometimes you are the mentee, and in some ways that helps you to see both sides of the fence. So a couple of years back, for example, I volunteered for Multiverse, which was a mentoring organization. It's something which I want to do again. I'm doing this unofficially within my organization or with friends. So we've changed time to mentor colleagues. And it's exactly what you say, because you can always get a book and you can become a better Python or Golang or Java developer and so on, because you can practice it. You can practice it, right? You can learn, you can do it in almost isolation. But things like teamwork, communication, effective communication, empathy, all those sort of things you cannot learn in a vacuum. You can only learn and grow by interacting with other people predominantly in person, predominantly in real life, although the changing ways of working also have shown that there are ways and it's an evolving challenge. How do you do that in a remote-first environment, in a hybrid environment, and so on? And that's a different chapter we can pick up separately. But I think being approachable, demonstrating things, and being open is one way you can mentor because people often do what they see, right? So the best way to instill something is to lead by example.

I love that. Lead by example. It's such a simple thing, isn't it? It's just, just do what you expect others to do. It's just, it's just that, right? If you want to change elements around your team, just, just, just be the guiding light.

Exactly. You need, you need— and also, if you need to do a change in the organizations, you, you have to be the change yourself first. You can't expect everyone else to change while you, you're not doing it yourself. Yeah, just not gonna work.

Simple concept, but I, I see that being done so often and so wrongly, where the apex of organization, you know, put some memo out or expectations out and, and just acts differently to what they put on the table. And then, you know, a couple of months in, you know, they ask why our, you know, change management doesn't really work. It's just because you're not doing it. Simple as that.

To me, that's actually the worst thing. You emphasize a behavior that you want, but you do something completely the opposite. There's no better way to undermine it.

Exactly right. So very often, in my experience at least, there's a, there's a misunderstanding, lack of context, which often leads to conflict between engineering and product, or a lot more sales team, right? Because sales team effectively, you know, they always are the team, you know, they bring the revenue, they always are at the pulling or leading role or space, right? So they bring the requirements back to, you know, product team and engineering, and you need to build something. And they go like, look, you know, we need this because we need to get this market share. And then in engineering, you go like, well, we can't do that. And there's many reasons because of that, it's going to take a long time. And that situation always— not always, but tends to lead you to some type of like head bumping and, you know, conflict. Did you have experience that? And if so, like, what's your way of getting that sorted out?

Yes, absolutely. What you're saying is, I think, happens in every organization. I think it never ends. In many ways, I think there's a healthy friction because it's kind of demand and supply. You need to go out, you need to get the business, and you need to sell new features and so on. And that makes sense. And you even have situations which I have seen, which that have features being sold which haven't even been built before. And this is because you secure a deal, a contract, something which is of strategic nature. And that's, that's understandable. But then you need to bring it down to reality. And this is where some honest dialogue and some compromise needs, needs to happen. Because let's say you overpromise. First of all, my rule is never to overpromise. If you overpromise, by definition, you will fail. It's better to underpromise and overdeliver. But again, in the sales context, it's, you know, you sell the moon on a stick, it's understandable. So when you need to corral the organization to make that happen, this is where you need to make some healthy conversation and trade-offs. So you can't, if you promise 10 things against 10 different clients, then at some point you say, look, we have finite resources, you need to be honest and tell me which is most strategic. Which is more important, which are the clients and I have worked with people in sales as well, that they've been really good at doing that and pushing back on certain clients. Because again, not everyone will be of the same significance, the same spend and so on. So there needs to be a bit of give and take, a bit of recalibration. And I think the way to approach this is put on the table the why, what would it mean if we were to divert X amount of resource to deliver this. That could mean it has those 5 implications. So I think saying just we can't do this, it's not very healthy and it's not very constructive unless you say we can't do this and we can do X, Y, and Z. Again, bringing back the solutions and options because then you give them a choice, you give them a Chinese menu, so to speak. What do you want to do? And even that is not my way or the highway, these are the 3 options. There might be some give and take. What if— I think this is where people need to get together, can be very creative and brainstorm and identify those unique combinations, if you will, that, that hit the right balance of all the stakeholders to, to find something which is acceptable to the organization.

What's better, get people in a room As in people who will do the project, you know, maybe it's team leads, maybe tech leads, with the salespeople and have some type of alignment session? Or, which I see quite often in bigger organizations, you have middleman positions like, you know, project managers, PDMs, you know, who effectively become this middleman. They talk with commercial and sales and they try to bring the message to engineering. In your experience, you know, is there a preferred way how you like those teams to come together and hash things out?

In my experience, there's a few factors in that. So obviously, the scale of the organization, the teams, if, again, if they are local, remote, they could be even based in different continents, all those combinations come into play. But I would say, on a side note, my job as a leader, and I think even at intermediate levels as the team leader and so on, part of the job is to be the umbrella, is to insulate the team from this fallout. And therefore, those people in these protected positions, it's their job to be the first line of defense and try to sort this out. I would not necessarily expect straight away the, you know, a middle manager or even junior people in sales that made an amazing sale to discuss with a junior engineer and say, hey, why are you not doing this? Or direct message in Slack, because that will lead into chaos. Okay, so I think it needs to happen a bit at the, at the high level first to identify where this misalignment came from and how we can tweak it, and then it will progress down. At the same time, I think bringing back to communication, I think it's very important to keep everyone informed. So it comes down to responsibilities, right? Who is accountable for addressing this? Who is not accountable, but they need to be informed, who needs to be consulted, and so on. And I think playing with these roles and responsibilities is paramount on getting the right mix of people. So it doesn't feel that this is a decision made in the ivory tower and impacts everyone. And on the flip side, it's not something which is everybody's involved, everyone's consulted, everyone's accountable, and therefore no one is accountable. So you need to hit, again, the right spot.

I feel like this, when you think about Dunbar numbers, which effectively is a concept around connection nodes and how information flows, you know, the more people you have, you know, the more connection nodes you'll have. And I see this being done very often quite poorly in the sense that, you know, there's a, there's a one person accountable to spreading the message and, you know, that person being the middleman. So you have, let's say, you know, a big range of product people and salespeople. Which reports to one person, and that one person brings back to development teams. If that one person is not that efficient with the work, or he's just not good at the role in general, like, all of these layers start suffering, and there's a lot of people which not getting the message, you know, they lack information.

And just what you're saying is, is very true. You start having like Chinese whispers, and this is where I think important messages like, like this, it always helps to be— first of all, you communicate in many ways, in many formats, and I have seen almost no problems for overcommunication. It's almost like every business problem you see, it's from lack of communication. The penalty you pay for overcommunication, if you get to that point, is very little. And so therefore, those kinds of messages are very good to be reinforced by different people. Why not include a decision in newsletter or a Slack message, whatever you use in the organization, that the CEO even signs off as an FYI, this decision. It doesn't need to be the full detail, but it shows to the organization at what levels this decision has been taken and been signed off and so on. And it's not, well, CEO said this, but then it went down to the executive management and it went down to the team lead. And before you know it, you hear something completely different.

Exactly. Very good shout, very good shout. And I resonate with that quite, quite strongly. I was on the receiving end, and I want to bring back to one point you said in the beginning when you talked about sales, is that sometimes sales make a sell and promise things which don't exist, and then they go back to the team and go like, well, we need to build this now. And I've been in that situation myself where You know, back in the day I was, you know, a hands-on head of engineering and, you know, I would sort of deal with this and it's always such a like, ah, situation, right? I don't like this. Like, you know, I don't know why I don't like this. Maybe because no one talked with me and, you know, made that promise or maybe because, you know, I'm getting this project now which I don't really like to do. Like it doesn't align with what we like to do in engineering, maybe. You know, I had a set of promises, you know, to the team towards their career progression, and now we're bringing this in and it's just not— it's not just not aligning. So suddenly I'm in this challenging project. Is there a way you do when it comes to motivating people and just, just, just getting them in the right mindset to, to go through these projects which just doesn't feel right?

Yes, I think, um, it's not only projects that came out through this route. I think A lot of projects can be demanding, can be a little bit like a marathon, which at times you feel is dragging too long, you feel it's like you're gonna give up and so on. So my take on this to motivate the team is always to remind them of the why. It's like show them the prize at the end of the road. So to expand on this example, the project came in in a wrong way, fine. I think it's important to highlight what is the importance of that project to the organization, and I don't think it's just, oh, it's revenue, but what does this mean? You need to relate this to people's potentially personal objectives or even career development, but also, you know, benefits. To put it very bluntly, if a project secures you a strategic renewal with a client for another 2 years, right? So this gives you some sort of financial stability. And again, in startup scale-ups, that's quite important. So showing this to people and showing, for example, that this is extending our runway, or this project is the one that turns us from, you know, we're in Series A, now we're actually becoming profitable. And that means that we can invest more in people. That means we have more flexibility around doing other things we want to do in the organization. I think that tangible benefits will, will help people, you know, push, push through it. At the same time, one key message I believe is important to say, it's not— we're not asking people to do more with less. I think when you do that, I mean, it's possible to do it, but you can do it only for a horizon of time, you can do it for a period because there's a crunch and so on. But otherwise, you will end up in a situation leading to attrition. So if you're telling people, yes, it's a tough project, yes, we know it came the wrong way, but this is what's important to do it, and this is how we are going to support in this. So maybe the business can do some, some other things. Maybe some people need to get training in order to be able more effective in this project. Maybe this day and age it is about utilizing AI more, for example, and increase efficiency in, in that way. And there's, there's, there's a lot of ways you can, you can attack it. But again, I think it's— if you give this to people as fait accompli without any ways to, to feedback into this, to be in order to be a little bit involved and even suggest how we can tackle this project and what trade-off needs to happen, I think the more involvement you give to people, the more likely they are to essentially to, to commit to it.

So it's just, um, again, it's quite simple, right? It goes back to communication and it's just narrative and positioning of the project rather than here's a project, get it done. It's just like, you know, let me explain why this is important.

Exactly.

It's just how you package it and deliver to the team.

Having said that, there is also another element, which is you have to bake into the ways of working and understand, and everyone from the people into understand why this is an exception. Because if this is an exception, fine. But if this exception becomes the rule, contrary to what has been agreed, contrary to ways of working, then it would be, I think, right for the people to say, hold on a sec, this is not worth doing. You know, we did it once, we did it twice, we can't keep doing this thing. And again, if you as a business leader, as an organization, if you keep doing this, you will find yourself with high level of attrition. And essentially, yes, you will be delivering these projects, but you will burn your teams to the around. So the net effect probably is going to end up negative.

Very good shout. So, uh, they sold this, right? So come back to that example. The salespeople overpromised something which didn't exist. Now we're in this project. So they likely gave dates as well, right? They went like, yes, you can have this feature, Feature X, and you can have it in the next 3 months. And, and one of the baked-in metrics, which, you know, engineering people don't like. It's actually finishing the projects on time and in the budget. It's just, it's just what happens, right? It's just how commercial looks at the deliveries of the project. But outside of those two things, which is, you know, making project happen on time and in a budget, what are your favorite metrics to look at engineering teams and go like, this team is doing well? This team could do better in certain areas?

True. Um, it's a good question. I think first of all is naturally, especially an organization that you have multiple teams or multiple squads, everybody can recognize, and if you ask them very instinctively, they will tell you Team X is doing the best, or Team Y is, is, is the worst team, or not doing so well, and so on. So first of all, it's worth looking— it's like Again, look at the things that they go well, the teams do well, and why other teams do not do the same. Is it ways of working? Is it people? Is it experience? What is that? That's the one thing. Then in engineering, we tend obviously to look at things like velocity and so on. So you can compare teams and say, what's the velocity of the team? Which I personally, I don't really agree because I always find velocity being a little bit abstract. Slices of units over the same time. We all have 2 weeks to do a sprint. You have a resource profile. If I deliver 10 points or 1,000 points, it comes down to how I slice my tickets. And you can— the system can be gamed and all that. So for me, um, I play a lot of variance and importance to the qualitative elements. So what's the sentiment of the team? How the team is feeling? And so on. Obviously in conjunction with deliver, right? It's not like we're feeling great but haven't delivered everything. That's or nothing, that's not the point. And one metric which I really like, and for me is very telling, is outstanding items from retros. So imagine the team is not doing well, right? The whole point of Agile is to introspect, reflect, and see how we can do better. It's to be agile, to improve things. So you don't do so well, you have low velocity and so on, but you identify 5 items, let's say for argument's sake, you need to do on your on your first retro. And second retro, another 5 items, another 5 items. And suddenly you're in sprint 6 or 7 in a project, and all you have is 35 outstanding items in retros, and you haven't done anything. Now, to me, this is a big red flag. Now, conversely, if you are not finding, or you have a limited number of items in your retros, and more importantly, you clear up your backlog of, you know, retro items, if you will. To me, that's a green flag, shows that the team is improving, is continuously improving. And as long as you're improving, even, you know, small baby steps, you're heading the right direction. And then you could have a different conversation about, with the team, with the product, and so on. If you want to improve us faster, what's the investment required to do? Is it, for example, in the past, we've had situations where we paused feature development, to dedicate a larger part of sprint on tech debt around infrastructure deployments and so on, and having a view on what that benefit will be in terms of speedup and velocity afterwards. So I think for me, these are the main things.

Coming back to velocity, Vas, what if you do Kanban?

True. Or there are teams that they do like Scrum Bands. So there's lots of variations. Exactly. Well, with Kanban, obviously, it is a work in progress. That's quite key. You want to minimize this. And I think there's something which applies both to Kanban and obviously more traditional Agile and Scrum is cycle time. Because ultimately, you start, if we think about this, you start with an idea perhaps. And you start and you end up with delivering value to the customer in production. So how long does that take you? Obviously, it will vary with the feature. So you could be delivering a whole homemade video delivery platform, for example. That's a big epic that would last, you know, sprints, maybe even quarters. Or you can do something small but delivers incremental value. And to me, it's, it's that sort of smaller incremental value how quickly you can go from the ideation to analysis, design, implementation, testing, all this, all this cycle. And leads back to what we're talking about, decisions and fast decision-making, because fast decision-making between all of those things will shrink your cycle time. Again, in my experience, when we have, you know, huge delays in cycle times, it's typically because things get blocked. And why things get blocked? Because indecision, because of something happened in this indecision, how to solve it, uh, because dependence of third parties, which again links to indecision too. Perhaps this is not the right item to be working on now and needs to go in an icebox because we know that our third-party dependencies, they're not mature enough to proceed now, and, and so on and so forth.

I really like the, the sentiment analysis which you mentioned when it comes to just gaging the team healthiness. And I'm actually a fan of Spotify's Squad Health self-assessment, which is a simple thing I do like once a quarter with the squad where you, you know, you basically rate from 1 to 5, you know, are we having fun, you know, how's our release processes, how is our codebase looking, you know, how's our team processes, communication, and all of that. And just, you know, effectively getting an average. And on top of that, I do like measuring burnouts and just basically asking the guys, you know, how you guys feel, you know, are we at the edge of 100% having a self-reported sentiment of the teams?

I think there's a lot of organizations now with DORA metrics and so on that they take similar approach. Of course, because it's self-report in different teams, there is always a bit of a, you know, to take with a hint of salt. But I think on the negative side, when things are not well, you will know. Probably when things are— and it's human nature, right? We complain a bit more when things are not going well. We're not as vocal when we celebrate our successes or when things are going really well. So I think this is something to factor in. But I completely agree. For me, it's also so simple as you did the sprint demo, you're out with the team, you're having a social event and so on. Just gut feel and sentimentally, the people that will come and have an offline chat and say, "It was a good sprint. I really enjoyed it," and so on, versus no one coming to talk to you versus people coming and talking about, "Oh, this was really tough and we did this." To me, that in itself is another gauge of health.

It just goes back to listening, isn't it? It's just like if you listen and you know what you're listening for, you will get what you need. So, um, so let's say, you know, we have a good team which suddenly becomes not as good as a team, or maybe we have a not as good as a team which suddenly becomes a good team. So some decisions were made, you know, maybe someone was taken away from a team, maybe a new person came in, maybe it's a process decision, maybe it's tools, something has changed and that came from, you know, from leadership. Do you have any examples to share where a leadership decision actually made things worse and where leadership decision actually made things better?

I'll start with the better, for sure. The better leadership decision, improving the teams. So what I've done not too long ago was the team was quite flat structure and the team was quite large. So it had gone to probably the limits of how much you can push the squad. You're getting to 12, 13 people. It's a little bit too much for a squad, even with a flat structure. So the decision there was to, I mean, not rocket science, break it into two squads, introduce a bit of a Scrum of Scrums, but also, and that's important, introduce some hierarchy. So for context, they were all senior developers, so there wasn't that much of technical difference, but we introduced a hybrid role of what we call team lead, which was a combination of team lead and people manager. And in some ways, that person was responsible for interfacing more with product and be the single voice of the squad, but also kind of insulate the team from, you know, the business decisions, the commercial decisions, if you will. And that worked well, because it removed the overhead in communications. And it also removed, oh, I don't know who to speak with for who. So basically that made the team more efficient. I'm trying to think of an example of management decisions where we did things and had a negative effect.

Maybe it wasn't your decision, Vas. Maybe it was a decision which affected—

Yes, yes. I'm looking more broadly. Let me answer this in a slightly different way. I think the one way you can, you can remove that danger is to treat things as experiment. So nothing is final, but things, especially with team changes, it's like, let's try something different. And let's evaluate and see how are we going and then be bold and say upfront, if it doesn't work, we'll reverse. So where I I've seen things not working. It's more when we're doing X and it's like, it's done deal. We're not going to review it. It's done. And so on. Because precisely how do you know that the team is improving? How do you know it didn't make things worse and so on? So I think that's for me the biggest red flag in this one.

Okay. And it does really connect up everything we just talked about. You know, you're making a decision because, you know, you want to try something. So you're reframing your mind, going from, ah, I'm afraid to make this mistake, to actually I'm doing an experiment and at the end of it I'll get, you know, outcome, I'll get the numbers and I'll be able to conclude my experiment. So you're making that decision velocity in play, you know, you're making a call, is it T1 or is it T2? As long as you make sure it's a T2, so it's reversible and it's a small iteration towards that, you're just making that experiment and rinse and repeat. So it's just all connects up quite well. And I want to share one of my stories, which is why I like the self-assessment numbers and just be, you know, tracking them as well, is that when you make changes to the team or processes, you actually can see, you know, how the team really self-assess in, in, in given situations. And my story is that I had a team which effectively was dysfunctional, and everyone was very pessimistic. So what you mentioned about taking everything with a of grain is that there's a bias baked into it. And, you know, once people are happy, they will really emphasize of not being happy when it comes to self-assessment. And when they are happy, they will be really on par of how they feel. It's not going to be overemphasized how happy they are. So, so, so the negative pull is always there. But, you know, the average numbers were very, very low. And then I just took two people which were effectively quite toxic to the team, and nothing else changed. Like, the processes didn't change, you know, we didn't introduced new, you know, like new tools, which just took the, you know, toxic people away. And the next self-assessments were 2 times better. Right.

That's— thank you for sharing that. I'm not surprised at all because it's what they say, you know, if you put a bad apple, you know, together with good apples, you know what's going to happen. And conversely, if you remove it. So I think that's, that's the case of that. And people, people is very important. I would say and thank you for giving this, this, this context. Team dynamics is important. You could have the very same people, but structure them in different teams because of ways of working, because of being someone being neurodiverse, and so on and so forth. And you could end up with much better allocation of people, much stronger teams. So when I am recruiting people for example, I'm always thinking which team they're going to be, who they'll be working together, and how they can complement the teams. And it's very important to look at strengths and weaknesses because even if you get a very strong person, or it's like footballers, right? You get the best footballer, if you get 10 of them, you're not going to make the best team. You actually need a slightly different combination of strengths and weaknesses to actually make a team.

Yeah, very, very good shout. Love that. So, um, before we move to another topic, which, you know, we'll talk about the talent acquisition— not acquisition, sorry, just finding good people in the market and making sure they don't leave your businesses, putting bluntly. So before we move to this one, in the spirit of the show, we have this question which we ask everybody. In your mind, or in your experience, or in your view, what is one most important thing for any tech venture when it comes to growth?

People. It also— it all starts and ends with people. If you think from, you know, startups, which you start with, you know, probably 3, 5 people, and as you grow, I think people is the most important thing because ultimately this is what you compete with. You know, resources and capital, yes, you can go to investments, get it and so on, but so can other people. But it's the people that you have in your company are the people your competitors will not have. And it's those people that will bring the knowledge. It's those people that will bring you the right processes, you know, the right decision-making and so on. So you should always pay, you know, the most attention to your people. It's people that drive software that hits the world.

I love that. That's a good saying. I'm going to use this on like a thumbnail. So you lead us very nice into our next topic, which is, you know, it's all about you know, finding and retaining top, top engineering, or maybe not just engineering talent, you know, in your business. So to kick this off, you just started a new role, right? So you, you effectively inheriting a team as well. So do you have a way of how you approach of, you know, inheriting a team versus actually building one from scratch?

Yes. Uh, well, first of all, I think it's very rare almost unheard of for people to build a team from scratch unless you actually start with a startup, right? There'll always be something. And it might be people, you know, again, you join the role, it might be in-house, it might be you work with the agencies and there's an offshore team that you're hired to bring it in-house and so on. So there's always something to work with. So nobody starts with a blank canvas unless again, you're the first person and you have a startup, in which case probably you start coding the solution yourself. And then you start looking who you're bringing in. So again, people, I think, understanding, getting to know people, showing empathy, understanding what drives them, why they're here, why they are on the same mission, it's paramount. And then really understand strengths and weaknesses. So for example, I met people who are, you know, great software engineers, but they haven't been so great on the subject matter expert on whatever company working in, and therefore you know what to tweak. Or conversely, you have people who are fantastic subject matter experts that could have, you know, even PhD in the topic, but they didn't have, you know, they don't have 10 years of software engineering experience, but they are, they're keen, they're willing to learn, they're interested, they have all the right, uh, attitudes to, to get there. And it is a, it is an investment situation. It's, it's a growth. So you need to understand, I think, in your team, how can you benefit everyone, not necessarily by giving them the same thing, but giving them what they need to get to the next stage, whatever that might be for each one.

Okay, I love that. Do you think remote has a selling power right now? So I'll give you context. Before COVID you know, a couple of years, so we're talking like 5 years back, remote was quite, quite rare, and it was a very strong selling point when businesses were looking to attract talent. They would go like, we'll give you 1 or 2 days remote. Like, that was very strong outside of, you know, all the perks and salaries. That was, that was a big selling point. Do you think in this current market and moving forward, remote has that selling power, or is just expected that businesses will have remote to some extent?

Uh, I like how you position this and you're right. I remember a few years back I had some friends that they're working actually remote full-time. Uh, it was very rare. It was very specific niche contractors and so on. And that was their way of working. This is very small percentage. Uh, post-COVID things have changed a lot. Uh, I wouldn't say that this is an attraction anymore, but I would put it the other way around. Not having a hybrid environment or remote in some cases, will actually repel certain people because it's human nature. It's very hard to take back something you've given to someone. So, you know, that door has opened. People have seen the benefits. And I think even big companies have seen the productivity gains out of this, even environmental impact, you know, less commuting, all those sorts of things. And it does work. Now, and that's why people want it. Having said that, I have to be frank and say I sympathize, and I think it's incredibly difficult for people to work either fully remote or even hybrid in the beginning of their career and as a genius. So for people who have done the whole going to work 5 days a week, they have had the experience over the years to work initially with remote, as in you have remote teams, like onshore, offshore, and so on, that have been through the traveling and so on, for them, it's a lot easier through that experience to, to be able to build that rapport and build connections in the hybrid model. But someone who comes straight out of uni, or they're in the first, second year of experience, not going to the office, not meeting people, you know, 3 times, if not 5 a week, I think it's hard. It's hard for them. And this is why my personal observation, I don't know if it's statistical, but in the UK, I see a lot of companies gravitating now to probably 3 days at the office, 2 days at home, or the reverse as a hybrid. But I also see some companies that they try to instill the 5 days at the office, they are running into recruitment issues. Because people think like, you know, they want that flexibility. They don't want this taken back.

I love how you positioned that sense of taste. Like people felt it in like very tangible way what that means to their lives. And that's going to be very hard to convince them to give it away. And yeah, the hybrid for the synchronous team, which means, you know, we, we live in the same city or we around the city, but we operate like in this, you know, same time zone, we all online at the same time, you know, hybrid works quite well. But then you have fully distributed teams where, you know, one team is India, South Africa, somewhere in Europe, and then you in UK, the time zones don't match up, and suddenly you become asynchronous team. A lot of change, a lot of what changes, like communication pattern changes, and you know, how you self-organize is a huge question mark, at least for me, because I don't think everybody knows how to actually do remote, like not on organizational level but on personal level. Like, do you have, you know, a studio at home? Are you able to concentrate? You actually know how to self-organize, you know, tasks and look at your days and calendar and whatnot. And I feel like companies should interview for that, which I'm not seeing that happening. Like, when you're hiring people, you know, it's always like soft skills, hard skills, but do you actually have a chat about remote? Like, do you ask people how, you know, remote is done correctly? Like, do they know how they need to communicate and self-organize? So for me, it's, uh, I do love hybrid, but it's, it's, it's probably personal, personal preference. Like, I love getting in touch with people from other domains like sales and, and, you know, product and, and customer supports, which some of these are actually not well positioned to do fully, you know, to do full remote. Like for example, sales is a very relationship-driven process. Like people need to come in a room and effectively deals are made face to face. So for them, they're always out there. And if they have a very short real-time ability to talk with someone from engineering, you know, to get the answers quicker than, you know, I'm sending you an email or Slack message, there's a benefit to that. So as a leader, I feel like, you know, I need to be around at least couple of days. But just my take on this one. So, um, talking about general strategies was to attract the talent. So, you know, the remote was definitely a big sales pitch, you know, back in the day. Currently you're saying it's losing its power, which I'm fully, you know, I fully agree with this. It's almost like given, like people expect that. Is there any other things from your perspective, which are, you know, strong factors to send to the market as a, you know, we as a business, we do this to be able to attract the talent?

Yes, I think you are, what you're saying kind of touches a little bit on branding, which obviously it's important for everything. So you have companies that even people outside tech will know. So, you know, Facebook, Amazon, Microsoft, all those big companies that We see a lot of people put it X, Amazon, then LinkedIn, and so on. So just being there gives you some status, or having been there gives you status. So there's that for sure. And then there's companies that could be a significant company, but it's in a vertical that you don't know, or the general people do not know, and so on. So people get attracted for different reasons. But I think how you build awareness of your company, let's say in the engineering and tech space, comes down to a few things. One is you need to be out there. So go to meetups, having a technical blog in your company, go to conferences, meet people, and then through word of mouth, that's important. And then you can also be proactive in you know, for example, recruiting from those places. Don't necessarily wait for people to come to you, build that presence. And this is what brings us back to Peopleware, because when you're describing your company, your values and so on, you know, it's your people who are your best ambassadors. It's your people that effectively, whoever you're discussing with, they'll say, yeah, I would like to work with James. He's a great guy. He knows his stuff. You know, I like how they work and so on and so forth. So for me, word of mouth is very important. And probably the biggest flag of success in this area are people who have left the organization and have come back for whatever reason, for personal reasons, they went somewhere else, they saw the grass was not greener, and they came back because going back to organization, it shows that, okay, you now you truly understand, you have seen elsewhere, you say, yes, I fully subscribe to that. And that's a great place to be.

I love the brand branding positioning. It's absolutely so true that you can leverage big brands in your background. X Twitter, X Meta, X— oh, actually not Twitter, XX. Yes, XX, you know, X Meta and all these brands, you know, that's, that's a very, very strong, um, implication of your knowledge and skill if you were able to, you know, spend some time within those companies because they are perceived market leaders and, you know, they effectively have the strongest innovation in the tech. So, you know, you get—

but I have to be honest here, and I've also seen people that, okay, somehow you ended up with this organization. I think it's unfair to always assume or to say that, you know, a senior person or any engineer coming from those companies is a better engineer coming through a smaller company. I think there can be different types of engineers. They might have been exposed to different things. There is, I think, a lot of bias and assumptions. Because someone could have, in a small organization, could have had a much more impact in their role, could have had a lot more autonomy, a lot more opportunities to take initiatives and grow. While you could be in a much organization, yes, with a very recognized name, but you are just a little box somewhere, and you just operate within the confines of that box. So I'm personally very careful to understand exactly of people's impacts in organizations and not to be swayed by the, you know, the fancy logos.

Yeah, I had pleasure interviewing, you know, ex-Googlers and ex-Metas, and you're absolutely right. You know, at the end of the day, it's a person and how that person learns, how that person grows, you know, how they consume knowledge, how they apply to make it a skill. It's very personal. So that positioning of X big brand doesn't really mean that they will have more skills. But from business perspective, having a brand which attracts talent is definitely a good thing.

Of course, it's a strong asset.

Exactly, yep. So what's your take on perks within like, so let's say, you know, you have a team, you already have people, so they already within, you know, your business and you don't want to lose some of them. How do you look at that, you know, extrinsic motivation, which is, you know, the salary and all the perks, and that intrinsic motivation of, you know, giving them, you know, autonomy and mastery and purpose? Is there a way you do, you know, things sort of your own way, or do you buy into the, you know, the, the general consensus of the mastery and autonomy and purpose?

I, I definitely subscribe to the mastery and autonomy, but I link this to, at least in my head, to learning. I always believe in our profession, learning is probably the most important thing. Learning with an opportunity to exercise, just to be clear, not just I learned and I never do it, but learning through practice. And I think this is what brings together the mastery on autonomy. So if you have, how do you build mastery on something? You do more of it. How do you have the autonomy? You give the freedom, the opportunity, to pick something which is not the status quo, but you want to explore, you think it's appropriate, you experiment, and so on. So this is how I believe it brings those things together. And learning comes hand in hand with career progression, because while compensation is an external stimuli for motivation, if we break it down to, you know, to its essence, typically it's linked to career progression, which directly is why would you progress in your career? Because you learn something, because you master something. And that could come all the way from either engineering or communications or management. It's those things that as you learn and improve, you improve on your career. And typically this is how you justify to your organization or to a different organization for people who move. That's why you get those additional compensation perks and so on. And the reason why I say this is because I found different people react to different kind of external stimuli or, sorry, for motivation. So I've had engineers that have been very keen on, in the startup world, how can I get more shares from the company? They really buy into the vision. They believe this is, you know, the skin in the game and they want to invest. There are other engineers that while they're great, it doesn't mean a lot to them. They don't realize the value that this has. And it's like, you know what, I prefer to have a pay rise. Versus you have people, for them training as in formal training is important. So being able to go and do like an AWS certification or go to conferences. So I remember it was very well received when we sent people to the re:Invent in the US. And you know, was it necessary? Couldn't they just watch the videos after? No, it wasn't necessary. I mean, there is the networking element, but as a token of the organization, of the appreciation of those people, that pays in spades, for example. So these are the things, and I always found out that you can give training, you can have budget for books and so on. Unfortunately, in You know, for the most part, I see people underutilize that budget because the one thing that they are missing is time. So the other benefits I strive to give people is time to be able to use those benefits.

That's a very, very good shout, Vas. Exactly that. Like, if you're not giving them time and you go like, you know, you'll use 8 hours a day for 5 days a week, but here's the budget you can spend on I don't know, courses. When they're going to learn that, you know, are you saying they should be doing this on weekend or they're no free time? You know, they tired.

I believe there's, there's an element of, again, since we chose this profession, there's always constant learning. So people, there are people who will buy their own books and put their own time and do LinkedIn courses and all that. But it's the kind of, kind of meet in the middle where the company recognize and say, we will give you some time that you can put towards study for that exam. And it's a kind of an exchange value because the company gains as well.

Absolutely. Attrition goes down because then, you know, it's a good environment to be in. You know, I'm getting time to learn, I'm getting time to grow.

And those things you learn, you can apply directly. So, you know, by learning new things in, again, AWS or any cloud provider, Google, etc., you can bring it directly into your day-to-day work.

It's a long-tail benefit to the business because, you know, it'll take some time until that knowledge becomes scalable.

What you do now, you you won't see direct benefit. You'll see it 3 months or 6 months down. It's like an investment.

Yeah, exactly. So how do you make sure that, you know, your engineers are actually being challenged to get that career progression happening? You know, is it selection of, you know, projects? You know, maybe how far do you actually go to make sure they're challenged? You know, maybe you have a, you know, a front ender who wants to upskill and become a, you know, full stacker, but you go like, you know what, I don't really have a project like that. Do you go extra mile to find one, or do you just accept the fact that, you know, there might be attrition in that space? It's like, what's your—

very, very good question. Uh, for me, another signs of success of, um, retention in the organization is when people move vertically. So I know people and colleagues that, for example, move completely different disciplines. They move from Android engineers to become product managers, to give you an example, or people that they were subject matter experts, they started as a backend, they found out, well, actually, we're doing mobile development, I'm kind of interested in that. What is the path to move into that? So I think this is where the team engineering comes into place. And there will always be attrition because people will move on for a number of reasons. And then being able to rejig the, the pieces to support as many of those objectives as possible. If not now, at least give them people an opportunity. Say, look, in 3 months' time we're making that change. We think there's going to be a role open to move into, uh, mobile development space. In the meantime, to bring it back into training, and I like to link it with the career objectives, in the meantime what you need to do is make sure you you know, follow this online course and read those two books. And that comes out from your training budget. And this is how you start piecing all those things together to support the team and make those things happen. And trust is also quite important to that one and learning, right? So how do you challenge your team? You have to give them something which is a little bit out of the comfort zone. but it should be achievable within a reasonable time. You can't take someone who has had, you know, to your example, no backend experience and say, I want you to build a production app that does X, Y, and Z, and you need to do it under time pressure because the sales team, you know, signed it. That's not the project to put them in.

Yep. I love that, by the way. That's a very, very strong answer. And how you actually go ahead and do that, you know, in the correct order. So I got one interesting one, um, diversity and inclusion. So we know statistically speaking, uh, if you have half of females within the team, the team tends to perform better. I can't remember exactly where I read this. I think it was in, um, in a DevOps book, uh, I will not remember the title now, but somewhere that it definitely got mentioned. And as the leaders, you know, we will look at this sometimes we even, you know, being sort of asked from HR perspective that, you know, we need to inject some diversity within the teams. In your experience, you know, do you have any anecdotal situations where you actually, you know, go ahead and do that and the team just, you know, suddenly becomes a high-performing team?

I have read similar studies and it was not just sex diversity, but more broader diversity. And I totally subscribe to that and I believe it. But unfortunately, I have never been in the position, and not for lack of trying, to actually hit that spot. So when I'm recruiting, for example, the sad truth is, you know, female engineers is a very, very small percentage in most roles. And my wife is a platform engineer. I have two girls, and it saddens me, this reality. I am maintaining a small hope with the, the whole AI revolution that could be another chance and opportunity to get more women into, that it would democratize this a bit more and we'll get an influx of women in IT so we can actually fill those teams in, in that way. But I'll give you a different, different example on diversity and inclusion. One of the One that stayed with me, which relates more to age, which is another thing that sometimes, and depending on environment, is overlooked. So I had a team member who was at the time in his 60s, ex-university lecturer, and he was working as a developer, or he came and saw Corner as a developer. And what was really amazing is his way of thinking and the pattern recognition of things he has seen that happened in the industry before. So, it was not about mastering the latest Java language and features and so on, but understanding the concepts and the semantics. And we have been through this cycle before, and what did it mean? And it had saved us in that project from a number of wrong decisions, because he had that insight and that experience, which was decades of experience.

How do you—

so that's why I think, and I think that's what the research is underlying, a very homogeneous team leads down to one way of thinking. And one way of thinking will potentially take you down one way, which might not be the way, while a more diverse thinking from diversity gives you different options, give you different solutions, and potentially gives you more things to explore and get yourself out of trouble when you when you need to.

So I absolutely buy into that as well, 100%. The trade-off is though, in my experience, is that you, you're getting a lot more conflict within those, you know, like the more diverse you have in the team, the more opinions comes out and, you know, the more hashing out situations, which is again, you know, you can have a healthy conflict, but that for me is a, is a maturity sign for the team where, where they can come in together in a room and go like, I'm thinking A, You know, you're thinking B, but we're gonna have a conversation, we're gonna come up with a solution which is beneficial to everybody. That's maturity piece. If you have a very young team coming together and it's quite diverse and you have a lot of opinions, I just see basically conflicts all around the place and people tend to go, ah, no one's listening to me, and it just leads to these conflict-driven trade-offs. Did you experience—

You're very true. You're very true. That's where potentially kind of decision by committee is dangerous to try to please everyone. And this is where I think having, you know, one or more, more senior people in the team that kind of corral the team and facilitate that decision-making and educate the team into ways of working and what's, what's the right way of working, what is not the right way of working. And it's not about being right or wrong, but it's about, it's always relative to the values of the company. And also, you don't need everybody to agree to make a decision. There's a lot of decisions which is you disagree, but you commit, which, you know, introducing this to the organization is very powerful. And this has nothing to do with with inexperienced teams. There's decisions going back to sales and marketing and engineering and all that, where senior people, executive managements, they disagree, but they can still collaborate and disagree and commit, and they work together for what has been decided.

Disagree, commit is actually one of Amazon's cultural pieces, as in, you know, you don't need to agree with everything everyone's doing, but if there's a decision, let's just commit to it and, you know, let's see, let's see the outcome of it. Okay, it puts emphasis on a team lead, isn't it? Like, if you have a team then and you have some team lead person facilitating, you know, that maturity of a team, it's a very important role then putting emphasis on, on, on you to make sure that the team, you know, gels and operates well and, and doesn't go off with conflict in the left and right, which then raises a question from my perspective is, do you actually hire for a team lead, or do you believe that a hands-on person who naturally grows in seniority and eventually reaches the point where everybody asks him questions can actually make a jump from being individual contributor to a people manager?

Very good question. I think it comes down to, first of all and foremost, what the person wants. So if somebody doesn't want to be a people manager, and I've seen this a lot, the people who potentially would have the skill, but don't have the interest or the appetite for it, don't, don't try and put them in that position. It's never going to work, and they're going to be unhappy. Also, my personal belief is always try to promote from within as a company. I believe this is very important to, again, bring back to people, work, career progression, growth, and so on. So if there are people who have that aspiration, and you feel that they have this capability or growing towards that capability, see how we— how you can support them. And that brings us back to mentoring. And again, experiments, have them put in this position, even as a trial, Maybe they find themselves, you know what, I wanted to do that, or I thought I wanted that role, but I don't because I don't fully appreciate what it involves. And once I see what this involves, say, well, you know what, that's not for me, and so on. Getting people from external to the organization with more experience from essentially from elsewhere is obviously another vehicle which I've used and I use, but I always try to do it more in moderation because while they bring that skill set, what they lack instead is the culture in the organization, you know, the domain expertise, the team expertise, all the tacit knowledge that you have. So it's a trade-off. What I've also seen work quite well is to do a combination. So grow, ideally grow from within. And then if you reach the position where you need roles, and you don't have enough from within at this point of, you know, the lifecycle of the company, then bring externally and then hire for culture fit.

Okay, that's a very good shout. Um, let me, let me ask you this. Just come back a little bit to diversity, which you mentioned age diversity as well. I took a note, it just came back to me. Um, do you balance senior with fresh graduate within the team? It's like, what's your take? Like, when you put a team together, do you want to have the best, you know, skilled team? So you're looking, you know, to hire for certain hard skills and soft skills. So do you try to balance a senior level and then put in some fresh people within the team? Because, you know, then you have some type of like mentorship, upskill processes within the teams. It's like, is there a favorite way from, from your end?

Uh, it's— I don't have a favorite way because this is very highly contextual and it's very related to the organization. So for example, I've seen organizations that they, they have the, uh, the mentality, well, we have a budget for X people or have X amount of budget. And, uh, again, to the, uh, small teams working quicker, faster decision-making and so on, and they feel like, you know what, we're going to hire more seniors or all seniors. We won't even have a hierarchy. We're not going to— because obviously if you want to have very senior and junior, that means, you know, somehow you're starting having people of in between levels? Because clearly, you wouldn't have a team that having only those two extremes, shall I say. So it links back to the, what is the mission of the team? And what's the potentially the growth vision for the team itself? If you're looking to, you know, a squad is getting too large, you're going to break it into two and so on, then maybe you need to start introducing juniors. I think The reality is that more junior people require more time to be mentored and to be supported. So it's an investment. So you need to make sure you, you have that capacity from the mid people, from the senior people, because if you don't, I've seen this as a recipe for disaster. You're getting very, very junior people, but you don't invest the capacity and the time to mentor them and to grow them, in which case they feel overwhelmed, they don't develop, and potentially that leads to attrition. So you need to set the right environment for the right— for the teams you want.

Okay.

And that could vary by team. So it's a very— I'm afraid there's no silver bullet on this one. It's a very tricky one.

Yeah. Yeah. It's probably was wrong question to ask or wrongly—

No, it's a great question to ask because as organizations grow, you— let me put it in a slightly different way. The other danger, if you make a team that is all seniors, or very senior, is where are these people going to go? How they're going to grow? So you deprive yourself of a career progression. So I always see, and linking back to my philosophy about hiring internally, externally, and so on, and growing people, is the pyramid level. So you're trying to elevate your people, bring them to the next level. And ideally, from externally, you should bring people mostly on the lower levels of the pyramid, and you repeat this, the circle. Do not try and bring everybody on the top of the pyramid externally to the organization. That is not going to be received very well in the organization. And people say, well, if that happens, then my only way to go there is to leave, is to go to a different organization.

Yep. There's a very big financial benefit as well. You know, it is an investment, as you have mentioned, Vas. But as an organization, if you, if you take someone in, in early career stages and you give them, you know, entry market salary, the way you're going to be increasing the person's salary is actually much lower than hiring someone freshly in whatever, you know, that progression is.

100%. I have, uh, I know companies that had an amazing, well, a very clever business model where they hire people pretty much straight out of university, sometimes even helping them or supporting them to go through university on obviously value exchange. Come and work for us X amount of years, we'll develop, we'll grow you, you'll be a consultant, we'll take it to X clients and so on.

Yeah, it's a, it's a, yeah, I, I even seen the recruitment companies do this where they have dedicated, um, business flows where they get fresh graduates, you know, they give them like a boot camp for like 3 months, you know, they upskill in a certain skill and, you know, they give them position which is a junior position in the big companies and then, you know, off they go. On opposite, if you want to get a salary raise much bigger than you would get in your organization, you probably want to change your organization. Just, you know, it goes both ways. So last question was attrition. Someone left and you're doing exit interview or whatever, you know, maybe you're not doing exit interview, maybe you have your own process, but you're getting some feedback on the whys, you know, of people leaving. How do you take that feedback and try to improve your talent retention strategies based on that?

Well, first of all, the exit interview is a little bit Talent Team slash HR. I really want to find out a bit more from the moment I hear, either directly to me or if it comes indirectly through a manager. I want to speak with that person, nothing formal, really understand their thinking. And while in most cases it's too late if people have sent I, you know, here's my notice letter. Most of the time, not always, but most of the time it's a little bit too late to change their mind for good reason. It's to understand. I seek to understand first what is the motivation, what drives you this, because sometimes it could be unavoidable, it could be personal reasons as in families, situations, health, all those kind of things, in which case we're just generally seeking how can we help you in, you know, the next parts of your journey. But if there are things or factors in the company that push you in that way, I truly want to understand because you're not going to be the only one. That means there's something, you know, malfunctioning. And that something, today it's you, tomorrow it will be someone else. And I want to, you know, jump ahead and try to prevent this from happening, fix this, and manage potentially a larger exit if it can be avoided.

Good job.

One of the things, for example, that I have seen people exit the organization, engineers exit the organization, and linking back to learning, is when they're being, for whatever reason, underutilized, or being utilized on things that they are kind of trivial. So they do things, but they don't do meaningful things anymore. Anymore. They don't do new projects, they do, you know, maybe just bug fixing, support, something, and that is going on for, you know, for with no end in sight. So I think people understand sometimes who have to do things that, okay, it's a certain phase. But if there's no way out, and they can't see themselves in a different future in the organization, then their response is, I can only see a different future if I leave the organization. That's really what I try to manage.

Okay, can I give you a situation, Russ, which is, um, it just came to my mind, and I'm— so it's a real situation, just to see how would you approach this. So the business is, you know, in play for about 12 years, and, uh, the, the, the product and the, the tech stack is just so, so old, right? It's, it's incredibly old, and they're having this huge attrition of senior people leaving, and, and, you know, they're doing this exit interview interview and everyone saying is, I just don't want to work with this legacy, you know, legacy nonsense. Like, you are like 7 years behind the market on these frameworks, and you know, I'm off somewhere where I can, you know, learn something more up to date, right? And they just end up with just junior people because no one else, you know, like stays, right? And they in this vicious now cycle where they cannot get a proper senior people in to resolve that legacy issue, right? And, you know, maybe do replatforming or whatnot, and they're just getting that, you know, junior-level element, and it's just going nowhere effectively as a business. What's your take?

While it's a hypothetical scenario, I have been in similar sort of situation observer. So I think the catch-22 here is exactly what you said, and I think put a CTO hat on for this one. It's a bold decision and communication to the CEO, to the board and say, look, we understand we made an investment in this platform, it served its role. Right now, the benefit we get is X, Y, and Z in sales, but it has this cost, that cost of attrition, that cost of replenishing the team. And I think deep down, we need to put them in hard figures. And I strongly suspect the hard figures will show that if not now, if you project over time, maybe not now, but we'll have another year or two, this will grind to unmanageable levels. So our choice is to act now and preempt this. And this is where the common wisdom said, do not do a replatform, do it in incremental migration. If it's microservice architecture, use the strangler pattern, all those sorts of things. I have done contrary to, you know, common wisdom on a replatforming projects as well, which they were successful subject to certain conditions. But I think as, again, as a CTO, as an exec board, you need to make the tough decision because what really happens here is indecision and you end up being hostage to the market. You just preventing the inevitable.

Again, goes back to that T1, T2, and the decision velocity. And numbers don't lie, isn't it? Put everything on a spreadsheet, you'll see.

And if you don't do it now, the decision will be made for you again, maybe a year, maybe 2 years from you, when you literally have no people to support. And then, yeah, you've been a really tough— in a really tough place commercially as well.

Yeah, you're probably losing business at that point in time. Okay, well, that was great, Was. Thank you for coming on the show. I hope you enjoyed my questions and, you know, things you shared.

It's been fantastic, Mike. Thank you so much for having me. It's a great show, and I want to wish you every success on your podcast.

Thank you, Was.