An interview with Steve Tendon
  • June 12th, 2019

Steve Tendon, Author of Tame Your Work Flow

1 H 32 MIN
In this Episode

Steve Tendon is the author of the Leanpub book Tame Your Work Flow. In this interview, Leanpub co-founder Len Epp talks with Steve about his background, the TameFlow approach to organizational thinking, blockchain, his work helping to establish a digital innovation strategy for the government of Malta and how legislation can drive innovation, his books, and at the end, they talk a little bit about his experience as a self-published author.

This interview was recorded on May 28, 2019.

The full audio for the interview is here: You can subscribe to the Frontmatter podcast in iTunes here or add the podcast URL directly here:

This interview has been edited for conciseness and clarity.


Tame Your Work Flow by Steve Tendon

Len: Hi I'm Len Epp from Leanpub, and in this Leanpub Frontmatter Podcast, I'll be interviewing Steve Tendon.

Based in Malta, Steve is the founder of Chain Strategies and a senior executive management consultant, speaker and mentor who works with multinational knowledge organizations to create high-performance teams and business environments.

Steve's research and consulting work specializes in the use and adoption of new technologies, particularly blockchain. Amongst his other projects, Steve was part of the team that devised Malta's national blockchain strategy, which I'm looking forward to hearing about in this interview.

You can read his blog, the The TameFlow Chronologist, at, and learn more about his work generally at his website, and you can follow Steve on twitter @tendon.

Steve is the author of a number of books on Leanpub, including The Essence Of TameFlow: Breakthrough Organizational Performance Innovation and TameFlow Patterns: How to Design Organizations that Flow, and, unpublished so far on Leanpub, The Book of Blockchain Strategies.

In this interview we're going to talk about Steve's background and career, professional interests, his books. And at the end we'll talk about his experience using Leanpub to self-publish.

So, thank you Steve, for being on the Frontmatter Podcast.

Steve: Hey Len, it's a great pleasure to be here with Leanpub. Which, as you said, I have been using for publishing a number of books. The first one was in 2013, if I remember correctly? My first Tame the Flow book. I think I need to thank Leanpub for making it possible at all.

Len: Well, thank you very much for being such an early adopter.

I always like to start these interviews by asking people for their origin story. I was wondering if you could tell us a little bit about maybe where you grew up, and how you got interested in the first part of your career - which was in software engineering, I believe?

Steve: Yes, that is correct. In the prehistory of this field, the previous millennium, I was actually a software engineer.

Talking of my origins, I was born in Sweden, and even as a kid, I was traveling quite a bit with my parents. I went to school in South Africa and Italy. And then when I started working, I spent some time in California and Texas. Then, professionally, I've been doing consulting assignments all throughout Europe, from Belgium to Poland, Spain, UK, Netherlands, Germany, Switzerland - you name it. It's been quite a ride.

I started - quite remarkably, I would say - my software engineering career in the incredible Borland International, the makers of Turbo Pascal, already, at the time when you had DOS, not even Windows. That experience actually shaped my entire professional career.

Borland was one of the most productive software engineering organizations ever - and once I got out of Borland, I was always disappointed at how sluggish the other companies were. That got me into the mindset of figuring out what was it that made software engineering, and later, knowledge work, performing or not. I can go more into those details if you wish.

But to continue answering your question of my background and my career. In 2006, more or less - I switched over completely from software engineering to management consulting. I would believe many of my former software engineering colleagues would say it's a software engineer gone bad. But no, sometimes you have to take these pivots in your life - and that turned out to be quite an interesting evolution in my management consulting career.

I went on, studying why certain organizations are more performing than others. And as you mentioned in the start here, I also considered the impact of emerging technologies on how organizations can become better at what they are doing. Not only operationally, but also in terms of business models, and ways of generating value.

In that context I came across the blockchain. I was aware of Bitcoin since the very early start - 2010, more or less, but I was never really convinced. And with more insight - you might say, "Well too bad, because you missed maybe a huge opportunity" - but anyway, in 2015 I came across the white paper of Vitalik Buterin, and realized that this thing of decentralized computation would be extremely significant - basically for the whole global economy, and I started working in that area.

The year after, by happenstance, I spoke to the Minister of Economy of Malta at a conference, where he was the keynote speaker. As it happens, during the small talk before the actual start of the conference, I was introduced. I didn't quite know what to say because I didn't believe that my management consulting experience would be of any interest to him, so I just came up with this notion that, "You know what? The blockchain would be great for our country. It will define the economy for the next 20, 30 years."

And that's how my third career as a blockchain advisor actually started. I was called later and asked to draft the national blockchain strategy of Malta, and then was the strategy lead of the national task force.

The strategy was turned into laws. There are three laws in Malta that regulate this sector. There is a fourth law upcoming, which is extremely controversial. It is about giving legal personality to decentralized autonomous organizations. I believe that would require a book in its own right to describe.

After that experience, I also ended up, presently actually, advising the Republic of the Marshall Island on how to create a cryptocurrency with legal tender status.

Len: Thank you very much for that very compact summary of such a varied career. You've given us a platform for a lot of things to talk about for the rest of the interview.

I wanted to ask you - actually this this might sound a bit funny, but one thing that comes up commonly on this podcast is the question of, what was your first computer?

Steve: Well, computers may be a stretch, because I started with these so-called programmable calculators. My first programming experience was on a Texas Instruments SR-56. You might have to Google that and see what it was. It had 56 programming steps, that's why it was called "56." They couldn't do much, but you could do basic logic and looping. That's how I got into programming, the very first time. I was probably 11, 12 years old at the time.

Len: You're the first person for whom that was their first computer, that I've spoken to. Was it a school experience, or was it just something you were exploring personally?

Steve: Well, as it happens, my dad bought me that thing as a birthday present. Anyway, it's funny - because my very first experience taught me a harsh lesson. I was following diligently the instructions that were written in the book, and was typing in all these instructions - these steps as they are called, programming steps - and it didn't work. I got really frustrated to the point that I complained to my dad, "This thing you bought me doesn't work." He knew nothing about computers, and he took me to the shop to show the seller that the thing didn't work. I went through everything, and this guy was a bit perplexed. He looked through all the steps and showed me, "You know what? This step you did here, that is wrong." I had created my first bug. It was so embarrassing, because I took my dad to the shop. And of course, he got upset. But it was a good lesson, because from that point onwards I was very careful. Now, anytime something didn't work, I thought, "Maybe I have a bug, I have to be more careful."

