Unmanaged with Jack Skeels

I’ve got so many takeaways. so So let’s run through them. 

You talked about this idea, we’re going to change the way we work, but actually we’ll carry on working the way we’ve always worked, but we’ll put another level of overhead where we get them to fill out Agile artifacts to pretend they’re running Agile. Lots of project managers take all the work the Agile team is doing and then fill out their project management templates on top for the PMO, so even more stupid than not changing the way you work is to add yet another layer on top. 

So the makers, and I love that term, the makers change the way they do things, but nobody else does, and somehow we expect that to have an impact. It’s great for the team, great for the makers. They typically deliver more, have more fun doing it, but nothing else gets better.

So you talked about the fact that a lot of the agile patterns came out of experimentation. And that experimentation proved that those patterns had value in a certain context, a certain situation. So when we’re looking at them, we should say, is that the same situation as us? Because then we have a high chance of success of that having value. The bit you added was, okay, so that technique was used in a situation that’s different to ours, how do we change the situation. How do we change the organization? How do we change all those other things to make our situation so that pattern has value? 

In a factory. When the manager makes a decision or a change, we can visualize the impact of productivity. We can see the system work better or break. Machines or humans do more, do less, do it better, do it worse. When we’re in a matrix model and a knowledge organization those systems aren’t so obvious. They’re not so linear. They’re not so measurable, but we don’t tend to measure them. So we can make decisions as managers and actually have no consequence whether we’re making it better or not. There’s been some research that the more managers in the organization, the less productivity. The more words in a spec, the less certainty of delivery. More is worse. We all know that idea of mythical man month, oh shit, we’re actually not going to make it. Add some more people. It’s the worst thing you can do. You’ve got no chance once you do that. 

And so then you went on to the idea of innovation and the idea that the more innovative you are, the more uncertainty you encounter. And that’s where I come to digital transformation. So if you’re going to digitally transform something. That’s where you want to innovate. That’s where you’re going into a massive amount of uncertainty. So having a big program with, three program managers, 16 project managers, massive teams is ridiculous because you’re walking into a massive amount of uncertainty and you can’t manage uncertainty with that many people. I’ve never seen anybody do it. 

And then you said organizations really don’t do spikes anymore. They don’t research, they don’t experiment. And yeah, I think that’s probably true. And then very few businesses do a trade off between business value and cost. They always have cost. What’s the cost? But they don’t actually articulate what the business value is or they do a business case with a whole lot of bullshit numbers that they know they need to do to get over the line and then they never measure it. And actually I was talking to somebody today and they’re doing some estimation for some permission to do some work and they picked a number and the leader that they’re working for tripled it before they went up for sign off.

And the person I was talking to said, stop, get it back to the number I wanted. And they’re like, why, we’ll just get you more money. And he goes, I picked that number because it was the maximum I could get without hitting that extra management overhead. And I thought that was a nice way of changing the situation. 

Again, you brought up this idea of budgeting is a structural issue that stops us doing a lot of the things we want. So look at your organization, figure out these things that are immutable, like your budgeting process, your financial year, and you say, how do you change the situation? Cause they will affect what you do. 

Intrigued about quick scoping. Cause you talked about. Quick scoping using patterns that are repeatable, and I think immutable, so it’s not just a guess, it’s this is how we do it. It’s a pattern, we apply that pattern every time, but we do it quickly. So if you’re doing a 100k piece of work, if you’ve got a team doing something for a month, you can’t spend weeks scoping, but also you should still scope, don’t walk in blind, just do as little as possible to have the reduction in uncertainty.

And then the next one, which I loved was, Bad projects make good projects go bad, because there’s a blast radius. We always have resources constraints. And actually I’ve seen that all the time. So our critical resources are not available because they’re being sucked up in a thing that in the blast radius of that bad thing is so much bigger than the thing itself. 

And then what’s the role of a manager? It’s to set the team up for success, get out of their way, help them when they’re stuck and just observe them. Don’t get in their way. 

And then anti pattern, take your best makers and turn them into managers. It’s how to make everybody else go slower and lose some of your best ability to deliver. 

And then you talked about, I think there were four manager stances. So why, what, go and grow. And they kind of reminded me of the agile coaching stances, teach, mentor, coach, facilitate. The key thing being to be able to change stance given the situation. You have to be experienced in all those things, know when to bring that stance, and when to back off. 

And then the next one, shut up and ask what do you want to know. There’s lots of things I could talk about. What do you want to know? That’s probably going to be the one I’m going to try to implement the most because I think it’s the easiest to implement and probably has the most value for me.

And last one, customers are in charge of the scope, link the customer to the team, get out all the middlemen, which kind of makes it interesting when you talk about scrum and a product owner, or product manager. So that was me. One of my favorite for a long time. So thank you.

Read along you will

Shane: welcome to the No Nonsense Agile Podcast. I’m Shane Gibson.

Murray: And I’m Murray Robinson. 

Jack: And I’m Jack Skeels. 

Murray: Hi Jack, thanks for coming on today. 

Jack: Thanks for having me. 

Murray: We want to talk to you about your new book, Unmanaged. 

But why don’t you kick us off by telling us a bit about your background and experience? 

Jack: Sure. . So I started out as a programmer way back when, quickly became a project manager. And if you’ve been on that programmer to project manager side of things, you’ll realize that the project managers don’t really know shit about , what you’re doing. All of a sudden I was one, and I thought I should stay out of the way of the programmers, and I very early on, got this attitude to lay back and let people do their work. But in 1983 one of my good friends who was one of the programmers said, Hey, you should read this article. It’s about Iterative enhanced project management on how to run a project two weeks at a time. And I thought that’s genius. And so I did that. Actually became a little bit notorious in a good way at the company I was working at over the next couple of years for running these strange two week projects that were big projects. We’d run them two weeks at a time. Agile didn’t exist in 1983 but that technique did. And I liked it. And I eventually got into project and program management in a serious way, built a management consultancy and fast forward about 15 years. I sold it, went to grad school and ended up at RAND Corporation, the think tank. Where they had me study how consultancies work and how project driven organizations work. I stayed there for four years and I learned a lot about how knowledge worker organizations should operate. And this was right around the time that agile had been coined as a term.

