The Rise of the All Rounder Why Cricketers are Better than Footballers

In this session, Peter Wallace discusses T-shaped leadership in the age of AI and how it can enhance value delivery in product and engineering teams. He draws from his extensive experience as a CTO in fintech and gambling sectors, comparing the leadership styles of successful captains in cricket and football to illustrate the significance of team dynamics. The talk explores different skill models, including T-shaped, M-shaped, and V-shaped individuals, emphasizing the importance of psychological safety and collaboration. Peter highlights Google's Project Aristotle findings, which identify key dimensions of effective teams and suggests practical approaches for fostering a supportive work environment and improving team performance through AI tools.

I'd love to welcome Peter Wallace to the stage. Peter has scaled high performing teams at Lendinvest Sporting Group and Camelot Lotteryies. And his topic, I mean, I'll summarize this a little bit, Peter, but uh why cricketers are better than footballers. I guess that's what you're going to talk about. >> Yes, you can you can feel free to disagree if you have a particular pawn for one sport

over the other. Um, so good afternoon everyone. Um, I'm here to talk to you today about T-shaped leadership in the age of AI. Hopefully some of you will be familiar with that. Um, how this can improve value delivery across product and engineering. All backed up by lessons learned by u me and my team scaling high performing teams at Lend Invest. And we'll touch on why I think

cricketers are better than footballers or are they? Um before I get into the meat of it, uh a little bit about me. Um I'm Peter, uh following a consulting career at Accenture and Capgeemini. I was chief architect at the National Lottery Camelot before being a three-time CTO with over a decade of experience scaling fintech gambling businesses across ETX Capital, Sporting Group, and um most lately Lend Invest.

Um, when I originally agreed to this talk, I thought, what a great opportunity to use a sports analogy, lean into another industry that has high performing teams and compare successful England captains across cricket and football and their high performing teams and successes. So, cast your minds back. Um, picture the scene. In November last year, Ben Stokes was about to head down under to take on a world-class

Australian team in the Ashes Series. Surely that was going to be a fertile ground full of examples of exemplary leadership and success. And then this happened and poor performance. Before I get into unpicking this some more, I'd like to switch tack a little bit and talk a little bit about different types of people and their capabilities. So to understand different people's capabilities and skills, um it's sometimes

useful to use a model. Um this model has arguably been around since the 1980s. I'm sure those of you with gray hair will have, you know, seen this before in your your time. Um it's been mostly attributed to Tim Brown who is CEO of design agency IDO uh when he was explaining the sort of people that he thought or felt best performed in interdisciplinary teams. So these

are the people that he called T-shaped people. Um over the years this model has been extended and modified to cover sort of four types. Um starts with eyeshaped people. Uh this covers many types of people. For example, at the start of their careers when they're developing deep skills in one specific area. In our engineering world, uh this would normally be a software language, a skill set associated

with a specific role like QA or DevOps. Uh T-shaped people are those that combine this deep knowledge in one area with a broad understanding across many others. Many of us CTO's in this room are are naturally more T-shaped. Uh these horizontal areas could be things like um compliance, finance, supplier management, vendor ne negotiation skills, people management, mentoring, recruitment. I mean it's it is what it needs to

be. Um Tim Brown argued that having both depth in one area and breadth improved cross functional working in teams and this diversity produced higher performing Over the years, this model has been expanded to include Mshaped people. So, those with deep knowledge in multiple areas, so possibly gained in different industries or working in different architectures or systems. And V-shaped people where the broadening is in adjacent areas upon

the building upon the existing depth where an engineer may for example be an expert in several complimentary software languages or frameworks. you know front-end engineer knowing both Typescript, React and Angular frameworks for example. So as CTO's you you're obviously all aware that our role nowadays is broader than than ever before. We we're expected to have capabilities um in other areas rather than just software engineering. So you

know commercial acumen, regulatory awareness, people leadership, uh vendor management, board communication, product design, um to a degree we expect to be experts in all of these things. How we acquire skills and experience in these areas of course is now changing. And that's where AI can help obviously um it builds functional literacy uh across the horizontal bar way way quicker. For example, in contract structures, you know, AI

can summarize lengthy contracts and distill key negotiating points way quicker than than you can um as a human. Financial management, um understanding uh you know, balance sheets, being able to talk to finance teams and language that they understand, you know, P&L, budget forecast, cash flow, why cash flow is important. You know, AI can help you understand, appreciate and empathize with them more. regulatory frameworks, you know, hey,

um, nobody really likes to spend a lot of time with compliance. I mean, the amount of compliance training I've done in the over the decades is is more than I'd ever care to remember. But keeping on top of evolving compliance needs and, you know, working effectively with those teams can be shortened. You can get better at it if you use AI. and working with boards. Um, building,

