In the latest episode of 'groCTO Originals' podcast (formerly: 'Beyond the Code'), host Kovid Batra engages in a thought-provoking discussion with Sergio Visinoni, a Fractional CTO, Tech Advisor & Mentor at groCTO Community. He’s also the author of the newsletter ‘Sudo Makes me A CTO’ and runs a tech leadership coaching startup as a solopreneur. The heart of their conversation revolves around ‘Maslow's Hierarchy for Tech Teams’.
The episode kicks off with Sergio discussing his background & then introducing a framework inspired by Maslow’s Hierarchy, categorising tech team maturity into 3 levels: vital infrastructure, application service quality, and developer performance. He explains how this framework helps align technical and business strategies, identify issues, and communicate needs to business leaders. Through a case study, Sergio illustrates that high feature output doesn’t always equate to high performance.
Lastly, Sergio addresses challenges like standardizing DORA metrics across diverse teams and justifying infrastructure needs, emphasizing how the framework aids in balancing stability and performance for data-driven decision-making and effective communication.
Kovid Batra: Hi, everyone. This is Kovid, back with another episode of Beyond the Code by Typo. Today with us, we have a very special humble guest. He comes with 24 plus years of engineering and leadership experience. He has been a Tech Mentor, and a Fractional CTO at multiple startups and orgs. He's also the author of the newsletter 'Sudo Make Me a CTO'. Currently, he's a solopreneur running his own tech leadership coaching startup, and I would like to welcome our guest from Spain, Sergio. Welcome to the show.
Sergio Visinoni: Hi, everyone. Hi, Kovid. I'm really happy to be here.
Kovid Batra: Same here. So today, Sergio, I think, uh, we have a very interesting topic to talk about and I derived it from the previous conversation that we were having. It's about the Maslow's hierarchy for tech teams. So I think it's very interesting. It's something related to, uh, personal life also, like how Maslow's hierarchy plays a role in our lives and how that maps to tech teams actually. But before we jump into that, I think, uh, the audience would love to know a little bit more about you. You can share your personal things also. Let us know who is Sergio. Over to you.
Sergio Visinoni: Yeah, sure. Thank you, Kovid. Yeah. So before we get into the very interesting topic, let me bore you to death with some personal details. Uh, no jokes aside, I'm Sergio. As you said, I've been spending more than 20 years in the tech industry. I'm originally from Italy. Um, I've been living in many countries, so mostly Europe, but then I spent a bit of time also in Mexico and then I moved here to Spain in 2016. The biggest chunk of my career has been in online marketplaces. That's where I basically went from being a software engineer and to actually being a VP, uh, of, like overseeing more than 300 engineers across multiple countries. So that's been like the peak of complexity that I've been dealing with. Uh, and after that, I've been, um, getting my hands dirty again with smaller companies and startups, until finally, at the end of last year, I took the decision to, you know, uh, move out of the traditional employment setup, uh, because I felt like I wanted more flexibility. I have a family, I have two kids, as you want more personal details. So I want to spend, be able to spend more time with them when needed. Like if there is something at school, I want to be able to go there without, you know, having to, uh, have too much justifications to add and also want to spend a bit more time for myself as well. So that's why I took the jump from January 1st, I became what I like to say a 'solopreneur', which makes it sound cool. Uh, the reality is that what I'm doing is mostly consulting for now. At the moment I have three B2B clients, three companies that I'm consulting with in different capacities. One of them is a traditional fractional CTO. Others are more project-specific. Uh, in parallel to that, I'm, uh, building up my own coaching and mentoring, uh, practice. I really like working with individuals, be them senior engineers or tech leaders who just want to get better in their professions. I really enjoy that because it reminds me of one of the things that I loved the most when I was an engineering leader, which was like working with people in my team, right?
Kovid Batra: Yeah.
Sergio Visinoni: And then, you know, eventually, I also want to start building, you know, online products that can sell themselves. That's why I consider this a solopreneurship. Consulting is a part of it. I don't want to be a full-time consultant forever, but I need to start close to what I can do, uh, right now, as I build my business over time.
On the personal side, I said that I have a family, have two kids. Uh, my main hobby is actually woodworking. So I like to have analog activities to do, uh, lots of pieces of furniture here at home. Uh, I've been there myself. And you can actually see the progression from the first pieces, it's not very good to the last pieces getting better It's like software, you know, when you look back at the software you wrote one year ago, you realize that's not very good. Uh same goes with woodworking. And then yeah, I like reading a lot. I'm an avid reader. Um, I spend time, as you said, producing my own content as well. I have my own newsletter. I write a lot of content on LinkedIn, trying to, you know, be part of this community, and as well, you know, I'm not hiding that it is a big channel for me to market my own brand, right? I try to show my knowledge through all that content so that hopefully people will feel confident, uh, you know, signing up for my service.
Kovid Batra: Sure. I'm sure they would. Great. Thank you so much for this sweet, quick intro. Uh, and I wish you all the best on this solopreneur journey, and I really appreciate you for that.
Cool. So I think now is the time we move on to making dev teams better, enabling engineering leaders to make dev teams better, and I really would love to, uh, hear about your theory of building great dev teams and how you bring in Maslow's hierarchy in that. Uh, over to you, man.
Sergio Visinoni: Yeah. So I'm going to start with a bit of context, right? Um, I remember the year when the 'Accelerate' book came out. Uh, that was 2018, and I actually remember it was, it's fun. I still have a clear, vivid memory of a Slack chat I was having with a software architect that was in Norway. I was already here in Barcelona. And we're talking about, you know, engineering metrics, how they were using certain metrics in their team, et cetera, et cetera. Because I had been kind of banging my head against the wall on this topic. We know it's a difficult topic, right? It's very challenging. It's very easy to come up with wrong metrics. At the same time, I didn't want to just give up and say, "It's impossible to measure anything." Right? Um, and he said, "You know what? This new book just came out and they claim that they found causality, relationship between certain tech metrics and business outcomes." I I said, "Wow! I need to read this book." So that's how, you know, I saw the link on Amazon. I bought it immediately and I started reading it, and it came at a very good moment, because again, as I said, I was kind of thinking a lot about that space. That's where, you know, after reading the book, I've been working with a collaborator, and I also actually need to say that a lot of the credit for what we did goes to him. All right. Uh, he was in my team. He was the Director of Engineering of my team. Uh, he was tasked with helping me figuring out how we can look at metrics across the whole portfolio.
And this is the second piece of context that is important. At that moment in time, as I said, y'know, overseeing a big engineering organization, I was actually overseeing multiple teams operating in different countries for different marketplaces. So it was a very heterogeneous setup where we had a combination of shared platform services, but a lot, I would say more than 80 percent of the code and systems was run locally, right? And this for historical reasons. So this company has been growing very quickly by, uh, forking, uh, different versions of the same platform in different countries to allow for maximum customization, but also through acquisitions. So it's very common, you know, every company or actually no company grows following the ideal path. It's always like bumps on the road. And then, you know, on the engineering side, you're left to deal with some historical, uh, legacy to deal with. So we were facing this very heterogeneous setup. At the same time, you know, I was responsible for making something out of it, right? So I was responsible to oversee all of it and try to figure out how we can look at this portfolio and how we can understand where each team, where each organization is in terms of maturity. And that's where we started thinking about, okay, we need to develop a 'tech maturity framework' to be able to look at this and be able to talk about where every team is and also help the GMs and the CEOs understand what type of investments they're supposed to make to be able to improve the situation, right? So we wanted this to become not a tool to just assess or judge or evaluate. Actually, we wanted this to be a tool to help all the local tech leads in the different countries to have stronger arguments, better arguments to justify investments in architectural refactoring, you know, building better tools or improving processes and whatnot.
So that's where, you know, on the one side, the Accelerate book came out. On the other side, we were having this, uh, challenge on our own. Uh, and that's where with my colleague, Marco, uh, Marco Cupidi. Uh, I recommend him for another podcast, by the way. I think you should definitely interview him. We came out with this idea of the Maslow pyramid for, uh, engineering teams. We started investigating this idea of building the analogous of the Maslow pyramid for tech teams, uh, in this optics of figuring out what, how we can look at tech teams in terms of their maturity, right, because if you think about the Maslow pyramid for humans, you can roughly say, you know, the more you move up on the pyramid in terms of being able to focus on higher and higher needs, the higher the level of maturity your personality has reached, right, because you're not only focusing on surviving, you're not only focusing on recognition, you actually, at some point, you reach the level of self-realization. I think that's the peak of the pyramid.
Kovid Batra: Yes, self-actualization.
Sergio Visinoni: Self-actualization, exactly. So we started working with this idea and now we didn't complete the work, meaning that initially we thought we will have five or six levels of the pyramid. We ended up with three, but that was enough. Honestly, you know, we didn't actually want to stick with the same amount of levels in the pyramid of Maslow pyramid, but we ended up with three levels, and basically, they were organized as such. The first level, the base of the pyramid, which is analogous to, you know, feeding, uh, having food and providing, for Maslow, was focused on what we were calling the vital infrastructure layer. So basically, "Is your platform stable?" And the reason for that is that I've seen many times teams focusing too much on velocity or going faster where actually their main problem is with quality and stability. And whenever a team is facing a lot of stability issues, that has a lot of implications in terms of their ability to work effectively. So it introduces a lot of disruptions, right? They are constantly interrupted by issues, by problems. So there is no way for the team to focus on improving output before they improve their predictability of the cycle.
Kovid Batra: Right.
Sergio Visinoni: And predictability is always negatively affected by how many incidents you're having, right? Every time there is an incident, your attention is redirected to dealing with it, and therefore, again, it disrupts and it adds, creates a lot of waste in the process.
So that first layer, I remember, it included metrics such as availability, but also it had metrics around, uh, latency of the most important pages. We're mostly dealing with websites and with mobile apps as well. So there were metrics on crash rates on the apps, for instance, etc, etc. I don't remember the full list because, y'know, this was a few years ago, but it doesn't really matter because what we came up with was.. Yeah?
Kovid Batra: The highlight is stability like the first level.
Sergio Visinoni: Exactly. So, 'vital infrastructure' is infrastructure, the basic level of what you build, operating in a healthy way, is it healthy, right? Or does it need to constantly look for food because it's starving, right? That was kind of the concept.
And then, the second layer above that was focusing more at the application level. What is the quality of service of your application? And here we're looking more in terms of error rates on the app, or, uh, you know, some of the Core Web Vitals were included there. Not all of them because it was still early days. Uh, actually I don't think we were calling them Core Web Vitals yet, if my memory serves me well. But Google was already quite advanced on, you know, pushing the idea of these important metrics on web performance that reflect the user experience. So this was a combination of, you know, application-level and the quality of service that you're providing to your users, not in terms of user flow, right? So it was not the functional part of user experience, but the non-functional part of user experience. Is it fast enough? Is it reliable? Is it loading in the right way? et cetera, et cetera. So that was the second layer, and the third layer, uh, was basically what we're calling developer performance, I think, and it was mapped into the DORA metrics. So these were the four DORA metrics because that's where you get to, from our perspective, the optimization stage, right? Once the first two layers are in a good place, you can really start focusing your attention on the third layer.
Now, as Maslow says as well, you don't need to complete 100 percent of one layer to start looking at the next layer, right? So it's more like you want a slice where always the base is much larger than the layers above, but you don't want to only focus on feeding yourself until you have enough food to survive for the rest of your life. So there's always a balance. But for us, y'know, going back to when we introduced it, when we introduced this framework, and again, lots of credit goes to Marco. Uh, I was there mostly to help, but also to help socialize this and get buy-in from the business counterparts, right, because until that point, the engineering side of the organization was really considered as a black box for any people outside of engineering.
Kovid Batra: Yeah.
Sergio Visinoni: So, yeah, it's no, things are slow. We have lots of legacy. Old platform. Now, there were all these common words being thrown around, but most people didn't really understand what was going on, and then they resorted to kind of comparing across countries based on how quickly they could ship new features, regardless of whether those features were actually the same or not, right? There was a lot of oversimplification in the discourse around, "Is my team or is your team performing well from a CEO perspective?" And I wanted to not put an end to that, but actually help business leaders understand better, have a deeper understanding of, okay, this is the situation within your team. Now, how do we have them move to a better place, right?
So, using this analogy of the Maslow Pyramid turned out to be a very effective and powerful way to communicate because, you know, every man, every person and their mother have heard about the Maslow Pyramid, and even if they don't, it's very easy to understand the concept once you explain it, right? Of course, we're always putting a lot of caveats, right? Saying, you know, "Don't just translate everything Maslow said into this context and assume that it's going to work." Because there is a lot of simplification going on here, but analogies are useful because they help people grasp the concept more easily.
Kovid Batra: Yeah, it makes a model in your head where you can always understand where you are, what you exactly need to do. So that way it makes it easier for people to make those decisions and then move forward according to that. Yeah. Makes sense. I understand.
Sergio Visinoni: Yeah. So, that. On the one side, so there was the benefit for the business leaders, so they will understand better, you know, their situation. Secondly, it was helping local CTOs because again, I was VP of Engineering, but I had CTOs reporting to me because we had different titles depending on the countries. It was very heterogeneous. Don't get too fixated on the titles. But basically, I had local tech leads who were reporting to their CEO, but then they were dotted line reporting to me, and many of them were struggling to find arguments to justify investments in technology, right? Because especially when you're a small, medium-sized team where the competition on the market is very fierce, you know, you get a lot of pressure to just push new features, right? You just, you need to launch this new feature because we need the revenue, blah, blah, and we all, we've all been there. There are lots of good reasons for that to be the case and some bad ones, right? And especially, first-time tech leaders tend to have a hard time, balancing that need, that business need with, okay, I also need to make sure that we ensure this system will perform well in the long run, right, not just tomorrow, especially with businesses that were well-funded with good business models. So it was not a typical startup that might disappear in a couple of months. Uh, this was a proven model that we're rolling out across different countries. So the long-term horizon perspective was justified even in the early stages.
So we put together the model. We put together a series of metrics, but then, the hard part of the work started, which was how do we collect the metrics, right? So initially, it was a massive, uh, Google spreadsheet, and we're asking local CTOs to, you know, fill in the data on a monthly basis, and the interesting thing for us was to look at the trends. Like, we learn a lot from when we work with DORA metrics. The absolute value is largely meaningless, because it's really very context-dependent, and also depends on how you define the metric, right? Every one of these metrics, you know, you work with that, you need to start with defining, okay, "How do I actually want to measure it?" Because DORA doesn't tell you how to measure them, but even when you talk about availability, there are different ways to look at the numbers and figure out how to calculate this. So, it was a lot of work to kind of standardize on those metrics. And once we got to that level of standardization, then every team will see how they were evolving on a monthly basis, and we're generating monthly reports with different levels of granularity, right? So, for the executive team, we will look at an index that was calculated as a kind of summary or a compilation or, yeah, aggregation of all the submetrics to show, okay, "This team is at 75 percent in the journey. Last month they were at 70%." So there's been a significant improvement. And if you look back last six months, they've been increasing month over month, et cetera, et cetera.
Whereas some other teams maybe were either flat or even decreasing, declining. That proved to be another very useful tool because in my perspective, one of the best usages of engineering metrics is what they call, um, conversation starters. So those metrics are a way for you to spot that there is something going on. It's very dangerous to jump to conclusions just based on metrics.
Kovid Batra: One question.
Sergio Visinoni: But at least they're telling you.. Yeah, go ahead. Sorry.
Kovid Batra: So I think what I am understanding from your, uh, analogy and how this hierarchy is helping people to actually build a strategy, it's more towards a technical strategy. Am I getting it right or is it more around mapping the business strategy also in place? So, that's the real problem for the tech leaders, right, that you are really not sure about what your business needs and what your tech needs, and then you're trying to map both of them so that you survive well, and in fact, thrive in certain situations where you really want to move fast. So this hierarchy, uh, analogy is it helping purely on the tech strategy point or, uh, is it bringing in the business aspect also?
Sergio Visinoni: That is a fantastic question, Kovid. I would start by saying that you cannot have a tech strategy that is decoupled from the business strategy to begin with, right? Because otherwise, so there is no absolute tech strategy that is right for every context. Uh, the tech strategy needs to be tailored to the specific company, team, whatever the scope we're looking at. So by definition, this was helping them better the business strategy into the tech strategy. But, at the same time it was also helping CTOs in some cases define a clear tech strategy because they were finally seeing clearly, you know, this is where you have problems, and based on the model, we recommend you don't start optimizing for speed if your site is down every other day, right? You should start first by creating that stability, right? But it also helps them communicate with the business and actually manage business expectations in a more constructive way. So, you know, in order for us to be able to get to a place where we can fulfill all the needs for the business in terms of like new features, new capabilities that we need to build, first we need to address this. Until we address this, we're not going to be able to predictably do our job, and we'll constantly be facing, you know, urgent fires that will disrupt our ability to plan and actually execute on those plans. So in that sense, there is a clear connection.
Now, what the framework didn't tell was what features to build or how to solve a problem, right? That's exactly how then, you know, in my team, I was combining the framework as a diagnosis tool on one hand. So it was actually an observability tool. It was giving us information about where the potential problems were, and then I had a pool of experts and software engineers that in some cases I was able to deploy to help specific teams improve in certain areas, right? For instance, you know, "You guys, I have an architect here. You need help on refactoring this part of the architecture on your side. I'm gonna have this person working with you next quarter to help you move from here to there."
Kovid Batra: Yeah, exactly I think that's the best part. I think it's not a static framework, right? You are always moving in between these layers depending on the situation. All you have to do is like make sure what exactly each state tells you, those metrics of each state tells you, and based on that, you can at least formulate in your, uh, strategy that, okay, this is where we need to focus, and if this is a business requirement, are we mapped to do it or not? You can actually make decisions by knowing the reality of your system.
Sergio Visinoni: Exactly. You're absolutely right. And basically, it's a framework that helps you prioritize what to do, right?
Kovid Batra: Yeah.
Sergio Visinoni: Uh, it gives you clear insights on, okay, I should look here or I should look there. So, what's the plan, y'know? Again, this is the problem. This is the symptom. Now, how do we go about addressing the underlying problem? And again, that was happening either in isolation within the team or with support from people that were, you know, uh, located with me in Barcelona. The 'how' is really context-dependent, again, because depending on what the specific problem is. It's also depending on the local pool of competences on the team that is suffering, you might come up with different ways to address it.
The other interesting side effect of this approach, by the way, you know, it was not easy to deploy it because in the beginning, a lot of teams were seeing this just as extra toil, right? You're just asking me to collect metrics. What's in it for me? Right. It took some time to prove the value, right? And that's where, you know, strong conviction, but also repeating why we're trying to do something, y'know, being very consistent in the messaging is helpful. But, you know, in any organization, especially big organizations, there is a lot of competition for attention, right?
Kovid Batra: So what do you think was, uh, your takeaway from the incentivization for implementation? Like, uh, why people started sticking to it, uh, with you?
Sergio Visinoni: I think there were probably two broad categories of people. Like, generalization, but to simplify things here, one category of people were people that, understood this at an intuitive level and actually saw this as a way to, okay, achieve something they wanted to do. So people were thinking, okay, "How can we become a bit more data-driven in deciding on this type of work?" So for this group of people, it was obvious. Of course, nobody likes extra work in general, but they understood why, right? And then, there was more like the detractors or people who were, uh, resisting this type of change, and what worked with them was spending time to help them understand this will actually help them do what they wanted to do, and they were frustrated because they were not able to do it, right?. So typically, and this roughly mapped, you know, it's not exactly one to one, but this roughly mapped to the more junior profiles, those who were able to see, okay, "I don't have time. I don't have resources to do all the important things I will need to do because, you know, my boss tells me that we need to prioritize X, Y, and Z." And I was telling him, okay, "So how do we change that?" Right? "How can I, how can we help you create, build stronger arguments to be able to, y'know, put those on the table and be able to have a proper prioritization discussion and say, okay, if we do this, we're going to improve that, and therefore, if we improve that, this will be the potential consequences."
Kovid Batra: Right.
Sergio Visinoni: So this has been the main driver, um, to get most of the people on board.
Kovid Batra: Makes sense. And as you were talking about the challenges, I think if you could give me one example, uh, like some anecdotal information around how things worked out when you were implementing it, that would be something very insightful.
Sergio Visinoni: Yeah. So, on one side we discovered, for instance, without naming names, we discovered that one specific organization that was considered (quote, unquote) "high-performing" because they were churning out lots of features. It turned out their metrics didn't look very good. All right, so this was an interesting case of doing a lot of average work rather than doing a little bit of good work. And once we started going beyond those, so those metrics, the first thing they did were they put us onto something. We realized there was something there that required further investigation. So we started working more closely with the team and we started realizing that there were basically gaps in their knowledge, right? So nobody had any bad intentions. But the problem is that, especially in a big organization, there is a certain element of competition across countries. So nobody wants to look bad. Everybody wants to look better, right? And therefore, they were a bit trapped in this self-fulfilling prophecy of showing off that they were good, even though they weren't, and therefore they didn't really ask for help, right, because asking for help would have meant, you know, we don't necessarily know exactly what we're trying to do. In this discipline, it's very hard to know exactly what you're trying to do. There's a lot of uncertainty, lots of surprises around the corner. So, in this specific case, this framework allowed us to identify something that was very much below the radar until that moment, which led us to spend more time with this team. Actually, this team from a business perspective was one of the most important countries in my portfolio. So it became quite evident that I and my team should prioritize our attention to this team, and over time, that led us to help in making significant changes at the organizational level and on the way they work, and therefore, the end results.
So this has been like one of the biggest investments. The other one, actually the most important asset in that portfolio, um, was falling in the category of those who understood this from day one, right? So this was like mature people who just saw in this a potential support. So there, the collaboration from day one was extremely easy, and it really became a partnership where I actually took a big part of my team to work with them for a sustained amount of time to actually move them very close to excellence on, you know, on the, at that moment, the DORA ranges, if you remember, and that has had massive impact on the business, right? The business was going through an important transformation. There were changes in the leadership, at the top, but actually also these changes on the tech side allowed to support a lot of the initiatives that the business wanted to push. So this was a very good success case where all pieces came together, the local tech team, my team centrally and the business realizing, okay, we need to put investments here, we need to do things in a better way. Um, you know, nowadays, that country is still thriving, uh, and part of it is because of some of those investments we made during those days.
Kovid Batra: I think this, um, philosophy, the tech philosophy, I must say, solves a lot of problems. Like, first and foremost, I would say the decision-making, like anyone who is trying to make a decision that comes to a very good point where you know your reality, you know what is needed from the business and you can map those two and then come out with, okay, "This is the priority list for us." So that's the best thing I see coming out of this, and then, of course, like it makes you achieve as much as you can, not that as much as you want. So that is also very important because sometimes we overstretch ourselves to do things which probably are not realistic or not achievable. This would really help you give a fundamental check, and then, you would say, okay, "This is what needs to be done there."
One more thing, I think I discussed this in one more podcast that it is very difficult for tech leaders to explain to the business counterparts, why this tech thing is very important, right? Now they have a very good framework in place and a few metrics in place to tell them, okay, "This is where we need to focus right now." And if it is needed right now, then you have to bring it up. So I think a data-driven decision-making makes it very convincible for the business counterparts also to take up the decision.
So yeah, I think this was really great, Sergio. I think a very, very good thing I learned today and hopefully the audience did too. So with that, I would like to say buh-bye and would love to have you on another episode anytime soon, and talk more on such topics with you. Thank you so much, Sergio, for today.
Sergio Visinoni: Thank you, Kovid, and you know, just hit me up when you want me to join again, I will be very happy to have another chat.
Kovid Batra: Thank you. Thank you so much. See you.
Sergio Visinoni: Bye!
Implement DORA metrics, gain dev visibility & drive success in your teams.
Try Live Demo