Len: It's a really curious experience, for those listening who may have never done any programming - single character mistyped, and everything breaks. And to have that experience on a calculator, I can only imagine.

And so you ended up working, you mentioned for Borland. What was it about Borland that made it so extraordinarily productive?

Steve: Well, I have three chapters about this in the first book that I published with Leanpub [Tame The Flow], which now is like retired, because it was taken up by J. Ross Publishing, and made into a real code hardcover book.

The point of why Borland was so productive was studied quite deeply, even at that time. You might know about James or Jim Coplien, who is one of the current proponents of Scrum patterns. At the time he was working for AT&T, and he was studying all sorts of software organizations to uncover why some were sluggish and why some were much, much better than others.

He came across the case of Borland, which was extraordinary. He would examine the work that Borland did, it was a total outlier - far out to the right and high up on all the charts. Eventually Jim came up with a way to categorize what were the, let's say, features and attributes of these kind of companies - and there are many, many aspects that come in. But you might want to look for his book on, I think it was, Patterns Of Agile Software Organizations or something, that - I might give you the right, the correct reference later. [It's Organizational Patterns of Agile Software Development - eds.]

It was a groundbreaking book, because - not even the book; he actually presented a paper at a conference, which later became that book. That paper actually inspired Jeff Sutherland in the making of Scrum.

So the Borland experience is, in a way antecedent of Scrum, and some of the things that you see in Scrum, like the role of the product owner, or the daily stand-up ceremony - those come directly out of that Borland experience. Of course, Jeff Sutherland was also inspired by other sources from Lean and Japan. But the role of Jim Coplien's study was fundamental in establishing Scrum.

And what is happening nowadays in Scrum, where they are trying to define patterns of hyper-productivity, as they call them, is an direct outcome of Jim's work. He was studying Borland in terms of patterns.

I, myself have been using patterns ever since, and they are one of the key ingredients in my so-called Tame the Flow, or TameFlow approach, for short. It's fascinating, I think that that experience in Borland was inspiring Scrum. And even myself, I have the advantage that I was there - I was at Borland. So in many ways I criticized quite heavily certain ways that Scrum has evolved - simply because I was in the field, and I can recognize what was like misunderstood or misrepresented in taking the practices of Borland into Scrum.

Len: I've got a few questions to ask you about that, about your Tame the Flow or TameFlow approach, a little bit later. It's really great to hear about you being there at the sort of, origins of Scrum. Which, for those listening, is an approach to software development.

Steve probably doesn't know this, but a theme of this podcast is that software is eating the world, the world is built on software. A lot of people might not know this, but the way software is built actually determines a lot about the world that we live in now. And so these processes are very important for understanding the products that we interact with every day.

One of the questions I was really looking forward to asking you, was about the transition from stage one to stage two of your career, when you went from software engineering to management consulting. Was it the thoughts that you were having based on your experience at Borland, and seeing the theory around Scrum developed, that led you to make the move from being a software engineer, to being someone who was sort of sitting on top of software engineers?

Steve: It was a number of events that happened in in my in my career. It started with the fact that - well, I was working as a contractor software engineer for a company inSweden, which decided to grow quite substantially through merger and acquisitions. So I was involved in the pre-merger due diligence of the acquisition targets, and also in the post-merger - once you've broken the eggs, you have to make the omelet - and get the two or three organizations to work together. That's when I started to become aware of the fact that there were many ways to produce software.

At that point I was not only concerned about performance and productivity as such, but was looking more at the organization as a whole. How does it actually help or hinder the effective business outcome of software engineering or software development? And of course when you start looking at post-merger operations - when you have two completely different cultures, which might even be in conflict and in opposition - and you have to make them work together, the kinds of problems are very different. You're no longer looking at code as such, but at behaviors, and how people can come together and get along - notwithstanding that they might have extremely different opinions, backgrounds, experiences and so on.

That was like a stepping stone towards becoming a management consultant Then I must say I also had a little incident, I got some severe problems with my eyes, so I could no longer look at a screen for longer periods of time. And of course for a software engineer, tell them not to look at the screen - and you can imagine how disrupting that is. But, long story short, I had to change my career and stop looking at screens, and start looking at people's faces. And that's when I really switched into the management consulting, and that's where I started stepping away from all these Agile, XP, Scrum, Kanban - all these software-based approaches.

I started thinking more about organizational performance, and learnt a lot about Lean - and in particular about the theory of constraints, which I am a great fan of, and which I, in recent years, see is being picked up, for instance, very much, or indirectly - but it is being picked up very much by the DevOps community, in the DevOps movement. I'm very pleased about that, because it like brings together my perspective on how to run a business with these contemporary software engineering practices.

Len: Thank you very much for sharing all of those details. There's so much to your story that it's kind of hard to know what to dive into, or where to go next. Although I do have to indulge in probably a rather specific question.

I used to be an investment banker myself, and I worked in mergers and acquisitions. I was wondering what your experience was like working on the due diligence process? So for those listening, due diligence is when - basically, imagine you were buying a house, potentially worth billions of dollars, and covering many square kilometers. And before you bought it, you wanted to look into everything about it. Literally looking at the pipes, going inside the walls, looking into the insurance. What was the part of the due diligence experience for a merger that you were looking into?

Steve: Well, at that time I believe that there were not many folks doing software M&As, it was a nascent industry. M&As have been around for ages, but not specifically those that have software engineering organizations as targets. They started to become fashionable at that time; we are in the time frame of like between 2003 and 2007. At that time, the only thing I could think of as a tool, believe it or not, was the Capability Maturity Model - CMM - which in insight, I realize maybe is not that a great thing.

Then of course, one cannot escape from, what are the objectives of the acquisition? Many times it is a matter of growth, so expanding market share. Many companies, for instance, the former Computer Associates, which I think has changed name or - I don't know if it's gone away? But Computer Associates became a giant through that strategy. They bought companies and basically threw away the programmers, just kept the product and the market.

In other instances you might be interested in, it's some core technology - something that, it's cheaper to buy a company than to try to develop on your own. In other instances, you're really interested in the brains, in the people who are doing this stuff. Because you know they are the best or they understand the domain best, and you want to have their brain power. So you want the entire team to be on your side. So depending on what the objective is, you will look into different things.

