Charles Betz is the author of the Leanpub book Managing Digital: Concepts and Practices. In this interview, Leanpub co-founder Len Epp talks with Charlie about his career, his book, and at the end as usual we talk a little bit about his experience self-publishing as an author on Leanpub.

This interview was recorded on February 16, 2017.

The full audio for the interview is here. You can subscribe to this podcast in iTunes or add the following podcast URL directly: http://leanpub.com/podcast.xml.

This interview has been edited for conciseness and clarity.

Charles Betz

Len: Hi I'm Len Epp from Leanpub, and in this Leanpub Podcast I'll be interviewing Charlie Betz. Charlie is a digital and IT management specialist, with a focus on big scale IT operating models. He worked at Wells Fargo as VP and Enterprise Architect for IT Portfolio Management and Systems Management for six years, and he has also worked for a number of other big Fortune 100 companies, including Best Buy, AT&T and Accenture.

He is a seasoned presenter and conference keynote speaker at events focusing on IT, service management, architecture and agile methods. He's based in Minneapolis, and is a lecturer at the University of St Thomas Minnesota, where he is part of the largest software engineering program in the country.

Charlie is the author of the Leanpub book which is currently called, Digital Delivery or Managing Digital: Concepts and Practices - I believe the title is still up for revision. His book is about teaching readers what a digital professional is, and what modern IT practitioners need to know.

You can follow Charlie on Twitter @CharlesTBetz, and read his blog at lean4it.com.

In this interview, we're going to talk about Charlie's professional interests, his books, and at the end, we'll talk about his experience using Leanpub.

So thank you Charlie for being on the Leanpub podcast, and for listening to that long intro.

Charlie: Certainly. It's great to meet you Len, and I really appreciate all the support Leanpub has given me.

Len: Thanks very much, it's our pleasure. We learn a lot from interacting with authors.

I usually like to start these interviews by asking people for their origin story, and I was wondering if you could tell me a little bit about how you started your career, and how you first became interested in IT Systems Management?

Charlie: Wow. Well it goes back some years now. I think one of the key moments was being at Best Buy, and running something that we were calling a "metadata repository," and having somebody come up to me and ask, "How does this relate to the ITIL concept of a CMDB)?" And at this point, I maybe have lost half the listeners right there, because these are fairly obscure topics.

But as we scale information technology organizations up, we find that they themselves need their own management. They need their own automation. You have to actually treat the business of IT with the same level of discipline that you treat your supply chain.

And when you have an IT budget in the range of say five billion dollars - billion with a "b," US - which was the budget at Wells Fargo - being spent just on IT, you find that you have actually quite a large supply chain and operations and execution management problem. And you actually need a lot of attention to your systems and your data.

So that's kind of the origin story. Now if I can continue just another half a minute here. In more recent years, I've become very interested in questions of workforce. How do we train the next generation? And so I'll give you origin story number two.

About a year and a half ago Target Corporation let go several hundred project managers. Some of these project managers wound up in my class at the University of St Thomas, where they were somewhat shell shocked. And the statement was made to me, "They let hundreds of us go from the PMO and other related organizations." And there were all these DevOps positions open.

I began to realize that the agile and devops movements had achieved a certain level of influence and importance, that really required a more coherent societal response, if you will, including addressing the fact that we've got an educational system that still isn't ready.

...my concern for how large digital organizations are run, and my concern for the impact that digital, agile and devops are having on society, the economy and the workforce - those are really the two fundamental bases of my book.

And so, in the intersection of those two stories - my concern for how large digital organizations are run, and my concern for the impact that digital, agile and devops are having on society, the economy and the workforce - those are really the two fundamental bases of my book.

Len: And going back a little further than this current book, your first book, Architecture and Patterns for IT Service Management, it has this fascinating subtitle, "Making Shoes for the Cobbler's Children." When I first read that, in my mind I interpreted it to be describing the challenge of providing something to someone who's used to having the very best of it. But I then read more about your book, and it turns out it was quite the opposite. I was wondering if you could talk a little bit about what,"Making Shoes for the Cobbler's Children" means and why that problem is so important.

Charlie: It's an old saying, and maybe a little bit obscure in this day and age. But the saying is, "The Cobblers' children are always the last to get shoes."

Len: Okay.

Charlie: You understand, right?

Len: Yes.

Charlie: And so in information technology organizations, especially in the 90s and early 2000s, we saw this problem. We saw massive - again, I'll use the term "supply chains," IT delivery chains, supply chains, pipelines - and they were being managed with spreadsheets and emails. Hundreds of millions of dollars' worth of business - IT organizations, that if you spun them out, would land in the Fortune 500 themselves. And they're running their business with spreadsheets and emails and intuition and back of a seat calculations, and a lot of emotion and politics, and "who screams loudest?"

This has really been an important theme for me, as I continue on with this work: How do we actually approach information technology management from a more rational perspective? That's a big part of what I'm continuing to attempt to do here.

Len: In one place you wrote about running IT like a business, and I was wondering if you could talk a little bit about that idea, which I guess we're touching on already?

Charlie: Well, the first thing, I just will note that unlike some authors, I don't get attached to various ideas I may throw out. I mean, I can talk about running IT like a business, which is a thought experiment that's actually been around since the 1970's, the idea that a digital organization or an information technology organization actually has all of the aspects of a business in the small. It's like a microcosm - if I can use that word?