I knew about XP and some of those other precursor things and worked in Rational Unified and all those sorts of things. I left RAND to get back in the real world and ended up being at Sapient. Ran Sapient’s Los Angeles office The management consultancy marketing organization. And they asked me to implement Agile. 

I implemented what they gave me, which seemed stupid to me actually, and we ran the first west Coast project using Agile, but What really happened is everyone did the project the way they normally do it. And then they would also make time to do the Agile things too. So they could show them and, hey, we did that. So they were high performers, but Agile didn’t do anything to boost their performance. in fact, actually slowed the project down. I had a moment where I decided I needed to prove that I could do this kind of thing. And step back and figured out what it was about Agile that you really wanted to keep and what you wanted to throw away and why it didn’t work in these agency and project driven environments. I tried it out at a new agency I was working at. It worked really well. 

And then I went out on my own and we built Agency Agile. We’ve been 14 years, 220 companies. And then here I am today here. So it’s the peak of my career.

Murray: Okay, great. 

What is Unmanaged about? 

Jack: Unmanaged is a book that comes from my biggest observation, which is Agile is getting applied everywhere. And the single common denominator that I could see through all the failed Agile implementations, and it’s not just confined to Agile, was that they would implement these techniques much like I did at Sapient, but they wouldn’t change anything about the way they manage the organization. And in fact, that ends up being the single largest factor in whether or not you can do anything remotely resembling agile or even remotely resembling improving people’s performance and productivity and happiness and the like. And I thought this is a message managers need to hear, and they need to realize that the act of managing isn’t necessarily all good.

Murray: Why not? 

Jack: it’s not the same as productivity. You ask managers, are they a source of productivity? And everyone will say yes. And then you say so if you call a meeting, does that make people more productive? No, they have to stop what they’re doing. There’s a culture of management that has little to do with productivity and has a lot to do with looking like a manager.

Murray: I remember when I did my MBA at quite a prestigious business school that they didn’t really teach us very much at all about managing people. 

Jack: No, they don’t teach you? anything. Nothing. 

Murray: So you’ve worked mostly with project services organisations, haven’t you?

Jack: Yeah, pretty much my whole career and on the client side of that as well, working in the PMO function and the like. 

Murray: I’ve been on both sides of the fence, client side and service provider side. And my observation is that most clients these days are saying they want to be agile, but 90 percent of clients that claim to be agile are far from it. And all of the service providers are saying that they are agile. And 99 percent of service providers are far from it. Mostly what they’re doing is their traditional waterfall management with, lots of agile words and some sprints for the dev people. Is that what you see? 

Jack: I don’t know that I’ve met anyone more skeptical about agile implementations than me, but I just have so it’s very nice to meet you. 

Shane: I think that’s the key, agile is not an implementation. We don’t implement Agile. What we try and do is increase agility so we can, change faster. But yeah, as soon as you hear somebody says we’re implementing Agile, that for me is a warning sign. Why is Agile the thing you actually want to achieve? Because it ain’t a thing, it’s just a way of working, it’s a culture, It’s about agility.

Jack: Yeah, I think you’re spot on with that comment. The origins of Agile, was a 10 year experiment. Where if we do X, does it get better? If we do Y, does it get worse? It wasn’t a dogmatic, we shall implement these seven rituals or anything like that. It was literally a set of experiments, including XP with pairs programming and other exotic forms of techniques, including they rolled IEPM. So they packaged a bunch of stuff that worked well in a specific situation. And I love your point that you’re making about, we better think about what we need to change in our situation that will make things more agile not what rituals should we copy, from somewhere else And then claim that we can plant the flag of agile on that and then move on.

Murray: yeah. 

So why is there so much terrible Agile out there? 

Jack: I’ve got a long list, but I’ll give you a few. I think the creation of Scrum Masters. As if two days of going to some class with ping pong balls and strange words made someone a master of anything is pretty crazy. And a real agile coach is like a industrial psychotherapist, okay, what is it, we need to get you guys taking ownership of this? And how do we get you more time? and what do we need to do for group dynamics? And how do we tune this thing? 

Murray: Why do managers keep wanting to do the same bureaucratic, industrial, type of stuff even though we know it doesn’t work very well. 

Jack: One is the managers are in charge, so they get to decide how things are done. If we go back to a hundred years ago and I’m a manager. We would have a department, say an assembly line, and I’ve got one manager and maybe eight people, and they’re making the proverbial widgets. So make 200 widgets a week. That’s the job of the department. And I, the manager, make sure that happened. Now, There are really clean measures in place because if the manager interfered with productivity, it would show up in the number of widgets. If I decide to call a daily meeting for a half hour, all of a sudden the widget counts goes down. And his boss calls and says, Hey, what in the hell’s with the widget count? And the manager says I convened this scrum meeting. It’s supposed to make things go better. And the manager’s manager says, stop doing that let people get their work done. And you could very easily track productivity of people against a single manager. It was my job to make sure I didn’t do anything to destroy productivity. and today, fast forward, our environments are largely what we call multi manager environments, the matrix organization, multi project, et cetera. And, whatever happens to the loss in productivity can’t be attributed to any manager. In fact, what we end up doing is we start hiring more managers to improve productivity when, in fact, the number of managers inside your organization is inversely proportional to its productivity. And this was something Agile proved, by the way, but I’ll explain that in a minute. 