If it's a market share thing, then it's primarily just marketing information. If it is a product that you're looking for, then you would probably do code inspections and try to figure out if there are any hidden traps in the actual software. If it is the engineering team, you will look into the processes, procedures, methods, practices, habits. All these things where we could say, "how we do things around here" - how people are working together. So there are many, many angles which you can take when we're talking about a software engineering M&A.

Len: That's really fascinating. I think a lot of people-- I mean even people who run companies or buy companies - might think that when you're buying a software engineering team, you're buying a bunch of typists. But in fact you're buying a bunch of brains and processes and mindsets and a culture. It's so interesting to me to hear you talk about how, when you're engaging in this process of evaluating an organization like that, to go all the way from the very top level - from how it's sort of run, to the actual code that's being written - must have been a really fascinating challenge.

And so, was it was it from this experience, that you developed the TameFlow approach to organizational knowledge work, performance in management?

Steve: In a way, yes. Or rather, I started helping companies to resolve their problems. And some were really, really nasty problems - because I spoke about mergers and acquisitions. But one case in particular, I want to mention - was the company, a group called 25:06 Wolters Kluwer, based off Amsterdam. It's was originally a publishing company, now it has become an information provider to all sorts of industries.

Well, at that time they had acquired like 32 different companies. They had over 20 business units. They were across 11 countries. And you had to get all of these different cultures to work together.

So I managed to do that, but as I went to other companies and they were asking me about, "What kind of method are you using? What kind of approach are using?" And I didn't have I could reply. I knew what I had to do - but I couldn't articulate or verbalize it, or describe it, or give it a label. So it was a bit embarrassing, because it was like, "Hey guys, just trust me. I know what I'm doing but I can't tell you what it is." So I set out to to give myself like a good answer to that. Because I had collected so much material in studying this this field, that I thought, "It's time to make some order."

So in. I think it was 2010, I actually took a year off and retired to a small island outside of Malta that's called Gozo - a tiny, tiny little island where you can literally live in peace and no one will disturb you. I started going through all my notes and trying to give some structure to all my thoughts. And that eventually resulted into the first book, which I published with Leanpub.

Later in 2014, I thought, "This this needs to be organized in a business sense." So I founded the first TameFlow company, TameFlow Consulting. And the name, Tame - the original title, "Tame the Flow," became TameFlow as a brand. That's how I brand my thinking and my methods right now, TameFlow.

Len: I was looking at your Twitter feed yesterday, just preparing for this interview - and I came across a quote where you said, "Like Phlygeas taming the flow of waves on the river Styx, #tameflow will tame the flow of energy through your organization." Was that story from Dante part of the inspiration for your. the name, "TameFlow?"

Steve: It really came about through synchronicity or happenstance. When I wrote the first book, I was searching for a good cover image. And I just came across this computer artist who had this amazing picture, which now you see on the cover of all my Leanpub published TameFlow books, which represented Phlygeas, and the River Styx. We see this man with an oar in his hand taming the flow of the river, with the waves washing away underneath him. I thought it was just so fitting that I just took that image. And then I asked him, "What is the story of this image?" And he told me, "It's Phlygeas. It is from the Inferno of Dante." So it was just so fitting, I had to take it.

Len: One of one of the things I found really interesting reading about - originally, Tame the Flow, and now, TameFlow, was the insight that you had, that - and I'm going to quote you back at yourself here = "Performance in the manufacturing world is easy to see and manage". This is something that's come up quite a few times on this podcast, with people that I've interviewed. The theory of constraints, I don't know if that's come up specifically - but a number of different approaches to organizational management have come up - so Deming, for example, things like that, or people like that. And in particular, the idea that a lot of organizational theories are based on things you can see, are not necessarily applicable to things you can't see - like knowledge work.

I was wondering if you could talk a little bit about that? I mean, I'm sure you have lots of thoughts on that topic, but how does your TameFlow approach deal with the fact that you sort of can't see the work that's being done in the same way in knowledge work, that you can in manufacturing?

Steve: Yes, that's a huge topic.

Let's first maybe define what is it that you cannot see. Because most often this contraposition between manufacturing world and knowledge work, is very, very limited. Because you would look at the widgets and gadgets that a factory produces, and that is visible. And many will say, "Well in software we will try to visualize that." Kanban is an excellent example. But even the Scrum task boards, where you use the famous yellow stickies, and they represent something which you can literally see and literally move around the board - so you visualize, you give a visual representation to what is not visible.

And most of the reasoning around knowledge work and visualization of work stops there. But I think that is just one dimension of things which are not visible or not even - things of which the people in the organizations are not even aware of.

TameFlow is the taming of four flows. The one we just said about making stuff visible, like on a Kanban board or a Scrum task board, is what I refer to as the operational flow. It's the work flow, how work flows through different parts of the organizations through different roles. There might be handovers, there might be stage gates, there might be integration points. Depending on how more or less agile you are, things will flow with greater or lesser speed.

But there are other flows which are just as important, and which are even more invisible. The second flow I typically deal with is the financial flow. So, how the stuff that you move around actually becomes money on the bottom line. This is very important, because all of the approaches that are being used in the software space are, in my opinion, extremely weak on the financial side.

There might be some attempts at using - for instance, Beyond Budgeting - which is an approach which I approve of. I even talk about it in my book. But it's still a long way to connect to the general acceptance of finance figures in actually driving your operations. Or vice versa, to have your operations actually reflected in financial numbers.

Now in the financial flow - I will employ the techniques that come from the theory of constraints, which are known as Throughput accounting, which is quite different from what normal accountants are accustomed to. To make that long story short, the way operations actually turn into financial results, or the way top level decisions are made based on financial numbers, which then become operations, is something that is invisible - and that must be handled.

The third flow is the flow of information. Here we can learn a lot from information design, but in particular how you deliberately create feedback loops. We all know that Scrum is a number of iterations and loops, but they have problems in their own rights. They might be too frequent or too infrequent, they don't give the right signal at the right time, they might not escalate high enough in the organization to get the right kind of action with the relevant information.

So, working on how information flows inside the organization - the building of the nervous system of the organization - is also something that is entirely invisible. And that has a huge impact on how the organization will perform.