uh, like we heard in the keynote yesterday, building that little persona that acts like that board member and simulates the sorts of questions that they will ask you, I think was incredibly powerful. Um, creating draft strategy documents, understanding board perspectives, I think AI can help with all of those areas and build, you know, that broader set of capabilities quicker. However, as many have already touched on, using

AI um you know, you have to remember it's only a tool. Um it will amplify the good and the bad. Um it provides speed but sometimes at the expense of substance. It can't replace lived experience nor professional judgment nor as we heard yesterday provide empathy. So accelerate the learning curve, broaden, deepen your knowledge and capabilities, but remember pattern recognition is not a substitute for professional judgment. So

we understand a bit about people and hopefully you understand how the different people in your team are shaped. But how can you improve performance of your team? So there's another piece of research which was mentioned earlier today which comes into this. Um who's heard of Google's project Aristotle? Wow, great. I'm glad some people have. Um so this was a two-year study completed in 2014. So this is

knowledge that's over a decade old that examined 180 teams at Google to try and understand why some are more effective than others. So it was a comprehensive study. Um there's I'll provide a link at the end of the um presentation if you want to go and read the the the outcomes of that study in more detail. However, the key finding was that teams that excelled in the

following five dimensions were consistently more effective and higher performing. These were psychological safety. So can I take risks and feel vulnerable safely? Dependability. Can I count on my teammates to deliver? Structure and clarity. Are goals, roles, and plans clear? Meaning, is the work personally important to us? And impact. Do we believe our work matters and creates change? Of these five dimensions, psychological safety was by far the

most important. Google provides some really good u guidance um for managers on how to improve this. Um again, I recommend you read that. It's only a one-pager. There's there'll be a link at the end. Of course, how you go about improving these dimensions because everyone kind of reads that side and goes, "That's great. Yep. Yep. We've got that." Um that's all really obvious. We'll just do that.

But you know how you go about doing it you know will depend a bit about the context and you know of your culture your environment and where you're starting from. What I'm going to share with you is what I did at Lendinfest um and what worked for me and my team. And hopefully some of those points might resonate some of them might be applicable to your context.

It's also obviously worth noting that none of these dimensions are technical. So, you know, just pause there for a moment. So, in Google, the highest performing teams didn't write better quality code faster. They weren't better at their craft. They just had higher levels of psychological safety, dependability, structure, clarity, meaning, and impact. Mostly people centered um attributes. So, what did I do to improve psychological safety at Lendin

Invest? Um well, we focused on uh frequent quality feedback loops such as uh fortnightly product team retros, monthly team lead retros, weekly demos, and we built a culture where it felt like we're all in this together through um active enforcement of a no blame culture top down. Human errors celebrated as learning opportunities. plenty of encouragement, support, and celebration. And above all, making sure everyone was present and

inclusive. So, all sounds good and obvious. So, what what did I personally do? You know, you kind of yros, yet we've done all those things, but you know, did it really make a difference? So what what I did was for example um if we looked at you know be present and inclusive that meant that if you were having a face-to-face meeting even one person or many people

shut your laptop don't sit there with it open it's a distraction it also shows that you're not actively listening to the points that are being made to the other people in the room you know acknowledge what other people are saying reflect and mirror ask lots of questions you those active listening behaviors that shows that you're present. Encouragement to me meant, you know, there's a good example when

a team member was was volunteered for giving their first talk at a company all hands meeting. you know, making time to rehearse with them, you know, giving them positive feedback, making sure that they owned and felt confident with the content that they were going to present, providing additional context, you know, where needed, checking in regularly in the run-up to that session about how they were feeling. Are

you feeling all right about it? What are you worrying about? Show some empathy. Realize it was a big deal for them on the day, you know, be there in the room. Don't just join the meeting remotely like half your team. Actually sit there in the room to be there with them. Um asking a pre-aggreed question. You know, nobody likes a silence at the end of their um

presentation. You know, thanking them publicly on Slack afterwards. Basically going the extra mile. Sounds obvious, but you have to do all these steps to really feel for them to feel supported and encouraged in doing something that would have been quite out of their comfort zone for Like many companies, you know, things do go wrong. Um, humans do make mistakes. you know, when things went wrong at Lend

Invest, um what what I did was you quietly ask typically the team lead, you know, come on what happened on a, you know, DM on Slack to try and get a bit more context and then, you know, contact the person who made the mistake and reassure them that, you know, we're keen to learn from this, that you're not going to blame them for it, but, you know,