And this observation was first made by, I believe, Robert Nolan, 40-some years ago, and it's been made ever since. How do we understand the information technology organization while it needs to be run more in a businesslike way?

But that starts to run into some limitations. Because you're assuming, well, maybe it wasn't run in a businesslike way? How was it even possible that it wasn't being run in a businesslike way?

And I think that the implication is that the IT organizations may have been a little bit too much technologically driven. They may have gotten a little obsessed with particular platforms. They don't necessarily have that very clear line of sight from what they're trying to do with the IT, and what the business is trying to achieve in terms of its market positioning and strategy. And I think that's where the idea that we need to run IT like a business comes out.

It's actually a phrase that I'm not hearing as much anymore. I'm not using it as much myself. But it certainly has a lot of resonance, and we certainly still see instances where, certainly when you see an IT person, or a software developer, say - I'll pick on the developers. And they just want to do something because it's cool.

Well, cool is not a business case. That's one of the reasons that I used the startup progression in my book. Because I think that the scaling model - when we actually think about information technology from this thought experiment or from startup to enterprise - [as a] startup, you can't afford to have any division between IT and the business. The digital product is the business. And if you don't have a very clear understanding of that product's market positioning, you're not going to survive. Which is why I used that as a thought experiment to train my students, even if they're not going to go into a startup.

Len: On that note, when I was reading a couple of the posts on your blog, I was struck by how - I interview a lot of software-side people, and one of the themes has been that in a world where, especially if your business is IT for IT products, digital products; but also with software eating the world, everything is sort of driven by software, and there's a sense amongst the people I interview that one can no longer be an executive, without having some domain-specific expertise. You need to know something about what makes the computers go, and what's really happening in that part of your company's infrastructure.

But what you're talking about is a responsibility and a requirement on the other side of things. That if you're doing IT, you can't just stop when the computers are going, you need to understand what they're going for.

Charlie: Exactly. And for the first 50 years of computers, the primary business case was efficiency. I mean we had hundreds or thousands of people managing paper filing systems. You'd go into a company like Prudential in 1947, and there would be thousands of file clerks. Even a hundred years before that, you had huge counting houses, they used to call them.

Remember Bob Cratchit in A Christmas Carol? I mean, that was the kind of work that white collar professionals did. Transcribing ledger entries. And it was the whole rise of the white collar professional.

Well, when World War II happened, people started saying, "These new fangled computers they're using to calculate artillery trajectories and break codes" - like Alan Turing in "The Imitation Game," with Benedict Cumberbatch - "Couldn't we use these computers to actually automate some of this paper shuffling we're doing in the big insurance companies and banks?"

And for decades, that was the business case of computers - efficiency, increasing organizational efficiency, trading headcount of file clerks and forehead count of programmers and developers and data entry operators. And in general, it was a positive business case. Otherwise we would not be where we are today.

But then around 2000, things started to get really interesting. Maybe even back into the 90s, all of a sudden, you see the beginning stirrings of digital, where it was no longer a matter of efficiency. You can't really explain Amazon.com in terms of efficiency and automation and replacing file clerks with computers, it's just not the business case. And the business drivers that led executives to replace white collar clerks with computers, were very different than the business drivers that Jeff Bezos was perceiving, when he started Amazon.com.

And so then we had the whole rise of digital, and we had computers which were now focusing much more on effectiveness, not just efficiency. And that's a very different set of business drivers. Efficiency hasn't gone away, it would be very dangerous to say that it had; but now it's been enhanced or increased into this new way of understanding digital value.

Len: It's very interesting, the connection between that and how people who are studying the many broad subjects that are encompassed by the concept of IT, should be trained. And I watched on YouTube, a video of a talk you gave in San Francisco last year for DevOps Enterprise USA, where you presented on the challenges facing higher education and teaching IT. You went into a lot of really interesting detail about what the different concepts that are taught are, and how they're bundled together, and how both the change that you were just talking about, and the sort of more technical, I guess in a sense, change towards agile and DevOps in managing IT systems - is going or ought to have an influence on how people are taught. I was wondering if you could talk a little bit about the shift you've seen happening in the industry, and how you think that ought to impact the way people are taught.

Charlie: It's a topic that I have quite a bit of passion about. Because certainly stemming from, as I said, that formative story of the people who'd been laid off, because DevOps. And who knew? I mean this is a surprise. And as I look at how computing and information technology is taught today, the fundamentals are handled reasonably well. We have Computer Science faculty who do a great job teaching automata, and discrete math, and compilers, and algorithms, and data structures, and operating system kernel design - and all of these kinds of things that they view as very fundamental and kind of the core. But the trouble is that there's still a long line of sight from that fundamental theory to industry practice.

It was funny, I was at my stepsister's house over the holidays. My stepsister has been a Dean at the University of Minnesota Medical School, and her son David actually works at Google. So we have some very interesting conversations sometimes. And I asked David - I think he graduated with a double major in math and computer science from the University of Minnesota, so he's a highly qualified individual - and I said, "David, when you first landed your couple of industry jobs, were you prepared from your degree for your day-to-day work experience?" And he laughed. He laughed loudly. Loud and long. And said, "Of course not. It was completely - Other than the technology, I was completely unprepared.

And my stepsister, his mom, really pricked up her ears, because she's from the medical community, where they handle things a little differently. And the long and the short of the conversation - and all three of us agreed - is that the state of the art in computing right now, is kind of like teaching people a very good fundamental grounding in biology, and then handing them a scalpel and turning them into the operating room.