But the key idea is if managers don’t realize that the fundamental act of managing is contrary to productivity and their job is productivity, then they’re lost. 

Murray: Is that job productivity or is it delivering value?

Jack: So when I say productivity, it’s the speed at which you deliver a quality first time product. In other words, that it’s first time correct, feature complete, and I’m doing it with the minimum effort required and delivering it on time or before and having adequate quality or superior quality.

Murray: Yeah there has been a big movement over the last few years away from speed and productivity towards focusing on business outcomes and products because you can deliver the wrong things faster and that’s not going to help you, 

Jack: Yeah. I totally get what you’re saying. I think the frame that I’m working in is the defined delivery perspective. Most clients don’t know shit about doing agile, and most clients. Fumble their way through product roadmaps and all that kind of thing. And aren’t enlightened enough to say, Hey, I really want to do an exploratory approach. The exploratory approach is a unicorn, frankly. 

You guys have a great shop down in Australia called Future Friendly. And we helped them go from the classic waterfall agency model to that sort of thing. The experience design agency that says, I know you’re trying to solve this, but is that the right problem And, is this the right way to do it. It can happen, but it’s so rare these days. I don’t think organizations have kept up with the vocabulary in any way. I think organizations still bumble along and in the way things get budgeted, like you’re going to do X by November and here’s some 1. 5 million to do it and you better get it done . 95 percent of the companies I work with live in that world. It’d be great if we were in the world you’re talking about, but I don’t run across it all that much. 

Murray: So if we’re in the projects world, which is mostly where you work, What usually goes wrong from the agency or service provider point of view? 

Jack: I think the key thing, is, by nature, the work we’re doing in a project driven organization is. uncertain, because we don’t do the same thing twice. We only do projects for things that haven’t been done before. So there’s some level of uncertainty. Now we work with software development shops, as well as advertising agencies, marketing agencies and the more innovative you’re trying to be, the more complex the problem, the more creative you’re trying to be, the more uncertainty there is, and uncertainty means ignorance. We don’t know what it is, and it’s actually a good situation to be agile around. This is the ultimate expression of the Problem software Agile was trying to solve, which is I want you to do something interesting, big, complex, creative, whatever. And I want you to tell me exactly how long it will take and how much exactly it will cost. 

And what happens is companies answer that question. They say, sure, we’ll have it by November 15th. It’s only a cost this much. And though we can’t even describe it all, you’ll be happy when you get it. That’s what the marketplace sells and buys right now. it’s hard to get out of that. 

Shane: We often see the big shiny suit big consulting companies that bring in, the partner, and then the graddies to try and do the work. We can often use them as a litmus test of when something’s getting traction because they all jump on and mcDonald’s it. And then they try and provide certainty around it. So, we’ve just been through a massive wave of digital transformation. And go back to your point right at the beginning, okay, new word, maybe different slippers, probably still working the same path. What’s your view on that? Are you seeing That kind of behavior in terms of digital transformation being this pretense of innovation, but actually we don’t want any uncertainty. So let’s call it digital transformation, give it a whole lot of certainty, which means it’s not innovation in any way, is it? It’s replaying what we’ve always known may or may not work.

Jack: This is customer driven. If the client is coming to you and they say, we need something by the end of the year, and here’s what it has to be. And you start working backwards from how much work is this going to be? How much time do I have on the front end? Then, the more compressed that is, the more likely it looks like the same old shitty projects that everyone’s still been doing all along. 

I have seen situations where people actually take the time to do things like ethnographic research, behavioral research, user experience, design, service design. When you do those steps in advance, you’re actually coming up with a solution and detailing it out in a way that’s actually very rich. When you do that, I don’t know that agile itself is really all that needed. It’s actually just good practice to try and understand what it is you’re trying to do before you do it. 

The thing that goes wrong with those big consulting projects is that they think that doing agile will somehow solve the problem of them not knowing what they’re going to be doing or how to do it. And it doesn’t change anything. And then no one does it well anyways. No one does spikes, no one does, things to drive risk down, no one does business value versus cost comparisons, no one does any of that shit. They just, argue about what’s in the backlog and get it done, and it, tends to be a mess. So we were talking with one where , they were getting ready to do another version of the same project three year later and they’d gone over by 180%, 180%. And this guy was in complete denial when I was talking to him, like he was going to bring it in on time this next time.

Murray: It’s completely normal for projects on the client side, to be done three times and for service providers to be fired because it’s going way over time and budget and then they get another service provider and that same thing happens. And then the third time they just say, it’s got to be done no matter what now. We can’t afford to fire them anymore. 

I think it’s very common for agency projects to be, unprofitable. My experience is that all the agencies and marketing companies will say they’re agile now and they do sprints. But their clients are asking them to do fixed price, fixed scope projects and those projects are sold and then the teams find that they can’t do it. So it’s either unprofitable, huge amounts of unpaid overtime and poor quality bad client relationships. Would you say that’s common ?

Jack: Yeah. First of all, it is, and I’ll give just the listeners who may not be familiar with that space, just a little bit more context. A 50 person marketing agency probably has 40 different clients and 120 projects running simultaneously. And none of those projects had a good scope defined for them. And the typical hours overage, is about 30%, somewhere between 25 percent and 40 percent on average. So they’re blowing through budgets and that blows up other projects and it’s a continual chaotic mess. So yes, it’s true. It’s the way it is.

Murray: Yeah I had a CEO tell me that the whole business ran on unpaid overtime. 

Jack: Yeah, and it runs on the acquisition of new clients cause you’re burning clients out. Your client retention is a year and a half or something. 

