We've all worked with "heroes," great professionals who frequently "save the day" in the company. What if we'd instead prevent the day from needing the saving altogether?
Dan Abel believes in 10x teams rather than 10x engineers. Listen to this episode to learn more about it and what aspects to concentrate on when setting up the teams for success.
Find Dan on:
- LinkedIn: https://www.linkedin.com/in/daniel-abel/
- Twitter: https://twitter.com/twicezer0
- Dan's 10x Teams website: https://ten-x.team
- Dan's blog: https://engineeringandcareering.co.uk/
Mentions and resources:
Follow Quality Bits host Lina Zubyte on:
- Twitter: https://twitter.com/buggylina
- LinkedIn: https://www.linkedin.com/in/linazubyte/
- Website: https://qualitybits.tech/
Follow Quality Bits on your favorite listening platform and Twitter: https://twitter.com/qualitybitstech to stay updated with future content.
If you like this podcast and would like to support its making, feel free to buy me a coffee: https://www.buymeacoffee.com/linazubyte
Thank you for listening!
We've all worked with "heroes," great professionals who frequently "save the day" in the company. What if we'd instead prevent the day from needing the saving altogether?
Dan Abel believes in 10x teams rather than 10x engineers. Listen to this episode to learn more about it and what aspects to concentrate on when setting up the teams for success.
Find Dan on:
- LinkedIn: https://www.linkedin.com/in/daniel-abel/
- Twitter: https://twitter.com/twicezer0
- Dan's 10x Teams website: https://ten-x.team
- Dan's blog: https://engineeringandcareering.co.uk/
Mentions and resources:
Follow Quality Bits host Lina Zubyte on:
- Twitter: https://twitter.com/buggylina
- LinkedIn: https://www.linkedin.com/in/linazubyte/
- Website: https://qualitybits.tech/
Follow Quality Bits on your favorite listening platform and Twitter: https://twitter.com/qualitybitstech to stay updated with future content.
If you like this podcast and would like to support its making, feel free to buy me a coffee: https://www.buymeacoffee.com/linazubyte
Thank you for listening!
Lina Zubyte (00:05):
Hi everyone. Welcome to Quality Bits, a podcast about building high-quality products and teams. I'm your host Lina Zubyte.
(00:15):
Have you heard of the term 10x engineer or developer - a person that knows everything and saves the day and is a hero? If yes, what are your thoughts on that? And you can hear from my voice that I'm not the biggest fan of that. So when I saw an article about a 10x Team concept, it sparked my interest. I was like: this is exactly what we're talking about. We're talking about high-performing teams. We're not talking about a high performing engineer, because I feel like it all depends on the context and the environment we put people in. So in this conversation, I'm talking to the author of the concept of 10x Teams, Dan Abel. Dan has over 20 years of experience as a software engineer, lead, consultant, and principal. He's full of great ideas and understanding about what it means to have good teams. And in this episode we're talking about 10x team's concept, what it is and some concepts of it, like flow and safety, as well as where to start if you do want to have a better team in general. Enjoy this conversation!
(01:49):
Hi Dan, welcome to Quality Bits.
Daniel Abel (01:53):
Hi there. Thank you for having me.
Lina Zubyte (01:55):
Would you like to play a little game for introduction?
Daniel Abel (01:59):
Sure.
Lina Zubyte (02:00):
So once I went to a conference with one of my colleagues and we were having lunch and we met some new people and my colleague decided to play this game, which is: you do not say your profession when you introduce yourself. You say what you do, you say all kinds of things - what you are as a human, but you do not say, oh, I am a QA, for example. So how would you describe yourself without using your profession as a word?
Daniel Abel (02:32):
Oh. Okay. I make electrical signals do things that they didn't know they wanted to do. How's that?
Lina Zubyte (02:39):
Wow, that's brilliant.
Daniel Abel (02:42):
I guess I also make the water do things it doesn't want to do as well. I go kayaking and I show people how to make kayaks go.
Lina Zubyte (02:50):
That's wonderful. I also like how even if you could use a lot of different words, you explained it in a very simple language, which is brilliant. We can speak in simple terms and just say, okay, I work with water, I work with electrical signals.
Daniel Abel (03:06):
There's a great book by the person who does xkcd who tries to explain really complicated things using minimal language. I think he must have spent so long on it, it's so much fun to read that he's trying to explain how a rocket works with using just the most popular, I think it's like 200 or 500 words in English language.
Lina Zubyte (03:28):
Wow. That reminds me of this quote which says "I would have written a shorter letter, but I did not have time."
Daniel Abel (03:37):
Yes. That is my life.
Lina Zubyte (03:40):
It is actually a science to make less is more a reality.
Daniel Abel (03:46):
This is true and I'll probably end up in this conversation using some complex term that's very important in my head. So do call me out and I've demonstrated that I can use simple words. So ask me to do that if I get well deep into the Dan world in my head.
Lina Zubyte (04:04):
Will do. So I've heard about you and I'm very glad that we connected after I've read your article about building 10x teams and I did hear before this term of 10x developer and I hated it. I despised it. I despised the whole notion of it because I believe that hero culture is very unhelpful for software development because software development is not a one man show. It's teamwork. So reading about 10x teams really hit home for me. So it sounds like a concept I would love and I really enjoyed your article. Could you explain about your motivation for creating this concept of 10x teams? What sparked the idea?
Daniel Abel (04:54):
Sure. Yes. And absolutely agree with the feeling of the frustration when you see the hero culture. I remember many years ago being in a company, working as a consultant, you get sent many places and see many cultures and someone said the hero culture here is so bad that people will pour, metaphorically, pour petrol on themselves and light it, put it out and then get acclaimed as a hero. You know, it's like people will deliberately do bad things to fix them because it's the only way to be seen and praised. We don't want that to prove it very clearly. And so how did I get to where I am recently? So I got made redundant back in December and I'm sure anyone who has been made redundant knows - it doesn't feel great. I needed to dig myself out the hole, find a great new job, and creating new things makes me happy.
(05:46):
As I started playing around with ideas, I needed data points for interviews anyway. So I thought what makes teams great? How do I make great teams? How do I be in great teams? And what do I care about? And then doing lots of interviews gave me this new perspective. It's like going on tour, you're seeing all these snapshots of different cultures and values. Some great and some I really did not like as, as you say, they were very focused on the individual to the point of for me, toxicity. The interviews these days, they're very value-based. Your job as an interviewee is to understand the values made to answer questions that your experience based in their values. And I was trying to do this and going, I don't want to work here. Which is maybe helpful, maybe that's what they want. Some of the values exposed were very much, I'm the case that if you've got a team and one member of the team is doing great and one's team is doing badly, where do you spend your time?
(06:39):
And the right answer was spend it with the person doing really great. That guy's doing badly. Yeah. Huh. Well, he's not valuable. Wait a minute. You might have two valuable people if you invest in the right place rather than one valuable person. There's only a limit to how great a one person can be and there's a much greater limit to how valuable a team could be. So to cut a long story short, this really started to align with the notes I had about what I cared about. These feelings. And so I noticed that there was a domain available. So I registered the domain, started writing. Really an experiment in focus blogging. I write blogs like many people do, but it's like here and everywhere. And it's like, what if I said this website is for this topic, what is it gonna bring out? And that's where it started.
Lina Zubyte (07:27):
And how has the response been so far?
Daniel Abel (07:30):
I think it's positive. It's so hard to measure in the sort of ethernet of the internet what's going on. But I mean, having you contact me is a great, great indication that I'm reaching people I did not know before I wrote the article that said, yeah, that's important. And some of the slacks I sit in, someone said, Dan, can you tell us more about that? So I think it's resonated. I don't think it's a new idea. I think it's the idea that's been ready for a while. People want it and there's time to push back against the hero culture that seems to be rising again in the way tech's been delivered the last couple of years.
Lina Zubyte (08:03):
Yeah, I believe that it's the shaping, the new restructuring, remarketing of the idea that can make it very powerful. Having good teams is maybe not a new concept, but wrapping it up in a nice term and again talking about it can really help to remind ourselves.
Daniel Abel (08:28):
I think you're right that maybe finding things, memetic things that are sticky is really important these days to go against other ideas that maybe are sticky.
Lina Zubyte (08:37):
Yeah. Actually one of my previous guests, Steve Upton, he's a such a philosophical human being. I love to talk to him about quality for hours. And he is obsessed with Cynefin. And he said that Cynefin's author basically on purpose used certain words which are more difficult because the creator wants it to stick.
Daniel Abel (09:02):
Yeah.
Lina Zubyte (09:03):
If you explained in very simple words, which is also sort of contradicting our original start of this conversation, but for some terms it's good to have some kind of different term so that you would remember it and it would be somehow unique to you. So maybe now we're building up this evolution, right? We start with simple words. So now we're going to like, why would we use sometimes a more unique term to describe something.
Daniel Abel (09:29):
They always say in writing. You start off with a very, very simple short sentence and then the second sentence, just go for it, say what you want, but start off simple and then grow into the complex once people get drawn in.
Lina Zubyte (09:41):
So we are drawn in into this idea... And there is this article which we can link, but there you describe four different areas for 10x teams. What would you say are those areas? Could you on high-level describe them and which of those four would you say are the main ones?
Daniel Abel (10:01):
Sure. I mean as a caveat, any model, any description is a lens across a very complex domain. If when I go through these and the listener goes, they're not mine, that's absolutely fine. One: you be you, and two: tell other people about it. If you've got a passion about what makes great teams and there's different list to my list, I'd love to hear it because I only get this list from sort of hearing what other people care about as well as doing things myself. So with that said, I made a long, long list of things that are important and said boil it down, boil it down. Can I get to something that really makes it clear? The German Beer Purity laws... These are the absolute for me, the most important things. And they were four things were coming down to, I'll read the four out and then we'll walk through them a little bit.
(10:48):
Basically being effective. And I felt that what I call flow and safety are the things that make a team effective. The purity of being effective. Those two things are non-negotiable. You need those two things. And then we have ownership. For me, ownership comes to having autonomy and alignment together, continuous delivery. And that is coming down to getting fast feedback and there to inspect what you built in the place where it's being used by others and having value orientation. When we talk about teams delivery of value, what is that value? Being able to focus on that value and learn about their value as you go, not having everything on plate, those difficult ambitious problems you have to learn to solve the problem, otherwise someone would've solved it already. So that's my four points and I'm very happy to dive into those. Would you have some thoughts on that, Lina?
Lina Zubyte (11:39):
Yeah, I really like those points and I especially liked when I looked at this article, the graph, low alignment, bad alignment and like where do you fall? I think it was with the flow and safety.
Daniel Abel (11:50):
Mhm. I think flow and safety. If you have nothing else, those two things are really important. The idea that to bring value into the world, you need a team that can keep making things, keep creating small amounts of work and testing them and the safety to fail. I guess a bit way of looking at it.
Lina Zubyte (12:10):
Yeah. Also maybe even safer to bring yourself to work fully and not hide behind something or not, I dunno, be in this like maybe numb mode that you don't really care and you just show up.
Daniel Abel (12:25):
Yeah, I think you are right. I mean, digging into that, I mentioned before I'm a sort of kayak and canoe coach and when I learned about that, there were two facets there that I learned. The first thing they taught me the first day I did my kayak coaching sort of training. They said, we're all about basically fun, enjoyable, and safe learning. People aren't gonna learn unless it's fun, unless they feel safe. And I was like, oh wait a minute, this is new. No one's ever said... We all know about the fun stuff. We all think fun is good, but safe. What's that mean? And then as I got to be a coach and got to make mistakes and find new ways, I noticed firsthand in myself and others that when people didn't feel safe, when they were tired or feeling at risk, they would perform badly, not intentionally.
(13:12):
Their performance would drop and they'd almost start acting like a beginner again. And then Google's project Aristotle presented a great big survey and demonstrated that this safety applied to pretty much all office environments. And I think bringing yourself to work is an aspect of that which is when do you feel comfortable bring yourself to work? I think it guess when you feel safe, so is it almost, you could say in some ways there's evidence that if you do bring your whole self to work, you are in a safe environment as indicator, but also it works the other way. That stuff that really fascinates me here, but it might not be that interesting anyone else? There's a guy called Dunbar. Dunbar's famous for coming up in the monkey sphere of the idea that there were numbers of people that can recognize each other, but it's got this much more interesting idea that language not was not invented to operate tools. Language was invented so we could socially form bonds. Monkeys spent loads and loads of time socially grooming each other, physically going through matted hair and moving bugs, helping each other.
(14:21):
And that isn't very efficient. They spend us so much of their time and his idea was that we develop language and do that more efficiently so we could form bigger, more helpful tribes. So bringing ourselves to work means we're being social means we are forming strong bonds which form teams that are resilient even at times of crisis. So I think it's both for evidence of we're doing it right, safety's there, and also a way that allows us to build this resilience that makes a great team and that brings us to flow, if that makes sense.
Lina Zubyte (14:50):
I'm thinking about the book - Sapiens, a brief History of Humankind - because there the author goes through the history, the ideas of humanity, and one of them is about tribes and the fact that we used to be in small tribes and your fact of language really adds on that. And then it allows us to unite. But also the interesting fact there that author mentions is only in creation of religion, oh my god, I'm going to very difficult subjects now...Caution alert.
(15:28):
Then we created ideologies which basically meant that we go outside of this tribe of let's say 50 people because we are connected in a certain idea. And I feel like a mini example of ideologies can be also our professional fields because we are all working in tech. So we may be very different people and we also have connectivity right now, we can work remotely, we can be in different countries. We can connect, we may speak foreign languages so we can communicate with each other, which allows us to somehow connect more than our inner circle.
Daniel Abel (16:12):
Hmm. I think think where you're going there for me is empathy. Empathy is so important. Um, not to take away for all the stuff you just said.
Lina Zubyte (16:20):
It's also values, right? It's shared values in general.
Daniel Abel (16:24):
Or accepting. When you don't share all those values doesn't mean you can't find a way to collaborate. You could find a team that has all these people's shared values and that's gonna be great and it's just gonna get to its groove. But what happens if you have a team that doesn't share the values? Can you find a way to get there? And I think a team that isn't wholly there, that isn't psychologically safe is never going to find that solution if they feel, you know, particularly for threaten or endanger. I mean there's a book, what's it called? The Chimp paradox. Basically we could just talk about monkeys through it out quite frankly. I've got a got a conference talk I've never delivered: what monkeys can teach us about ourselves. And the chimp paradox, it talks about how we've got two brains.
(17:04):
We've got the thinking brain, the human brain, the creative and empathetic brain. And we've got the monkey brain, which when we feel threaten or in danger, the monkey brain takes over and it, cause it's there to save us, it's gonna protect us. But we get scared these days by things that aren't actually dangerous. When we feel threatened in danger, we lose the empathy and creative thinking and go into kind of protect the tribe mode and the we and the not we and the me. And I think being in a safe environment allows us to start to develop empathy, creative thinking and solve problems that we don't know how to solve. We're not, not feeling like I must protect my stakes. It's like, well I'm okay to share, I've got enough.
Lina Zubyte (17:43):
I'm also wondering about safety levels because I may have a difference. It's a level in the team or I may feel less safe than for example another team member. What do you think about it is safer to universal for everyone in the team or every team member has it differently? And how do you we work with that?
Daniel Abel (18:03):
I think think you are right. Everyone has it differently. And it wax and wanes people... Where their heads at that day, that week, that month. There's lots of things going in people's lives outside work that change that. And the people just have good weeks and bad weeks. Maybe they've just had had the flu or covid, they're coming back from that or just feel tired for a bit. For me, the 10x team is something that's about resiliency in the long term. It's not about being super effective in this one week and let's sprint, let's sprint, let's sprint. It's everyone being able to support each other and I think that comes down to a certain amount of trust and a certain amount of space. If the team is under too much pressure, too much load, then they're gonna lose that general team safety.
(18:47):
I think the general team safety supports individual safety and I think it probably is up to, I gonna say team leadership. And I don't mean there is an anointed leader. There are people who have experience and are ready and see the patterns of the team and wanna make that team great and that that there may not be anointed, there might just be people who care. And that might be their job to make sure the team is safe by making sure there's time to listen and people are heard. And so to come back to your question, how do we deal with situations where different levels of safety are for different people? I think it comes down to empathy and understanding again and opportunity. So a lot of the stuff that I do in teams is finding delivery methods and means that are oriented around collaboration so people can lift each other up.
(19:37):
There's a great blog I actually read this morning. It says you specifically create meetings with when you are blocked and you make clear that this is an unblocking meeting and then the team collaborates around that and I guess it is sort of a synchronously remote teams who maybe don't answer the same room. So it's not obvious, because you know, if you sit in the same room you just go, Hey, can I get hand there? And it's about the outcomes and the output of the team, not an individual. I feel I could speak for a long time on this because it's a difficult, interesting question. There's another aspect to it, which is do people have appetite for risk? And I was talking about this to someone that reminded me of... If anyone does any financial stuff in the UK the financial advisor has to access what's your appetite for risk for this money?
(20:23):
And I wonder sometimes whether that great engineering managers really trying to find that out about their team. What's the appetite for risk right now? And they have to work out, well, given these people I've got, can I do this? Are we at the right level to take these risks? We need to take these big leaps or what can I do to add the right safety so these people feel they can take a risk? When I was an engineer manager about three years ago and hired two new staff members, I found that they didn't wanna ship into live. I was in a culture where we ship daily, hourly and we occasionally broke things and every time we got a new staff member in, they'd spend weeks and weeks and weeks trying to get the confidence to ship a thing. And it's like... they're not safe.
(21:05):
They feel that by shipping a thing that will expose them to risks. And it's my job as engineer manager to not hold their hand or maybe hold their hand for the first time, but to demonstrate that actually they are not at risk by shipping work they've done or work the team has done. Then even if it breaks, it's not a problem. If it breaks then we will fix it and it means the system isn't good enough to support a change. We need more test automation, we need more resilient production. One thing I do these days is when a new person joins to say when the first time there's an outage, first time there's an incident, go and hear what happens. It's more important probably these days than someone go and shipping their first bit of software is go and listen to what happens, the incident. Uh, because oh people are all collaborative, they say people were really wanted to fix this and get together and solve this. And then they've blameless postmortem going, yeah, that's what happens when we mess up. We find out what we did wrong, we fix it. Obviously there are things that are too bad like leaking data or losing data. And my rule then is we don't let engineers to be one step on disaster. We put those things in place, we actually have a safe resilient environment for risk.
Lina Zubyte (22:19):
I think risk profile is an extremely great addition here because a different team may have a different risk profile and then as a result you need different conditions to reach flow. Because I've also heard of some teams, for example, having very thorough requirement analysis because otherwise, you know, they are not feeling happy with whatever work item they get. And then other teams are like, oh we just need something like rough, it's fine. They have better risk profile, they're fine to not get it right and they don't take it to heart as much and they feel safe and for them it's okay. So this flow and safety are really related but very unique as well. Do you have any examples that you could share to illustrate the flow and safety in the team?
Daniel Abel (23:12):
I must admit my flavor of leadership is when I see a team that is too hesitant or feels to me too hesitant, they're not shipping change often enough because I worry about team that's doing a lot of introspection analysis - they're not putting reality into their imagination often enough. Teams that are shipping code to users or at least shipping, getting value to users are finding about their users. Teams that are sitting, doing a lot of analysis unless they're actually doing sort of griller user experience testing, going out there and finding out what the users want, maybe giving someone to the users for free. Honestly, I figured they may be at risk analysis paralysis rather than actually innovating with their users, with the partners, they're actually, they're trying to solve a problem with, and I'd ask why are they're doing that.
(24:04):
In kayaking if we're in a lake it's very different to being on a very big risky river in the middle of nowhere. When we'll get in an ambulance in worst case situation, you know, in three minutes or basically the ambulance is a day away because I'm in the middle of Canada. There's a different approach to risk there. It's an honest approach to risk because the dangers are far, far worse. So in a software team, I might, based on what are the consequences... In kayaking, we actually do risk analysis going this could happen, the consequences are, this could lead to, and then we say, well that's a very sensible approach. Yeah because someone might die. The great thing with software is 99% of software, no one's gonna die because we get it wrong. But there are consequences and the consequences of a software bug can be leaking information about someone that puts them in actual danger. And that is the situation I found myself in.
(24:55):
Not actually leak that data, but holding data that could calm an individual if it was made more publicly available. The great thing about being a consultant is you get to go into places and you get called into help. So you see problems that occur and you get to help fix them. And because you weren't around for the cause, you are not in that bad place the team is. You've got that wide open, you come in with the empathy and a broad problem solving perspective that maybe the team is lost. So partly my job is to not be in that place of danger. And so let me tell you a story about that. So it's flow and safety story around a precious material manufacturer. They had a real shop floor with bespoke devices that manipulated these precious materials to either record the value or make them more valuable.
(25:42):
And it was connected to a software system to record all these processes because it's important when this precious material was changed that every change was recorded. That's part of the value: it was traceable. And so this system had broke down and the team had broke down. The shop floor got closed for a couple days, which lost a rather large amount of money when everyone who worked that shop floor had to go home and no value could be produced. So double the damage. And so me and a fellow consultant were dropped in to help the team get back in the groove, to help this business get back to where they need to be. And we landed, the team was clearly burnt out, blocked, they were frustrated, they were crossed from each other, crossed through the situation, crossed with the management and the management were frustrated and rightly crossed too the fact that they've got these software developers who done harm to their business where in fact they were supposed to be adding value.
(26:34):
But it was complicated. It wasn't a simple software system like we have these days where we shipped to live, we get feedback, and when we write test automation. They were writing software for an environment they weren't allowed to go into as highly secure. They couldn't ship software very often because of the situation and they were working bespoke devices that really didn't like usual style of automation. So they had complicated problems and it turned out it was hard. And then there were lots of requirements coming in from the business and they were under pressure. You could argue that the cognitive load on that team was massive. You look at it and go, no wonder it was hard. They can't go super fast. They'd overcommitted or been overcommitted tried to meet that goal and quality had dropped massively. So me and my companion consultant came in, we tried to work out what to do and decided that my partner would focus on working on the external problems, the demand and the cognitive load being put on that team and also trying to gain empathy for what's going on outside this team.
(27:36):
And my job was to bring the team back to being able to feel safe to solve the problems and to start shipping software again to find their flow. And my first job is bring the team back together. I just let them be angry at me, you know, take them for a coffee and then they go, this is so, so wrong. Get it all out and, and I'm gonna listen and make them feel a little bit safer. One that someone is listening and someone understands and two, this is fixable. This is not a danger for your career. Because we talk about safety in an office. It's really coming down to what about my mortgage, my kids, my ambition, my life, caring for the people important to me, making sure there's a roof in my head. Can I pay the bills? All those things are safety to an individual in a job.
(28:20):
There's also shame I guess in a way people, I've done a really full of good intentions, this is going wrong. I feel ashamed that can affect safety too. So taking that away from them, lifting that off their shoulders a bit and starting to show them what a team is like, maybe we can't deliver to the shop floor right now, but let's build some software and it means we have to do things more manually. So the team room had a set of devices in it, the same that was used the shop floor, and the QA would manually test the software changes through those devices because it was almost impossible to automate the reality of the situation we found themselves in. And because software only shipped to the shop floor on a schedule I think of every three months. It was a manual QA process.
(29:04):
And you imagine when they started writing the software that software would... the metaphor I like to think is like a metro line. When you build your metro line or your tram system, you're probably just going four stops along the way and it's very easy to test the software that runs that tram system. And then many years later you've got loops, branches... Trying to test that software was really hard and the QA individual was finding it really hard to get to the point of testing the software was good because it's a very complex system. So the first thing was just get everyone, get more people into that testing, accepting with a manual job it's gonna be slow but we're producing software. There is a flow of value coming outta the system and feeling that's good. And then once a team can see they are a team, they can deliver asking them how do we speed this up? Automation is always good. Where can we put automation? It's gonna make this QA job easier. So they got, rather than blaming the QA for not testing their software, they got to be the QA and gain empathy. So we're starting to be the team cause we're getting empathy in sharing the problem. It's not a siloed situation. And then saying to engineers who are really good at solving problems: solve this problem, solve the QA problem.
Lina Zubyte (30:19):
I think they also have to see that problem. So having them to test together, you show them the problem in real life, like what's happening actually. So then they can think about it because I think it's hard to sometimes empathize and understand the problem if you don't see it or face it yourself.
Daniel Abel (30:39):
And you gotta do the reality of the situation people are in. You can hide from reality. They get frustrated that they can't see the real shop floor and they only release every three months. But that's the reality of the business. They couldn't change those things but they absolutely can change how the team deals with those situations as a team. As a set of collaborating individuals. A very much a 10x team is a set of individuals all aligned to solving the key problems they have. Not a set of siloed individuals sort of going, well that's your problem, go solve that for me. So yeah, go going and seeing is really important and accepting this is our problem. And I think one thing that taught me is that safety hold up flow but flow supports safety in the long term that my job there was let's get some flow and get the feel and then we need to get safety in the system, which is going to sustain long term flow. It's a little bit of a dance to try and get to that point where you've got both of them sustaining each other, if that makes sense.
Lina Zubyte (31:38):
Yeah, absolutely. Where do you think we should start if we want to build a 10 x team? We want to collaborate, we want to do it. Are there any prerequisites or buy-ins we'd need to make sure this is successful?
Daniel Abel (31:53):
I think that's a great question because we've talked about a team that's potentially waterfall, it has fallen down and we're putting 'em back together again. And then this is the other aspect as well that's as we're starting from a nice green field, where do we start? I think there's three aspects to that. The team setup: If I was an engineer manager and I wanted to set up my team for success, I use the four Ms: Means, Mission, Motivation, and Method. So basically, mission is do we have clarity of what the job to be done is, what problem we're solving? Do we have a north star, an ambitious mission? And then means is do we have the tools and the knowledge and the team to get there? What are our ways of working? What do we need to get to that emission?
(32:34):
The method: we need some way of incrementally building software that we can test against that mission, whatever we choose and kind of leads into the tools that support that. And probably for me, it's delivery tooling. And how do I build the motivation for the team to get through those problems when things get tough? And that probably is understanding the team, understanding what motivates them, what's gonna bring them joy and making sure everyone's growing. So that is important for the team set up.
(33:07):
Then I need to line folks. So you only need people who are comfortable in the environment where they're not gonna be all always leaning on the skills they currently have, but they're gonna be learning new skills and that can be quite scary. If you are a Java developer who's been writing this sort of Java for 10 years, are you ready to not be a Java developer but be a problem solver who's trying to find value for users and selecting people who want to do that or love doing that? I think that's really important. Not everyone wants to do that.
(33:37):
I'm not saying that you kind of a group of job developers that are a 10x team, but my 10x team is: people are generally specialized generalists and not everyone wants to be a specialized generalist. Some people just love what they do. They might be a facet of a team, but you certain need people around them or are specialized in generalists as well as experts. So you've got enough line folk who more skilled and ready to learn and then it's having the org ready. Your grand bosses across your teams probably need to understand the shape and the why and what you're trying to do. You might want some air cover, there's probably, if you've got generalists learning new things, there's probably be some pauses and ramp up. You probably need to make sure the organization values outcomes not output.
(34:20):
If an organization wants you to build a backlog of the next 10 months of work all sized and then work to that work, you are limited to what you knew at the start, which is probably not very much. I must admit I do try and find places to work who care about outputs rather than backlogs. That value is more important than predictability. Not that predictability isn't important but predictability and low value isn't very good. I'd rather work places that say, well get me the value, get me the learning. I'd likely to be as predictable as you can, but I need the value more. I think you both need engineering management and engineering contributors that understand that the only way we can find the answers is to test what we know about against reality.
Lina Zubyte (35:09):
Right? This is all against the hero culture, right? This is not some omnipresent knowing everything person that never makes mistakes. It's humble people who say hey, we do make mistakes and it's okay.
Daniel Abel (35:25):
Yeah, I mean I know I don't often know what the end result's gonna be, but I know processes that help us get there. We're going on a long multi-day hike or canoe trip. We don't know what we're gonna find along river or in the valleys, but we should have the skills to get us down that river up, out back out the valley and to find out when we might have to backtrack, we might have to walk around something that's actually is risky and too dangerous for us, but the skills admitting that you'll find things on the we didn't expect and you have to work around them. That can be scary for a business I think, who think that predictability is the most important thing and value comes from predictability. And maybe the hero culture says, yeah, I can do that. But that probably leads to burnout in most people that yes, you can do that for a while if you really try and you forget about sleep. There are some people who are are amazing engineers to solve a problem but usually it's the problem was solved before and so they will shape the outcome to be matching the thing they can do rather than find an outcome that suits the users in the business.
Lina Zubyte (36:28):
Yeah, it's using the same trick that you know. Basically just in a different context. I mean when you were talking about teams and their setup, I remember the Greenfield project I worked in and we had multiple teams there and the way those teams were built, I remember we told the person that was combining those teams, what kind of magic did you do there? Because we had one team that was all full on like, wow, who are we? We're Lions! Even their name was Dragonfish. Everyone in there, they had a personality and they worked really well together. And then I was in the team which was called Plankton and we were a completely different vibe of people and we worked really well together. But then our PO for example, once said, you know, if I was in the Dragonfish I would be a gray mouse. And here I have a team which listens to me and I feel like I belong here. And this is so important, right, that they built the teams that we were not the same, we were very different. We had our clashes but we had the same mission, we had the same motivation, we had similar values and that helped us to work really, really well together. I wonder though, what about the teams that already exist? You join a team and it's far from 10x team, is there hope to make it work?
Daniel Abel (37:57):
I mean the answer seems absolutely yes. There's always ways to get better to learn new things. I mean it does depend on the people, as you say. If people enjoy what they're doing, enjoy their working, then that's fine. And it's about appetite and ambition to a sense. Are the team frustrated? They have the appetite, they can't work it out. And if I go somewhere like that, I would say where's the pain? What's the blockers? What's not working? If a team knows that they could achieve more but there's something wrong, then start there. Are they overloaded? And the great thing about 10 X team comes into my head is that both contributors, coders and managers, engineering managers, team leads, there's facets they can all get at in terms of what's going on. Is it flow? Can we make that flow better for engineering? Can we make that flow better through the right cognitive load?
(38:49):
And I love team topologies use the phrase team cognitive load about the needs space to think of all these technologies and changes and initiatives and challenges. Unless the team's got space above all that to think about the problem at hand, then they're going to feel either overloaded or just be moving things from A to B as best they can without actually solving the problem. So finding what the team knows. Certainly in my previous team I could see that with our brand new teams coming in, they've not worked this company before and there's massive change coming on in terms of how the platform's gonna work and the current state of the code bases, which some bay areas haven't been loved for a while and they're in an area which why the new team is forming because there's some areas that I haven't been love that need some more love.
(39:37):
My job was to build a roadmap that expose them to reality situation in ways that they could affect and not give them more they could do. So we start off, we're gonna just build a microservice. We're not gonna look at the old code, let's just get going with that with a minimum platform, just enough monitoring, just enough CD and then, right, well they've got this, then they're gonna slowly fill that cup up no more. Then we'll overspill if that makes sense. So if the team's there, knows what they're doing, you can help them. You can see the problems because you are in the environment, you got a new team, you can start laying out the table for them, so they don't get overload in the moment they get there, but there's always enough space for them to grow.
(40:18):
So that's one aspect is as a team. Second aspect is new team: make a plan so they get onboarded and grow without being overloaded. And the third one is if a team is there and they think they're great, but there's frustration outside of the team, the team is not adding enough value. Then I'd question just so we talk about software, is a team exposed to the reality of their situation or are they being overs shielded to keep them safe? And then what if we were to give the team more information?
(40:46):
Interesting story there is one where I walked into a team room once to help them grow and perform better. And I said, well where are the teams? And this is 40 people, 45 people in a room. They said that's the team. What? The 45 people are a team? And they went, yep. And I watched a standup and there were 45 people going to the standup. And I'm going: I don't think people are gaining what I want people to gain from a standup. Are they coordinating? Are they moving blockers or are they just feeding their team mood? And obviously I was there because they wanted the team to be more productive.
(41:20):
So my job there was to almost like break up the band and I asked, do you like being this way of 40 person team? Do you feel you're getting delivery done? They're like, yeah, yeah, we love it. What about small team? No, no, we don't do that. So my job was an experiment to say we've got an actual problem here that needs about four or five people to solve it for about four weeks. We let some people do that and those people did that. I said: How did it feel? They said: Amazing. We're just high communication. We just got things done. We didn't spend an hour every day trying to have a standup. We're just five minutes and we're going. And it's like, oh, you would like to do more of that. It's like, yeah and we find another problem like that.
(41:55):
And these teams are starting to learn what higher performing feels like and they started loving it and it's like they ended up with about 15, 20 people in this core team, which was personally a little bit too big. But basically it felt right for those people, they'd seen what other teams were doing and sort of come back to the team and it felt right for them. So to come to your question is like a team that knows that they're not performing as well as they might: find out what it is and help them solve those things. They might be like pointing, oh, that thing outside the team that's causing us a problem. It's like, well yeah, but can we find some way to work with that in the team? If the frustration's outside of the team try and show team what good looks like without damaging how they're operating, find ways to add onto that to them, bring them more information and to remove the over shielding of a bit of truth. As the new team's coming on board, make sure there's time for them to learn, set them up for success.
Lina Zubyte (42:50):
It's funny because when I was thinking about this question and about existing teams, I also was thinking to ask you, how can we help with unlearning? Unlearning was the word that was in my head because I thought there are lots of bad habits that we learn. But talking to you now, I think the word unlearning itself is oversimplifying things in a sense because what helps us there is to learn more actually. So it's not that we're unlearning what we know. We build on top of that and we see good examples and we see the reality and sometimes we expand our knowledge in order to grow.
Daniel Abel (43:32):
People are only gonna let go of the coping strategy when they are ready. You can't force a coping strategy because they've developed that for good reasons. They're only gonna let go when it's like it's not needed anymore. Cause there's something more mature that's gonna solve upon or for them instead.
Lina Zubyte (43:48):
Wow. I really, really like this idea. To come full circle here: what is the one piece of advice you would give for building high quality products and teams?
Daniel Abel (44:02):
It boils down to, as we always talk about agile, inspect and adapt, but keep talking. People teams are probably the most complex system we're gonna deal with. We deal with a distributed and event driven systems, but that's human beings too. The system of human beings working together. We have very low internal observability and no way to apply more observability other than being social. So being social, as we talked about, builds resilient human groups. So let's do that with a mission in mind. Build trust, be honest, talk about the problems we're solving. That is both the problems we're solving is us as humans, as a group being better and adding value to some people out there. We should raise the bar and seek, join the doing, but keep talking.
Lina Zubyte (44:50):
I love it. It was such a pleasure to talk to you today. Dan. Thank you so much for your time.
Daniel Abel (44:56):
It's, it's been lovely. Thank you.
Lina Zubyte (44:59):
That's it for today's episode. Thank you so much for listening. Check out the notes if you want to find some of the references from this conversation. And until the next time, do not forget to continue caring about and working on those high quality products and teams. Bye!