The forth flow is what I call psychological flow. It's all based on the studies of - I don't remember how to pronounce the name, maybe you will check it up? I think it's Mihaly Csikszentmihalyi, something like that? The Hungarian psychologist who studied flow states, individual flow states on what makes an individual perform in the best of his or her capacities.

When we look at organizations, we are interested in team or organizational flow states. That might seem very far-fetched, given how sluggish many organizations are and how many - it's a "people problem," problems exist in organizations. But that kind of flow is entirely invisible, and if the organization becomes aware of how to trigger that kind of flow in individuals, in teams in units - and across the entire organization, it will literally flow away.

Just to give you a sense of what kind of performance we're talking, I want to refer back to Borland, because there is, none other than Jeff Sutherland, that recounts that when he was studying the papers from Jim Coplien, I have mentioned at the beginning - he realized that one Borland engineer was as productive - at that time they used the word "productivity," rather than performance - that was as productive as 50 Microsoft programmers. So that means that one person could perform as much, could deliver as much as 50 people in a competing organization. My focus on hyper-performance has all been in this direction. How can you replicate that kind of performance lever? So that with a small organization, you can really give a good fight, and punch way beyond your weight?

Len: That reminds me of something I read in one of your books, where you wrote, "What can replace procedures, processes and automated algorithms when the workers know more than the leader?" I'm not sure if it's exactly related to what you were saying. But the idea of someone who's so powerfully productive seems to me, that it must be related to some extent to the idea that - as a manager, you're dealing with people who are better than you at what they're doing - and know more than you do.

Steve: Yeah, that's also something extremely important, and it's related both to the flow of information and the psychological flow. There's a lot we can learn from military organizations, especially the elite special troops, where you have this notion of unity of effort, without unity of command. Or the notion of leader's intent. Like, "Hey guys, capture that hill. It's your problem, come back once you're done." So the leader might express an intention - and then the organization will have to figure out, or the unit will have to figure out, the best way to achieve that.

If you do this, then of course you can avoid a lot of meetings. You can avoid a lot of micromanagement, avoid a lot of reporting. But there is one necessary element that must come into the picture, and that is what I call the "unity of purpose," or actually two. The "pattern of unity of purpose," and the "pattern of community of trust." Unless there is a very clearly defined goal, and I say this word with a clear reference to the novel of Eliyahu Goldratt, The Goal, which defined the theory of constraints. Unless you have a very clearly defined goal, all of this will never happen.

It's like - I mean, you're in Canada. So there, you play hockey; they do so in Sweden as well. And we won't enter the debate on which team is better, because then we will never end this podcast. But in hockey, it's a team that have this idea, "We have to put the puck into the opponent's net." It's very clear what needs to be done. Anyone who has the puck knows what he has to do. And in a high-performing team, there is no time to think - if things just happen, they are in the state of flow.

How does this relate to the organization, and the fact that you mentioned - how do you replace procedures? At the first level, procedures are replaced by software. Software are just an embodiment of procedures. They are a way of quickly making decisions in an automatic manner. But when it comes to the more - let's say, high level cognitive processes that go into creating the knowledge - there is no way you can define that as a procedure. But if I am the CEO of a company and I have a team of engineers - where even the junior engineer knows much more than me - there is a no way I can micromanage that. Any such attempt would fail and would basically alienate the highly skilled engineers.

So what is the alternative? Well, it is to adopt what I call mental models, so that no matter what level of competencies or skills or your position in the company - whether it is a hierarchical position, or it is a power position acquired through seniority or through recognized skills and abilities - no matter what your position is, you can agree that if that decision you are about to take is consistent with a shared mental model, it will not go against a similar decision taken by anyone else.

So you're creating that trust across the organization - because all people involved will make decisions constantly at all levels at all times, which move the organization forward towards the goal. And that's when the top management, the CEO can trust the organization to move forward. The commander's intent is present.

Len: That's really interesting you say that. When I was reading your books, preparing for this interview, I was reminded of an old analogy I like to give about the role that Oxford and Cambridge played in the British Empire. Which was, more or less, to train young men so that they would all know exactly what each other would be doing under any circumstance. So, for example you knew that at, I don't know, 3 p.m. if you were on a boat in in the Indian Ocean, or if you were in a fort in North America - someone would be having tea. The idea of creating this kind of coherence in a culture means that people can be given a great deal of independence and latitude to act, as long as you can trust that they're going to be operating in accordance with the same model.

Steve: Yeah, that is correct. I mean that's exactly the point, the idea of having tea at 3 p.m. is, in a way, a mental model. We know that at that time point, we expect that something is happening. Which means that I don't have to make the call for that event - even if it's a trivial one like drinking tea, as you say. But it becomes ingrained in the organizational habits that develop from the sharing of a mental model.

Len: I know we could talk about this a lot longer, but there's another stage of your career that I'd like to move onto. We've gone from your calculator and programming, to this very high level management consulting. But ultimately you ended up working now on blockchain technology, at the national level of legislation - which is something I'm really interested in talking to you about.

But before we do that, I'm curious - you mentioned you're from Sweden, but you traveled a lot as a child with your parents. and then you've worked in many different places as an adult. How did you end up in Malta?

Steve: Simply because I had some clients that had business here, so I came down from Sweden. And I just realized that the weather, the sea, the food - was at another level, so I said, "Let's give it a try. Maybe stay here for six months and test the waters." Well, I've been here for over 13 years now, I'm still testing the waters.

Len: I watched an interview with you on YouTube, where there's just this wonderful background of sea and I think actually people walking around with drinks. It seemed like such a wonderful place.

On that note, just for a couple of minutes, this is a bit of a sideways question. But one of the pleasures of this podcast is that I get to talk to people from all around the world and ask them about things that they might be experiencing locally, that the rest of us just read about in the headlines.

On the subject of moving around and migration, Malta is in the middle of the Mediterranean and it's an EU country. I know from the news that Malta has its own experience of people trying to get there from North Africa. What's the experience of that like on the ground? I say this is someone - I mean, I've moved around a fair amount myself, but between me and the rest of the world here in Canada, are three oceans and the United States. What's it like to have this sort of imminent issue of people trying to get in?

Steve: Well, Malta has always been - because of its geographical position, it has always been a crossroads of different geopolitical interest. The whole history of Malta is a continuous change of population coming from different places. Starting from the Phoenicians to the Romans, the Greeks, the Turks, the Arabs, Napoleon, the British Empire - it's an ongoing story.