Murray: Yeah So if you decided to take a job with one of those organizations as their general manager of delivery. What would you do? 

Jack: I’d quit. No, just kidding. 

The first problem that you have to fix is actually scope. Most project driven organizations, even if your project is 2 million it’s very scopable. You can actually drive the uncertainty of the scope, but it takes technique to do that. A smaller project, a hundred thousand dollar project. you can scope it. It’s just that people don’t understand how to do that well. So the first thing you implement is a process, which is, let’s make sure we really understand what the client’s asking for. Let’s make sure the client understands what the client is asking for. And a lot of times, the person you’re talking to at the client isn’t even aligned with the other people inside that organization. So , even if you did what they said, it’s still going to get rejected because they didn’t even have everyone in agreement. So you really need to work from the very front end of the process. And then it needs to go all the way down to the team. In other words, the team really needs to validate that they understand what’s being asked of them. This isn’t a long process, but it’s a methodical process. When you follow it, you can slash those rework rates and then the agency gets better. They’re not in crisis all the time. But poorly defined scope and the ignoring of the fact that scope is poorly defined is the biggest problem in almost every digital agency today. 

Murray: What about selling projects that are fixed price, fixed budget, but variable scope. 

Jack: Look, if you can get clients to do that’s great. The challenge is either you are going to have to narrow your focus and say, we’re only working with clients like that, which back then this was five years ago that was about 25 percent of the clients that seemed would try that. Okay. Partly because they wanted to try it. But to really mean it is a whole ethos on the client side that defies the way budgeting is done. I think that there are these structural issues that no matter what you say, the whole thing has to be done for a certain amount of dollars by a certain time, And so I think it’s, a tough road and a lot of shops I know sometimes get clients like that, but in general, it’s a fixed price world. There’s a buyer seller dynamic because of competition, which goes something like this. I’ve got this project, I’ve got 200, 000 and I need it by November 15th. Do you want it or not? And the answer has to be yes, or else they say, okay, cause this, other agency calls me every Friday asking me if I have any business and they will say yes. So it’s this race to the bottom between agencies that has agencies taking blind scope in the door. And it’s really only in those longer term relationships where you can start developing trust And saying, come on, let’s get real about this. Let’s really talk about what success looks like. Let’s implement the right features first and recognize that some features will never get used and that kind of thing. But I just don’t think the client, the buyers are there in terms of that belief system 

Murray: Yeah, but the scope is pretty unclear even from the client’s side. As you said, there’s often contradictions internally and even more so on your side as a service provider. So you’ve signed up for something, presumably your partners and your sales people have promised the client, yes, you said you have 200, 000 to do this and we can do it for 200, 000, cause they want to get the sale cause that’s what they’re measured on. And then you go in and you find out that you can’t do what you’ve signed up for. If you do your scoping exercise, you spend a couple of weeks all working together defining it. So what do you do then?

Jack: Yeah so first, you can’t spend a couple weeks, you gotta spend a couple days, and that’s what we teach, because you gotta get moving, first of all, and it’s got to be easy enough to do and easy enough to share that you can get some alignment. 

So , there are multiple problems. Okay? And one of the biggest problems inside of an agency, because of so many projects going on at the same time, is a thing we call scope contagion. Because many projects have overage to them, and, I don’t know it ’cause I don’t know the scope, this overage surprises me and, it blows up other projects schedules. A bad project makes the good projects go bad because I can’t get people off of the bad project to put on the good project until eight weeks later and now that project’s going to be late and that’ll ripple through.

So the first problem you want to solve is contagion. I don’t think solving the difference between sales scope and delivery scope is the first problem to solve. If I know early on that project is 1300 hours, I can plan for that. Okay. I can make sure I don’t blow up other projects. I can make sure I have resources available for those other projects. Cause I know this one’s going to go longer than what we hoped for, but when it surprises me, that just blows my whole organization up. So the first step is to just be intellectually honest with yourself about scope and say,, we sold it for 200, 000 and the probability that we’ll be able to deliver it at our full billing rate for 200, 000 is almost zero. Now let’s find out what the correct number of hours is. Let’s plan for that and see if we can beat that. I always like to say the 1300 hours will beat you to death. Unless you beat it. So we want to know the 1300 first, and then we can work on how do we bring it down from 1300? But that’s a scope exploration development thing. And we’ve proven it, over 200 companies now. It changes the way the organization operates by getting in front of scope in that way. Our techniques reduce that overage rate by about 80%. Then things get a lot calmer. And projects get delivered better and agencies can handle the overage. They survived despite the fact that they’re not profitable projects, but what they don’t survive well is the chaos that goes with not managing this sort of craziness inside project scope.

Shane: So they can constantly go over their expectations of the work they’re going to do for the money they’re going to get paid. And so there’s only two patterns where you can do that. One is you charge a shit ton more for your people than you pay them, or you’re a Ponzi scheme and as soon as you stop getting enough work in the, front, you’re bankrupt. Is there one of those that’s more popular for these companies or not? 

Jack: I think what we see is the consultancies do the former. A lot of times the consultancies have very big high level engagements that are millions and millions of dollars and they take the projects on at ridiculous prices, but they don’t care if the project comes in at 100 percent over because they’re getting most of their money from the executive and board level work that they’re doing.

So that’s one answer. I think the other answer on the smaller shops, like agency side is that they do it partly on the backs of their people. It’s unpaid overtime and, hey, come on, we got to get it done, that sort of thing. But that costs them in terms of, turnover of employees and all that 

A lot of times when they say they’re losing money, that’s a fictitious losing money because the way they’re counting the number, look, they don’t go out of business. I was at an agency for a couple of years before I started doing this and every single project was in the red. But they were growing, and they were doing well, and it wasn’t a Ponzi scheme or anything like that. But it was really that none of the projects were coming anywhere near close to the margin that they’d expected. 