you're going to need them to sort of engage in that retro process. So involve others in the team, run a retro and try and get that sort of wider awareness around, you know, how the mistake, you know, came about and uh and how we can avoid um making that mistake in the future. Again, treating it like a learning experience, not a blaming experience. Communicating upward to the

stakeholders, managing the CEO's expectation. Hey, we had that outage. What went on? Who did what? Who messed up? you know providing that protection is really important for your team. You know own it and don't expose your team when it came to um dependability, structure and clarity. It's re it's really the simple things that make made the biggest difference. So um on delivery cadence you know we had

very visible delivery measured through dorometrics. uh we had efficient flow enabled standardized software delivery cycle across the team. So you know we just had a very very simple way of measuring everybody across the team in the same way. So there's no um divergence around well I'm being measured against these bars and they're being measured that way. It was just all the same for Uh clear roles. Well

this is one I I find quite interesting. um in all the smaller sort of scale up organizations I've worked in um there's a huge amount of confusion because there's lots of madeup job titles and roles you know there's too many heads of directors of because you know they were one of the original 10 people who joined the company and now they've been there five years they have

to be a director you know it's absolute nonsense and you have to kind of work out how to fix that as a problem you know these people aren't heads of anything typically you typically don't even have a team. They've just been there longer than everyone else. So, um what what I did at Len Invest is we just created a really really straightforward career path structure that had

people managers and individual contributors. You know, it's not it's not rocket science, but we cleared away all those heads of director of roles and made it very clear kind of what each of the roles were, what they were there to do, how they were going to be measured, what it took to get promoted, and then divorced that whole pay and reward from the role because they got

themselves into a situation at Len Invest where where the highest role as an IC was senior engineer. So, it's like, right, I'm a senior engineer. I've been here a long time. I want to earn more money. What do I do? Wow, I'm going to have to become a team lead. So, you had IC's who were becoming people managers because a team lead paid more than a senior

engineer. So, you created all these bad behaviors where you had the wrong people leading teams because they didn't have necessarily the skills and capabilities to do that. So, you have to kind of divorce the two. And in this case, we created more IC roles above senior. So those people had a career path and didn't feel obligated to have to go and try and lead a team unless

of course they wanted to, you know, but options were important. We also got rid of um the title junior engineer. I I hate junior engineer. I think it's really demeaning. You're just a software engineer at the start of your career. Um but you know, it was in use in other parts of the organization. We had junior recruitment consultants or whatever. and and I just I think personally

it just didn't work for me. So I got rid of that and we just made it really really simple from engineer mideng engineer senior lead the um on the accountability side you know it was just the straightforward using that weekly roll up of outcomes that the team have achieved into the monthly report that then got shared to the whole company. It was about that lineage so people

could see exactly you know what they had done at that micro level and how that then impacted something at a monthly and whole company level. Also having Slack channels public by default helped so that there was no hiding. Everyone could jump in and see what a team was doing. So, you know, they're very open in their communication style, but also about who was responsible for doing what.

To help improve collaboration across product and engineering teams um and ultimately working with business stakeholders, we use some research from the Silicon Valley product group um to help us understand the differences between delivery feature and product So it starts with you know delivery teams. So these are also typically known as a scrum team, a dev team. Uh they are there to deliver projects. Um the product manager

is typically the backlog administrator or it's called a delivery manager. The product designer is really just making the changes to the UI. You know they're measured by how many projects they delivered that month year. you know, they're effectively trying to do agile, but they're constrained within this waterfall process. Um, and you know, ultimately the business value is owned by the project stakeholders or the steering group that's

running those Feature teams, you know, this is at Len Invest. We like to think we had product teams, but actually we had feature teams. you know we you know we were product in name we called ourselves product teams we were delivering features um and you know we were trying to measure you know what we were doing but ultimately you know we were doing what business stakeholders told

us to do go and deliver these 10 features you know I'll determine you know what 10 are important because I know the industry better than you do um and then on the right hand side is what you know Marty Kagan and and the Silicon Valley product group would call a proper sort of product team. So it's what some of you will recognize as a an uh crossf

functional proper product team where their purpose is to solve problems in way the customer loves yet work for the business. I love love that phrase as a purpose. You know the product manager is the one who owns that value and business viability risk which ultimately leads to the impact of the features they're delivering. The product designers are responsible for leading that u user coming up with interactive

designs not just changes to UIs totally measured by outcomes you know and you're following a total agile process from discovery all the way through delivery and ultimately the product manager owns that business value using this framework and actually writing it down and having an honest conversation with the team around you know where are we now in these three kind of buckets and where do we want to

be basically gave us the permission to then talk to the business stakeholders and say hey you know being on the right hand side is good we want to be there but you're going to have to give up that ownership of value and you're going to have to work with us more collaboratively through our pri prioritization meetings to help us articulate what that value is but the product