Len: That's a great analogy. In the talk, you mention the analogy to how medical students are all taught rigorously how to do personal hygiene, and also the importance that this is a persistent requirement that you have to do all the time. And it doesn't matter if you are a nurse or a brain surgeon: every time you go into that room, you wash your hands and you hold them up in front of you, and you make sure you do that right.

Charlie: Right.

Len: And you draw direct comparison to that and version control, which struck me, because one thing I've always had difficulty with - and I came at this not from the IT side, but from the investment banking side of things, but I learned the importance of version control in one of my jobs - and not to digress, but it is actually something that is very difficult to get people to do.

Charlie: And yet it is the fundamental hygiene of digital systems. And Andrew Clay Shafer said it best: "Without version control, there is no agile." And Andrew gets to have an opinion on that stuff. He's one of the great thought leaders in the community.

Len: I know you were part of producing a report that was sort of laying the groundwork for change, and I was wondering if you could talk a little bit about that?

Charlie: Sure. There was a report that I put together with some of my colleagues in the Minnesota State University system. We put together a 60-page report, called, "Renewing the IT Curriculum: Responding to Agile, DevOps, and Digital Transformation."

This report went out to all of the computing, IT and information systems faculty in the Minnesota State system. This is not the University of Minnesota, which is the tier one land grant research institution. This is actually the tier two and tier three teaching colleges that teach roughly four times as many people as the university. This is where the mainstream of education happens in this country, is these huge two- and four-year systems that are primarily based on teaching.

And so I felt, if we really wanted to make a difference to the day-to-day student - I mean to the two year IT student at Fond du Lac Tribal Technical College in rural Minnesota, the community college devoted to the native community - how do we make a difference for people like that? We need to actually get some guidance out there that represents the state of the art.

Because, Len, they're still being taught waterfall. They're still being taught that project management is the be all and end all. They're still taught the planning fallacy - that if something goes wrong in a project, it means that somebody just didn't plan it enough - or there was a failure of execution. There's no discussion of the iterative and information-generating aspect of product management. And it's so important that we start getting this out into the mainstream bodies of knowledge.

Len: And could you talk a little bit about the distinction between project management and product management - and perhaps, if you, can specifically in the context of what happened at Target, when those hundreds of employees were let go?

Charlie: Sure. This is - by the way, Target has been very, very public about this. I mean, multiple public addresses. I'm not dealing in any kind of insider information here, of Target's. They're to be credited for how open they've been in this transformation. But what's been said on multiple occasions in public forums, is that Target, for the most part, has gone to a structure of, I've heard the number, 800 product teams.

And these are persistent teams that are not broken apart and reassembled every year. I mean that was the old school. You would bring the team to the work. You'd fund the work, you'd fund these initiatives. You would maybe have some degree of continuity on the business side with business management. But the idea is that well, we're going to give the business some more money. They're going to turn around and give the money to IT.

The first thing IT does is they scope the work, they assign a project manager. And the project manager goes out and - quote unquote, "Sources three Java developers and a DBA and a tester, and a requirements analyst," right? And these people were perceived to be infinitely flexible and transferable. The economic word, your investment banking and the economics word is fungible, right? So there was this persistent assumption of fungibility of resource.

Well in complex systems, this does not work. One Java developer is not necessarily like another Java developer, and the singular unit of value really is the persistent team that can grapple with a problem in a sustained way over time, and build a collective cross-functional mental model of what it is they are dealing with. And when you go down that road, you find you don't need as many project managers. You might need some scrum masters to serve as facilitators, methodologists, and to also, to some extent, make sure that the team is protected from too many external distractions.

You certainly need a product owner. You need somebody who has domain expertise in whatever the product is trying to do. But the idea that any chunk of money bigger than 50 thousand needs to have some project manager with it, who's going to spend their day drawing Gantt charts, ultimately there's - and Target's not the only company - there's just a lot of questioning in the industry as to whether that's a value-add operating model.

Now sometimes you do need to coordinate across teams. And so your really good project managers I think will become release-trained managers. There still is a need to coordinate sometimes if you've got five or six or 10 small teams. But in the end, that result has got to be a coherent release that is up and running by September 1, and stable in time for Black Friday. I'm not dogmatic that it all can just happen through the magic of microservices. But there's less of a need for that kind of role.

Len: And how does this translate into teaching practice? For example, switching from an older waterfall way of working or way of producing software, and transitioning to continuous integration or flow or continuous delivery. How does that change teaching?

Charlie: Well it's played out for me in a couple of ways. The first thing is that I have a fully functional small devops virtual lab that is defined as code. It's out there on GitHub. And so I can spin up and tear down a basic continuous delivery pipeline that includes JUnit and Ant. It's based on VirtualBox and Ubuntu virtual machines. I've got a little silly, "Hello World" Java application. I've got git and Jenkins and Artifactory and Chef running the thing.

So it's very much experiential. And this is just an educational best practice. The educational system is becoming very enamored with flipped courses, where you don't lecture as much, but instead you make the students watch the lecture offline on their own time. And then when they come into class, it's all experiential. Which I think is really a great way to run classes. And I think really the best way. Because when you're up there lecturing, the students are just surfing. Maybe that's a reflection on whether or not I'm a compelling lecturer. But I hear it consistently from faculty that lectures just leave them cold.

Len: Are you talking about the Calavera project?