Murray: Yeah, so my experience is that if you’re paying somebody a hundred thousand your goal is to bill them out at or 250 revenue. Or maybe even 300 if you’re one of the bigger brand agencies and That’s your goal. You don’t get there, but you get enough so, you can keep going. Although one of the big problems in those agencies is excessive overhead. 

Let’s move away a little bit from the projects and the project team level. What is the leadership and the management responsibility for all of this?

Jack: Look I like talking about the two week sprint and I say, how many managers are involved in the two week sprint, that you’ve got some managers involved on day one, you got some managers involved on day 10, and where are all the managers days two through nine? Who gives a shit? Get the hell away from the team. Let the team get work done. The cardinal rule is stay away from the team, let them be productive. But managers don’t know how to do that. 

I’ll tell you some scary numbers. Okay. the typical advertising marketing agency, say 60 person agency has 25 managers in it. That’s like a one to two ratio of managers to makers. That’s crazy. And that’s why I wrote the book, because people don’t get that. Managers always think managers are the solution to any problem. There’s a great shop down in Melbourne that we love and we’ve done a lot of work with them. There are 35 people and they have one manager, the owner. The CEO and everyone else is just doing the stuff and they spread out all the, managerial responsibilities among them. I know of a shop in the U S that they’ve grown really large now, so it’s no longer true, but there were 120 people with eight managers. You don’t need that many managers. And a lot of the managers come out of the maker class as well. And so you’re taking your best makers and turning them into managers, which makes them far less productive or maybe completely non productive. We do need some, but we don’t need a one to two ratio. We don’t need 25 managers in a 60 person organization, not by any stretch. 

Murray: Yeah So why do we have so many managers? 

Jack: So This all came from the matrix management movement back in the seventies, which said maybe people would be more effective if they had more than one manager. So I’ve got this department manager, and then I’ve got these other managers. You can think of it. as a matrix, one vertical, one horizontal. And then someone said if, having two managers is good. Maybe having four managers is even better. And so if you look at an agency even today’s modern client side organization, everyone’s a frigging manager.

I’ve got department managers? Yes. That’s the only true manager. The other ones are quasi managers. they have a managerial title but they don’t have any people. They might have other managers they, work with, but they all have a right to go interfere with makers. They all have a right to inject their opinion, to argue for their priorities. Instead of having one manager for eight makers, we have eight managers for one maker. That’s the problem is that we let organizations get this way thinking there’s no cost to it. And then we wonder why people aren’t productive and the cost is the, managers. 

Murray: What’s a good organization look like? 

Jack: A good organization looks like the minimum amount of managing that you need to get the type of work that you’re doing. Done, And that’s very context specific. But in general the idea is we build specialists in our departments and we want to keep the specialists in the departments. The department doesn’t need to be a fortress or a silo, but it’s really just a discipline in which we mentor people and support them and the, like. And So softening the idea of department management, and then trying to de layer between teams and the people that they’re doing the work for.

And a lot of times we decide we’re going to protect the team. By adding more managers between them and the client, which isn’t protecting the team. Don’t give me three layers of managers between me and what the client asked for. I want to hear them and I want to talk to them and share with them. We insist the team and the client talk. You can have account people if you want, but they’re not intermediaries in that conversation. 

Murray: What should a manager be aiming to do in this flat organizational structure? How can you be a good manager in this environment? 

Jack: Yeah. That’s essentially the paradox if you believe even 30 percent or 40 percent of what I said, you should be terrified as a manager because, okay, then what can I do? And the dilemma is people do need a guideline. So we came up with one, it’s in the book and it’s called the four key managerial moments. 

There are four moments in which you need to be a manager in a, certain way. And the four moments are the why, the what, the go, and the grow. So why is understanding the why, the context of the work. You need to make sure everyone understands it and there are proven ways to do it. 

The what is the scope, What it is we’re trying to accomplish, what the deliverables are, all that kind of thing. Most of the time when we try and transfer that information to the team, it fails or it’s incomplete or misunderstood.

Go is when the team’s doing it and how to not interrupt them. 

And the fourth is really something that underlies all of that, which is grow. 

As a manager one of the most important things to do is to grow everyone else. When I go from junior to mid level in my role, my job should be to help a bunch of other junior people get to mid level, that’s part of my job is to help grow the organization. And as I go farther up in the organization, my job is to actually get more people to follow me. Wouldn’t it be great if we had everyone was senior skill level. But today’s organization structures don’t work that way. It’s a winner take all situation as we go up the organization. You got two great people in the department. Only one of them becomes manager. 

So a whole different management ethos and learning how to lean back and not get in the way of teams. 

Murray: What are some practical things that people listening to this who are managers can take away? What are some things that they can start doing straight away that would help them be better managers? 

Jack: The easiest insight that we see people being able to grasp is that you explaining something, especially a whole project is almost utterly, ineffective. I used to do it when I was a group account director and I was running the Sapient Los Angeles office. I’d give everyone a 30 minute briefing. I had a 20 page PowerPoint that I’d put up on the screen and I’d talk constantly, jamming every little fact I could in and ask if there was any questions at the end and. No one asked any questions. I thought, man, I’m so damn good at this. 

And then for the next six months, people will be coming to my desk every day, asking me questions about the project. I was like, weren’t you listening at all? And they were listening, but they weren’t learning. They weren’t understanding. 

And so the biggest thing is to actually lead by question, by getting them to ask you and pull the scope out of you.

It’s a technique, the Japanese called BA, B A. What do you want to know about this? What can I tell you about this? What else do you want to know? What do you think that means? Using questions is the primary skill of a great manager. Because we don’t want to be the one who does all the thinking. We want everyone else to be doing all the thinking. That’s what a great manager does. A great manager tries to teach the team how to solve problems. 