So Malta has always been very open and welcoming of foreigners. Now, of course, in the current historical situation, there is clearly pressure from countries in North Africa. Many people want to reach Europe. Malta has fared quite well - because most of these migrants actually want to arrive in [continental] Europe, not in Malta.

But having said that, the pressure is visible. At the same time, the economic success of Malta - even the financial services, the iGaming and lately of course, the blockchain sectors - have also significantly increased the inflow of experts from all sorts of origins.

In particular, in the case of iGaming, there are huge communities that have grown in the last few years. If we take for instance the Swedish community - when I moved down, we were probably two or three hundred people. And now I think the population is in the order of 8,000 units from Sweden or thereabouts, it's been a tremendous growth. Keep in mind that the population of Malta's like 450,000. It's very small, it's the most populated island or country in Europe, in terms of population density.

Connecting a few dots, what is interesting is that Malta also recently came up with a proposal on how to manage these migration flows, to use the word of TameFlow. With the blockchain, applying blockchain technologies to help with, for instance, digital identity management. To help with disbursement of social benefits, and so on. So the problems that are arising, are also being addressed by thinking in new ways of using technology to address them.

Len: And how did iGaming become such a prominent industry in Malta?

Steve: Malta had already the experience of financial services. But in the case of iGaming in particular, the effect is quite similar to what is happening nowadays with cryptocurrencies and the blockchain. The fact was then that iGaming was not regulated in other jurisdictions. Take Sweden, for instance, iGaming was - it was not illegal in a strict sense, but it can only be exercised by a state monopoly. So if any Swedish company wanted to provide iGaming services, they could not do it.

So Malta took the opportunity to regulate that sector, and of course ran into a lot of heat and controversy. But eventually it became accepted practice, and many other countries followed. Many other countries regulated iGaming, to the point that now even Sweden in 2019 is allowing companies to set up a iGaming operations. So Malta was leading this trend, and I would say through innovation - not in terms of technology, but innovation in terms of legislation. By giving legitimacy to a whole sector, they created an industry.

And now the other countries are following suit. Which, by the way, is creating a problem for Malta. Because now those companies that came down here from Sweden, for instance - might possibly move back to Sweden, so it would be a loss of business for Malta. That experience has also been one of the things that have inspired this initiative of regulating cryptocurrencies and blockchain technologies. As of today, I think Malta is one of the few countries where cryptocurrencies and blockchain technologies are fully regulated.

Len: Thank you very much for that great explanation and segue into the next part of the interview, where we're going to talk about your experience helping develop Malta's national digital innovation strategy.

As I understand it, you were at a conference, and you were introduced to a keynote speaker, who happened to be a sort of cabinet minister, I think Minister for the Economy. And in a very brief encounter, you convinced him or her that blockchain was very important. And it was from that momentary chance encounter that you ended up working on the National Blockchain Strategy for the country.

Steve: Yes, that is correct, it was very much by happenstance. I had an elevator pitch moment, and gave this vision for for a country built on blockchain. I was called to the office of the minister shortly thereafter, maybe just a couple of weeks after. I had to explain this in more detail. And at the end, I was asked, "Can you can you draft a national strategy for this?" I said, "Yes, of course - let's go."

Len: I think you describe in your book that there was a little bit of a moment before you said "yes."

Steve: Well yes, I was a bit nervous...

Len: It's a big thing to be asked all of a sudden by a cabinet minister, "Can you develop a national strategy for this emerging technology?" But you did, and it's a fascinating story.

I mean, I guess we're all assuming that anyone listening to this this podcast knows more or less what blockchain is, and understands that when we talk about distributed computing, we're talking about the Etherium blockchain. Actually, anyone interested in sort of a from-the-bottom-up explanation, I would refer you to an earlier podcast where I interviewed someone named Don Tapscott, who, along with his son, wrote a book on blockchain technology. He gives a pretty good explanation.

One thing that I think that often gets lost in the discussion, is people get preoccupied with the technology. But you brought up the importance of regulation. And so your task was to be part of a team to help Malta be ahead of everyone else on the regulation, with respect to not just cryptocurrency, but blockchain technology and distributed autonomous organizations and things like that. Can you talk a little bit about that?

Steve: Well yes, and as I mentioned at the beginning - I was looking at emerging technologies for the sake of allowing organizations to perform better, and the focus was on blockchain technologies - technologies, as such. Which of course include even cryptocurrencies. This was, keep in mind, in 2016.

Len: Ancient history.

Steve: Ancient history, especially in blockchain years or crypto years. 2016 was before the amazing Bitcoin boom and the ICO explosion of 2017.

So, we had already done all the groundwork, and we were still setting things up, when these two phenomenon happened. Other jurisdictions reacted in, I would say, in panic mode - and some were extremely quick to come out with rules and regulations, but limited to cryptocurrencies and ICOs as a regulation of financial instruments. That knee-jerking reaction made them come out with regulation before Malta.

So we were exposed to this criticism, "Oh, you're talking about a lot of regulation - but you're way behind all others, because you're not presenting anything." The reason was that our strategy was much, much deeper and much more far-fetching - once the whole thing became evident to me, we had not one law, but three laws - only one of which was the equivalent of what the other countries had had done up to that time, dealing with cryptocurrencies and ICOs.

The other two laws were building up the regulatory framework to deal with blockchain technologies, or more generically, to what we termed innovative technology arrangements. Because the whole idea was to have a focus on innovation, notwithstanding what kind of technology that innovation took form with. So it could be a blockchain, it could be a DLT, it could be IOT, it could be AI - and who knows what other acronyms will come out in the future?

DLT is the distributed ledger technology. It's like blockchain for corporations, private blockchains basically.

Len: Just to give people a bit of a sense - as you started expanding to AI and the Internet of Things - so people understand that the really fundamental legal challenges that Steve is talking about. Imagine a company that is basically a program running itself, undertaking transactions. For example, you can imagine someone creating a decentralized autonomous organization that is running a fleet of self-driving vehicles, and its vehicles plug into an electricity network and need to pay for some electricity. What legal status do you give to the organization running that, if it's some software? Or, how do you manage the transactions that it's undertaking? And very, very fundamentally - what happens if it goes under, who's responsible? Can you attribute responsibility to an organization that has no owners?