Charlie: Yeah, that's the Calavera Project on GitHub. And full disclaimer, I know Calavera needs some updating. I've been working on my book on Leanpub. So the next generation of Calavera this summer, I'm going to get it out - I'm going to get some Node.js microservices, and I'm going to be standing up the infrastructure using Docker. The point is that you don't have to be on the bleeding edge, but you've just got to be keeping up to some level, maybe a couple of years behind where the bleeding edge is.

And then the other piece, the other way that it shows up to your initial question - how does continuous delivery show up? It also shows up in the fact that you may have - if you saw my DevOps presentation, you know that I was critical of software engineering and the fact that even the large structures of curricular guidance from the ACM and IEEE and the AIS have basically baked in waterfall. I mean, we've got the idea that you plan the degree with the IS majors plan. Computer science and software engineers build. And IT majors run. And so we've baked waterfall into the fundamental computing curriculum, and then within a software engineering program, for example, you have three credits on requirements, three credits on analysis and design, maybe various practical coding kinds of classes, three credits on QA. And so we've baked waterfall into those curricular too.

Len: On that subject actually, that was a really interesting thing that I learned from your talk. I wasn't aware that there was a high level of detailed guidance coming from various industry associations that direct the way these different degrees are structured. There was a really interesting table where there were columns that were for skills, and then rows that were for different specializations within IT, like computer engineering and software engineering.

In each intersection of row and column, was a little number that indicated how much expertise a student should have in that specialization, in that particular skill. And it was really fascinating to see the underbelly that I hadn't been aware existed for the design of those programs before.

Charlie: And they've baked in certain assumptions. They've baked in - if I can use the word, "Taylorist," they've baked in some very Taylorist assumptions. And they are thoroughly embedded in the curriculum, you can point to them - I mean the idea that a computer scientist should know next to nothing about product management.

So basically you're going to sit in a dark cellar, and every so often there's this trapdoor that's going to open up, and there's stuff called requirements that's going to fall in on you.

So basically you're going to sit in a dark cellar, and every so often there's this trapdoor that's going to open up, and there's stuff called requirements that's going to fall in on you. And you don't need to have any domain expertise. You've just got this interface called, "The Requirement." And it lands on you, and then you do your thing. And then you get out into the industry, and the first thing they say is, "Well go talk to the product manager." And you've just gotten out of four years of a CSci and you're like, "What's a product manager?"

Len: I just wanted to mention, for anyone listening who didn't get the Taylor reference, I believe that's to Frederick Taylor?

Charlie: Yes.

Len: If you'd like to learn more about that, you can listen to another one of our interviews with Erik Dietrich, where Erik and I go into that subject in detail. But sorry for the interruption.

Charlie: No at all, very apropos, it's an odd reference, but one that comes up a lot lately as we talk about digital.

Len: And how do you get, for example, those Taylorist principles out? I mean, do you need to lobby the industry associations to put out different guidance? Or do you need to lobby the higher education institutions and tell them, "You shouldn't be following this guidance as rigorously as you are?"

Charlie: To some extent, developing a 60 page report with the input of 12 faculty and a couple of dozen industry notables was essentially the first step on that kind of lobbying journey. And I'd like to say that we've gotten great results and great feedback. It's been a little bit quiet on the feedback side with that report. But I suspect that this is the kind of thing that people need to digest and think about for a little while. These are some fairly significant things that are being advocated and recommended. But I think that they're going to realize that they're really at a crisis point.

And I think, as I go back to the Target story - in the state of Minnesota, there's a Senate sub-committee on higher education and workforce. I talk to colleagues of mine in the actual community here in town, and I pose them this question: "Look, if somebody subpoenaed you or called you to testify before the Minnesota State Senate Committee on Higher Education in the Workforce, and they said to you, 'Mr. X is a noted industry practitioner who's clearly career successful. Would you recommend that the Minnesota State College system continue to teach project management?'" And the answer I'm consistently getting is, "No."

And in fact, at the University of Berkeley in the I School, I think I'll tell the story that Jez Humble related, because he's out there, and it's a matter of record. UC Berkeley, in what they call the I School, used to have a project management course. They no longer have a project management course. It's been shifted to a product management course. And I would say we're having some more conversations in various institutions here in Minnesota.

Now does project management go completely away? No. There still is some need for formal project management. It provides a useful set of tools. But perhaps it's not as required? Or perhaps we start to enrich project management courses, and insist that at least a third of them be attentive to product management concerns.

Len: Before we move on - thanks for that great answer - it leads me to my last question I want to ask before I move on to talking about your book.

I mentioned themes coming up in the podcast earlier. One of those is whether or not a person I'm interviewing would recommend that someone who wants to get into software engineering, particularly the product development side software engineering - should they go to university at all? I find that about half of the people that I talk to, whether they went to university to train in computer science themselves or not - they say, "No, they wouldn't recommend in 2017 that someone do that." And I've never had anyone as eminently qualified to answer that question as you on the podcast before. So I was wondering if you could give us your thoughts on that subject?

Charlie: Sure. Well high praise indeed, and thank you.

I am very much of two minds on that. I believe in the power of education. And I think that there are certainly fundamental practices and fundamental techniques and theories. If we wind up with people not understanding the fundamental theories of Turing and Shannon - the Church-Turing hypothesis, Shannon's information theory - how it is that logical structures are mapped onto digital circuits - I mean, we're going to have real problems.

