Human Skills 020 - Decisionmaking
with Joel Chippindale
Joel Chippindale has served as Chief Technical officer at a number of different startups and scaleups. He has been through the process of scaling, seen the many dysfunctions that happen in these chaotic early stages. And now he runs an independent business as a CTO coach.
In our conversation we talked about some of those team dysfunctions, and Joel shared a great story of breaking out of disfunction by creating alignment across engineering, customer success, and sales. But that isn't what stood out to me most in this conversation.
This discussion of dysfunction led us into the question of decision making, and that became the common thread through the majority of the conversation. Where decision should live in an organization, how making decisions quickly is often more important than making them perfectly, different models of decision making and how they break down, and how you can step into a decision making gap even without explicit authority to break through a logjam and make things happen.
How do you think about where decisions should live in an organization?
There's a book, Turn the Ship Around, which I think has been quite influential on me. It's written by a nuclear submarine captain. He talked about intentional leadership and delegating decisions to where the information is.
And so I think that's a really good start, in terms of making sure that decisions are made as close to the coal face as possible. But he also talked about, well, the one decision he wasn't going to delegate was launching missiles, that's on the captain there.
And I think that's important as well to think about the things that you wouldn't delegate.
I think it's really important here that you have to teach your teams to do this. It's not enough to just say, "I won't make decisions." That's not helpful in itself. Um, and so as you say, you do have to consider for each decision, what's the decision you're going to hold onto, what's the decision you're, going to let the team make, for example, but you want to be informed about, which decisions you'd like them to just make without even telling you what's going on.
And clearly your team are making decisions every day. They're sat there, at the bare minimum, they're sat there coding and they're deciding what lines of code to write, you want them to do that. So where do you find those boundaries?
And I think there's a level of comfort you need to get to when you're leading a team, to take responsibility for decisions that you're not gonna be involved in.
As a CTO, if you have 100 people in your team or 50 people in your team, they're all gonna be making decisions every day that don't go through you. And so highlighting to them the decisions that you don't want them to make without you is really important.
And there you should be thinking about where if they make a decision different from the one that you would be comfortable with, you'd want to overturn it, for example.
And I think the answer to which decisions you do that on is the perennial "it depends."
On why making a decision quickly is often more valuable than making the right decision
I think that's something we often underestimate. It feels like the the cost of not making a decision is zero. That's often what we implicitly, whether we explicitly say it to ourselves or not, feel.
And that's definitely not the case. I think many of these decisions are too complex to decide on by pure analysis. A lot of the work we do in software development is in that complex space. And any assessment... relies on so many guesses about what the future will hold, that it's very hard to have confidence in them.
And so I think if I wind back what I said earlier, I think it's about trying to get feedback from the system as soon as possible. So try, as soon as you can try a thing, try it and get working with it, and then see what feedback that gives you to... keep deciding how to change
How do you deal with a team that wants to keep relitigating a decision?
I think this is a real responsibility when you're leading a team. In an ideal world, everyone roughly agrees on things. You'd like to believe that there is a way of reasoning to an answer that everyone will be happy with.
And in practice, that's not true, and some of this will be at the level of tabs versus spaces and some of it will be at a level that really does matter.
As a leader, if you're seeing your team thrashing about, then it is up to you to squash that thrashing about and take responsibility for that decision. Take that responsibility away from the team... for their own good.
And you can explain why you're doing it. I'm laying down the law as the authority in this space. This is the decision we're going with at the moment.
And you can, depending on what it is, perhaps offer up the conditions under which you would change your mind. Maybe it's to do with where the focus of the team is, and it's like, well, when we've raised our next tranche of money, we can revisit this. Or when we're getting too many bugs every day or whatever it is,depending on the decision you're making.
So you can be explicit with the team about what you would allow to change the decision. But I think that taking that decision away from the team when they're finding it really hard releases them from worrying about it to a certain extent.
What type of education do you need to do with your reports around decisions?
There's a few things going on here, I think.
One is assumptions people have about leadership and about leadership making decisions. Often people will come to you to make decisions because they believe you're the person who should make the decision. Whether or not you know most about the decision or not. Whether or not you are the right person to do it.
And so I think it's important to be aware of that, as a leader, that's going to be a natural thing to happen. And I think there, when someone comes to ask you to make a decision for them that you feel is not decision you should be making.
So for example, maybe your tech lead comes to you and says, well, "We're choosing whether to build a feature flag system or buy a feature flag system. Joel, tell me what I should do." The first thing you can do is lead with curiosity there.
Find out from them what they already know and what they think the decision should be. Ask people the question, "If you ran the team, what would you decide? What do you recommend?"
And often they will have a strong opinion on that. And then you can ask them why, what's behind that strong opinion. Maybe your tech lead says, "Well, I don't think it matters a great deal which one we pick, as long as we pick one and we start working with it and we're ready to change our mind. And so I think we should build a little system. It'll only take us a few days and start using it and see how we get on."
And so if you can get them to tell you what decision to make, and you can then ask them why you need to be involved in the decision. What do I need to add to this? And so that's the sort of conversation you can go through around learning.
I think another way is having explicit discussions about this. I think it's really good to set expectations with one another. Certainly with your reports. "These are the sorts of decisions I want you to make. These are the sorts of decisions I want you to talk to me before you make. And these are the sorts of decisions I want you to make sure that I make."
And you can make it explicit with them that you want to move things down the track with them. This won't be the same with everyone who's a report to you, depending on their areas of expertise, depending on their experience. But you can set it as goal.
If you're explicit about these things, then when we next have our review, I would love to be saying, you can make these decisions. All right, what do we need to make happen in order for that to be true?
So again, that's a way of you both thinking and being explicit about this. And it's also really important to tell them that not everything will feel like it's covered by any explicit arrangement and that we both understand that sometimes we'll get it wrong.
They'll push a decision towards me that maybe I shouldn't be the one to answer. Maybe they should make that decision. But similarly they'll make some decisions and I will be gasping... But, they've made it. That was their best call. We can talk about how to learn from that in the future, but that doesn't mean we have to overturn the decision.
What are different models of decisionmaking you've seen and transitions between them?
One of the teams around, there was a real heavy focus on collaboration. And that translated in the team often to assumptions being made that every decision needed to unanimous.
That makes decision making really hard, and particularly as a team grows. If you've got three people in the team being unanimous, that's not that hard. It's possible for all sorts of things, but it will still slow you down.
If you've got 10 people in the team, there's almost nothing that will have a unanimous decision. And so there,I think firstly, having those explicit conversations about why, the cost of waiting for a unanimous decision is really important.
And I think being able to tell stories about collaboration that aren't the same as every decision being unanimous. Collaboration is about people sharing their expertise. It's about people inputting into decisions, but it is not about every decision being unanimous. Talk about disagree and commit as being important.
I think in teams like that, it's really useful to introduce very explicit models for making decisions. And so one model is, "we'll only decide this if we're unanimous." That's maybe a model that a team has been working on for a while.
But you can introduce different models, so maybe, well, "This decision is Kevin's decision. He's going to decide, but he's going to talk to all of you beforehand, you know, so he's going to get your input and then given all that input, you trust Kevin. He's a sensible guy. He knows a lot, you know, and we're going to go with his decision. We're going to back it." So that's another model.
Or you can go for some decisions, it may make sense to have a voting model. And again, if you're open ahead of time, "On this, we're gonna decide what the majority thinks." That can be useful.
But I think that setting the situation up so you say how the decision is going to be made before it's made really helps with all the interactions. If you say, "Kevin's going to make the decision, but he's listening to everyone," then that gives everyone the opportunity to speak to Kevin, talk to him about what's going on, share their views.
But then they know they're not responsible for the outcome of the decision. And so that can make it freer for them to speak, for example. So yeah, so I think being explicit about the mode of making a decision. And you can have a conversation if need be about why that mode has been chosen for that particular decision.
On decisionmaking in startups and scaleups
I think on decision-making, we talked about it from a leadership perspective, but one of the things that I see happen a lot in startups and scale-ups is decisions not being made because no one's really sure who can make the decision.
In an organization that's very stable, you feel like, "oh, there's these responsibilities written down, you feel somehow it's clear." I think in practice it's often not, but in startups, you can see things get stuck because people are worrying too much about who makes the decision and I think there are a couple of tactics you can use that are really helpful there.
One is imagine that you're making the decision and that it is yours to make. What do you need to know? What help do you need in order to make that decision, to make a good decision? And then who you're perhaps consulting there and finding out information from.
I think this can work really well with being open about your intent. "So look, I'm not sure who can make this decision. So I think I should make it. Here's what I'm gonna do. Here's who I'm gonna involve. Shout if you're unhappy. If you don't shout, Friday or whatever, this is, you know, I'll assume I can make this decision."
And so I think that being really open about your intent and then thinking about what you need to make decision can give you a lot of power when you've been stuck with this.
For example, there aren't training budgets in this company. I don't know how much money I can spend on training. Can I do this or not? A you talk to your boss and they go, "well, I don't know, we don't have training budgets either." We haven't sorted them out. I don't know who you speak to.
So you can go, great, no problem... all the people who might need to be involved. That's my boss. Maybe it's the CFO because he manages all the money. I'm going to make this decision. Here's why I think it should be done. Tell me if you think I'm wrong. Otherwise, I'll book it on Friday.
That can be a really useful way through those impulses.