[00:00:02:02 - 00:00:22:04]
Welcome to the Tech World Human Skills Podcast with me Ben Pearce. Every episode we talk through different aspects of how to really thrive in the tech world and if the podcast isn't enough for you and you want weekly micro learning delivered straight to your inbox, sign up for the Tech World Human Skills Weekly. Head over to www.TechWorldHumanSkills.com to sign up.
[00:00:22:04 - 00:01:39:00]
the Tech World Human Skills Podcast. It's lovely to have you with us. Now, this episode, we're talking about creating a thriving team. What is it? Why is it important? And how do you do it? Now, our guest today knows a thing or three about this topic. He's been an engineer, he's been a sales professional, he's been a head of product, he's been a CTO. So please welcome to the show, Lee Smith. Lee, it is brilliant to have you with us. Thank you, Ben. It's really good to be here. I'm really looking forward to the session. Well, no, it's a pleasure. So thank you for taking the time to come and see us. And before we dive into it, I wonder for all of those people that have never met you before, which I imagine is quite a few, could you give us a bit of an overview of your background? Yeah, sure. So as you said, I started my life in engineering. So this was IT support systems working in manufacturing. That was many, many years ago. Moved into service providing, still very focused on IT system support administration.
[00:01:40:03 - 00:01:54:22]
Then I was really fortunate. I got to work with Microsoft in a primary field engineering role, which was a rapid response, critical situation type role. Still to this day is one of the best jobs I ever had with the team of people that I worked with there. It was phenomenal.
[00:01:56:08 - 00:02:20:17]
While I was at Microsoft, I really got the interesting opportunity to move into sales. So I actually transitioned into technical sales. And that was a real eye opener. It's a very, very different world. And I'd say it's transitioned from that black and white technical landscape to a much more colorful world of actual solution definition and solving problems for customers.
[00:02:22:01 - 00:03:27:06]
Then moved into product development. So after a very successful six or seven years in sales, a friend of mine said, "Look, you should go and actually talk "with software developers and product leaders "and how they build software." And to get me started on that, I did a training course in Agile and I was hooked. Absolutely hooked from day one. So from about the last 10 years or so, I've been leading product and technology teams from different software companies around the world. My most recent engagement was with a global SaaS company based in the US for marketing automation. And I was their CTO responsible for architecture, engineering, product, and all of the go-to-market around all of those. So it's been an interesting career so far. My venture today, I've started my own business around products and technology advisory services. So I'm helping businesses in startup and scale up phase grow and deliver against their business objectives. So that's me in a nutshell.
[00:03:28:08 - 00:04:02:17]
Brilliant. Well, loads of experience. And we cross paths first at Microsoft in that premier field engineering team that you talked about many, many years ago. And that's where we first crossed paths. And it's great to see all of that experience that you've had. And I think that starts to set us up for the episode and the topic we're gonna be talking about today, which is great teams, a really thriving team. We've probably all been in brilliant teams and we've probably all been in rubbish teams.
[00:04:04:05 - 00:04:41:11]
And so we're gonna be thinking about what that is and also how you create one, taking as a leader, how you create that thriving team. So I wonder if we could start off thinking about to you, what is a thriving team? Yeah, it's a great place to start because I'll be honest with you, every team I've worked with has the potential to be a thriving team. It really is a very, very, very rare thing that you encounter a team inside of a business or a team of teams in a business that knowingly wants to fail.
[00:04:42:11 - 00:05:08:13]
It's just super rare. So when I think about a thriving team, I kind of think about actually what it's not. So a team that's not thriving, they're very quiet. They're very accepting. They're very inconsistent. So when we're giving them challenges and you're trying to have kind of consistency in the outcomes that are being delivered, this is a very particular thing to product and engineering.
[00:05:09:16 - 00:06:25:20]
You don't get that consistency, which means you get some good days, you get some terrible days. And it's very, very hard to plan around that kind of delivery consistency. I think the quietness that I mentioned a minute ago, that's one of the biggest problems. Not having a voice, not challenging what we're trying to do, why we're trying to do it, it really removes a lot of the confidence. Am I actually gonna get what I'm looking for? Because if I'm not getting that challenge, well, how do I really know that you understand what we're trying to achieve? And if you're not asking questions, I'm just getting good enough for best effort type activities. So that's what isn't a thriving team is in those areas. On the flip side, a thriving team very much wants to challenge you on what you're trying to achieve. They want to understand the why. They want to understand not only the why is this important for the customer, but why this is important for the business, why this is important to them. And the reason they want to do that is partly it helps them establish a decision making framework. So it helps them understand, okay, when I encounter this challenge, who do I need to talk to? Is this a decision I can solve myself? Is this something I need to talk to other people?
[00:06:27:03 - 00:07:12:13]
I think the other thing when we talk about thriving teams as well is it doesn't matter if it's an individual team or a collection of teams. It's often a collection of teams, people with responsibilities in different areas. We want to make sure that the interaction between those teams is good. Thriving team or thriving teams has really good structured communication and really good outcomes, consistent outcomes. So they're very confident that when they say they're going to do something, they do what they say. And that confidence is reflected in that consistency when you're starting to plan. So it's what I tend to see from a thriving team. I think one of them, oh, go on, sorry, Ben. No, I was just going to say, when I reflect on when you've been in a really thriving team,
[00:07:14:02 - 00:07:39:15]
it's a pleasure, isn't it, there? Because there's a great relationship with people. You're not scared to challenge or be challenged and make your opinion known. The quality of the things that you're doing is raised. The pride of what you're doing is raised. The outcome of what you're doing. The value against the mission that you're working against. Absolutely. It feels less like a chore and more like
[00:07:41:03 - 00:07:54:00]
less of a job and more of a hobby to be in a team like that. So it's brilliant, isn't it? It really is. I think as well, I've had a few people say, oh, you can tell a good team when how they react when the things are going badly. Yeah.
[00:07:55:03 - 00:08:01:19]
And that is a really interesting characteristic of a team. Again, they tend to rally around when there's a problem. Yeah.
[00:08:02:21 - 00:08:06:08]
But what I really like is when there's a problem,
[00:08:07:15 - 00:08:10:01]
is there any hesitation in bringing in the other teams?
[00:08:11:20 - 00:08:16:00]
And a real thriving team environment is, okay, we're having a problem.
[00:08:17:01 - 00:08:50:07]
I will openly communicate that to the customer success team so they know we're having an issue. There's not that fear of, oh my God, I'm gonna get a reprisal for telling people the system's down. Yeah, it's an openness structured comms, hey, we're having an issue, we're working that issue, we'll keep you updated every 20, 30, 40 minutes. That's another good characteristic of a team, of a thriving team. There's a confidence there that even though we are in a situation, we're in a critical situation, we're managing it. And we're gonna manage the comms because we know that's important to you and we know that's important to our customers. So it's a good characteristic of a team.
[00:08:51:09 - 00:08:59:04]
So why, let's maybe look at this from two angles, from an angle of being in a team and then from an angle of being a leader of a team.
[00:09:00:04 - 00:09:39:06]
Why is having a thriving team important? Well, I go back to that confidence piece. And I think that confidence piece is both within the team and as the leader of the team. So I'll talk about it being within the team. I've been in these teams, I've operated in these teams. And you are asked to sign up to commitments. You are expected to attain those commitments. So your confidence around that attainment is really important. And for that confidence, you tend to lean on a couple of things. Your knowledge and your own personal understanding of the problems you're trying to solve and your own ability to answer the questions that you're tasked with. And also your ability of your team.
[00:09:40:10 - 00:09:42:12]
How a team you get to know and understand.
[00:09:43:19 - 00:10:11:20]
So there's that element of it from your own personal perspective being in the team. But from the leader perspective, I like to hear from all of the team. So you'll hear in a second when I talk about how we do some of this. One of the structure communication sessions I have with product and engineering is around refinement. And the purpose of refinement is not to get to 100% understanding of exactly what you're looking for. Yeah, that will actually come as we start to build what you're looking for.
[00:10:12:22 - 00:11:16:05]
What we're trying to do in refinement is understand, do we have a fear? Is this in an area we've never worked? Is this something that we need to go and have a bit of an investigation around where we don't carry the commitment of a delivery, but we can start to improve our knowledge and experience so we can have a structured conversation with you to set a realistic expectation. So again, in a thriving team and why it's important, getting that confidence and that consistency is what we're looking for. That's why it's really, really important. From that confidence and that consistency, we get realistic expectations. From realistic expectations, we can start to put accountability in place. If you're setting a very realistic expectation, you can be held accountable for what we're trying to achieve. And you can carry that accountability yourself. You understand, yeah, this is what I've said I'm gonna do and I'm gonna do what I've said. So it is why it's important, that confidence, that realistic expectations around delivery and that accountability. It does help quality when people are taking accountability. Exactly as you said, you take some pride in your work.
[00:11:17:08 - 00:11:45:19]
Mm-hmm. Well, you started to tee up there the how. So let's maybe start to get into some of the practical things. I think you've probably got four or five sort of key focus areas that we're gonna look at today. Yeah. On how you create this striving team. So do you wanna maybe give us an overview of all of the areas that you're gonna focus on so that people have got it and then we'll maybe start to unpack each one? Yeah, okay. So the five areas I'm gonna touch on are around purpose,
[00:11:47:07 - 00:11:50:16]
communications and process, roles and responsibilities,
[00:11:51:22 - 00:11:59:22]
respectful challenge, and then finally around your own personal development. So those are gonna be the five areas that I'll touch on for thriving teams.
[00:12:01:18 - 00:13:19:17]
So I'll start with the purpose one because I think it's, it is probably the most important. When we define a team, a team of people or a team of teams is a collection of people or individuals moving in the same direction towards a common goal. If you don't have a common goal, you just have a group of people or groups of people accidentally moving in the same direction, going to whatever they've defined as what the goal is. So when we're talking about purpose, it starts at the very top, it's one of the senior leaders most important jobs. What is the mission and vision for the business? And we're setting that for a few reasons. One, it looks good on the slide and we'd like to talk about it. Two, it sets a decision-making framework for the rest of the organization. If you're thinking about a product and technology organization, for example, they are solving problems, solving problems for their customers, solving problems for the market that they're trying to address. So the mission and vision really helps the wider organization you're operating in to answer the questions, is this aligned to where we want to go as a business? It's a real important question that whenever you're particularly in product and engineering, but it does impact other areas of the business, whenever you're in a situation where you think,
[00:13:20:19 - 00:13:28:15]
it's the first thing you go to. Before you escalate up the chain of command, you look at the mission and vision and this is what I'm trying to achieve aligned.
[00:13:29:18 - 00:13:31:10]
It also goes down another level.
[00:13:32:15 - 00:14:00:06]
And again, another particular example from product and technology is when we're building a product, there's often project cycles. So you'll have a good example from my own personal background. I built a software product, which was Skype for Business Audio Integration Service many, many years ago. And don't ask me to quote the mission and vision of the company, I can't, but it was all. I know, I know.
[00:14:01:08 - 00:15:19:10]
(Laughs) And also Skype, I haven't heard Skype mentioned for a while either. Yeah, it's the A's, show my age a bit. But we had a challenge that our parent organization had already set an expectation with the customer. So a lot of the normal type of questioning around product market fit that would normally be answered by the mission and vision was already answered because this was a, I would call this more of a project-based piece of work. That doesn't mean there wasn't the opportunity there for us to actually set the vision for what we were building within that context. And that's exactly what we did. We set the vision, we broke it up into a few areas and it really allowed my team to understand very quickly that we have to prove that this is a solution that we can do. So kind of do our product market fit, sorry, that was already done, kind of do our minimum viable product exercise, an experimentation exercise very quickly to show our customer that this could actually be done. And that all came out of our kind of purpose session for the project where I sat down with my team and I took them through the outcome that we were trying to achieve, and the history of what had already happened on this project, basically had been running for many years and hadn't delivered properly.
[00:15:20:19 - 00:15:41:05]
So it was really important that we addressed that need quickly and the team understood that. But again, it's that whole setting and mission and vision, it can be done at several levels, but it creates the decision-making framework. I never told the team that we needed to go and iterate on this and produce an MVP to meet this requirement. That's something they made the decision on themselves.
[00:15:42:22 - 00:16:11:13]
So it was really important. So sort of helping really with, right, what are we gonna say yes to, but also what do we need to say no to? And so it helps you prioritize by aligning it constantly back to that mission, back to that vision, back to that purpose, back to the why. Yeah, I often encourage engineering teams in particular that the vision and the mission does not give you a veto. Yeah, so this is not about saying no, this is about saying what if.
[00:16:13:02 - 00:16:18:14]
So when we get a request coming into the group for solving a problem,
[00:16:19:14 - 00:16:43:08]
the often the question the teams need to ask is why. They have to really get to the bottom of what is the problem you're trying to solve? Not what you've asked me to do, what is the problem you're trying to solve and why. And if I can get to the bottom of that, I can then actually come back to you instead of with a no, I can come back to you with a, well, what if we was to do that this way? What if we was to adjust it in this way?
[00:16:44:16 - 00:17:47:08]
And that's really the power of a thriving team with that kind of common goal and that understanding around the vision and mission. That is their strongest asset is that ability to, I understand this is a problem. Now I understand what the detail of the problem is. I can actually give you alternatives to what you're thinking we need to do. And I can explain to you why that's perhaps a better approach. It could be quicker to market. It could be easier architecture. It could be lower cost delivery or all of the above. Okay. So that's purpose and vision. Should we move on to the next area to focus on? We can do. The next area is a bit of a monster because it's communication and process. So I've worked with products and engineering teams for the last decade. And I can tell you now, I've done lots of project framework training, structured training, classroom training. So I've done ITIL service management, Prince 2, Agile, Scrum, Safe.
[00:17:49:04 - 00:18:07:01]
I think I did XP a few years ago. There's a lot of different delivery frameworks out there. And every single business that you engage with has a slightly different approach to software development. But these two areas for me stand out in a thriving team and that's communication and process.
[00:18:08:01 - 00:18:35:13]
So I like to talk about communication in two areas. I've got structured and unstructured and the cost of unstructured. So when I talk about the structured communication, it very much leans into the process. So in the process, we will have, for example, in Agile, in a typical delivery sprint, as we call it. We'll have a planning session at the start of the sprint. Every day the team, and the team will consist usually of the product stakeholder, the engineering team and the team lead.
[00:18:37:02 - 00:18:46:10]
We'll meet, they'll talk about very quickly what they've done, what they're doing, and do they have any blockers. So it's just their opportunity to keep the rest of the team
[00:18:47:21 - 00:19:07:02]
aligned on that team's objective. Because at the start during planning, we set a sprint goal and we set our team accountability. What are we expecting our team to deliver? So it's to keep the team updated on, yes, we're progressing towards those deliverables. Or no, I'm having issues and I need help.
[00:19:08:02 - 00:20:04:16]
And then at the end of the kind of delivery sprint, we also have a demo where we all come together and all of the teams will come together and they'll see each other's work and they'll talk about what's been done. It's a good joint learning exercise. And then we have a retro. And the retro is where we look at, okay, what's the lessons that we learned? We share kudos with team members who perform well. We talk about things that perhaps haven't gone so good. And what we're looking to identify is the one or two things that we can take forward as an improvement. So those are the structured comms sessions that occur in a sprint. I also add into a sprint refinement session, which I'll talk about in a minute. But those structured sessions means that I know for my teams I'm working with, I'm spending eight hours out of their 10 days of delivery doing those key activities. Which means the rest of the time they can focus.
[00:20:05:17 - 00:20:08:13]
And focus is so important when you're in these delivery cycles.
[00:20:09:21 - 00:20:43:02]
Then we come to the unstructured type comms. So this is the, hey, I've got a question for you. Have you got five minutes over IM? And what you don't realize is that person you've just messaged was 30 minutes into a deliverable that they were working on, really in a good throw, throw a good rhythm of delivery. And you've thrown that all out. So they've answered your question, it cost them five minutes, but it's then taking them another 30 minutes to get back to where they were. So the actual cost of that interruption was very high.
[00:20:44:11 - 00:21:26:13]
It's also very difficult when we start to talk about in unstructured comms, like the endless meeting scenarios. So particularly for product and engineering teams, there's a lot of, look, I just need an update type sessions which people can fall into. And a lot of, I want to kind of get your opinion on this future piece of work, because engineering teams are a valuable asset. They solve a lot of problems. They're also a font of knowledge about how things work. So we tend to find when we talk about communication and thriving team, there's that preference for structured communication, but we have to extend that structured communication to accommodate these other interaction scenarios. Otherwise we just end up in a mess.
[00:21:27:16 - 00:22:27:09]
I don't understand why we've had 10 days and nothing got delivered. Well, eight days of that 10 days was spent in meetings. So actually only had two days. And the times that I was given for focus was one hour slots. You know, it's not enough to get a good rhythm of delivery going. So that's where refinement comes in. Refinement really is that opportunity for extending structured comms. So communication and the process is so, so important in a thriving team. It's important in a couple of remarks. One, it helps us achieve focus and two, it really starts to enforce an element of discipline. Yeah, so, and that disciplines in both sides. If I'm asking an engineering team to attend a refinement call, they attend that call. They take part in that call. It is their opportunity to have a voice on what we're doing going forward, to give that opportunity back to the business of the what if scenarios. But if we look at this from a product side perspective,
[00:22:28:17 - 00:23:43:16]
I've got two hours with this team a week now. You know, I will do my homework. I will have tickets prepared. I will have the information I need to make the most effective use of that time because it's such a valuable asset to me. And it is a real change in behavior. And I see it, it has a much more positive impact. There's nearly always a bumpy start, but there's a much more positive impact of that consistency and that confidence once you start having this structure comes over and structure. What about inter-team conversation? So what I'm thinking about is collaboration. And you've got somebody that sat there with a bit of a blocker that knows that this other person has got the answer because they've done some similar stuff before. This person can sit here and twiddle his thumbs and try and figure it out for three hours. That person over there with a five minute conversation, she could fix it. But how do you balance the productivity of the person that needs to speak to somebody that can't speak to them versus the productivity of somebody that we shouldn't interrupt because they're focused? Yeah, and I think this is where you start to look at, you know, when you're talking about collaboration,
[00:23:45:06 - 00:23:55:07]
you have two different scenarios. So when I talk about a team, you have, we sometimes call them squats. So this will be three developers, a team lead and a QA. So it's a typical squad.
[00:23:56:15 - 00:24:03:14]
But also in a team, I have the entire engineering group. So I had one of my biggest engineering teams was 70 developers, 75 developers.
[00:24:05:05 - 00:25:27:01]
So yeah, I have always encouraged the developers. If you have a question, you go to the person who has the answer. Yeah, it's the way you move forward. So there is that challenge and engineers are more mindful of that impact than others. So they tend to follow the structure that they have in front of them, which is I have my immediate team. So if I have a problem, I ask my immediate team. I have my team lead, I'll ask my team lead. And if they can't help me, and I think I can get help from this other person, then I'll go and ask that other person. Yeah, it's a maturity you see in different teams around engineering to action and standards and practice. Yeah, I would encourage the engineering teams to follow that kind of use your team first type approach, but it doesn't then wait until tomorrow. You know, it's something that they can immediately kind of escalate into the other teams. The challenge is that for an engineer talking about an engineering challenge, they're very often, there is contextual impact, absolutely 100%, but it is a little different to somebody coming to talk to you about a hypothetical approach with a product. Yeah, yeah, very different mind space. Well, I wanna go back to that black and white and the color of the world. Tyson, when I have a technical issue, there's typically a black and white answer there. When I have a, well, I'm thinking about doing this and how could we approach it?
[00:25:28:20 - 00:25:32:05]
Well, there's 30 ways that we could approach that.
[00:25:34:14 - 00:25:38:08]
You also tend to set off a different kind of thought process
[00:25:39:13 - 00:26:23:15]
in that type of interruption. And that's why it can really throw off or create a much bigger cost for context switching when we're talking about these different scenarios. Inter-team comms, is that the wrong one? Intra-team comms is the right one, isn't it? So, intra-team comms, it tends to be a little bit freer because they understand the impact. They all know if they've got a difficult question. And if they've got a particularly difficult question, I've also seen mature engineering teams kind of, well, we can ask them that in the standup. We can ask their team lead to bring that up in their standup and see if you can carve out an hour to talk with them. That's a very common characteristic of an engineering team. Very, very, very common. Okay, let's move on.
[00:26:24:19 - 00:26:36:15]
What's your third theme? So, in my third area that I want to talk about, I just want to finish off on the communication process because one bit which I think is really important. When we get brought together into these group sessions,
[00:26:37:22 - 00:27:14:21]
there's often a senior individual involved. So, one of my key learnings as kind of the head of product and the CTO role that I've had has been that I am, one, a very tall person, so I'm six foot eight, and two, I am the highest paid person's opinion in the room. And so, if I'm vocal about a particular strategy or a particular approach, it very often becomes the answer. So, it's really, really important when we're talking about communication and process and the interaction with the team. We set the frameworks as leaders. We set the standards that we're trying to achieve,
[00:27:15:22 - 00:27:18:07]
but we need to allow the team to make the decisions.
[00:27:19:07 - 00:27:36:06]
Yeah, it's why I very, very rarely attend a refinement call because it is the team's opportunity to have that discussion. And I know if I'm on there and I say anything at all, the team will just defer to what I've said. And it's like, you have to kind of avoid that.
[00:27:37:09 - 00:27:44:06]
You need the team to be engaged and create a good atmosphere of interaction.
[00:27:45:07 - 00:27:49:07]
So, that leads me nicely into the next part, which is roles and responsibilities.
[00:27:50:16 - 00:27:56:13]
So, we mentioned before, one of the important areas for thriving teams is taking accountability.
[00:27:57:14 - 00:28:51:17]
Yeah, if I'm gonna say I'm gonna do something, then I want to have confidence in what I'm saying I'm gonna do, but also I wanna be accountable for doing what I say. It's how we achieve a very consistent and productive environment for the business and for the teams. So, to do that roles and responsibilities are important. And that's not just, hey, I'm a software developer level two, I've got these, da, da, da, da, da, da. It's also around the team commitments. So, when we talk about team commitments, these are things like we want to create an environment where people can ask questions, where people can challenge what we're trying to achieve, where people take time to learn from our mistakes. Yeah, when we fail, we fail forward and we fail fast. We don't spend too much time just doing what we've been told to do. We really want to make progress through learning and iteration.
[00:28:52:22 - 00:30:28:11]
So, the roles and responsibility piece is making sure you understand not only your role as a job and your responsibility as a job, but your role in the team and your responsibility as a team. And with that tends to come both the role and the team accountabilities. And I tend to have that enforced at several levels. So, there's you as an individual, whatever individual you are, you could be in product, you could be in marketing, you could be in sales, you could be in engineering, could be in QA. Understand what you do and how it impacts the team. Understand what the team does and how it impacts the elsewhere outcome. What are we signing up to as a goal? And really live and breathe that as your accountabilities. Because that accountability piece is just so important for that confidence. You know, if you're taking accountability for what you're doing, your confidence will come through, your consistency will come through and your quality will come through as well. Now, a quick question on this. So, I was talking to a friend of mine, another CTO just this week actually. And he was working with some people that were developing some outsourced group that were developing something for him. And the old, the age old fixed cost, fixed scope type thing. And then there isn't been much scope creep, but it's taken longer. They're not delivering. And so I guess the point I'm driving at is, where you've got this, when we're working with new stuff, where we don't actually know how to do it because nobody's really done it before,
[00:30:30:04 - 00:30:33:11]
how do you balance accountability
[00:30:34:12 - 00:31:06:13]
along with the undiscovered, the stuff we don't know, the unknowns? How do you balance that and bring that together? Yeah, and again, this is where that roles and responsibility piece is really, really important. Because what I'm asking for from, let's say an engineering group. So an engineering group typically consists of architecture, developers, quality assurance, and then DevOps. People who manage and run the underlying production infrastructure. My expectation of that team is consistency. Say what you're gonna do and do what you say.
[00:31:07:17 - 00:31:26:01]
Have very good engineering standards that leads to very good high quality output, leads to a very stable, manageable production infrastructure that can scale. And in that comes all the aspects of cost control and all of this sort of stuff. But you're absolutely right. So when I then look at these unknown products that are coming in,
[00:31:27:13 - 00:31:32:00]
what am I doing with that? Somebody comes and drops a ticket on my table and I'm supposed to deliver that consistently.
[00:31:33:00 - 00:32:11:08]
So that's why we introduce things like refinement. Because part of the refinement process is to see that big ticket, that outcome that's fixed, that has a defined scope and defined delivery time, and to actually challenge it. And first say, okay, that's too big. We have to break that down. We have to start to break that. And usually that starts with the architecture team. So the architecture team will step in and they'll say, okay, from an infrastructure, from a software architecture perspective, what's the most logical approach to this problem? And it's also where the senior engineer step in and say, hey, this problem's massive.
[00:32:12:19 - 00:32:59:10]
Are we sure this is actually what we want to do? Why don't we break this down into these chunks, get these chunks in the right order? And you start to bring the work down into much smaller, much more manageable implementation things, which you can then start to set your, yes, I can deliver that. So as part of your role, it's actually to challenge what's coming into your pipe to maintain the consistency. Because what I'm expecting the engineering group to do is deliver me consistency, high standard deliverables. What I'm expecting the product organization to do is to work with the engineering team to achieve that right balance of breakdown. Because you'd be surprised the number of times I've been told that this project is fixed scope, fixed cost and fixed time. And when I've actually gone back to them and said, okay,
[00:33:01:12 - 00:33:48:20]
if the scope is fixed and the time is fixed, there's too much work. So what order do you want work in? And suddenly a third of the work is no longer as important in the fixed scope project. So the scope isn't fixed. You can actually figure out, can I increase the budget? Can I adjust the timeline? I can set that based on a realistic expectation. Or do we change the scope? But you only ever get two. You can't have all three. That's not the world we live in. I'm conscious of time. So as time is escaping us, so roles and responsibilities, anything you wanna finally add on that before we move on to the next thing? No, no, I think we're good. I think the next part we'll move on to is respectful challenge. Because I think we were just talking about it there. When we talk about defining the scope of the work,
[00:33:50:23 - 00:33:52:11]
I find in engineering,
[00:33:53:19 - 00:34:15:12]
there's a natural approach to challenging. So again, it's very black and white, but there's nearly always five, six, seven, eight ways of solving a problem. So the teams will have a very direct and honest discussion with each other, and they'll settle on a way of doing it. And you'll find that the challenge will come from infrastructure, it'll come from DevOps, it'll come from all sorts of places. But it's very respectful, and they always agree.
[00:34:17:02 - 00:34:41:09]
When I talk about respectful challenge, I'm actually talking about creating an area for psychological safety, for teams of people to come together. And it's usually the space where I bring engineering and product as the natural one. But it's also marketing and sales has been involved in these. Where we want to have a discussion, and quite often, because engineers are natural problem solvers,
[00:34:42:12 - 00:34:53:23]
they want to ask the why, because they understand when you bring something to them, you're bringing them, "Hey, could you build this?" Well, the answer is yes. I could build anything. But tell me why.
[00:34:55:04 - 00:36:06:14]
Tell me why that's important. Tell me why that's important to the customer. Now tell me why that's important to the customer's business in this area. Now tell me why that's important to the customer business in the area with the impact of revenue that they're having. You get to the bottom of, well, this customer of theirs needs this particular nuance and this particular piece of work doing in this particular area. Well, that's a much smaller request than what you were originally asking for us to solve. We can actually do that very quickly. So it's a really important aspect, but it's also an important aspect for them to receive the challenge. When they say, "Hey, this is a huge piece of work." Why? And they start to break it down. And when they start to break it down, they start to understand that actually this might not be as big a challenge as we thought. So we're turning it down into that consistency sort of space. So we get confidence in what we're hearing. So yeah, respectful challenge, I think is an absolute hallmark of thriving teams. You typically see it in a thriving team, individual team anyway. But when we talk about different teams interacting, that's where it's really, really key. And the objective that we're looking for is just again to get that confidence and consistency up.
[00:36:07:20 - 00:37:04:12]
I always like the metaphor of like a match, right? If you think about how, if you take a match out of a matchbox and you were just to run it along a smooth surface, it'd never ignite. You've got to get that rough bit on the side of the matchbox. And then, then that's how you get the flame. You need that friction. You need that kind of, to my mind, this respectful challenge, this natural friction that's created. And if you get that, that's when it ignites. Whereas if you're all just saying yes, and not really, there's no friction, it just doesn't quite spark in the same way. You're exactly right. I mean, I've got a very real world example. I was working on a product where we'd made a decision that our go-to-market was going to be quite small. So to save us cost and effort in product and engineering, we went with the manual provisioning process, which our customer success team was going to handle. And they were on board with it. But that was when the scope of the project was, 50 customers in our first quarter.
[00:37:05:17 - 00:37:21:06]
Well, as we moved forward with development of the product and we got some customer insight from our early customer adoption, we realized that this is big and we need to get this out faster. But suddenly 50 customers turned into 500 and then 500 into the entire customer base of several thousand.
[00:37:22:08 - 00:37:55:20]
That's a big ask. And the customer success representative came to the group, which I was absolutely loved to this day, and actually said to the group, hey guys, we made a decision based on a criteria that was different before. I need you to understand that this is now thousands of customers you want us to enable. The propensity of error in a manual process is there, multiplied now by thousands of times we have to do it. And the resource expenditure we're going to have to do is now very, very high. Can we rethink this decision and can we do something different about this?
[00:37:57:05 - 00:37:57:14]
Do you know?
[00:37:58:15 - 00:38:01:06]
Absolutely yes, we can. (Laughs) Yeah, yeah.
[00:38:02:08 - 00:38:29:00]
That wasn't me that had to say that. That was the team that turned around and said, absolutely yes, we can. And it's really important that we had that environment that that representative from that, outside of the product delivery team, outside of the excitement of what we were building, brought that very real challenge to us. That thing that we'd made a decision on, but the criteria of that decision had changed and challenged us on that decision. And yeah, it was the right call.
[00:38:30:07 - 00:38:40:23]
Great example, great example. Next thing, I think is it this your final theme? It is, it is. So this one's a quick one. So this is talking about personal development. Because when we talk about thriving teams,
[00:38:42:10 - 00:39:25:06]
this is a muscle and a skill set that you have to develop. There is no book you can go read while there's lots of books, but there's no specific book you can read that I think will just endow you with the knowledge you need to do this well. So from my own personal experience, I invested in practical presentation skills. It's absolutely critical in this process or whatever level you're operating in, whether it's engineering, product, marketing, sales, you have to be effective at telling a story. You have to be effective at handling challenge and creating an environment for respectful challenge. And it does require some training to do that. I think gaining experience in different roles,
[00:39:26:07 - 00:39:30:06]
funny story I have is a developer who showed interest in doing pre-sales.
[00:39:31:07 - 00:39:56:19]
And I was like, do you really understand what technical pre-sales is? And he said, yeah, yeah, I really wanna go for it. Okay, so set him up with a pre-sales consultant, gave him some of the materials, we gave him some training, and then he attended, I think four or five pre-sales meetings with this consultant. Came back after a couple of weeks and said to us, loved the experience, really, really glad I did it. Decided I definitely don't wanna ever do sales.
[00:39:59:05 - 00:40:34:16]
(Laughs) But it's skills that the career trajectory took, actually moved more into learning and development, encouraging people to grow and take on different skills. And it was really nice that, that kind of shone through how we took that on. But yeah, it's really important when we're looking at these thriving teams, you can do the best you can around the process, you can set up structured comms, you can define your roles and responsibilities, you can have the best goal and purpose and mission and vision that you could possibly define. But if you are not investing in your people, they're gonna struggle, maybe you have to do that.
[00:40:36:20 - 00:41:25:14]
So I think that's the five themes, is it you just wanna run us through what just to, and then we'll do some quick key takeaways. So what are those five themes on making a team that thrives? So we talked about a purpose, which involves setting the mission and vision, and goals and project. So it could be set at different levels, but the idea is to convert a group of people, potentially walking in the same direction, to a group of people walking in the same direction with a common goal. That is the definition of a team. We talked about communication and process. So really, really important, we understand structured and unstructured comms. And it's really important that the process that we put in place around this, it kind of mimics common sense. And it's the most effective thing for what we're trying to deliver. But ultimately, we're trying to get confidence and consistency out of the groups that we're working with.
[00:41:26:14 - 00:42:22:17]
We talked about roles and responsibilities, and the need for both the team and the individual accountabilities that come with those. We talked about respectful challenge. Respectful challenge is just the hallmark of a thriving team. You know, if we create that good environment where different people and different teams can interact, you get the collective knowledge base. And the collective is always smarter than the individual, always. And then finally, we talked about personal development. This is something that you need to invest in. My own personal example, effective presentation skills. It's one of many, many different courses that I've done, which have had a real impact for me. So those were my key areas we talked through. That's probably the key takeaways I've covered for you as well. Yeah, yeah, key takeaways. Yeah, I mean, for me, the bits that really spread to my page, I like thinking about that balance of structured communication versus unstructured communication, the impact of both.
[00:42:23:19 - 00:42:27:22]
And thinking about that, I thought was really interesting.
[00:42:28:23 - 00:43:24:17]
I love this idea of the respectful challenge. We don't want a team of yes people. We've got smart, motivated people. We want to harness all the horsepower that they've got so that we can be better. And that was really good. And then just the investing in people, literally without people, the team would be nothing. And if those people are skilled and trained and have got great skill sets, then they're of course going to be more effective for you. They're going to be better. And it's interesting, we think of cycles. It feels like the tech world's going through a bit of a low cycle at the moment. And those are often the things that people get rid of first. Like, oh, things are a bit tough. We don't need to invest in people. But actually, when things get tough, that's when you need people to be really effective. Because after the world's been made redundant and the other half are left carrying the can. I think that key word you use there is effective versus efficiency.
[00:43:26:01 - 00:43:29:01]
I'm a big believer that you...
[00:43:31:02 - 00:43:47:09]
There are things you can do to improve efficiency at the organization level, but you make people more effective. And that's what the personal investment does. You just make yourself more effective in what you're being asked to do, but also more effective in what you want to do next.
[00:43:49:16 - 00:44:04:04]
You're right, I think the tech industry is a bit of a low, but I took on sales in 2008. And if anybody remembers that, that was a financial crash. Yeah. That was an interesting time to go into sales. Yeah, I bet. I learned an awful lot.
[00:44:05:13 - 00:44:14:04]
And yeah, it's these types of times where I think you have the best opportunity to learn. Even if it's your own personal investment in yourself,
[00:44:15:09 - 00:44:16:13]
but it's absolutely key.
[00:44:17:15 - 00:44:47:03]
Brilliant. Well, just before we wrap up, if people have loved what you've been saying, wanna connect with you, wanna find out more about the things that you're doing, how can they get into it, really? That's cool. So the business I've started is called Vantage Effect. Okay. That's Vantage Effect, E-double-F-E-C-T. And you can find me on LinkedIn. So I have a very easy profile, Lee Ivan Smith, L-E-I-G-H, I-V-A-N, Smith.
[00:44:48:07 - 00:44:55:01]
And I think I'm the only one on there, but feel free to send me a connection request. You'll find information on there, how to book time with me.
[00:44:56:02 - 00:45:09:11]
I'm spending my time now helping businesses do exactly this, create thriving teams, look at effective strategy, and really help them achieve elevated results in products and technology delivery.
[00:45:11:05 - 00:46:02:19]
I'm very focused on products and technology teams. I love this space. I'm very passionate about it. It's something I, every team I've worked with, I've learned something new, and every team I've worked with, I think I've delivered value to, which has been just great. I think the last call out, Ben, I've gotta make as well, is that personal investment that people can make. I've worked with you, like I say, in field engineering, that's where we started. But at least two of the businesses I've worked with, I've engaged with you on training courses for my team. One was the actual whole team having your remote training sessions for effective storytelling. I know a few of the guys who did that took a lot from it, and still use the skills and techniques that they heard today. They were all engineer and senior engineer-focused people. And then most recently, one of my team members who's strongly encouraged by a very supportive CTO,
[00:46:04:01 - 00:46:07:08]
took on a presentation to a large group of people
[00:46:08:11 - 00:46:45:21]
to talk about the area that they were passionate about. And they did an absolutely stellar job, but they also had someone on one training with you, particularly to help them create the content and some really good presentation techniques which all shone through in their session. So I would absolutely recommend that folks engage with you on your engagements around storytelling. Oh, well, thank you very much, Lee. That is very kind of you to say. So thank you very much. Well, we are at time. So final thing I want to say is, you know, thank you so much for your time, your energy, your insight, everything you shared with us. It's been an absolute pleasure to have you on the show. Thank you,
[00:46:48:02 - 00:47:08:05]
Don't go yet. Remember to subscribe to the podcast and rate the show. It really helps us grow and book new great guests. And remember, if the podcast isn't enough for you and you want weekly micro learning delivered straight to your inbox, sign up to the TechWorld Human Skills Weekly. Head over to www.techworldhumanskills.com to sign up.