Murray: Yeah, I really like that model. 

That’s more like a sports coach, because you’re not on the field, but you’re growing the capability of the people so they can do the right thing on the field. 

Jack: Yeah, it’s one of the best analogies to what we do. Sports teams are, high performance organizations. they have to learn every week or after every game. And the coach role, the position coach or the overall head coach, those roles are the ultimate definition of managing, which is all my people can be superstars. If only I figure out what they need to unlock their talents. That’s exactly how managers should be. You’re spot on. 

Murray: Unfortunately, there’s very little of that. That I’ve seen in my career. I’ve had to learn that from, reading books like yours

Jack: yeah. 

Murray: it’s a shame.

Jack: It’s hard to teach in the abstract. Our trainings are very, hands on with the actual project. We teach managers how to do it right in front of the whole team. We coach and say, no, you need to wait, shut up, let the team ask questions. And they start learning that there’s a safe place in which they can do something different. And so it’s that patterning that’s so essential. And then once they get good at it they figure out the other moments. They figure out the other ways to be, and they start using questions all the time. 

Murray: How do you scale this up to larger organizations? 

Jack: We, do a whole diagnostic to figure out where your problems are and then design the pieces that you need to implement, and then we do hands on implementation. We do train the trainer work as well, but you need to do a wave of implementations where you teach groups how to do a briefing correctly in a way that engages everyone, how to develop a scope that you can confirm with a client. Change is hard. This idea, if I send my project managers to Scrum Master School and they start doing something that we’re going to be Agile. 

That’s just a lie. Worse is the marketing of Agile by software providers. Just, install our package And you will be agile in 24 hours. Really By installing software. But that set expectations all wrong. The expectation wasn’t that, hey, if you change your culture, if you change the way you think about work and the way you think about your people, You can achieve amazing things. It was no, just agile in a box. Just add water and you’ll get there. And that’s, of course, doesn’t work.

Murray: I really like what you’re saying about manager as coach, but it strikes me that if you’ve got a 500 person organisation, And 300 of them are makers and 200 of them are managers. There’s going to be a lot less managers after we’ve gone through this process. Maybe there’s only going to be 50 managers or 20 managers left. 

Jack: Some managers just do leave because they’re like, I don’t like this. I like being in control. I like telling people what to do. They’ll just leave. Amongst the, top 20 or 30 clients who we’re regularly in touch with that are using our methods the vast majority probably haven’t cut the managerial stuff at all. I’m not sure why not. I think maybe project managers have shrunk in most of them. Because it is a self managing system. I think that changing that culture, that ethos of managers are a good thing is actually quite hard to do. And look, if you can get your makers 30 percent more productive and, kill the rework rate and boost margin a little bit. We can afford those managers. I’m always amazed that they. Don’t thin down more. But they just say, fine we’re happy getting the production side, delivery side results. And we’re going to keep the rest of the organization fine. 

Murray: I found when I did this at a digital agency that a lot of the account managers, decided to leave. And there’s always a high turnover in agencies. People don’t tend to last longer than 18 months anyway. You just restructure and don’t replace if you don’t need them anymore. 

Jack: People Are going to leave one way or another eventually, so you just let that, happen and you don’t refill those spots. It’s a bit more gentle to the organization. 

The book’s called unmanaged because I was trying to make that if I said, my team is unmanaged, you’d go oh my God, how are they going to get anything done? And my answer would be, no, they are going to get things done now that they’re unmanaged. and the idea that managing doesn’t have to be dominant like it is. I think we just need less managers in the faces of the people that are the makers trying to get work done. We need less managers thinking they, are in charge of scope when the team and the client should be in charge of scope. I don’t need to take on that political cause around managers, but I do, want to protect the makers and the workers and actually the organization by helping them make things better, get things done better. 

Murray: How much responsibility does the CEO and executive team have? Because my experience is that they are the ones who got the organization into the situation it’s in when you get called in. And they are also the ones who might not want to change anything about what they’re doing. But it seems to me that typically that they are the root cause of the problems that the organization is having. So the change needs to start at the top. what do you think about that and what do you do

Jack: Look, there are bad CEOs. Plenty of them out there. The thing I’ve seen is that there’s just an endemic notion of what managing and leadership is that’s just messed up. And I don’t want to blame a CEO for adopting the attitudes towards leadership and management that everyone else is doing. Okay. they just don’t know better. We don’t work with an organization unless we have it from the top down. And then what we require is you have to be serious about this. Once you learn how to do it, this is the way we’re doing it. We can adjust it, but it’s the way we’re doing it full stop. And if you don’t have that kind of mandate, then everyone just backslides on the change. 

Murray: So you haven’t really talked about Agile much in your book. So I’m wondering what else are you adding to the mix. 

Jack: Look, were it not for all the shit show around agile, I would say we’re doing agile. Except then the problem is that all the people who are doing shitty Agile, will go are you doing this? Are you doing that? I’m like, no, you don’t need to do that in this situation. Or they’ll say you’re pretty damn expensive because I hired this joker over here for, 100 an hour and he says, you’re stupid. So we get into those name games and the like. So in a way I step away from Agile. I do believe we essentially use what I think is a lot of the key values about believing in the fundamental strength of the worker and empowerment of people and everyone should know and all those great things that happen in a great Agile setting.

We implement sprints. We call them cycles because we structure them differently. And then we do standups. We call them check ins because they have different rules depending on the situation. And we have planning session. You know, we have, We have a lot of that stuff. The only one that we’ve truly thrown out is Scrum planning. The post it notes with Fibonacci numbers or planning poker and all that kind of thing . It isn’t necessary to be so vague and so consensus based in a , multidisciplinary situation. At the end of the day, when you look at the wall, you go, that’s like Scrum planning. It’s got index cards and, painter’s tape all over the wall and everything. But it’s not.