Steve: Yes, these are exactly the kind of questions that we've been addressing here in Malta. In particular, this notion of having a technology which is autonomous - but even worse, it's even self-sufficient. This is the object of a fourth law, which is currently being discussed. This fourth law aims at recognizing legal personality to these autonomous entities or autonomous, innovative technology arrangements - if you want to use the whole wording.

But the point is exactly what you said. The software is becoming so pervasive and capable, that it can effectively replace an entire organization. And as a matter of fact, the very Bitcoin protocol and algorithm and network is the first real instance of this. Because we know that the Bitcoin protocol, this intermediates the clearing and settlement houses - and anyone else who was in the middle of transactions happening between two individuals or two endpoints. So effectively, this protocol has replaced a number of companies and organizations.

It's even more perverse, because the Bitcoin protocol, as you might know, is being upheld by a network of computers owned by people who install the Bitcoin software and run it, and that ensures that the Bitcoin network is always functioning. And why do they do that? Because they get rewarded. They are the so called miners - that create the bitcoins and get a cut, so to say of that creative effort. So not only do we have a piece of software that has replaced human organization, but it is actually employing humans. It's like backwards. It's not humans owning software, it's software who is having humans on its payroll.

Now, I say that the Bitcoin protocol is very simple, notwithstanding the - let's say, the complexity of the cryptographic algorithms which underlie it, but the - functionally, the Bitcoin protocol is very simple. It moves a number from one wallet to another, like assigning a number from one variable to another. Conceptually, it's not a big deal. But even so, we see this fact - that it is replacing a number of human organizations, and it is employing humans as workers.

Now imagine that, instead of just moving a number from one wallet to another, this sort of software does operations which are much more sophisticated. You gave the example of a software that has a fleet of self-driving cars, and needs to buy electricity and has to pay for the service. Well, at that level of complexity, we, being software engineers, now we can go back to my very first experience when I got that SR 56 and created a bug. We know that bugs will happen. And then the question is if these bugs affect us humans, who is responsible?

Now, in the United States, there is this notion which is heavily promoted by some lawyers and even some regulators, that the software engineers should be held liable - they are performing a fiduciary function towards, say, the consumers. But what they don't consider is that one of the key attributes of a blockchain is that it's like an elephant, it remembers everything forever. So a software that is put on a blockchain will be there forever. And we have this wonderful opportunity of creating the eternal bug - that once created, will never go away. And what's worse is that this software will persist and live beyond the lifetime of its original creators. So even if you want to go after the software engineer that created the bug - and according to the lawyers, acted irresponsibly - he might just not be there. But the software is still there, it's still providing its services. It's still paying it's employees. And it will get paid by people or other pieces of software that benefit from its services. So what do we do, if this new entity is somehow harmful? That is the key question we are trying to address.

Len: There's so many dimensions to this. Thank you for that great explanation. You're reminding me of something. I had an old colleague who worked for the Bank of England. And when I was in my investment banking days, he said, "The one thing you guys don't have to handle is what happens if you fail." And this is why the regulators are important - one of the reasons they're so important, and one of the reasons that actually, although regulation often seems sort of dusty, it's actually incredibly challenging and creative work.

Because, if you're going to be a good regulator, you need to be ahead. And you don't just need to be ahead of managing risks, but you need to be ahead managing opportunities. How do you create, for example, a place where someone can conduct a utility token type of ICO and feel comfortable that they're not going to have, basically, the cops knocking down their door the next day? Is actually a really important problem.

There's so many things we could talk about. But I wanted to take the opportunity to bring it down to a very human level. You talked a little bit about - you mentioned digital identity management earlier?

Steve: Yes.

Len: In the same interview I mentioned earlier, that I watched on YouTube while preparing for this interview, you talked about how one of the experiences that people who are migrants from catastrophes can have - for example, from Syria. Let's say you're a doctor in Syria, war breaks out and you flee. And you end up in a new country, and you say to the officials that you encounter, "I'm a doctor." And they go, "How do we know?"

This was in the context of talking about how blockchain technology can be used to give people credentials that can be confirmed publicly without question. This is something that's talked about with respect to property ownership, for example. I believe in Malta there's an initiative with respect to students' accomplishments - like their diplomas or degrees being publicly recorded in this way.

Steve: Right.

Len: When I heard you talking about this, it actually reminded me of a very romantic story from my own family's past, where a bunch of my relatives were - during the Second World War, they were German-speaking Mennonites in Ukraine, and they ended up being displaced and under the control of the German military, in Germany somewhere. At one point there was a lot of bombing going on in the area where they were, and a great aunt of mine managed to get out of the area where they were being held, and melted into the crowd. And because she could speak German, she went the next day to the bombed out records office and said, "Hey I'm from here - but my records have been destroyed in your records office, I need a new birth certificate."

And because she was a fluent German speaker, she got away with it. Then she got her new birth certificate, and then because she had that, she convinced a bunch of German officials that the people they thought were Ukrainian captives were actually German citizens. It was on this foundation that they all eventually managed to get out of Germany and move to Canada.

And so it just made me think about how there's sort of two sides to this coin, of having your identity out there in public. Something that that can't be changed, because it's confirmed by this blockchain technology.

Steve: Right, I mean you raise - well, it's an amazing story you are telling there. But we should also then take into consideration that if this technology is going to, let's say, have mass adoption with the appropriate provisions for privacy protection, then the negative scenario that you are hinting at, it could be prevented.

Because we have this notion, which maybe you have not heard of - but it's the notion of self-sovereign identity. Or more generically, self-sovereign data. Yes, you can have your data on the blockchain, it is there and present forever, whether it is the real data or a hashed pointer to some other storage.

There are many architectural questions that software engineers and software architects would love to delve into. Conceptually your data is on a blockchain, but you literally you have the keys to accessing it, to make that data available to other a third parties. Now, there are many complicated schemes that can be built on top of this, so you might have, let's say, different identities or different personalities, depending on what context you need to use that information. And you can also have information that becomes more valuable, the more it is used.

For instance, with self-sovereign identity, institutions could attest that that information is correct. And you would be collecting these at stages, like pearls on a string. And the more at stages you have, the more credible your identity becomes.