We won't be able to stand up and support Intel chip fabs if we lose that body of knowledge. So from a societal and a workforce point of view, I think it's critical that many people, large numbers of people continue to go to formal computer science programs, and computer engineering programs, and understand the basic material science, questions of digital logic, computability - all of that. I think it's very important that as a society, we have people with that basis of education.

However, I am also noticing - you might have noticed the Y Combinator study from the DevOps talk that I gave, where they were very clear that the software developers that were most in demand for the Y Combinator startups, were not the most technical programmers, but were the programmers who had a sympathy for, and an understanding of product development.

So in my ideal world, you would still have people going to computer science programs. But they would do two things. First of all, they would be given at least three credits - I mean, come on - I know there's always fighting over what the required courses should be. And I'm familiar with those discussions at a faculty level. But three credits of product management should be a strongly encouraged elective for people going into industry contexts. That's not that big of an ask.

And then secondly, I do think that there should be very, very rich capstone experiences. Not necessarily internships. I mean, I know that internships can be great. But do the internships really give people the full spectrum grounding in digital product management that they need? I'm more of a fan of capstone. And I'm almost a fan of starting capstone early.

Len: What's capstone?

Charlie: A capstone project is you take two semesters, and you actually do something. It's a very common engineering school practice. This is your senior project. Create something. And so you get credit for it, and you get graded for it, you get juried on it.

It depends on the program, and it's very hard to characterize universally across education. But I do think that giving people more of an experiential bent, giving them some of the basics of product management, and then certainly changing some of the discussions around QA, testing, requirements management, and emphasizing the whole problem of fast feedback and information generation in systems design.... Also changing some of the way that systems architecture is taught.

I took a distributed systems course, where literally the system we were building, we tried to integrate it the last week of class. And the thing fell over and didn't work, and we were all demoralized. And then it was only after that that I really started reading deeply into things like Alistair Cockburn's Walking Skeleton.

I realized - well of course, you can't integrate a system on the last day. No matter how good you think your interface definitions are. That's just wrong. And yet, that is how I was taught, by a person who was actually a fairly senior computer scientist. But even this individual didn't really know some of the problems of implementation.

We should've integrated the system first, and then enhanced the modules with continuous integration throughout the semester. We would've had a fully functioning system at the end. But in 2003, that was not the state of the practice, that was not the state of the educational practice.

I've gone in a couple of different directions there. So I apologize that I rambled a little bit, but -

Len: Oh no, that's okay. It's all very interesting, I'm learning from you.

On the subject of creating something - you've written a book that is currently called, "Delivering Digital or Managing Digital, and I know that you're floating different ideas for what the book will be called in the end.

Charlie: Yes.

Len: I wanted to give you the opportunity to explain who the book is for, and why you wrote it?

Charlie: Sure. I wrote the book, first and foremost, for my students. I teach a required survey class at the University of St. Thomas. The University of St. Thomas in Minneapolis and St Paul has the largest software engineering program in the country. At least that's what I'm told. My students- the IT students, and there is a software engineering track and an information technology track - the IT students are required to take my course, which essentially serves as a survey course. That's how it's evolved over time.

Originally it was going to be the ITIL course. But I came in already fairly critical of ITIL, and it's evolved now into basically the equivalent of an MIS survey course, but from kind of an inside out perspective. MIS survey courses, they make everybody in the business school take them. You said you had a background in banking, so I'm betting maybe you had a B school or MBA background?

Len: No, I wrote my doctorate in English literature.

Charlie: Oh, okay - well good for you. My BA was in political science, so actually I'm a big fan of liberal arts. I don't think we're going to get to good product management... I think liberal arts majors actually make great product managers. But that's a topic for another day, and maybe another book.

So I wrote the book as - basically I said, "I need a survey text for my students, and none of the current management information systems texts are suitable." I mean, I have one that goes on for 20 pages about the beauties of waterfall. And then for half a page, "Oh agile might be a thing some day." And this book is copyright 2014.

I mean, at this point, the current management information texts are really quite behind, even if their copyright is current, because they re-copyright them every year, and make small revisions, so that they can sell new copies of the books every year.

So I said, "I've got no choice, I've got to write a book." I had written a book before. I had been using my book in my class, the Architecture and Patterns book. The learning from that was, it was just not suitable as a survey text. Because it was written from the enterprise perspective, and my students would come in, and they would just glaze over with all this enterprise junk. And it was just too big an elephant to start - like swallowing a whale.

I said, "Well how do I come up with a learning progression that brings the student along?" And I had the thought, well, I started to think about Walking Skeleton. I started experimenting with the Calvera simulation - the minimum viable platform for teaching DevOps. And then I also ran into the startup literature. Books like, Scaling Up by Verne Harnish. AndI said, "Well why don't we treat the course as an exercise in scaling?

Because every student can identify with Larry Page and Sergey Brin in the garage starting Google. Or 80 years before, Dave and Bill starting Hewlett Packard. It's the great universal success story, rags to riches. Horatio Alger.

Len: Or Hero's Journey.