Murray: It’s really hard to estimate. I worked with a client recently where they’d done a very detailed scope on a big E commerce project. And we had four major companies bid for it. Three of them all came in around the same sort of figure. But when we drilled down on the amount of labor, The amount of hours of effort by people. There was a threefold difference in the amount of hours between the different companies. And then there was another team who were on another planet completely. So it’s amazing how vast the differences are in estimates between different organizations, even when you do have a very detailed scope. 

Jack: Yeah look, there’s how certain is your project? Is it Microsoft Azure implementation that we do over and over or something like that. That’s one thing doing a standalone project that’s really never been done before that has some serious size to it. You show me a specification, I’ll show you a book of lies. If you read the Mythical Man Month, it points out that the size of the specification is inversely proportional to the ability to understand it and its correctness.

We had an agency that had couple million dollar project that they’re running. It’s mostly a platform project. And we were doing our technique and everyone said it was useless because we had a full specification already. We’re doing our scoping technique with the cards all over the wall. We got pretty far and I said let’s pull out the spec and just double check. We’re not missing anything. It’s a good way to make sure you’ve got completeness. We start. Piling through it, it’s about 150 pages and we get to like page 87 or something like that. And it’s got 17 pages of boilerplate with nothing filled in. And the requirements, people are start freaking out and it’s right around lunchtime. And the requirements people say, we must’ve printed the wrong copy.

Sorry. We’ll fix that during lunch. And we come back after lunch and it turns out it wasn’t the wrong copy. It was the copy that got signed off by the client and no one ever filled out that section. So the VP of technology at the client company signed off on the document. I don’t know who he told to read it, but obviously they didn’t read it. And the agency didn’t even read it before they sent it. Okay. I’ve seen highly specified projects come in with 200 percent missing scope.

Murray: And also there’s a lot of things in the scope that you end up not doing anyway, because you realized you didn’t need to. And it’s the same for the architecture. If somebody does an architecture document, they have no idea what the cost of anything is. So they just put in all of the latest toys that they want to play with and everything becomes gold plated. 

Shane: It depends on the architect. If you’re an agile architect, then you don’t do that. You follow an agile architecture set of patterns and you don’t gold plate it.

Murray: I agree with you. I was talking about traditional architects. . How about we go to summaries, Shane? What you got? 

Shane: I’ve got so many takeaways. so So let’s run through them. 

You talked about this idea, we’re going to change the way we work, but actually we’ll carry on working the way we’ve always worked, but we’ll put another level of overhead where we get them to fill out Agile artifacts to pretend they’re running Agile. Lots of project managers take all the work the Agile team is doing and then fill out their project management templates on top for the PMO, so even more stupid than not changing the way you work is to add yet another layer on top. 

So the makers, and I love that term, the makers change the way they do things, but nobody else does, and somehow we expect that to have an impact. It’s great for the team, great for the makers. They typically deliver more, have more fun doing it, but nothing else gets better.

So you talked about the fact that a lot of the agile patterns came out of experimentation. And that experimentation proved that those patterns had value in a certain context, a certain situation. So when we’re looking at them, we should say, is that the same situation as us? Because then we have a high chance of success of that having value. The bit you added was, okay, so that technique was used in a situation that’s different to ours, how do we change the situation. How do we change the organization? How do we change all those other things to make our situation so that pattern has value? 

In a factory. When the manager makes a decision or a change, we can visualize the impact of productivity. We can see the system work better or break. Machines or humans do more, do less, do it better, do it worse. When we’re in a matrix model and a knowledge organization those systems aren’t so obvious. They’re not so linear. They’re not so measurable, but we don’t tend to measure them. So we can make decisions as managers and actually have no consequence whether we’re making it better or not. There’s been some research that the more managers in the organization, the less productivity. The more words in a spec, the less certainty of delivery. More is worse. We all know that idea of mythical man month, oh shit, we’re actually not going to make it. Add some more people. It’s the worst thing you can do. You’ve got no chance once you do that. 

And so then you went on to the idea of innovation and the idea that the more innovative you are, the more uncertainty you encounter. And that’s where I come to digital transformation. So if you’re going to digitally transform something. That’s where you want to innovate. That’s where you’re going into a massive amount of uncertainty. So having a big program with, three program managers, 16 project managers, massive teams is ridiculous because you’re walking into a massive amount of uncertainty and you can’t manage uncertainty with that many people. I’ve never seen anybody do it. 

And then you said organizations really don’t do spikes anymore. They don’t research, they don’t experiment. And yeah, I think that’s probably true. And then very few businesses do a trade off between business value and cost. They always have cost. What’s the cost? But they don’t actually articulate what the business value is or they do a business case with a whole lot of bullshit numbers that they know they need to do to get over the line and then they never measure it. And actually I was talking to somebody today and they’re doing some estimation for some permission to do some work and they picked a number and the leader that they’re working for tripled it before they went up for sign off.

And the person I was talking to said, stop, get it back to the number I wanted. And they’re like, why, we’ll just get you more money. And he goes, I picked that number because it was the maximum I could get without hitting that extra management overhead. And I thought that was a nice way of changing the situation. 

Again, you brought up this idea of budgeting is a structural issue that stops us doing a lot of the things we want. So look at your organization, figure out these things that are immutable, like your budgeting process, your financial year, and you say, how do you change the situation? Cause they will affect what you do. 