But it's still yours. You are in control of who may access that information. And this might also be the disrupting element that might put out of business this whole recent success of civilians, of a civilians economy - with the Facebook's and Google's and all the big IT companies, cloud-based companies - who are tracking every single little movement you are doing in your life.

So as with all technologies, there are pros and cons, there are new opportunities that come about. And at the end of the day, it's up to us to invent the best use we can make out of this opportunity.

Len: There's multiplying podcasts of topics that we could talk about, obviously. But just before we move on to the last part of this interview, where we -

Steve: We have to make a series.

Len: Yeah, exactly - where we talk about your writing. So, you mentioned sovereign, with respect to personal data ownership - but you're actually working on something called SOV - which stands for "sovereign", which is a new digital legal tender for the Marshall Islands. I was wondering if you could talk a little bit about that?

And by the way, I just wanted to mention I was quite struck by how you live on an island in the middle of the Mediterranean and now you're working on a sovereign legal tender for an island in the middle of the Pacific, but I don't know why that struck me so much. But what is the SOV Project, and how did you get involved with that?

Steve: The SOV project is very ambitious. While we have already witnessed some countries trying to make their own cryptocurrencies, they did so on very shaky grounds and with very doubtful objectives and some outright failures - without mentioning anyone in particular.

Len: Well I'd mention Venezuela), but there you go.

Steve: The big problem here is that cryptocurrencies - it's good that you mentioned islands because I have this notion of the crypto or blockchain island.

Len: Right.

Steve: I actually run a community, which is called, an online community where I bring together people who are interested in the business of blockchain. And why is this word so important, "Island?" Because the crypto space, the blockchain space - the crypto sphere, as I also like to call it - is an island. It's existing in its own dimension, it's not physical.

We go back to the TameFlow notion of working within the domain of the invisible. The crypto sphere is invisible, but we human beings are material - and we have our feet on the ground. So we need to build bridges between the new emerging economy in the crypto sphere, and the real world.

Now, the original proponents of the Bitcoin, the cypherpunk crypto anarchist libertarians, might have a vision that in practice is very, very difficult to realize. Why? Because at the end of the day, we live in jurisdictions with laws and we need public services in order to be able to like live a decent life in a lawful manner.

So what is the problem? These crypto currencies are cross-jurisdictional and they are not subject to any sort of regulation. And it is true that the cryptocurrencies are such - in particular, those that are aiming for complete anonymity like Monero and VCash - they cannot be regulated in any way. And it's very clear in the eyes of the regulator that those cryptocurrencies will never be regulated, but they will also never become mainstream. They will not be the bridges between the crypto sphere and the real world.

And why are these bridges so important? That is a key question. Because - well, you mentioned it before, Len. Because once we start having Internet of Things where you have microtransactions between autonomous self-driving physical entities, which might be roaming across organizational or jurisdictional boundaries - well, we need something that looks very much like a blockchain to handle that kind of transaction.

Identity, we mentioned it, digital identity. We must start thinking in terms of identity of things, and how do these things transact - especially if it's microtransactions, where the cost of transaction is so low that it would be a non-profitable proposition on the current payment networks. We would prevent the economy of things to develop.

So in this light, we need something that is like a cryptocurrency but which is bridging that gap. That may exist in a regulated manner.

The SOV project goes in that direction. There are huge motivations for the Republic of the Marshall Islands to embrace this this technology, and long story short - it's because the Marshall Islands have also been exposed to the repeated nuclear experiments and bombing in the Bikini Island, at the atoll of the Bikini Island.

The US has been paying like sort of damages for that for the last 50 years. And in 2023, if I remember correctly, those payments will end. And they are the equivalent of 30% of the GDP. So imagine a nation that knows that in a few years 30% of GDP will disappear, it's a disaster that is coming.

Len: Wow.

Steve: Not only that, but the Marshall Islands are - you might try to look at some pictures on Google Maps. They are literally small pebbles in the ocean. Very, very tiny pieces of land, typically in the rim forms of an atoll. And the elevation is almost insignificant. So what is the problem? It is climate change and rising of sea levels. The country could literally be wiped out in a few years, depending on how fast the seas will rise. So they are facing an economic crisis, and they are at the risk of being wiped out by climate change.

The idea is to create a currency and also possibly - and I put this in parentheses, because it would be the second phase - but possibly a whole infrastructure of blockchain-based public services, like the pensions, the registry of people, insurance - you name it, would exist in the crypto space, rather than in a database that happens to be on a server on one of these islands, that might be wiped out.

That is the motivation for the SOV, from the perspective of the Marshall Islands. But since it will have legal tender status, and the Marshall Islands have a seat at the United Nations, this means that this new cryptocurrency will also, necessarily, have to be exchanged on the Forex exchange markets.

So it will be an ideal on/off boarding of fiat currencies to cryptocurrencies. And that's where we go full circle - and we see that we might have a cryptocurrency that is used globally, that can address the issue of microtransactions that happen between autonomous vehicles who may be owned by a DAO who becomes a legal subject in Malta through legal personality, where the transactions have fees so low that they are not profitable for the normal payment networks.

And at the same time, we are building the on/off boarding towards the fiat currency world. So it's an extremely ambitious project. Don't ask me if we will manage to pull it off, I don't have a crystal ball - but it's one of the most exciting things I've been involved with.

Len: It sound absolutely fascinating, thank you very much for sharing that. Such an interesting story and, I mean I'm sure we're all going to be following it very closely. Because it's the intersection of so many things - from a form of colonialization, where one is nuclear testing on someone else's land - to climate change, to the development of brand new currencies, that can be sort of automatically managed, things like pensions. It's just such an incredible confluence of so many different things.

It would it would normally be hard for me to know where to go next, except we're reaching feature length in this interview. So I need to move on to the final stage, where I ask you about writing.

So to go from sort of 30,000 feet to three feet and a keyboard, you decided to use Leanpub to publish books about Tame the Flow or TameFlow. What led you to choose Leanpub as a platform for your self-publishing projects?

Steve: Well, it was in the very early days. By the way, when was Leanpub actually founded? I don't remember.

Len: 2010.

Steve: 2010, right. And I think you came out of the world of Ruby, right? Ruby on Rails, maybe?

Len: Yeah, one of Leanpub's co-founders, Peter Armstrong had written a programming book on Ruby on Rails. He'd written a couple of books, and his co-founder Scott had written a computer programming book as well. But basically it was their experience writing computer programming books that could quickly become obsolete, that partially led them to the idea of Leanpub.

