In this Episode
Jutta Eckstein is the author of the Leanpub book Author of Company-wide Agility with Beyond Budgeting, Open Space & Sociocracy: Survive & Thrive on Disruption. In this interview, Leanpub co-founder Len Epp talks with Jutta about her background in tech, how pair programming works, "consent decision making," "Beyond Budgeting," her books, and at the end, they talk a little bit about her experience as a self-published author.
This interview was recorded on May 25, 2018.
This interview has been edited for conciseness and clarity.
Len: Hi, I'm Len Epp from Leanpub. In this Leanpub Frontmatter podcast, I'll be interviewing Jutta Eckstein.
Based in the city of Braunschweig in Germany, Jutta is a consultant, trainer and coach with 20 years' experience helping teams transition to and improve their agile processes in areas like product and project development, and advance-orientated design, amongst many other things.
Jutta's the author or co-author of four Leanpub books including including Diving For Hidden Treasures: Uncovering the Cost of Delay in Your Project Portfolio and Company-wide Agility with Beyond Budgeting, Open Space & Sociocracy].
In this interview, we're going to talk about Jutta's background and career, professional interests, her books, and at the end, we'll talk a little bit about her experience as a self-published author.
Thank you for being on the Leanpub Frontmatter Podcast.
Jutta: It's my pleasure to be here.
Len: And thank you for taking time out of your evening there in Germany - even though it's the morning here in the west coast of North America.
I always like to start these interviews by asking people for their origin story, so I was wondering if you could talk a little bit about where you grew up, and what your path was through your education, and how you eventually got into your career?
Jutta: Oh, how much time do we have for that?
Len: Well, sometimes these interviews take an hour and a half, sometimes they take 15 minutes. It depends on how much you want to say.
Jutta: I started off actually to become a teacher - a school teacher and for sports, and for artwork. In Germany, it's kind of a funny thing, how it works - how teachers are employed or wen they're educated.
The thing is, typically, maybe every five or seven years, the government discovers that well, everyone is going to be retired, and therefore we need really urgently new teachers. In the time in-between, they are not employing any teachers. So there's always this wave where the government all of a sudden recognizes, "Oh no, again - everyone is retiring, what's wrong?"
If you are done with your studies in-between, which was the case for me, then you don't get a job. I was in the down wave where they thought well they have enough people.
I thought, "What can I do?" Still trying to make a job, I was working in a pub at that time, and there was one of the guests saying, "Oh, I know a really cool thing that really would be great for you." That thing is called product engineering.
I studied at university, and I looked into that, and what intrigued me was that the students could put a focus on industrial design. That sounded like, "Well that would be for me," because of the artwork I did before in my other studies.
I applied and I was accepted to the university, and I started there. Actually there, because it wass engineering studies, in the first two semesters - for the first time saw a computer and worked with it. I'm a bit older, so it's way back when. It wasn't really that everyone had one, still. I got so excited about that. I liked programming really a lot. First, I started classically with Pascal , then C++ and Assembler. Especially Assembler, actually I liked it a lot, because you can see the result straight away, so that was really cool.
Then I thought I would have liked to change, and not finish product engineering, but do computer science. But then I also thought, "Well, it's already my second studies. Maybe I should just hang in there, and just finish that and get it done. Try to make a focus in that product engineering field on developing software." Which I then did.
Really the key focus was on C++, and I worked with that a lot. Also, my first job was around C++. That's how I got into that field - by being an engineer, but being excited about what's going on, how creative it really is working in programming.
Len: So you went from education to engineering.
Len: Then did you work for companies before you eventually became an independent consultant?
Len: So what was your first job like?
Jutta: My first job was - let me think about it. So the one thing was, that company already said, "We really like that object-orientated stuff." Which was kind of new at that time. We are not talking about '67, right? But more like the early 90s or so. That was, for me, a reason to go there. Because I really wanted to do object-oriented programming, so that's why I applied there for the job - and it was easy to get a job anyway.
We just developed all kinds of applications for customers. My speciality in that company was actually working object-oriented databases, which never really took off - but people thought that this will be the big new thing, and relational databases are gone. Which was proven wrong over time. But that's where I was focusing. For example, for a power plants we used an object-oriented database to capture all that information. Or in the medical area, for x-ray pictures - because object-oriented, it's kind of easier to keep it together as one object.
Then I moved onto a different company, and this was more like a "body leasing" thing. Everyone who worked there was sent to a client, and worked with that client, and developed software with them. There, the first project they sent me to was working with Smalltalk. I learnt Smalltalk programming, and that kind of screwed me up, I guess - because I liked it so much that I never wanted to go back to anything else. When they put me on the next project, which was C++ again, I said, "I can't do that anymore." I just fell in love with Smalltalk.
Which then led me to work for a Smalltalk company, ParkPlace, that was the company at the time for having all the environment and the compiler and stuff, for Smalltalk - well, interpreter. Which also led me to look at the way we are working in Smalltalk, and going to different kinds of conferences in the object-oriented field. Also into patterns, which then just started coming up.
Maybe now, I'll make it a little bit shorter, because the thing is that all the actual stuff has two main routes. These two main routes are Smalltalk and patterns. Because they're like XP and Scrum. So both have been first described in the Smalltalk world, and described as a pattern language. So similar to the design patterns, the Gang of Four patterns. These have been also described as pattern languages. In those communities in the Smalltalk and patterns communities, that Agile started - it wasn't called Agile at the time. Because I was there anyway, I heard about it. That was kind of mid-end 90's then.
Len: That's kind of when you went independent?
Jutta: That's true. I think, in '98, I went independent and I think it was like '97 when I first heard about XP and then Scrum, later on, as well.
Len: XP being Extreme Programming.
Jutta: Extreme Programming.
Len: Can you talk a little bit about what that is, and maybe- an interesting experience you had with that?
Jutta: The interesting thing first of all, is that just yesterday I returned from the XP Conference, which still exists. It's actually the very first conference in the actual field, that was started in 2000 in Sardinia, an island in the Mediterranean - very nice.
Len: I bet.
Jutta: This year we were in Porto, Portugal - also very nice.
Extreme Programming actually - well you asked me, and therefore you get my answer - is Scrum plus more stuff. Scrum is kind of an abstraction of XP. XP has - How do you setup planning and work as a team? How to involve the customer? - that stuff, and writing stories. Plus it has many developer practices, which are now making it into Scrum as well. For example, tester and development or pair programming. These are classical XP practices. People now talk about them, just saying, "Okay, these are mostly like agile practices that are helpful if you develop with Scrum," right?
Len: What was your first encounter with Agile practices? You mentioned before that it more or less existed before it got named.
Len: I was wondering if you could talk a little bit about what that experience was like - going from, I would imagine, a classical Waterfall experience, to an Agile workplace?
Jutta: When I first heard about XP, I think it was around '97, I thought, "This is a very natural way to develop software. It will make much more sense to me than whatever I learned at university." In the project I was on, we tried some things - other things we did anyway in Smalltalk. There was for a long time, that thing that was called the Refactoring Browser - developed by Joe Yoder, who also was at the XP Conference last week.
Ssome of the people are still around. We had those tools or SUnit, the TDD tool for Smalltalk - which is now well-known for Java JUnit. We had a lot of that. There were things there already. But we didn't use it with the discipline that now the agile methodologies are asking for, and are then helping a team to be successful together.
For example, we didn't do much pair programming before, but we tried that. When I came back from that conference and said, "Oh, let's try that." So that was good. But again, also, the Smalltalk environment allows a lot of these things. So it was kind of a natural fit.
Len: It's really interesting, as Marc Andreessen famously said, and as I think you quoted in one of your books, "Software is eating the world." How software is built is actually a really important part of our lives, in a way that I think a lot of people who aren't familiar with it might not really appreciate. I was wondering if you could talk a little bit about - specifically, what is pair programming? If someone's building the service that I'm going to be using in a pair programming process, what's happening?
Jutta: What's happening is that if we are together in a team in the same space, then it means we are sitting together in front of a computer, and we are sharing one keyboard. Sounds a little bit weird, because the thing is, one person is typing, and the other one is overlooking what's going on. The metaphor that's used is, it's the driver and the navigator.
The driver is the one sitting at the keyboard typing, and the navigator is more looking, "Oh, what might happen here?" Or, "We shouldn't forget about this." The rules are switching very quickly. It's not that, if I will be the driver, I would be this for the whole day and you are the navigator for the whole day. It's more like, often every two minutes or so, we are changing those roles, so it's very, very quick.
Actually it's a very nice question from that point of view. Because one of the books, we also wrote in a pair programming, pair writing way.
Len: Was this your colleague, John Buck?
Jutta: John Buck, exactly..
Len: I've got some questions about that in a little bit, I'm looking forward to talking to you about that. I guess it's curious to me like - because a program is a product of thought and review, and things were talking about, like test driven development and things like that. What's it like when you're pairing with someone? I've got to admit, I've never done that. I think I would find it - I think other people would find pairing with me incredibly frustrating.
Jutta: Why do you think so?
Len: Because I'm opinionated and demanding and short tempered when I think I'm right.
Jutta: I know that.
Len: Which are probably traits that many people who - I mean, not that I do a lot of programming myself. But I think that a lot of people could probably sympathize with being like that. How do you work out a relationship? For example, if you're pair programming, and you have a real disagreement about what the next step is - do you have a project manager that you can appeal to? Is just bickering part of that relationship, and just the way you get along?
Jutta: The very first thing is - and I know you didn't ask about that, but pair programming works best if people are kind of on the same level. It doesn't have to do anything with really education or training or mentoring. Although you learn a lot by doing it together, because the one person uses the programming environment in a different way, then the other one will know some shortcuts the other one doesn't know or whatever, something like that, right?
But whenever you have a big difference in knowledge, then it gets really frustrating for both. Because on the one hand the one who knows maybe less, hardly dares to ask a question. Because if that's me - I cannot really follow what you are doing here, and so I can't really ask anything. On the other hand, if we stay now in this scenario - you would be very frustrated for me slowing you down. That's kind of the premise that we are on eye level here, so that we are really in the same space.
Len: I think I see what you're saying. That's a really good description of it, I think. It would be kind of like trying to write with someone. You'd better share the same vocabulary.
Len: If one person knows a lot of words that the other person doesn't know - do you spend all your time explaining yourself, and the other person spends all their time being humiliated?
In your work, when you get a contract or something like that, are you tasked with pairing people together?
Jutta: The way I'm working right now has changed a lot from what I was talking aboutso far. I'm not programming anymore. The thing is, well if this is what the team wants to do - I'm not somebody who pushes stuff on them, but I invite them to try it out, and then help them to get along. But if the team says, "Well we don't do that," then they don't do it.
Yet pairing in general, I think is just such a powerful concept for many things. As I said, like writing - but also speaking or running a workshop together or coaching or any kind of thing - the way I'm working now is really more - Well, sometimes on the team level, ensuring that the teams are pulling together. So it's most often that I'm not working with one team, but with many. Often they are also distributed, and it's kind of, "What can we do that we really build this one system, and not as many as we are people or sites or anything like that."
On the other hand, I'm helping companies to allow agility on the organizational level, because often now we see that, even if we stay on the subject of software - that the teams are not as successful as they can be, because the organizations are often too slow. That goes back to what Marc Andreessen said, what you quoted already - that some companies are struggling with what does digitalization really means, and how do we speed up?
Len: It's interesting, you draw a connection in your writing, I think - if I gather correctly, between incumbent, hierarchical forms of organization, and how this isn't really compatible with Agile both in the upper case "A" and the lower case "a" sense of the term. I was wondering if you could talk a little bit about that? What is it about programming now that's not really compatible with the conventional hierarchical organizational structures from companies?
Jutta: First of all, the book you are referring to, it's not so much about programming, because we think it's beyond IT. Yet still, things have also changed in programming, like when I started, we worked in teams, but not so much. It was really more an individual thing.
I would say most of the problems were much smaller, and it was way easier to decide upfront, "What is it we want to do, and what is it that the customer needs, and what the market needs?" Whereas now, things are just changing so fast. There are new markets just jumping up every day, and you have to deal with it. Maybe what you thought your product should do today, is tomorrow really something else.
The same is true then - not only with like Marc, but also with existing customers. They learn something else, and then they find, "Well, your product is really outdated here. It's not really doing this anymore." Which means we have to be very fast and flexible, and that's actually for me more the definition of "Agile" - really more in a literal sense - flexible, nimble, fast, responsive - and all of that - to deal with these changing needs, and with the complexity that's there - and still being able as a team to really deliver something, and deliver that fast again.
That requires, for example, fast decision making. Now, coming back to your question - what does it do with the company, or with an organization? Well, if a team is not empowered to make a decision, but it has to go up the hierarchy, up and then again down - then maybe you are really too slow for some of those decisions.
Len: That reminds me, when it comes to decision making - one thing you write about is consent decision making. I think I'm quoting from your colleague, John Buck. He said, "A consent decision is not one that you unite with or agree with, but one that you can accept or tolerate. You consent if you have no reasoned and paramount objection to a policy proposal."
I've got to say, this makes complete sense to me. I've always, when I've been working in teams, operated on this way. My personal experience with it, although I didn't have the term, "consent decision making," has been that there's a certain type of person that finds this intensely frustrating and difficult. Because when you say, "I disagree with you, but I'll do it," they often think that you're being passive aggressive, or that you're not really going to try, and you're actually going to undermine it.
Whereas to me, I completely understand. It's a team - I'm not going to get to decide everything. Often I'm going to be doing things in my job and in my life that aren't ideal or what I want ideally to happen, but we're making these compromises all the time.
But I think a lot of people really need - they really need people to agree. What's it like trying to convince someone of this idea, when their instincts tell them that when someone says they disagree, it means they're not going to cooperate?
Jutta: I think the way things are phrased are very important. It starts with that. If we make a decision based on consent, it's very clear that we are not looking for the best possible decision. We are looking for a decision that's also - quoting John Buck, "That's good enough for now, safe enough to try." That's a key thing. Because as soon as we start looking for the best possible decision, we probably will never get done deciding. Because we will only know if it's the best possible decision after the fact, in hindsight, right? Before, you really never know.
With this more open mind, it's much easier. Then the other thing is, we ask - well, most often we don't ask for, "Can you accept it also?" But we ask, "Do you have this paramount objection?" That means, "Do you think if we go that way, that our joint goal is put at risk?" Which emphasizes that, "Good enough for now, safe enough to try," right? Because if we would start saying, "Also, can you accept it?" Or, "Do you agree?" would be the more consensus question. Then well, there is always something else.
Almost everyone has something where I think, "Oh it could be better this way or that way." But that's not the question. The question is, "Is this something that would hinder us reaching our goal?" If it does, then we really want to hear about the way we should change our decision. Which also makes a huge difference to what I know from other ways of decision making, because if somebody has an objection, then this objection is really welcomed by everyone who is involved in that decision making process, because we all know it will be a better decision, and we have overlooked something. It's not that we try to pull that person over and try to convince that that person is wrong, and should better deal with the - whatever, majority or so. No, if the objection is there, it's an objection for us all, and we want to solve it. Because we want to reach that goal.
Len: It's really interesting, the use of the term "consent" in this as well. I mean, maybe I'm overly sensitive to the language? But I see a connection between that and the non-hierarchical form of organizing. Because consent is almost a kind of patronizing term in some ways. Like imagine - there's a certain type of boss, who, if an employee said, "I consent to your decision," they would be horribly offended. They would say, "You should submit to my decision, not consent to it." I just wanted to point out I really like that nuance in that way of talking about it.
One topic that's come up on this podcast, since I talk to so many people in the IT world is: Is domain-specific understanding something that's necessary when you're dealing with software? For example, some companies operate on a model where executives actually shouldn't have any domain specific expertise. They're supposed to be operating at a level where they understand how businesses work, but what's actually being done in the business isn't particularly important to them.
Many people I've spoken to think that this actually isn't compatible if your business has anything to do with software whatsoever, and it all does now. For example, if you really don't understand software at all, can you be in charge of a company where that's driven by software?
Jutta: I think this question is right on to what we are seeing right now. I was very impressed when - I think it was five years ago, a guy from BMW told me - one of the managers, I think not top, but still he said to me, "You know, we think of BMW as a software company now." Probably not everyone in BMW agreed at the time, and probably not everyone agrees right now, right?
Putting this a step further, I think it was like two years ago when I heard someone rom ING, an international bank - that person said that he is absolutely sure that the next CEO will be somebody from IT. Because of digitalization, because we think somebody has to understand what software is about if we really want to make that step into digitalization. I agree with that actually.
I think it's difficult if you don't understand anything about software. However, I also find it difficult if you have only people who come from that field. My main answer to the question is, you need diversity. Because otherwise, you are also blamed with only looking at the kind of software you have seen, or the product how it should be - and you are not really exploring new fields.
Len: It's interesting you bring up diversity. One thing that you write about is the question of whether a company should define jobs, or should they look for talented people? In the war for talent, if you can manage to grab a talented person - then you see what they can do. I was wondering if you could talk a little bit about that? Have you seen companies carry out that kind of tactic successfully?
Jutta: Yes, there are companies now exploring that more, in that they are not saying, "We have a job description, and we put those people then in this box." I'm pretty sure - we will see this more and more. Exactly what you said. It's because of the war for talent. Yet also, because people want to grow. If they are in a box, then they sit in that box and have no real possibility to grow - well, except for the given career path. That might speak to them or not.
But if you really look at whar are the interests and what's possible for the individual person, it's better for the whole company. Again, speaking of digitalization and the need for speed in innovation. I think over time, we will hardly see anything else.
Back to your question, I've seen companies doing that, but only a few right now. It's not a common thing, and it's not a common thing for like large companies right now. It's more companies that started succeeding, and they are growing. We're speaking of, for example, Spotify - companies like that.
Len: You've written about Spotify. Can you talk a little bit about how they work?
Jutta: That's really an interesting thing, because at least in the actual field, so many people refer to Spotify as, "That's the Spotify model, and we should use that," and a lot of companies do. Then they rename their units and all the structure they have in the company, and then they speak about squads and tribes and guilds and use all those terms that Spotify came up with.
Sometimes, they didn't really change much, other than using that new terminology. Which is maybe already a bit difficult. But the biggest problem is that they didn't understand what the Spotify "model," in quotes, really is. Because there is not really such a thing as a Spotify model. The thing is that they keep changing, and look at, "What do we need right now?" Then the whole company keeps really permanently changing itself.
Whatever people hear about - well yeah you have squads and tribes and blah - whatever. This is always a snapshot from a momentum. It's not something that's lasting long. Because the key thing is to stay with it, be in the flow and change with the needs. That's the Spotify model, if you will. But it's not a fixed model.
Len: On the subject of your latest book, the one you wrote with your colleague John Buck, you talk about the "BOSSA nova" model. I really like the way you talk about how you know this is a term that means, "new wave," and it's also a form of music, and it's also a form of dance. It's very intricate, the way you use this metaphor to fit different things together. But I wanted to kind of break it down a little bit. And so - the BOSSA part, the first part of the acronym is "Beyond Budgeting." What's that?
Jutta: Beyond Budgeting has been created by CFO's. It's not a consulting thing, but we see it in other worlds that new stuff is invented by consultants observing something. This is really from within corporations. They figured that the way budgeting is traditionally done is not helpful for organizations. Therefore, they are on the one hand suggesting a different way. On the other hand, they also have implemented different ways, and they saw that this is way more successful.
One of the examples is where they say, "Oh this isn't really working." So if you have that yearly budgeting approach, and somebody's applying for some money for - because, "Well, I want to do that project, and therefore I am applying for a bucket full of money. If I'm lucky, I'm getting it." Now, if the market is changing, for example, it changes in the way that I don't need that anymore, because that project is really useless now, then what's typically happening is that the money is not returned into the big pot. It's more like, "Okay, I will spend it anyway. Because if I return it, then next time I'm asking for money, I will not get that much." Everyone would say, "Oh this is Jutta, and we know she only needs a tenth of what she's asking for."
Also the other way around, if the market is changing and it's really very emergent, and I would need like double as much as I thought at the beginning of the budgeting process - well, I cannot do this, because all the money has been distributed and it's gone. I can't really act on the new market needs. Both ways are not good for the company in general. Because in both situations, you are losing money.
One of their answers is to be more flexible with the budgeting process, and not doing yearly budgeting. However, having said that - I think otherwise they would be really angry with me - I have to add that the term "Beyond Budgeting," is in that sense, maybe a little bit misleading because it's not about budgeting only. It is also a different management style, which is also like in Agile, more about empowering people. More about having autonomous self-organizing teams. It fits pretty well with Agile, but it focuses more on the management, leadership style, and not so much - well, Agile comes from software development and it's just really good in this area.
Len: Thanks for that description, that's really clear. You reminded me of an example of a friend of mine who was going through a hard time in his career a few years ago. He had a project manager diploma of some kind. He got a job with a big company that was very good at getting government contracts, and not so good at making software. Two different skill sets, they're not mutually exclusive - but they don't always go together.
He got the job, and it was a six month contract or something like that. He realized, when he got it, that he didn't have anything to do. The only reason his position existed, was because they'd won a budget that included a space for an employee at his pay grade. No one wanted to cut it, because then it meant you'd just get less money next round.
It's an example I find fascinating - where people think they're being kind of hard-ass. Like, "Here's your budget numbers Johnson, stick to them." But actually it ends up being this really weak and kind of sad, sort of born to fail way of going about things. Because it's actually driven by a kind of dollars and cents approach that's all cost based, and not profit-center based. You don't look at people as ways of getting stuff. You look at people as sinks for money.
Jutta: That's true, and you are also not looking at the overall success of the company. It doesn't matter anymore. It's more like, "Yeah, okay we have the money put in here, and therefore it will be spent here."
Len: I haven't worked in an environment like this, but it seems to go along with a culture where it's like, if you're a middle manager or a manager, an executive - and you say, "Well I've got 20 people underneath me, how many people do you have underneath you?" It's like, "But what are you achieving? What are you trying to actually do? Are you actually achieving those goals?" Again, it's funny that this discourse gets represented as kind of macho and tough - when really it's actually like profoundly pathetic.
Sorry to give my opinion in your interview, but -
Jutta: No, it makes completely senseh.
Now that you've actually brought up the goals thing, I really need to add that - which is another Beyond Budgeting thing - so, actually targets are more the thing, which I also find such a strong example. If people - well, units - whatever - but people are getting targets, then they aim for achieving them.
Let's imagone - I'm a salesperson, because sales is the best example for reaching their targets. Which is also true for other people, but just it speaks better.
My target is, I have to sell 100 of whatever we are selling. Then, imagine I really reach it, and I sold that 100. Then I get my bonus, that's cool - I'm really happy. But what happens if my competitor has sold 200 of the competitive product? Then those 100 are really meaningless. On the other hand, if the competitor has maybe sold only 20, then the 100 is a really a great number. One of the other key things around Beyond Budgeting is that, well, maybe fixed targets are not such a good idea, because they don't tell a lot. What we need is relative targets.
Len: That's really interesting. You've just reminded me of a kind of infamous example that's sort of an ongoing scandal in the United States right now, with the bank Wells Fargo.
Jutta: Oh right, yeah.
Len: I'm sure you've heard of this - where basically there was this top-down pressure-sales culture, that resulted in employees creating bank accounts for customers that the customers didn't know about, in order to reach targets. Of course - fortunately they ended up being fined, I think in the billions for it. There would have been people along the way making their quarterly numbers, and getting their bonuses, passing their performance reviews. But ultimately, the company was undermining itself in its pursuit of these overly straightforward targets, is one way of putting it.
Moving onto the next part of the acronym in BOSSA, and then nova - is Open Space. I confess this is something I have not heard about before. Can you explain what Open Space is? Jutta: First of all, it gives me a chance to correct your introduction. Because at the beginning you said the title of the book, and you refered to "Open Source," instead of, "Open Space."
Len: Oh did I say that? My apologies.
Len: Oh no.
Jutta: Which happens from time to time. But Open Space is actually a facilitation technique. This is where it's coming from. I'll go through that. The key idea is that, if you go to a conference, very often you find that after the conference you feel, "Oh, the best times I had were really in the breaks." Because I had the chance to connect to people, and we talked these topics through, and we really were diving into something and explored something and so on.
There's Harrison Owen, who is the originator of Open Space, and he just thought, "Okay, what makes that difference?" Then also organized conferences around that difference. The difference is - if you think about your great conversations during conferences, the first thing is, it just starts whenever people feel like we are starting, talking about that topic. It's not that somebody's waiting, "Oh it's not ten o'clock yet, and so we should wait another five minutes till we can start," right? It's just starting.
Then the next thing is, which is a bit related - well whoever's there, are the right people. We are not waiting till - I don't know? Len is coming along, because we think he should really be part of that discussion. We just get started, because it's a break "session," right? It's "session" in quotes here. Similarly, as how it starts, it also just ends whenever people feel like, "Oh we are done with that topic." Maybe we move onto the next topic over our coffee conversation?
Another really key thing is a law which is best known as the law of two feet. Now it's often called the law of responsibility and mobility. It means, as in a coffee break conversation, if I'm not interested in that anymore and nobody's interested in what I am saying, then probably I look for another coffee and move onto the next table and talk there.
It basically says - if I'm not learning anything else anymore, and I'm not contributing to other people's learning - then maybe it's time to move on? Which is actually a great concept also for every kind of meeting. I use this in companies as well.
Then there's [the idea that] wherever it happens is the right place. Also, the location doesn't really matter. Again, in a coffee conversation, we don't need a room. Maybe we do, and so we move on and go to a room. But maybe we are just wherever we are, right?
Then in general - whatever happens is the only thing that could. Which is also true. Maybe at first I go there, and we chat over coffee and we think, "Oh we really want to talk about microservices, digitalization, whatever." Then we get tracked away, and we talk about something else. Maybe that's the right thing to do? It was the correct thing.
Open Space is a facilitation technique. There are companies that run strategically like that. Oh right - I missed another key thing to it. If you ever run a conference that way, with Open Space - going back to the facilitation. What you are doing is, you provide a space, and everyone can suggest a topic. If there are people who are interested in that topic, they will meet and talk about it - and if nobody's interested, nobody will talk about it. But everyone is invited to suggest any kind of topic.
We know companies who are strategically run like that. Everyone can suggest a new feature for the product, or a new product. If there are enough people who also believe in that, then they will join that person and say, "Oh well let's put this on, it's like a cool idea." If nobody comes along, well then maybe it's not such a good idea, and we are not doing it.
Which has a very, on the one hand, innovative power. Because every person in the company can bring the creativity and innovation to the spot. On the other hand, it's also working with the passion of people. Things they really want to do, and what they really strongly believe in - and they've put this forward, and work on that.
Maybe now going back to Beyond Budgeting, where somebody said, "Oh we have that money to spend, and it's not necessary, but this is the bucket the money is in." Len: It's really interesting you brought up passion, and I believe also responsibility. I'm leading into my next question. But one of the themes in what you're talking about is that, in a sense, people should be granted a lot more autonomy in their workplace.
But this is, of course, contingent on trusting them to behave responsibly - and also to contribute responsibly as part of a group.
The next part of the acronym is I believe sociocracy, and I was wondering if you could talk a little about that - I've read a little bit about it, I'm sure people listening have heard the term before. But if you could talk a little bit about what sociocracy is, how it works?
Jutta: Sociocracy is from terminology a little bit related to democracy. Whereas democracy means - it's the "demos," so the mass of people; whereas "socius" means we are working with people we have a relation to. Sociocracy, if you will, which is not the correct really way of explaining it, but still - it is a kind of democracy for organizations. Because they are the people who have a relationship with each other.
It comes with also only a few principles. One of them we have talked already about, which is consent decision making, which is a very core thing to sociocracy - that you decide based on consent. Based on consent, the policy decisions you are making. Not anything that's operational. But all policy decisions, you make by consent.
Meaning, everyone has a voice, everyone can object. So everyone who is involved in a decision can object as soon as a person thinks our joint goal is at risk - what we talked about earlier. That's the one thing. It's different from a democratic decision, where the voice of the minority is ignored. Sometimes even of the majority, as I've learned in your last elections. It's different there, because you really hear all the voices, and everyone can object, right? That's the one thing, consent decision making.
Another really big thing is called "double linking." Double linking works, first of all, with a hierarchy. Think of whatever company, and there's a hierarchy in place: the problem with the hierarchy is that the people who have been appointed as managers for the next lower level, they're on the one hand, appointed top down only. On the other hand, also - because of that - typically they are mainly responsible for the top-down flow of information and decision making, and ensuring people are really aligned. It's always kind of his direction.
However, there is also that thing in-between, where we refer to middle-managers, or even more extreme - being in a sandwich position is the term that's often used for middle managers. The reason why the sandwich position is used as a term is because those people have to ensure both the top down and the bottom up things. They also represent the group they are responsible for higher up. But also have to ensure that whatever has been decided top down is really carried out for that unit.
Now sociocracy says that's actually a bad idea to put people in such a sandwich position. We have to separate this out. We have on the one hand the top-down link, which is just a regular hierarchy, so you can stop where you are with your company. So you have your managers in place, and everything is fine. But then you have on every level of the hierarchy - you have also an election going on, and people elect a representative for them.
That representative is then representing that team, group unit one level higher up - and has exactly the same say as the person that has been appointed top down, and same say - this goes now back again to decisions by consent. The representative can object to something in the same way as the manager that has been appointed.
Len: And is this a popular form of management in organization in German companies?
Jutta: No, it's not popular. It's a bit more popular maybe in the Netherlands. That's where it originated. It is something more people know about right now, because sociocracy is kind of at the core of holocracy, which people, at least in some fields, are talking about. Holocracy has put way more staff on it, so it's just - my opinion is, it's just too much and it's too prescriptive and too rigid. It's lost simplicity, with only those few principles. Because it's not having way more.
Sociocracy is kind of easier to apply. However, with holacracy, more people have heard about that linking and are also trying it. But I would say it's really mainly in the Netherlands. It's used a lot in non-profit areas. Non-profit organizations, they are more and more using it, also outside the Netherlands. And also, outside the Netherlands there are companies exploring it and experimenting with it.
In Germany maybe just - the one more thing what we have, is we have a typical thing for special arts companies - we have elected representatives, so the unions - quite simple, right?
Len: Is this related to works councils as well?
Jutta: Exactly, exactly. However there it means the whole staff is electing some representatives, and those are then sitting at the very top. Which is good, because they are the representatives. But the difference with the double link is that you have, on every level in the hierarchy, representatives which can then also influence all the decisions and ensure that the interests from the ones who are below are really taken care of. It's not like leaping over all those different steps in the hierarchy.
Len: My last question about the subject of your book, as opposed to the way it was made - which I'm going to ask you about shortly - is, what's the biggest challenge that you see companies facing in 2018?
Jutta: That's really, really hard. I'm not really sure about that. Actually I think I want to skip that question.
I don't have anything on my mind right now, other than digitalization.
Len: Fair enough. It's an overly broad question I think.
So, moving onto the last part of the interview, I wanted to ask you a little bit about your process of writing. I guess my first question is - you've been on Leanpub for quite some time, longer than most. What was it that drew you to us when you were thinking of writing and self-publishing?
Jutta: That's really an easy question, because it was Johanna Rothman who was with you even much longer than I am. When we wrote up our little book on Uncovering the Cost of Delay, he just went ahead and said, "Well, we'll do it in Leanpub," and so I learned about Leanpub from her.
Len: Did you publish the book in-progress, or did you publish it all in one go?
Jutta: We published it in progress. I think we had like three chapters or something when we started publishing it. We kept sending out updates and informed the readers whenever there was a major update. Which was really good and helpful.
Len: Was gathering feedback from readers something that you have engaged in in your books?
Jutta: We did that, however - to be very honest, it didn't really work out just with Leanpub. So, hoping for any kind of readers will provide feedback to us. What worked really well for us was that we specifically asked different kinds of people if they want to review our book and keep providing the feedback to us. In our case with the BOSSA nova, we really took care of that. We have people from all those different fields, so that we'd get feedback from the different perspectives. So Beyond Budgeting, Open Space and sociocracy.
Len: Oh, so you organized the kind of feedback process yourself formally with people?
Jutta: Right. Well, formally, I'm not sure. We said, "Can you find our book?" and gave them the link to Leanpub. Then we also said - well the formal thing maybe was, "And we really would need your feedback by then and then." Then we worked it in, and we had actually two big rounds of that feedback.
Len: You wrote the BOSSA nova book jointly with someone else.
Len: We referred to earlier. Can you talk a little bit about that? How did you organize that, how did that work out?
Jutta: So this was really an experiment, and a great experiment. I said before, I wrote that first Leanpub book with Johanna. But there it was more like just each one of us contributed like one chapter, and the other one, another chapter. With the BOSSA nova book, it was really that John Buck and I, that we pair wrote - meaning really every single sentence that's in the book has been written by us jointly. We did this on Google Drive, that's where we wrote it.
It was then on me kind of explaining to John the basic Markdown thing. But this worked really, really good for us. For every chapter, we had a Google doc, and we transferred that in Dropbox, and this is how we published. The thing really with-- Well everyone who did pair program probably isn't surprised about that, but the thing with pair writing it's just - it's so much better from quality-wise, because you have always a second pair of eyes looking at it right away.
In software, it's the same thing. You just have fewer bugs, and if you have a problem you can fix it easier. Because both people know about it, it's not only sitting in one person, what you've done. From this point of view, it was very helpful. Also while writing, we had a lot of discussions, because we had to find out how can we best explain it, or where are we heading with that book now? I think you mentioned that before.
John;s home is absolutely sociocracy. Whereas my home is more actual [? 59:21], which also meant we had to find a way to exchange and come up with a common base.
Len: I should mention that you very generously shared a pretty detailed description of the technical details of the process of how you did this using Google Docs and things like that, and I will definitely put a link to that in the transcription. We added it to our Help Center, and it was a really interesting story.
I guess my last question for you, is the selfish one I always ask people last in the interviews. Which is - if there was one thing we could build for you in Leanpub, or one thing that's broken that we could fix for you, is there anything you can think of that you would ask us to do?
Jutta: Okay, it's a spontaneous answer, and the thing that I remember most where I really struggled was the index. Because there is no way to make an index. I found a way to do that, but it really took some effort, and it also means whenever we have an update, it's just difficult. I understand that it's not necessary for an ebook. But whenever you do a print-ready PDF - which we did, so we have it also in print - you need that.
Len: Thanks for that feedback. I believe that there are plans to have a kind of robust way of making indexes when Markua is complete. This is the successor to Leanpub-Flavored Markdown, which was a way of taking Markdown, which was for making web pages, and then applying it to books. Markua's kind of starting on it's own, fully for books and courses and things like that. I believe there's going to be a way of making an index.
Thanks for that feedback. In particular, I appreciate the point you're making about how it may be that for ebooks, which can be searched, the canonical use of an index isn't really all that useful. But obviously, if you've got a print book it's definitely useful. Providing a feature set like that is actually really important for authors.
Thank you very much, Jutta, for this really great conversation. I really enjoyed it. We covered a fair amount of ground.
Jutta: Thank you. Was my pleasure.