Intrigued about quick scoping. Cause you talked about. Quick scoping using patterns that are repeatable, and I think immutable, so it’s not just a guess, it’s this is how we do it. It’s a pattern, we apply that pattern every time, but we do it quickly. So if you’re doing a 100k piece of work, if you’ve got a team doing something for a month, you can’t spend weeks scoping, but also you should still scope, don’t walk in blind, just do as little as possible to have the reduction in uncertainty.

And then the next one, which I loved was, Bad projects make good projects go bad, because there’s a blast radius. We always have resources constraints. And actually I’ve seen that all the time. So our critical resources are not available because they’re being sucked up in a thing that in the blast radius of that bad thing is so much bigger than the thing itself. 

And then what’s the role of a manager? It’s to set the team up for success, get out of their way, help them when they’re stuck and just observe them. Don’t get in their way. 

And then anti pattern, take your best makers and turn them into managers. It’s how to make everybody else go slower and lose some of your best ability to deliver. 

And then you talked about, I think there were four manager stances. So why, what, go and grow. And they kind of reminded me of the agile coaching stances, teach, mentor, coach, facilitate. The key thing being to be able to change stance given the situation. You have to be experienced in all those things, know when to bring that stance, and when to back off. 

And then the next one, shut up and ask what do you want to know. There’s lots of things I could talk about. What do you want to know? That’s probably going to be the one I’m going to try to implement the most because I think it’s the easiest to implement and probably has the most value for me.

And last one, customers are in charge of the scope, link the customer to the team, get out all the middlemen, which kind of makes it interesting when you talk about scrum and a product owner, or product manager. So that was me. One of my favorite for a long time. So thank you. Murray.

Jack: Oh, wonderful. Thank you. 

Murray: I really like your advocacy for a Manager as a sports coach and there’s far too little of. I have also seen organizations go from chaos to calmness by implementing this sort of approach you’re talking about. And I’ve also seen them greatly increase their profitability as a result. If you can do more of your projects on time and on budget, you’re going to make more money. That seems obvious.

Jack: Absolutely.

Murray: There’s a bunch of tools you can use around working with the client to negotiate the scope more effectively because it’s very uncertain. I love that story about page 86. There’s 12 pages of boilerplate that nobody filled in and everybody signed off on. That is classic. I always say to people, the requirements are always partially wrong. Maybe only 30%, we don’t know. But then, the architect is always partially wrong as well, because it’s building on those wrong requirements. And the more of those big fixed scope things you do up front, the more wrong they get, because they’re all built on flawed things from before. 

We work in an environment where there’s considerable uncertainty. Project world is always a lot of uncertainty, particularly digital. We’re being asked to do something. New every day, and people don’t really know how to do it. They don’t know how to estimate it properly. Everybody’s wrong about a lot of stuff all of the time until they test it. And see if it works. And so the best way to work is one that accepts that reality and says, we are going to test everything as quickly as possible and find out what works. And there’s lots of tools in the Agile tool set to do this. And Agile is much, much more than Scrum. It’s includes DevOps, continuous delivery, lean startup, all these things. 

I think there is a very serious problem with over managing in organizations today. In DevOps, they talk about the Westrom organization models. And he says there’s three types of organizations, pathological, power oriented organization where everybody tells people, whatever they want to hear, because otherwise they get shot.

Then there’s bureaucratic organizations, which are all about rules. So trying to move away from failure due to bad individual managers by putting up bureaucracy and rules everywhere. But those are very slow and have all the problems we’ve been talking about. 

And then there’s what he calls generative or performance oriented organizations, but I think you could call them. Organizations, agile, creative, adaptive organizations. It’s all the same sort of thing where there’s high cooperation, information and risks are shared. There’s a lot of collaboration. And I think the management model that you talk about is what the devOps people talk about as the generative model. And really it’s just the modern way of doing things that everybody should be doing. But if you’re an empire building power focused manager, who is trying to climb the ladder and dominate the people below you, I can see why you wouldn’t like it.

Jack: No, they don’t like this stuff. 

Murray: Ultimately I think that it all starts from the top, because the leaders set the culture of the organization by example. Not by the posters they put on the wall, but by what they actually reward and punish. And so real change has to come from the top, but also from the bottom I like the agile approach of you can be a leader anywhere in an organization that’s really important. I would love for more of the executive team to take on this approach that you’re suggesting as well, and I think that would really lead to success.

Jack: Yeah.

Murray: So where can people find your book, Unmanaged, and where can they find out more about you and the services you offer, Jack? 

Jack: Yeah. Thanks. So you can find the book on Amazon. You can find me on LinkedIn, Jack Skeels. Also, I do a couple of tours every year. I’ll be in Australia probably in March or April this year, and then again in September, October. In the UK probably during the summer for three or four weeks.

And depending on where you are hit me up and I may be around your town. If you’re in one of the big cities, I can come by and have a chat if you like. And then you can find out more about our organization at agencyagile. com. 

Murray: And what sort of engagements do you do with companies? 

Jack: We have a standard program. You commit to doing work with us over the course of about three to six months and we implement a set of high intensity workshops and the like, and we start with the leadership for a couple of days, and then we go into the scoping problem for four or five days. And then we go into the daily productivity problem. And if you want to keep on going, we’ve got some other modules and the like, but it’s a very, , tried and tested and true if you’re essentially marketing, digital marketing agency, digital agency, that kind of thing. They’ve been battle tested with over 200 of those organizations now. 

Murray: All right. Thanks for coming on.

Jack: Hey, thanks for having me guys. Great discussion. Really, really enjoyed it and smart questions and a lot of fun too.

Murray: That was the No Nonsense Agile Podcast from Murray Robinson and Shane Gibson. If you’d like help to create high value digital products and services, contact murray at evolve. co. That’s evolve with a zero. Thanks for listening.