Steve: So I was keeping a keen eye on Ruby on Rails. I had many projects that were being developed on Ruby on Rails, client projects. I remember I was off the software engineering career at that point. But that's how I discovered about Leanpub, and it made sense in so many ways, that when I had jotted down my notes about what TameFlow was about, and I was thinking about writing a book - I didn't even look for other options. It was just a natural choice that Leanpub would make it feasible for me to self-publish without having to go through the - well, extra effort of dealing with a "real" publisher. I have published books in in the past on C++ and Delphian and other topics, so I know what it means to work with a publisher.

And then of course, I had the experience that the first book I did with Leanpub then also became of interest for a publisher who approached me and wanted to do it. And I thought, "Okay, maybe to get some bookshelf exposure, it might be might be worthwhile." But thereafter I've stuck to Leanpub, and all the things I'm working with are with Leanpub right now.

I am doing two books - one is, The Book of Blockchain Strategies, where I collect my ideas on strategic topics around the blockchain for businesses big and small. And the other one is the next one in the TameFlow series, which is, Tame Your Workflow, where I delve a lot into how the theory of constraints can be applied basically to the Kanban method.

It's interesting how I have also evolved my toolset, because of the increased need to collaborate with other people. Initially, my first books, I wrote them, believe it or not, in Vim directly, old programmer stuff. And the first edition was done by dropping the files on Dropbox and keeping my own versions with GitHub.

Now these latest two books, because I have other authors who are not so keen on programming tools - we've been testing the Google Docs version that you're supporting. I think you know, I've been a good Beta tester, right?

Len: Yes - so that leads me to my second last question. We save these very in-the-weeds questions for the very end of the interview.

You are an early adopter of our latest writing and publishing workflow, which is using Google Docs - which we're very excited about. We were very glad to have someone as technically proficient and patient as you to be there at the beginning. Which is not to say that it doesn't work, it works like a charm under most circumstances. But it still has the odd issue, which we're ironing out.

So I wanted to ask you, why did you choose to use the Google Docs approach - and it sounds like collaboration was the reason?

Steve: Yes exactly. Because with Google Docs, I could have co-authors and editors writing or making suggestions, comments and corrections - with a tool which is of course, very well-known, and which is not as intimidating as a plain text editor and Markdown.

Len: Yeah.

Steve: Which from a programmer’s perspective, is quite natural and easy. But for someone who has absolutely no programming experience whatsoever, but maybe just - someone authoring an English-language review of the book, obviously that would be an unnecessary torture to put them through.

Len: Yeah, that's actually one of the reasons we're so excited about having the ability to make books using Google Docs through Leanpub. We know that our origins are in computer programmers writing computer programming books. But for a lot of people, when they hear a word like "Vim," or they hear a word like, "Markdown," they're like, "What the hell do I have to get a degree in to type out some words and make a book?"

Steve: Personally, when I'm writing, I'm much more productive using Vim, and there's a fact. It's that finger memory that's just so sticky and so productive, that comes to fruition. But of course, if you have to write with someone else across the globe - by the way, my co-author Daniel Doiron of the last TameFlow book, he's in Canada as well - so, we are literally across the Atlantic pond. When you have to collaborate with some someone which has no previous experience - or doesn't want to learn, or cannot learn these tools - then something like Google Docs makes perfect sense. And I can just encourage you to pursue that, and to make it as good as possible. Because I think that will also broaden the potential adoption to non-technical writers, and make your business thrive even more.

Len: That's definitely our goal.

So my last question - and I always like the close out the podcast with this question - is, if there was one thing we could build for you on Leanpub, or one thing we could fix for you, can you think of anything that you would ask us to do?

Steve: Well there would be many things on this wish list. But one area which is particularly painful - no matter if it's in the Markdown or the Google Doc, I think, is the support for tables. Tables with the right options for formatting them in all possible ways. That single feature alone, I think, would be very, very valuable. Of course, given that you write books with tables, then it's valuable. Some books are just text, and then it's not a problem.

Len: Thank you very much for registering that interest in tables. We do have support for tables in Leanpub-Flavoured Markdown, and we're completing the implementation of the Markua specification, which is our new approach to writing books in plain text - where, for anyone listening - if you're writing in plain text and you want the output of what you're typing to have formatting, you have to type in the instructions for what you want the formatting to be.

In the olden days, what you would do is you would underline text on a typewriter to indicate to the publisher that you wanted it to be in italics. Now, imagine the same challenge, but you want what you're typing to come out as a table - that's what Steve is talking about.

We do plan on having pretty robust support for that in Markua. We currently do have relatively robust support for that in Leanpub-Flavored Markdown.

With respect to Google Docs, I'm sure you can imagine the challenge of taking whatever Google decides it wants it's binary code to be, to represent tables in Google Docs, and having us translate that into a table - is its own particular challenge. But we do understand that for people who need books with tables, tables are very important. It's something that we'll definitely think about supporting going forward.

Steve: In a Google Doc, you also have the option to escape back to Markdown, Markua - whatsoever. So if you have that capability in your engine, but you can't get it out of the Google Docs - you could literally write it. Some form of escape or parenthesized form, indirectly.

Len: That's really interesting. I know there's some tricky things there - but that's a very good idea, and something that we could think about. Basically there are different document formats that can be used in Google Drive. And so it's possible that there's something interesting that we could do with that going forward. Thank you for ending the interview with a challenge. We appreciate challenges.

And thank you very much for doing this interview, and for being so game for such a wide-ranging discussion, I really appreciated it, even if it wasn't necessarily all that coherent, I think everything we talked about was in itself quite interesting.

So, thank you very much Steve for being on the Frontmatter podcast, and for being a Leanpub author.

Steve: Thank you, and thank you to all of the Leanpub team. I think what you're doing is an exceptional product and service.

Len: Thank you.

And thanks as always to all of you for listening to this episode of the Frontmatter podcast. If you like what you heard, please rate and review and like it wherever you found it - especially in iTunes, it really does help. And if you're interested in becoming a Leanpub author yourself, please visit our website at Thanks.

Podcast info & credits
  • Published on June 12th, 2019
  • Interview by Len Epp on May 28th, 2019
  • Transcribed by Alys McDonough