Charlie: Exactly. Steve Blank, "The Hero's Journey." [Note: Charlie was probably referring to Steve Blank's book The Four Steps to the Epiphany - eds.] So there's deep iconic metaphorical terrain we're working on here. And it works well, and certainly as I viewed it as the "Hero's Journey," all this stuff that my students were struggling with when I was approaching it in the wrong learning progression - it started to make sense.

Like, "Yeah, I can see how now I need to be concerned about a team. Now I have a team-of-teams problem. Now I've got an enterprise problem." Whereas discussions of governance - if I'd started lecturing day one on the COSO and the Treadway Commission, and formal controls - my gosh, the students, they wouldn't have stood for that, they would've just been completely bewildered. But by lecture 10, I've set the stage.

I say, "Yeah, you've got that first initial system you were working on the first three weeks of the course. Well you've now got 1,000 of those. And so you have a scaling problem that's emergent, and so now we need to talk about what governance actually means."

Len: It's interesting, you talk in the book about - I forget who it was who came up with the idea, but it's something about scaling valleys or something like that?

Charlie: Yeah, that's Verne Harnish. He uses the "Valley of Death" metaphor - the idea that you go through this crisis, this like dark night of the organization. As you realize that - hey - what got us to being a high performing team? Those same techniques will not get us to being a high performing team of teams. We need new techniques. Well what are those new techniques? What do we need, and why and when?

And then you can have a very interesting conversation, a very grounded conversation in things like, "Do we need project management right now? Do we need process management right now?" Whereas again, the temptation - and this is a trap that the current management information systems textbooks fall into - is to just start with some of those things as - a priori assumptions. "Well of course we're going to have project management. We're going to learn all about it in chapter one." And then people are like, "Well yeah, but they don't use formal project management in startups.

Len: It's interesting. You write also about how one of the - I think this is what you were saying - but one of the dangers that happens when you reach one of these scaling points, where you go from being just a founder, to having a team of eight to ten people - to having 500 people, to having 5,000 people. It's at that moment, when you start to formalize things that were not previously formalized, you write, "the danger of course is that the formalization effort may be driven by its own logic, and you start to lose track of the all critical business context."

Charlie: Exactly.

Len: I've never seen such a clear description of what I would call the bureaucracy trap.

But that description itself points to the way out. Which is, whenever you're engaging in a formalization effort, or something that probably only formalization professionals enjoy, you need to keep your eye on the purpose for the formalization effort.

Charlie: Exactly.

Len: And that purpose is continuing to develop and produce whatever your products are. And that's true at all levels, that that's your mission - don't lose sight of that when you're undergoing one of those efforts.

Charlie: It's so tempting. Because when you bring in specialists in something like IT service management or process management - well their functional specialization is what they know. They've got a tool box, they've got more than a hammer - to be fair, it's not just a hammer and a nail problem. But they've got a certain set of tools. And if you don't really watch them very carefully and constantly ask critical questions, they will pull out all the tools. And that can be very dangerous.

For example in the ITIL framework, it calls for 26 processes. Now I'm on the record as saying that I don't think that any company of any scale can actually accommodate ITIL's full process model. It was created as kind of a thought experiment. You could call it a reference architecture. But I've seen companies go quite a bit too far down the road of implementing that. And there is a classic example of the formalization effort taking on its own logic in a very dangerous way.

Len: You touched on this earlier, but you also write in the book saying, "It is possible that there is no higher unit of value in the modern economy than the high-performing team." I was wondering if you could talk a little bit about why you think that's true in the modern economy, and maybe how that's something that should be taught to students in IT related subjects?

Charlie: It's a great question. I am so glad you brought that up, because I was actually trying to figure out how to segue into that point myself.

So here's the thing with the high performing team - and the reason why it's important, and why I use the qualifier "modern."

It's because - if I were to sum up what's different about the economy - if somebody said, "Charlie, just how would you break it down for a CFO?" I would say, if I had an impatient CFO who just wanted a one sentence answer, I would say to that CFO, "It's because R&D is now pervasive." And if they're a good CFO, and they understand the modern corporation, they understand that R&D is not operations. What's the one thing that probably is not under your COO, I would hope is not, is R&D, right? Because R&D is that iterative, risky, experimental thing.

Now when you are doing highly uncertain, iterative work, with a lot of unknown unknowns, you're in chaotic or complex situations. The most effective approach for solving that is what has been established in military organizations for many years, is a high-performing, cross functional team, that has solid cohesion, multiple specialties -- and in the words of Amazon, can be fed by no more than two pizzas.

There is so much organizational literature that converges on this point. And in the modern economy, since so much of it is R&D-driven - well, why did I say that to the CFO? Why am I saying operations is going away? It's because we're automating everything. And when operations becomes completely digitized and automated, what's left? Well, if you want something more than just factories full of robots, the people have to do something. What do the people gravitate to? They gravitate to the non-deterministic creative work - i.e the research and development.

And of course, software development is only one form of R&D. This is something I have to remind software developers of. That they're not special. They will say, "Well, we've got nothing to learn from manufacturing or physical industry." I'm like, "Excuse me, your colleagues who are chemical engineers or biotechnical engineers or electrical engineers might beg to differ. Because their work, as is everybody's, is iterative and uncertain and risky.

Don Reinertsen is really the guru of this whole discussion. He just views it as product development, whether it's software-based or chemical-based. You're trying to wrestle with unknown unknowns.

Len: Before I move on to asking you questions about the experience creating your book - which is, I think quite interesting - on that subject of automation and jobs, just generally speaking, what's your take on that? That's something that a lot of people are talking more and more about these days. Especially in the face of discussions about people being left behind in the economy already.

There's this looming possibility of greater automation of the kind of tasks that people are doing, including driving. What are your thoughts on that as someone who has a lot of experience with this activity of automation, and also teaching the kids who are going to be going out there maybe doing that in the future?

Charlie: I'm very concerned. And I think that this is one of the responses - is that we have to make it clear to people that the future is going to be - the value is going to be added in creative endeavors.

Now there's always going to be a need to surround the digital systems with some level of human-interfaced support. And that's why I don't think operations management's ever going to go away. I kind of define operations as relatively more interrupt-driven, in work.

But in general, you have to understand the fundamental dynamic, which is that R&D, and digital R&D, is driving the economy. And so how do you latch onto that as a career strategy? And in that way, I'm hoping that my book is of service to people who need to prosper in this new - new economy. But I am very concerned. I've got a friend who actually drives a truck, and he's quite worried.

Len: I think one of the crises we'll face will be determined by the fact that not everybody is suited to creative types of work. A lot of people get a lot of pleasure from doing what I call "tooling around." Which is - you get in your truck, and you go get this, and you go do that, and you go get this, and you go do that. And you put this together, and you take that apart. If that type of activity goes away, my personal concern is - what are people who are suited towards those types of activities going to do, that won't make them miserable?

Charlie: Right. It's the question of the age, Len. And I don't know the answer.

Charlie: Are you following Martin Ford?

Len: No.

Charlie: Martin Ford wrote The Lights in the Tunnel. He's one of the leading thinkers in this.

Len: Okay, I will start following him now. Thanks for the suggestion.

Len: On the subject of the process of writing and publishing your book - I looked into it, and - so your first book was published by Morgan Kaufmann, which is an imprint of the giant publishing house or company, Elsevier. And you contributed to another book that was published by Productivity Press, which is an imprint of another publishing giant, Taylor & Francis. And I know that you eventually decided for your new book that you would set up your own publishing company, and manage everything yourself, under, I believe it's called "Digital Management Academy."

And I was wondering if you could talk a little bit about your journey - from starting out with a project that was going to be published by a conventional publisher, to deciding to do it yourself, and what that was like?

Charlie: Well some of it's in the introduction or the preface to the book, as you're alluding to. There were a few different things that went into it.

First of all was the desire to have the ability to publish the book for public consumption and feedback, and be able to iterate on the book a little bit more readily - just have more flexibility - that the publishing process didn't have to be such a huge batch process.

Well, realistically the publishing process, to some extent, is somewhat batch driven. And I could talk more about that, but I won't. I mean it still is a large batch of work - even though I can be a little more iterative with it.

The other thing was, it was certainly an interesting technical challenge. I was not really happy with, for example, how the Elsevier book came out on the Kindle.

And so just understanding for myself the various toolchain aspects, was an interesting mental challenge - and I found it fairly stimulating. I ultimately wrote the book in AsciiDoc, and then wrote a series of tranformations from AsciiDoc into LaTeX, to get an attractive PDF.

I looked at the Leanpub publishing paradigm, but I wanted two things. In the PDF copy, I wanted floats and I wanted marginalia. And those seemingly simple things are not trivial to achieve. I spent a lot of wrestling, and ultimately LaTeX was really the only format that was going to give me what I wanted. There are no open source free DocBook converters yet that support floats well. I'm sorry if I'm going into publishing arcana here -

Len: No, please do.

Charlie: So the other thing of course was the feeling that I could do better financially. That publishing the book - obviously when you go through the big houses, they take seemingly 92% or 98% of the money, it feels like.

Len: In academic publishing, it can be up to like 98.5%.

Charlie: Or 101%, you actually wind up paying.

I didn't feel that that was necessary. And I felt like I'd already proven myself. I mean I'd been through the process - not just once, but twice. I qualified for a second edition with Elsevier. That was, I felt, a significant vote of confidence in my capability and choice of topic. And so I felt that starting my own - trying to do this on my own was a reasonable choice. I'm fairly happy with the result.

There's decisions I'd wish I'd made differently along the way. But in general, I have more or less functional HTML, PDF, EPUB and MOBI files. And I'm working a little bit more to polish them up. I'm also a little bit late to the game with - I'm hiring a couple of copy editors. I write reasonably well, but I'm hoping the copy editors can take it down a grade level, maybe even two grade levels, in terms of reading difficulty. Because sometimes I use stupid academic prose, that really doesn't add a lot of value. And somebody can give it a good Strunk & White treatment, and it'll be value-add all round.

Len: You described how you make your PDF, but I was wondering if you could explain to people listening, who might be interested in making books themselves, and using Leanpub's "Bring Your Own Book" feature, where you make a book however you like, and then you can upload it, and take advantage of all of our storefront features. And you can upload one or all of PDF, EPUB and MOBI ebook formats. So I think people might be interested in hearing how you make the EPUB and MOBI.

Charlie: That's exactly right. I mean certainly if you have the artifacts, if you have a good-looking PDF that you feel proud of - and same for the EPUB and MOBI.

As Len says, you can upload it directly. You don't need to use Leanpub's authoring tools. Which - by the way - for many applications, I mean if I had written a different book, and there's already books I've thought about, that I would just use Leanpub authoring tools.

A full blown survey textbook that's running 600 pages, that might be actually hard copy in a bookstore, it's kind of a special animal, which is why I did what I did. But for monographs or books that are more current, more topical - books that really need to keep up to date very quickly with new technologies, I think that going with the Markdown route, and - as long as you don't want to do fancy things, like wrap text around pictures, which is, when I used the term "float," that's what that is - if you don't want to do fancy, dumb stuff like that - then you don't have to.

But in terms of the toolchain, basically I chose to write the thing in AsciiDoc, which is a little bit more formalized, has a little bit more of a standard around it than Markdown. Markdown's kind of gotten fragmented. And you can also integrate AsciiDoc with BibTeX for citation management, which was also a plus. And like I use a converter called dblatex.

I use AsciiDoc to convert to DocBook, and then I can rip the DocBook to LaTeX. And then I've go to do a whole bunch of massaging of the LaTeX which I use. I use some regular expressions, and turn it into that final publication-quality PDF that you see that will be also getting a further visual upgrade with the assistance of some LaTeX professionals that I've identified, and will be working with.

Len: And do you use that same source document to make the EPUB and the MOBI as well?

Charlie: I do. Although in that case, it goes from AsciiDoc to DocBook to EPUB. AsciiDoc has a direct EPUB converter, but it doesn't work with the bibliography approach that I chose. So in some ways this tool chain is still a little bit crazy-making if you want all of the good stuff. I mean, I've got 270 citations in the book, I need a citation manager. I can't be messing with those manually. And yet AsciiDoc, BibTeX are in an early stage - and I just couldn't get it to work with the EPUB output. So that's where I was last week, is pulling my hair out around that.

Len: And what was the solution?

Charlie: What I did was, the AsciiDoc, BibTeX converter works fine to DocBook. And then from DocBook there is a set of stylesheets called db2epub. And those stylesheets were what I ultimately went with.

There's actually a few different solutions from DocBook to EPUB, including just sticking the book into a tool like XMLmind or oXygen. But I was getting some failures, and I think I stuck in XMLmind and just did an export to EPUB. And then a Java stack exploded on me. And it's like, "Oh boy, okay maybe go in and upgrade the memory on Java."

But I got another working solution. I've got this whole spreadsheet of tool chain stuff that works, and tool chain stuff that doesn't. I mean, I've been messing with Pandoc and Calibre and Sigil. Then I had to put the thing into Sigil to get a cover in. But then once I put it into Sigil, then KindleGen didn't like it anymore, because it had an HTML cover. And I made some adjustments to the table of context and contents. And then KindleGen blew up on that. And then, KindleGen has also been failing for less clear reasons in other cases.

It's really been an amazing set of kludgy, semikludgy things. And thank goodness for Ubuntu. Because with Ubuntu you just download these packages, and set up this toolchain, and you set up the scripting. But it still all feels very, very early stage. I mean, I think I keep coming across people like tearing their hair out like me saying, "Why isn't there just one integrated solution that gives me the publishing control of LaTex, and the flexibility of DocBook, and it's free? It's like it's not all there." And if anybody can tell me that there's something that I'm overlooking, I'm all ears.

Len: Well, we're trying to provide - obviously our own approach to that problem at Leanpub, we've got various things we've done, but they don't accommodate everything. Like for example, we don't have a way to do marginalia.

One of the founding principles we have, is that although we want books to look great, and we do think the Leanpub process makes great-looking books, part of our philosophy is that when you're -

We want to build a great tool for writing and publishing, particularly in-progress, but also completed books. And what we strive to do is allow you to get to the point where, when formatting becomes important, then you can take something from Leanpub that can then be used to apply formatting to. One of our solutions to that is an InDesign output feature. But these are huge problems.

We're working on something that my co-founder, Peter Armstrong is creating, which is called the Markua spec, where he's basically writing a Markdown for books. So we're transitioning away from Leanpub-Flavored Markdown to create books [Editor's Note: While Markua is the future of Leanpub, we will support both Leanpub-Flavoured Markdown and Markua for the forseeable future -- presumably indefinitely, or at least for a number of years.] - doing something specifically created for books. And hopefully that will help with some of the issues that you've been describing.

