This is a transcript of episode 158 of the Troubleshooting Agile podcast with Jeffrey Fredrick and Douglas Squirrel.
We start with a listener question on roles in an agile team, but quickly divert to Squirrel’s “driftwood theory” of hiring and role specification, which turns out to be based on effective conversations and flexible problem solving (what a surprise!)
Show links:
Listen to the episode on SoundCloud or Apple Podcasts.
The Driftwood Theory of Hiring
Listen to this section at 00:14
Squirrel: Welcome back to Troubleshooting Agile. Hi there, Jeffrey.
Jeffrey: Hi Squirrel.
Squirrel: So we’re going to answer another listener question, and I think this might be from our most question, asking listener. His name is Simon. We’ve heard from him many times and he’s asked me a question probably months ago in our question backlog. And you grabbed it today. And I thought that’s a great question. His question is this. “Have you done any episodes,” No, Simon. That’s what we’re doing now, “where you talk about the different roles in an Agile team?” And I must be kind of hungry because I was thinking of that is the rolls that you eat. But he means the roles, the different things that people do. “I have enjoyed the product owner role, but I would be fascinated to know what you think the different roles need in terms of skill set. So what do you think about that, Jeffrey?
Jeffrey: I think it’s fairly interesting. I think I’m a little bit heretical here in that I don’t really put a lot of stock into pre-defined roles and instead think in terms of responsibilities. So it was funny for me in how this was formulated. I get where it’s coming from, which is very often people have pre-defined roles and will have their own sort of process and they will want to put people in them. And there’s a bunch of titles that are common. So, for example, he’s given us “product owner”, which could also be product manager with slightly different implications. You can have someone who’s a program manager, you can have a project manager. So we have three different kinds of PM’s in there. And there’s often very different implications between them as far as what people mean. However, when it comes down to it, I tend to look less at the static structures of an organisation or static structures of a process and instead say “what are the dynamics? Are we getting the dynamics we want?” And if that’s working, “How much do we care about titles?” But to get those dynamics often requires certain things to be happening, and it is possible to map those back to different sets of roles. So that’s my view. And I think it’s a bit different. But that’s where I start from. And so then I sort of organise around what are the skills that we need and then how might we parcel them out.
Squirrel: And that’s the crucial thing for me too and I think I might even be more radical than Jeffrey because I have what I call the driftwood theory of tech hiring. Jeffrey, have you ever been to a beach?
Jeffrey: I have.
Squirrel: Was there wood on the beach that had drifted out of the sea?
Jeffrey: Absolutely. Very different, different beaches though, I’ll say that.
Squirrel: Absolutely. Well, different beaches of different driftwood. That’s one of the wonderful things about driftwood, is that in different places you get very different things and every day you get something different that the sea brings to you that just brings up whatever it is and it’s it’s beautiful types of wood. The there are people who make art out of this wood. They carve it into beautiful shapes. And what you notice is that they always follow the wood. They do things that are kind of in keeping with whatever shape the wood is. So what they don’t do is to define the role that they would like the wood to play. They don’t say, “I’m going to carve a boat today and I’m going to go down to the beach and I’m going to look for a piece of wood that looks exactly like this is going to be this long and it’s going to have this kind of grain in it. And it will be set up exactly for the boat that I have in my head.” They do exactly the opposite. They go down to the beach and they look at all the wood that turned up and they say, “You know, that one, it doesn’t look like a boat, it looks like a rabbit. And so I’m going to carve that piece of wood into a rabbit.”
Squirrel: And people who are particularly skilled at this make amazing pieces of wood. But they would be a terrible disaster if they turned up with a role in mind. So this is my theory that I often explain to people who come to me saying “we have this job description Squirrel and we’d like you to help us find exactly this person. Where should we look and what kind of recruiting should we do?” And I say, “stop, you’re asking the wrong question. You’re thinking about this wrong.” And I claim that it’s the same possibly in Simon’s situation where he’s thinking about “what roles do I need in my Agile team? What should I look for and what should I have that will fit into certain boxes? How can I look for the piece of wood that has the right grain, is exactly the right length and it will make a boat?”
Squirrel: Unfortunately, unless any of you have a cloning machine or a machine that will allow you to produce developers and engineers and product managers and all the other roles to specification. In which case, if you do, please talk to us, because that would be a really valuable consulting angle, would be great to sell to clients, unless you have that, you’re going to have to deal with whoever you’ve got. And that’s true even if you go out and hire them because the supply is so, so limited and the demand is so, so great that it skews the market in favour of the applicant. And that means that you really don’t have that many choices. You kind of get what you get. That doesn’t mean you can’t filter and look for exactly the right skills. And I think that might be what we can talk about more productively. Assembling those skills into packages that then match to certain roles is, in my experience, almost never the case. So I’m often hiring people who don’t know the programming language of the team. I’m hiring someone who has never been a QA before but is really effective at breaking stuff. I’m hiring someone or bringing someone new to a team who has never been a product manager before, but knows the business inside and out and is interested in building better software. Those are the sorts of people that I find that’s the driftwood that I find on the beach and put together into a team.
Playing the Sceptic
Listen to this section at 05:59
Jeffrey: Wow, I’ve never heard you talk about the driftwood theory before, it’s a new one for me as well as our listeners. So if you don’t mind, I’d like to take the opposition here for a bit, the sceptical opposition rather than the loyal opposition. So the sceptical opposition might say, “that sounds great and I can see that’s great for producing art. Driftwood art makes perfect sense. But, you know, we’re not a bunch of artists here. We have a business to run and we need to be able to make things reproducibly. And so in the same state where you have people producing driftwood art, they also are cutting down trees and planing them into boards so we can have standardised things. And that’s the same way if we want to reliably- if we want houses, then we need to be able to go and get, reproducible, standardised things. And that’s the point of having these roles, is we’re putting out a specification saying this is what we need. And people can know, hey, can I be that shape? Can I can I show up and fit together to make that house? And that’s anyone who’s going to want to do things at scale. Anyone who wants to run a business and not just a curiosity shop, is going to have to go that route.”
Squirrel: And I completely agree. That’s why I was saying if any of you have the equivalent of planing machines or something that can package up skills into a single human shape, you’re going to be a very wealthy person. And I’d like to invest in your business that sounds like a super thing to have. The problem is we don’t have that. So although it would be wonderful to do that, the fact is we have a bunch of driftwood. We have people who turn up in whatever shapes and skills and characteristics that they have. And we don’t have a lot of choices. And it may be that at superduper scale, if you really are Google or Facebook or somebody like that, and if those folks are listening to the podcast, please come on and be a guest. I’d love to pick your brain. How how do you do it? But if you’re not one of those folks for whom there is really a very broad talent pool and a lot of people available, then you have a much smaller pool than you would like to have in order to be able to follow that process. So I would encourage you to certainly try for the role or the package of skills that you might find most effective. I have absolutely no objection. That would be super go ahead and define it. But I predict that you’ll find a bunch of people who don’t quite match that specification. You wanted a person with five or 10 years of experience in product management and you’ll get somebody who’s really enthusiastic, really knows your business has come internally, is very knowledgeable and excited and interested, but only has two years of experience. And are you going to say to that person, well, sorry, you don’t fit, you’re not the perfect board, you’ve got a little warp or something that’s not quite perfect. And you I think if you do that, you’re not going to scale because you just won’t find enough people but I would love to be proven wrong.
Jeffrey: All right. So I’m going to continue here and say, “OK, I see what you’re doing there. But, you’re kind of alighting the real thing you have. What you’re saying is certainly true, we’re not going to get people in standardised shapes. And so they’re not going to exactly match our spec but but still, we have to have these standardised roles because that provides the contract for the team so they know what they’re going to rely on each person for. And so it’s important to define these roles so they know what each person’s contributing and to contribute effectively then, according to the contract on the team, then they need to have certain skills to go with it. I mean, I don’t think you can deny that.”
Squirrel: Well, I would certainly claim that, for example, you can get on very well with people who learn skills that they never knew before, if they have characteristics that allow them to do that. So I mentioned before, I’ll say it again. Some of the very best engineers that I’ve ever hired have been people I brought into the team who did not know the programming language that the team used, just never written a line of Python or Java or Rust or whatever it was. And that may seem astonishing to folks who are really used to this kind of rigid definition of roles and skills. But what I found was that someone who was really capable of understanding software deeply and quickly and could learn very fast, which were things that I could test for in which my driftwood did bring up for me. The brought me those people. And I said, “look, I can give you a book and three weeks and a pairing partner and you’ll know Python.” And that is exactly what happened. So while you’re absolutely right that you do need some level of ability to master skills and ability to shift from one to another, you can get tremendous amounts of flexibility from people and they will often surprise you if you make them, quoting you here Jeffrey, if you make them into a real team that is a group that shares a problem. And they will also do things like say, “hey, actually,you know what we need is this type of skill, that’s what we’re lacking on this team. And we’re going to go find in this way. So I’ve had lots of success with that, it has scaled and I still claim that you can get by with a lot less rigid definition of the skills and packages of skills into roles than you think you do.
Jeffrey: Ok, but it sounds to me like even in your example, you were looking for a particular set of skills. You said “the ability to understand the software deeply” and things like that. So you definitely had skills in mind.
Squirrel: Oh, absolutely! And that’s what the sea brought me. If the sea had brought me an expert Python programmer, I might have hired that person. But what I had was an amazing C programmer who didn’t happen to know any Python. And I was able to make that work. I was able to carve that into a shape that worked for me and just encourage listeners and Simon to consider doing that.
Jeffrey: Ok, I’m going to push here a little bit more. With that C programmer what do you need to pair them with? What are the other skills that you think you’re going to need to bring this team together?
Squirrel: Well, that’s fascinating. So in that particular case, I’ll just stick to the particulars, because, again, I really think there’s not very much of a general answer to Simon’s question. But if I’m remembering that particular team, we had an amazing QA person who could break anything and was also a pretty good product manager and we used her for a lot of product manager activities like prioritisation and filtering incoming requests and things of that kind because she had such a deep understanding of the product. So she was not a traditional QA person who was rigid in her role. We had some amazing programmers in the programming language that we were using, which were and they were they had deep understanding of it and also deep understanding of our industry, which was finance at the time. So they had worked as contractors and banks and they escaped. We would also always call them refugees because they were really glad they didn’t have to wear a tie. So we had those skills, but they were less skilled in computer science. So they were practical folks who could hack stuff together but didn’t have as much of a theoretical understanding. And I’m trying to remember who else we had in the team. We didn’t have any designers because our front end needs were limited and we had at least one very good product manager who worked with the keyway person. So there’s an example team that I’m describing, really an artisanal building of a team that’s that’s a particular team that solved a particular problem at a particular time that I remember six months after that, we might have built another team. I’m sure we did. And we put that together from internal folks and maybe hires to solve a different problem. And we would have had a different mix of skills. So there’s my not very helpful answer to your question.
Flexibility is Key
Listen to this section at 13:49
Jeffrey: So I’m going to drop the role play here and come back, so as I listen to what you’re saying, in part, I’m going to sort of compare and contrast the mindset that you have to this with, I don’t really know what Simon’s mindset is, but I’ll go ahead and say a mindset I’ve seen from other people that would say, look, we want to have a ‘by the book’ Agile team. And so let me know how we can standardise everything. So we’re doing things correctly, because if we don’t define all the roles right, then we can’t possibly have a truly Agile team unless we’ve staffed everything. And you’re describing a very different approach, which is not looking at the book, but instead looking at what’s the problem I’m trying to solve right now?
Squirrel: And solving it imperfectly. So you were right in your sceptical role to say, “hey, why would you hire a person who’d never written a line of code in this programming language if you could not do so?” And the answer is, well, yeah, of course that would be great. The person might still be better after three weeks of learning than others. So you might compare them and their innate programming skill. But certainly you would consider people who knew the programming language before you would consider people who don’t, that seems pretty obvious, but that isn’t often the choice that you have. And so what I’m advocating there is the mindset that consists of approaching the problem first and being willing to be creative and flexible in how you solve it, trying to standardise and scale and make everyone look the same, make everyone look like a board instead of a piece of driftwood is not likely to succeed, in my experience.
Jeffrey: I agree with you and I think for me, the real contrast is describe these contrasts in mindsets. It seems to me what you have is what I would describe as an Agile mindset, which is you’re looking at the problem and saying flexibly, what are our resources and how are we going to solve it the way you would want the team to work when they’re working on the problem? And so you are you’re approaching the problem of creating the team the same way you want the team to approach the problem that they’re solving, there is a very strong consistency there in approach.
Jeffrey: The contrast is saying, we want to be very rigid and specified about how we’re going to approach putting a team together. And I suspect that very often- I definitely know in those organisations it often goes with a very rigid approach to what is ‘Agile’ which ends up actually not being very Agile in practice. And I think they’re in it for the same reasons, which is what drives people for scale or efficiency, these things, whether they want it to be standardised, keep them from taking a an Agile approach in solving the problems that the team faces. That’s what comes up for me as I’m comparing these mindsets. Does that resonate with you at all?
Squirrel: Well, certainly it does. And it reminds me of an episode which turned out to be our most popular episode ever, but we’ve not figured out why. So if anybody knows why the episode titled We’re the Aliens Three Ways to Seek Safety, became our by 50% more our most popular episode. Please tell us, because we don’t know. But what we talked about, there was different ways of approaching safety for your team. How could you be sure that you’re solving the problem correctly? We talked about having a single source of truth and appeal to authority, having a process that you could follow or working it out with people. We, of course, advocated the third one and said, “That’s really kind of an alien approach.” So apparently there are a lot of aliens listening to this podcast. So welcome aliens. We’re glad to hear from you. But more seriously, we’re advocating here a similar approach that instead of being rigidly attached to an authoritative source of truth or a rigid process, that you work with the driftwood that washes up on the beach and that makes people feel uncomfortable, that’s probably good. And that is an illustration, that’s an indication that it’s new learning. So that’s what we’re trying to bring you here.
Jeffrey: I’m glad you brought that up, because that was the point I wanted to make, which is that we are describing this and we say it as though it’s easy and I will admit that in practise there is a price to pay, when we form a team in this way, it requires people to converse with each other and to learn their strengths and weaknesses and agree on their roles and responsibilities. That kind of conversational, what people would see as overhead. It can be uncomfortable because you need to actually say, “well, what are you good at? How are we going to divide up the different responsibilities here?
Squirrel: “What do you mean you don’t know how to write a for loop in Python? Oh, you actually don’t know the language. OK, how can we work with you anyway?”
Jeffrey: And in particular, I see this very much, people would say, “but what’s my role?” They’d like the certainty and comfort when they join everyone else to know what their role is going to be. We’ve probably said before, people are very uncomfortable with uncertainty. And what we’re saying is, “yeah, there’s going to be some uncertainty as you work through this. We advocate it because we think that if you’re willing to have the conversations and work through the uncertainty, you’re likely to get a better result because you’re making better use of the-I’m not sure this is a complimentary analogy here, but the driftwood that comes. We are all our own unique piece of driftwood that we’re putting together and acknowledging that and working with that in the unique character of all the people in my experience is more fun and gives a better result, for the price of that, not pretending that we’re all standardised boards.
Squirrel: Excellent. All right. Well, if you are a standardised board or you’re an alien and you’d like to get in touch with us, you can find us at Conversationaltransformation.com. And we’ve got a very busy few weeks coming up. I’ve got a live stream I’m doing on the 1st of March. We’re at a conference toward the end of March. I’m doing a workshop on how to talk to your tech team and decoding tech talk at the end of March. We’ve got all kinds of exciting stuff coming up. We’re at another conference in the middle of March. I can’t even keep track. So have a look there if you’re interested in hearing more about what we are doing and seeing more of us, or if you want to argue with us that, in fact, aliens are not a good thing to hire for your tech team or anything else, you’ll find email, Twitter, all the wonderful things there. And of course, we like it when you hit the subscribe button, because then you can come back and mystify us by suddenly being 50% more of you by the next episode, which will come out next Wednesday. And you can talk to us then. Excellent.
Squirrel: Thanks, Jeffrey.
Jeffrey: Thanks, Squirrel.