manager is going to be the one that says actually we think that's got the higher value that's what we're going to do first over that. So less of that gut feel we need to just build this thing to a more datadriven user research-led product delivery process. And that helped to really create a lot of meaning and impact across the team. But it it was only really facilitated

by drawing a pitch like this using some research grounded and um and being honest about where we were and what we'd have to change to get there. final part of um Google's findings are in the meaning and impact area. So getting product and engineering teams to work more collaboratively was key. This meant really making the end to-end process from discovery through define develop and deliver more transparent.

So connecting the engineers who are writing the code all the way through to those business outcomes created that meaning and impact for everybody in the team not just the product managers. Yeah this LinkedIn post um is an example uh where we celebrated uh a change um to our product transfer process. I won't go into explain what that is but basically our our um uh product designer Conair

had gone out and spoken to all these mortgage brokers and said you know kind of why aren't you using our product transfer process come back with a bunch of research and said this is what we need to do and here's the evidence around why it's going to be successful and then we made that change and we communicated it and it was a fantastic success. So it was

the first thing we did once we'd understood how we wanted to work as a product team and it was really important to publicly celebrate that as a productled change rather than a business stakeholderled change. So hopefully some of those points resonate with some of you um here and maybe applicable in your your context in your business. But really, you know, I know you've all really come to

hear the proper question, which is kind of who's the better captain. So, is it Ben Stokes or is it Harry Kane? So, Ben Stokes, well, if we look at him, you know, he's good with both the bat and the ball. He's he's an allrounder. You know, he leads his team by example. Um, and he does that. He gets the best out of his team through his own

performance. You know, he's the guy who can change a game, the outcome of a game by his personal performance. So, arguably, he's T-shaped or possibly Mshaped. But did that make him a better captain? You know, did that help the team perform? You know, Nash's, you know, his bowling, which you can see up here, um, was solid, you know, he he was the second best performing England bowler.

His batting was poor, but maybe that's because the Australians are above him on the bowling chart. His record as captain for England cricket is better. You know, overall for players who've captained England over the last for more than 10 tests, um he has the highest win percentage at 55% for the last 45 years. He's the most successful England captain on that metric. So arguably, you know, he

does achieve success. Conversely, I'd argue Harry Kane was much more eyeshaped or possibly slightly narrow T-shaped. You know, he's scored over 500 professional goals across all tournaments. You know, he is literally defined by that one metric. That's the one thing he does. You Google how successful is Harry Kane, it is just goals, goals, goals, goals. But if you look at his record um of England's team performance

when he was captain, you know, his win percentage is 69%. So it's greater than any cricket captain ever. So maybe arguably he is the better captain or certainly the more successful But what about the team performance? Well, you know, T-shaped leaders all around us, you know, would we would naturally think would be better at captaining a team. you know, have the baller capabilities to be more successful.

But in the Ashes series, the team failed to excel in these five key dimensions. You know, Stokes blamed bowlers for bowling inconsistent inconsistently and destroying psychological safety in the team. The team's performance started to literally drop, you know, drop catches. You know, players could no longer rely on each other. The bazball game strategy, the game plan was inconsistent. Players not really understanding, you know, clearly what they

needed to do with a bat and ball resulting them throwing away their wickets with reckless shots and bad behavior outside of the game, you know, driven by a lack of real meaning and impact. Compared to the cricketers, the England football team have come a long way since 1996 in improving psychological safety under Gareth Southgate. You know, these are the two images um across those years of Southgate

obviously missing penalt or have penalty saved and then more recently in 2024. I'd argue that the team greater team acceptance effectiveness drove the performance more than the individual captain in these cases. So in summary, if you want to improve performance of your team, focus on the team effectiveness and the five dimensions that Google highlighted and most importantly psychological safety. You know, this is easier as you broaden

your capabilities and become more team-shaped, become more of an allrounder and use AI to accelerate and amplify learning new capabilities and deepening existing ones. Thank you. That's all I've got. There's there's a link tree on here with links to the wider content and the presentation. So, please do take a moment, scan it if you're interested in reading more and learning more or connecting with me. >> I

think we're out of time. >> Let's see. >> I know. It's flashing at me. It may be we're out of time. I don't know. If they don't put the slido up, that means you're out of time. >> I think you may be out of time. Hopefully you guys can >> I'll be around for the rest of the day if you want to ask questions though. >> Peter

Wallace, thank you so much. Did you answer the question though? >> Well, you know, I think ultimately Ben Stokes has the capability to be better captain, but the team beneath him aren't >> Oh, okay. What a way to get off the stage, right? No, let's give him a round of applause. It'll be an a lot nicer. Thank you, Peter.