I just wanted to ask you one last question, which is, what's the future for your book? What are your plans?

Charlie: My plan is, I'm not going to short the marketing of the book. I'm developing a marketing strategy with some associates right now. The book needs consistent and sustained marketing, and I think I'm in a position to do that. It needs a full-blown campaign. Like I said, it needs a full copy edit pass, it needs a new LaTeX template. Once I get those two things done - and I've I've identified partners on both of those, so all of that work's in progress - and then we get a marketing strategy going.

I mean, when somebody googles, "DevOps textbook," or, "Agile textbook," I want this book in the top five. There's going to be more and more requirement for that. I mean, these bodies of knowledge have stabilized. They have become dominant in their influence on how digital is delivered.

And my book is a comprehensive survey suited to the busy teaching faculty who don't have time to research all the stuff - they just want a good solid reference that brings it all together. And I think there's a great opportunity here. I think that I'm hitting a market that is currently under-served. And certainly looking for any interested parties who have ideas on how to partner on this.

Len: Well, if there's anything we can do to help you when you're marketing your book, please let us know. We're always listening to authors and trying to figure out how we can help them solve their problems, including getting the word out. So please let us know if you ever have any suggestions or run into any blockers.

Charlie: I will.

Len: Well, I wanted to say Charlie, thanks very much for taking the time to do this interview. I learned a lot, and our listeners probably will have as well. And I also wanted to thank you for using Leanpub as the platform for publishing your book.

Charlie: You guys are certainly welcome, and I certainly appreciate the support you've given me so far, and look forward to continue to working together.

Len: Thank you.