On November 4, 2015 Steve Tendon was interviewed by Clarke Ching “the Bottleneck Guy” about the TameFlow Approach
Here’s an edited transcript:
Clarke: The easiest way to find your book is to search on Amazon for your name as Steve Tendon, the title of the book is “Hyper-Productive Knowledge-Work Performance”. There we have two big phrases. The “Hyper-Productive Knowledge-Work,” and then “Performance.” I remember you originally called it “Tame the Flow.” Could you maybe talk a little about the title and I guess more specifically just about _“TameFlow” because it is there it all came from.
Steve: Yes right, the original title almost came about by accident. TameFlow is what I been working on for the last twelve, thirteen years and it is just a collection of my experience and way of doing things when dealing with teams and organizations. In this work I tempt to focus on four things, four flows actually. The first one is the obvious one, the Operational Flow, things that you would probably recognize on the manufacturing floor if you are looking at Theory of Constraints, or you will recognize the Kanban Board. Then I look into Financial Flow which matches pretty nicely to Throughput Account and TOC. Then I was looking into Informational Flow and finally Psychological Flow.
So we have all these four flows. It just so happene that when I was writing the manuscript of the original e-book which I self-published, and I was looking for a cover for the book, I came across a wonderful computer generated image. It showed a mythological figure and came with the title of “Tame the Flow of the River Strix — that is what inspired me to use the phrase “Tame the Flow” which became the title of the original book. It is that image that I put in relation to the four flows that I was working with. Hence: “TAME THE FLOW!”
Clarke: You worked on the book with Wolfram Müller. How did that work, is it kind of 50/50 or 80/20?
Steve Wolfram took mostly the part on what we now call “TameFlow Scrum” in the last part of the book. It is what he had developed autonomously. We got to know each other because I had been working on Kanban and merged together Kanban with the TCO concepts (like buffer management and signals); and it was by a series of intermediate contacts, the last which was with Rudi Burkhard. Rudi put me in touch with Wolfram saying: “You two are doing more or less the same thing. You should talk.”
We had a chat and I think that after five minutes we came to the conclusion that we should write a book. As a matter of fact, I had already a manuscript, because I was working on that by myself. Not so much with the intention of actually publishing a book, but more with the intention of collecting my thoughts and to be in the position to answer the question: “How do you do you things?” It had always been hard for me to answer that question; so I was trying to collect all these ideas, give them some systematic treatment. With that material; meeting Wolfram and saying, “Let’s write a book.”, Wolfram replied “Yes let’s do it!”. And so we did it.
Clarke: The book, if I remember correctly is really targeted at managers and executive. Is that correct?
Steve: The first half of the book is targeted at managers and executives; the second part is more operational, and it will typically appeal to people who are trying to apply TOC to the software development / knowledge-work setting. Or people coming from an Agile background — say Scrum, Kanban, XP — who face the problem to scale agility into larger organizations. I think that merging some of these ideas you get a good combination that really addresses the management of knowledge-work at scale in very large organizations.
Clarke: So it is the management knowledge-work at scale. I know you are doing a lot of consulting work on this stuff, could you maybe give some examples of the kind of things that may help people out.
Steve: In the Agile space, I made quite a mark last year because the client I worked with, actually won the UK Agile Awards 2014 for the best use of Agile in the private sector. Much of what they did was actually an application of TameFlow to agile, from a setting were Scrum and Kanban were the backbone on top of which I brought in my TameFlow concepts.
I also have other examples that go further back in time which are not strictly related to a software development situation, but rather to situations of management. One instance was this company that had done a series of acquisitions throughout Europe and ended up with tens of businesses which were all more or less producing the same thing. The problem was how to bring them over to a common platform. Of course the real problem was not at all technical. It was more of a psychological nature because all the country managers, project owners, product owners, were of course fearful that their bit of business would be cut out of the bigger picture. So that is where I started applying these ideas of creating Unity of Purpose and building up a Community of Trust. To make that long story short, it was about an organization that had thousands of employees; just the engineering part was about 300 engineers. At the end, these ten ten country managers, came to an unanimous decision of how to move forward. They had tried to do that for three years before that point, and never reached this kind of agreement. So that is an example which is not related to the Operational Flow, but more to the Psychological Flow.
Right now I am dealing with a large organization in the automotive industry. We are talking about engineering teams, which are in the order of forty-five hundred people distributed globally all working together on a common project which needs integration at the end so it is like a large scale TOC implementation with aspects of TameFlow added to them.
We also have examples of startups which have been in a challenged situation, and adopted TameFlow, and in a matter of weeks or months just unblocked whatever was blocking them; and were able to get to their MVP very very quickly.
Clarke: Could you maybe elaborate a bit more on this: there is startup that does, say Scrum or Kanban, and then picks up TameFlow. What is different there with TameFlow?
Steve: This gives me the opportunity to get to the core, the essence of TameFlow; what TameFlow is really all about. TameFlow is a holistic approach like TOC; so it looks at the whole. Looking at the whole means that you can attack the problem from many different angles, and having four flows I can easily approach any organization from different perspectives. So if there is a workflow problem, we have solutions; if there is a financial problem we have solution; and so on and so forth. But the question is: what is the common thread across all these flows?
Let’s start with that example you gave about the startup that maybe adopts something like Scrum or Kanban. Not withstanding how good or bad their adoption might be, the problem is that at a certain point when this organization grows it will inevitably call in quote-quote “professional management”. When professional management comes in, the organization becomes both wider and deeper. As a manager or as an executive you then have this problem: how can you make sure that the organization really goes in the direction that you want.
In the old traditional manufacturing metaphor, that problem is easy to solve: it is solved through processes; by defining processes. What are processes? Well, they are nothing else then the embodiment a decision or a series of decisions. In the extreme case, the process is an algorithm. Anything that is automated, at the end of the day, is a process that someone has thought up and is delegating the decision making to the process. If you are on a factory floor you have very well defined set of actions that you must do under certain conditions: that is a decision making embodiment which you read off your process schedule.
But what about knowledge-work? Well this is where we come to TameFlow. Let’s get back to that startup that is growing. When you are in the realm of knowledge-work, there is nothing that can be captured in a process or in an algorithm. So how do you, as a manager, ensure that you are leading the organization in the direction you want. As a knowledge-work manager you have an additional problem: the knowledge-workers know more than yourself. Drucker highlighted this.
Iin a knowledge-work organization the leader has to delegate decision making to whomever knows the most.
An example I use several times, and I like a lot because anybody can relate to it, is that of aircraft captains. Even if you are the CEO of the airline, when you board a plane, unless you were a pilot yourself in your professional life, you just have to delegate complete responsibility to the pilot. That is an example of delegation of decision-making.
So going back to the question: when you are in a situation of knowledge-work and you don’t know yourself what decision should be made, how can you deal with this? The answer — and this is the core of TameFlow — is that you instill in the minds of all people in the organization a reference model of thinking.
Now, you come from a TOC background and you probably are quick to connect the dots here, and connect this to something like the Thinking Processes and you would be right. because they very much inspired me a lot in developing this idea. The big thing is that you want the people of your organization to be able to make decisions on the basis of some reference models of thinking. That gives you the power to delegate the decision-making because you will know that your people will make decisions that might not be exactly the same as those that you would have made, but at least they will go in the same direction. At least they will be consistent and coherent, and above anything else if everyone uses the same reference of model thinking, they will avoid a lot of conflicts and friction. That for me is the key for hyper-performing organizations. If you have conflicts, if you have diverse interests or hidden agendas, and things like that, you will never have a hyper-performing organization. Through this methodology or way of working by using reference models of thinking and getting everyone to make decisions in a consistent way you can be reassured that many problems just don’t pop up to begin with. That, in a nutshell is the core of TameFlow. It is not about processes; it is not about principles, practices, roles, artifacts, ceremonies; it is not about maturity levels; it is not about values; it is not about a framework. It is really about a way of thinking.
Clarke: So the core idea of TameFlow is, that you get people moving in the same direction. Is that right?
Steve: Absolutely! One of the things I say, is that you see to create Unity of Purpose and a Community of Trust. Those are like the two, I do not like the to use the term “pillars,” but that gives the idea. To have a high-performing organization you must have — it is aa necessary condition — the Unity of Purpose and a Community of Trust.
Clarke: Ok, so the Unity of Purpose means we are all rowing in the same direction. Say I have a brand new start up here: What kind of different directions could people be going in? Could you give us some concrete examples?
Steve: Yes. I really like to mention some examples that come from Throughput Accounting, like the PQ exercise of Goldratt. In fact in the book I have taken that example as it was presented by professor Holt of the Washington State University. The example highlights the financial aspect of deciding which product I should produce to make most money. You go through the exercise of finding Herbie — the constraint — and basically calculate the financial throughput on the constraint. Then you make the decision based on that.
What am I like most of that set up, is that it illustrate how in such a very simple situation, you can have hidden agendas. So, while the accountant will tell you, of course we must hit the product which has the highest profit; maybe someone in sales, who is driven by sales commission, would rather prefer the product that has the highest sales price, because his commission is based on the sales. Someone in production might prefer the product that utilizes his resources most, because they are still stuck in the resource efficiency mindset. So just that simple question gives you three different answers; while there is one political correct answer that everyone and everybody will sustain — with straight face, and that is “the product which makes the most profit” — but then you have these hidden agendas. The salesman will push another product. The production engineer will push a third one. That’s an example of how the 2257 traditional accountant practices, the “management accounting” practices not only make you pick the wrong product from a financial perspective, from a profit perspective, but actually undermine this thing that is Unity of Purpose, because you encourage people to have different interest.
Clarke: OK, that is interesting. Let’s look at Agile. With my TOC spectacles on — which determine a lot how I am think and see the world nowadays — I sense there is a huge difference in what other people value and what I value. Often just looking say through the Twitter streams, it seems there is a lot of tension. Like people who are pushing for technical purity, perhaps; versus others pushing for commercial performance. There seems to be a lot of conflict within our community about what we value and where we are heading.
Steve: You are touching on a real conflict that happens in all places where Agile is being “successful.” Because when Agile is being successful typically it starts at the team level, with one team. Then maybe it expands to two or three teams. But if the organization is large, then at a certain point you get this cash of paradigms. The Agile mindset, and let’s call it the quote-quote “business mindset.”
Agile has not been able, and I do not think it will ever be able to resolve this different in viewpoints, because Agile is not equipped to deal with the financial requirements that come out of finance driving the business. And vice-versa: finance, for as long as it remains entrenched in Cost Accounting practices, will never ever be able to appreciate what Agile and Agility really bring to the plate.
This is a situation that just cries for TameFlow, in my opinion, because there you have an intrinsic conflict. With TameFlow we can resolve that conflict. TameFlow works both bottom-up and top-down. Top-down we work on the financial aspect to make the organization appreciate that by going over to Throughput Accounting they will make different decisions. And the beauty is that those decisions will be more consistent with those that you will do from an Agile prospective.
Vice-versa with the people who are practicing Agile, you might change their perception as well, and make them appreciate what the larger context is. This is were the whole idea having a Goal which is clearly stated, verbalized, and constantly brought back to the attention of the people, is so important. This is were leadership becomes of essence.
When I work with people who are doing Agile, when they typically do the daily stand-ups, whether they do it in Scrum style or Kanban style, I try to get them to do them in a TOC style. At the stand up I just ask two questions. One is: “Where is Herbie?” And two is; “Will the troop make it to base camp before sunset?”. You know what those questions mean, because you have read “The Goal.”
If you are, say, in a development team, and you have a Kanban board, then the first question is simply, “Which work item has been aging the most? Which one is laying in behind?” We leave no one alone. We do not leave Herbie alone in the woods, so we must help that item that is lagging in behind. The second question is “Will the troop make it by sunset?” This means: will your “work package” (or, however you want to define it: an “epic,” a “release” or whatever); will this set of items you are working, will it be delivered by the time it is expected to be. And this is why we have Buffer Management.
Of course both of these questions are deeply dependent on collecting proper metrics. Once you start having numbers and metrics, then it becomes much easier to reason with the finance guys because you can relate the operational numbers to actual throughput; you can relate that to time to market; and to many other figures, that the business side appreciates. Slowly and surely, by doing this you start building up this Unity of Purpose of both the business side and the operational side. It might take a while, but sometimes it can go really, really fast.
Clarke: That is interesting, I like that. So that is Unity of Purpose getting people heading in the same direction. A big part of that is making sure that measurements, whether they are explicit or implicit, are relied upon. That is good. So the second pillar was around trust. Could you please tell us a little about that.
Steve: Yes, in principle it is very simple. If I as a manager delegate something to you I trust that you will do it properly and that you sort of keep your promises. In most organizations there is always this recurring breakdown of expectations, so trust is not there to start with. I think it is really exacerbated by the Cost Accounting practices.
In the Agile world there is a lot of ranting, literally, about Command-and-Control. I attributing it to an obsolete mindset, and that is true, because it comes from Taylorism. (Note that the intention of Taylor was actually noble in a way; but let us not go into that discussion.) This idea that Command-and-Control is caused by an “obsolete mindset,” is — in a way — like a romantic wishful thinking thing… while Agile is the new thing, so we will be better off with Agile.
I see it quite differently. I claim that because you are using Cost Accounting; you are using budgeting; you are creating silos; you are artificially creating different areas of interest, hidden agendas, and so on — therefore you as a leader cannot trust that your people are going in the same direction (because of those artificially created different interests). Hence, the only way that you have as a means, to ensure that they go where you want, is Command-and-Control.
In other words, the Command-and-Control paradigm is caused by Cost Accounting and not by “obsolete mindset.”
It is a wishful thinking to hope to replace Command-and-Control with quote-quote “a better mindset” as Agile hopes to do. It would be nice, but it just can not happen because we have all these *Cost Accounting practice in place. Therefore, in order to replace Command-and-Control with something which is much closer to the Agile mindset, and which is based on trust, you must go away from Cost Accounting, budgeting, and all these dysfunctional financial practices that create conflict and friction inside the organization. The objective I think should be fight the competition, not your own people and your own organization.
Clarke: That is a nice articulation, I like that. So we got Unity of Purpose, we got Trust. Now, with my imaginary startup here, we are busy working away, and people are heading maybe approximately in the same direction. What kind of tools do you use? You mentioned this kind of logistical stuff like the basic stand-ups, Sprints, Kanban boards, and all of the stuff that we practice. If you are working with peoples heads though, what kind of tools do you use to get people aligned and heading in the same direction?
Steve: Well, one thing I have discovered relatively recently and which I have entirely incorporated into TameFlow, is the Popcorn Flow approach of Claudio Perrone. “Popcorn” Flow is a very illustrative name; actually but it is a long acronym. It is basically a way to do very quick experiential and experimental based learning. It works very well also with TOC. In fact it my latest blog post on the Chronologist, I explain how you can merge Popcorn Flow with “Levels of Disagreement” of TOC’s Thinking Process.
Now, Pop-Corn Flow, going back to your question, “How do you start?”, I think it has the incredibly advantage of very quickly making it acceptable to be wrong. Accceptable to make experiments, to have a safe environment where people are allowed to try things out. So Popcorn actually stands for: Problems (and observations), Options, Possible experiments, Committed (experiments), Ongoing experiments, Review (of the outcome of the experiments), and Next. If you put those initials together you get “Popcorn.”
What is nice about this, is that it is a loop were the objective is to have the team (or the people participating) learn something, and then on the basis of that learning make decisions. It is a way of opening the minds to possibilities, it is a way of opening the attitudes. So rather than fighting about “your idea is wrong, and my idea is better than yours,” let’s just run an experiments. Let’s do it for a couple of weeks. Then we have some facts to discuss, rather than speculations.
This goes back to one of the principles of knowledge-work management and that is that nothing is 3509 deterministic, and you have to base everything on empiricism. When people start to accept that they are allowed to make experiments and open up their minds and attitudes, well, that is the point were I might propose some “special experiments.” Experiments that I already know what the outcome will be, but which are new for the people. Instead of me as a conslutant saying “Do this! Do that!” , I first work on making it acceptable to do experiments, and then I propose some experiments which they will try out, and.. OOPS!… by magic they turned out to be positive. Why? Because they are within the TameFlow mindset or the way to doing things.
For instance when we do the stand ups and I start asking “Where is Herbie?” At the beginning nobody knows. They have never thought about it. The next question is “How can we find out where Herbie is?”. That brings to the fact you have to start measuring things; and that brings to the fact that maybe your Kanban or Scrum board are not instrumented in order to measure these data points. So we start making experiments. Let’s start measuring in a more focused way so that we can answer that question. And that is were it starts.
Then we just keep on asking these kinds of questions. It is really very closed to Goldratt’s way of thinking; it is like TOC “in disguise.” By finding, on a daily basis, the answers to such questions, the team will improve. Once the team starts improving, I start working on other aspects which are more about the flow of information. Flow of information, for instance, between the executives and the operational people I might use variations of Patrick Steyaert’s Discovery Kanban or even the Popcorn Flow boards, and use those tools to create the very tight feedback loops in both directions, from executives to operations and vice-versa, whereby the flow of information inside the company is greatly enhanced and becomes really, really focused.
Then of course there is the psychological aspect of how to put people in a state of Mental Flow. You might be familiar with the concept which was theorized by Hungarian-American psychologist Mihaly Csikszentmihalyi. The point is that, once we have a Unity of Purpose and a Community of Trust, what is the next best thing we can do? Well, it is to create a situation were both individuals and the teams (the collectives) can perform at a very, very high levels. When you talk about Mental Flow of course the image you might have of maybe an athelete doing an extreme feat, or maybe an musician, an artist doing incredibly things, is exactly the kind of image I have in mind for individuals and teams doing knowledge-work.
Mental Flow can also be literally triggered if you organize both the environment and the work in a certain way. You can actually create this Flow Triggers, but like a precondition for that is that the Work Flow is really flowing first, and that information flow is in place. It is almost a paradox, but the faster the team goes, then the more time it needs to spend on coordinating and synchronizing, because things are advancing so fast. Therefore you must have a really, let’s say, well-oiled machinery to transmit all information and have all feedback loops in place. It does not make sense to have a single hyper-performing team, and then have things bogged because maybe management is not handling and escalation issue in good time. So in order to reach the Mental Flow states, all other flows must already be there in place and working at their best.
Clarke: Let me just sum up here what we got. You are Steve Tendon, you have a book which you wrote with Wolfram, “Hyper-Productive Knowledge-Work Performance” and it is about your TameFlow Approach. The pillars of it is around Trust and Unity of Purpose. I like that! It cuts through a lot of crap if you forgive my bluntness. I like it and it kind of works on top of all of the logistical stuff that we have in Agile and TOC. It is kind of a mixture, in my mind: I remember when I read The Goal I initially noticed all of the logistic, the bottleneck stuff, but there is so much more around than TOC. It is a way of thinking and it is a way of getting everyone aligned. Thank you very much.
Steve: Thank you Clarke. I hope the listeners will have found something useful in this chat.