In this Episode
Michael T. Lombardi is the author of the Leanpub course pwshop: A PowerShell 101 Workshop. In this interview, Leanpub co-founder Len Epp talks with Mike about his background in tech, restorative justice and workplace conduct, what PowerShell is, the success of the PowerShell Conference Book in raising money for a scholarship, his course, and at the end, they talk a little bit about his experience as one of the first people to create a Leanpub online course.
This interview was recorded on December 4, 2018.
This interview has been edited for conciseness and clarity.
Based in St. Louis, Mike is a software engineer who works for Puppet, a company based in Portland that helps companies automate their software delivery life cycle - both for people who build and deploy applications, and for those who manage infrastructure.
Mike is co-founder and organizer of the St. Louis PowerShell User Group, and he is the co-host of the PSPower Hour, which you can find on Youtube at youtube.com/c/PSPowerHour. And, he is the occasional host for the ChatterOps community chat show, which you can find if you search YouTube for ChatterOps. You can also follow that podcast or that interview series on Twitter @chatteropsorg.
Michael is the author of The Leanpub course pwshop: A PowerShell 101 Workshop. In this interview, we're going to talk about Mike's background and career, professional interests, what PowerShell is, his work on the PowerShell Conference Book, and of course, his course. At the end, we'll talk a little bit about his experience being one of the first people to make a Leanpub course.
So, thank you Mike for being on the Frontmatter Podcast.
Michael: Thanks for having me.
Len: I always like to start these interviews by asking people for their origin story. I was wondering if you could talk a little bit about where you grew up, and how you first became interested in computers and software?
Michael: I grew up as an Air Force brat. So, everywhere was home, and nowhere was home. I sometimes think of Brooklyn as home, because that's where my dad's family's from. We would go back there every year, it was one of very few places that had sort of stability in my life.
We ended up in St. Louis, and my dad got [out of] the Air Force, and I've somehow just magnetically stuck here ever since. That was not intentional, but it's been enjoyable.
I got into tech the way I think a lot of people initially do, which is, being geeky, nerdy - I played around with computers, and decided to build one. I had to play with stuff, I needed to mod things. And then I went away to college, ambitiously thinking that I would manage to get myself a computer engineering, electrical engineering and computer science degree simultaneously.
Michael: So I started off as a triple major. I took a really, really hard left turn though, and dropped out my junior year as a history major with a minor in Russian and philosophy. And then I fell into a really good internship opportunity - which, it turns out, you can only maintain student internships if you retain student status. So a pointer for those of you out there that are thinking about that - don't quit halfway through your internship, they will end your internship.
So I found myself scrambling to figure out how I was going to pay the bills, and I lucked out. A friend of a friend asked me if I wanted to interview for a [?] role, and I ended up in tech.
And at first it was - to quote my earlier self, "I'm just doing this to pay the bills till my novel takes off." That never happened. It turned out I really enjoyed doing tech. And so I've circled back around to the joy of writing by sharing technical learning stuff with folks, instead of writing novels.
Len: That's really interesting. So your training in software engineering came partly from a university experience, and then partly from on the job. Did you do any other kind of training?
Michael: I had very little formal training. After some initial schoolwork, I went back to community college. I took a couple of courses on server stuff, exactly as much as I needed to become a DoD contractor. I had a heartbeat, I had a security clearance - and I just needed to get one or two certifications.
Everything since then has been either self-learning - trying things out on the job, trying things out at home, building a home lab - that sort of thing. I've been very, very lucky with mentors. I ascribe a lot of my success to having the right people around me and being able to learn from them.
Len: What's the experience like - obviously without giving up any details, working on Department of Defense contracts?
Michael: I am lucky that I was able to do it at the time. I would never go back. The whole system is pretty gross.
I needed to pay bills, and I'd grew up around the DoD. But seeing it from the inside - the way the contracting works, it's not a pretty picture. There's a lot of politics, there's a lot of nonsense that happens there. And at the end of the day, the way that I kept myself from like going nuts about it was that I would say, "Well, at least I'm doing a good job here." They'll just hire anybody to do it. So at least like if I give it what I can, then we're getting something back out of it. But I don't think I could go back.
Len: It's really interesting. I've interviewed people for this podcast before who've worked for similar types of organizations, and I don't think anyone's ever said it explicitly - and I might be confusing this with some TV I've watched, but I get the impression that when the money is so big and the stakes are so high, that often you end up in a situation where there are a lot of very ambitious executive and manager types who are jockeying for a position in managing their own -
Michael: I think that's a lot of it too. And I think part of it is that the processes and the system around it is so byzantine that it's very easy to decide that it's more valuable to you personally and to your company, to pursue excellence in that arena - rather than excellence of a product or service. But if you play the game better, it doesn't matter how good the product is.
Len: You just said in a better way than I normally do, something I often say when discussing these kinds of topics. Which is, getting government contracts and building efficient and working products are both very interesting and difficult skills to master, and they don't have anything to do with each other.
Michael: I would agree to that.
Len: In one of your bios online, you talk about a stressful situation that you encountered when something went wrong with a critical application, and this prompted you to think about stress generally, and how to make work more humane. I was wondering if you can tell us tell us that story, about that experience.
Michael: Absolutely. So that job that I mentioned, I got hired into was as a tier two sysadmin. So I went from an intern managing spreadsheets and having no idea how to do real IT, into a tier two systems administration. The system that we were responsible for is the system that moves medevac patients for the military. So, reasonably high profile. If the system goes down, people are still able to move them by hand, right? Flight nurses are amazing. The folks on the ground are incredible. So there's no real worries about that.
But it's more - when you get a call from a user, the call is from a colonel wanting to know why he can't find out where his injured soldier is. Or it's somebody who's trying to report on status to a family member. And it's like, "Hey, your system isn't updating. I need this report, what am I going to tell this person's spouse?" In that regard it was good experience, because anytime something crashed, you immediately understood how the user felt.
I say all that to build the context for this - which is that I built a beautiful bespoke patching system, which I would never recommend to anybody. It's a terrible idea. It involved being able to do systemic reboots of your system. So you would patch it, and then you would drop it down and bring it back up and then verify that everything is in state. So theoretically, all automatic - perfect.
By default, because I design stupidly, it would apply to every single system we had. So I was running the patching, which was supposed to be for our [?] site, thinking nothing of it. And then I hit go, and I was looking at the server names and I was like, "Huh, does that say 'prod?' That's not right. It's not. Oh no."
And so I began to drop our production servers. Luckily one of the first servers to go down was the control node. It rebooted itself, so it didn't carry out the others. So the only servers that went down were a few app servers and the control node. None of the databases were dropped live, which was good. But it stressed me out, freaked me out. I was horrified I was going to lose my job.
There was a big after-action review, all that kind of stuff. I realized that at no time did we ever look into, "Why were we able to have one person just drop all of prod?" That didn't seem to be a question that ever came up. It was, "Why did Mike think it was okay to drop prod?" Which is a very different question.
So I started looking into it, and what I found - I have tried and tried to dig up the article - and I can't now, which is frustrating - but it was a series of articles that I found where it talked about the effects of stress on your health. One of the things that came up was that firefighters and cops have what you can think of as these massive spikes of stress during their career.
Most days it's relatively stressful but not excruciatingly so. But those spikes kill you. Those massive spikes and stress destroy your body, destroy your health.
What they also found is that people who have medium-high levels of stress - they focused on people in operations roles, and in that case I believe it was financial operations -so not necessarily like technical operations, folks who are like in accounting for big business, that sort of thing - they operate with very little autonomy. They operate with very little freedom to move, but lots and lots of responsibility, and almost no recognition - unless it's negative recognition.
What they found was that the stress levels that they were seeing there, and the health outcomes, were roughly the same as they were seeing for cops and firefighters, which sounds kind of goofy on its face. The question that I asked was, "Surely there's another way to do work?" There has to be something else.
When I came around to the whole idea of devops, it had absolutely nothing to do with shipping software and everything to do with, "Can we find a more humane way to work?" There have to be better work patterns available to us.
And it turns out that there are. From there, I fell into looking into restorative justice for organizations as well.
Len: That's funny, that was going to be my next question. You talk in your LinkedIn profile about how you're passionate about restorative justice. I wanted to take the opportunity to ask you, just to explain a little bit for the listeners what it means, and how you express your passion for it.
Michael: The short version of this is that I'm stealing everything that I have here from Sidney Dekker, who's a professor in Sydney, I believe? [It appears to be Brisbane - eds.] Who first started studying this through airline safety. His book, Just Culture, is where I learned a lot of this stuff.
The idea of restorative justice is an alternative to punitive justice, retributive justice - which is what we typically think of when we think of our justice system.
In a retributive justice system we ask, "Who did a wrong thing, and what should we do to the person who did the wrong thing?" What should their punishment be?
The idea being that punitive justice, retributive justice will prevent future infractions, because people will be less likely to make them, because they're concerned about the consequences. It's fundamentally a backwards-looking approach to justice.
Whereas restorative justice asks instead, "Who was hurt by what happened, who has been impacted?" And that will include first-order victims. Agood example of this is - if I'm texting while driving, and I crash my car, qho else was hurt first? Who did I crash my car into, If I damage somebody's property by doing it - there's nobody else involved, it's just me and somebody's light pole. What are their needs? What do they need to hear? What do they need to get from it?
That can also include second-order victims. In a lot of cases, especially organizational - this comes up a lot in medical fields. So, you're working to save somebody's life, and you make a mistake. It's not like that doesn't have an impact on you; nobody wants anybody to die on their watch. Nobody wants anybody to have a bad health outcome. No doctor goes to work wanting that. So you could think of them also as victims,
What restorative justice asks is, "Where did the system of measures go wrong?" You can make the argument for restorative or retributive I think at the societal level. Like, "What should we do about like violent crime?" But inside of an organization - if somebody has an infraction, most times it's not malicious. I would almost say, almost never; very, very rarely does somebody decide to maliciously throw a wrench into things.
Most often what you'll find is that things go wrong because we haven't taken a more holistic view of the system. When something does go wrong, what you want is an accounting, an honest, forthright accounting of what went wrong - why you did the thing you did, what factors played into that? Because most people when they're wrong, they want to understand what happened, they want you to sincerely give an accounting. But at the same time, they also want to know that something in the system is going to change.
So in the case of my reboot of prod, what we wanted to see changed was really some sort of control over, or oversight, like, "If we're going to do something that could bring down all of production, do we need a second 'yes' person to it?" Should it be in the hands of one, or should we have some sort of system whereby we say, "Before you run this command, get a verbal okay and eyes on." Which is what we ended up agreeing to.
Restorative justice looks forward. What can we do to make sure this doesn't happen to anybody again? That's very often what victims want to know - so if you're using Amazon and it triple-charges you, you don't want to hear how they're very, very sorry that that happened to you and it was just a technical glitch. You want to know what the bug was. And more importantly, you want to know what they've done to make sure that that bug's not going to affect anybody else. Because you don't want any of your friends to go through a similar experience.
This explanation waffles around a huge amount of stuff, but restorative justice is a fundamentally alternative approach to how you handle problems. I think, based on the evidence we have, it is a fundamentally better approach inside of an organization.
Len: It's a really interesting subject, partly because I gather that one of the hardest things to get over in trying to bring about a system more like what you're describing, is an association that people have with being tough and being effective. They think that the tougher something is - I have a little phrase where I call it, "Conflating negativity with realism."
If you're in an environment where say there's a manager, who might even be a non-technical person, but who's got to manage all these technical people - how do you convince them that they should adopt more of a restorative justice approach, if they're just deeply in the culture of punitive justice?
Michael: The first question I would ask is, "How effective has your punitive justice measures been?" Has it actually reduced the incidence of the stuff you're trying to stop? Because in a lot of cases, it doesn't, or it doesn't seem to.
A good example of this is, if you investigate the logic of a punitive response to an accidental dropping of prod, the person didn't intend to do it in the first place. So are you going to scare them into being more careful, or is what's going to happen, is the morale's now going to take a hit and they're more likely to leave?
That would be the next question I would ask, is, "What's your retention like after a punitive action? Do they stay? Do they improve as engineers? Does your team continue to function highly, or does it break down the team?" Because I would expect - my prediction is, based on the evidence that I was looking at through Sidney Dekker's links and his resources in the back of the book - is that the answer is, "No."
The second line of questioning I have is, "How often does your team come to you to let you know there was a problem? And how often does it only get uncovered when it's huge and critical?" As a leader, I would rather know early and often that, "Something went wrong, and here's what we did to adjust it. Here's how we changed process." I don't want to find out when it blows up live in front of all of our customers that, "Yeah, we've been having problems with this thing for six weeks, and we thought we could work around it, but it didn't really work." And now, "Oops."
Len: Does your approach to restorative justice inform your approach to documentation?
Michael: I like to think it does, I like to think that it kind of speaks through a lot of the stuff I do. But I also think that documentation is one of the tools that we have towards a restorative approach. When you notice something's wrong, you immediately document that it is. And then you let folks know about it, you're as open and transparent as you can be as early as you can be. And then you use that documentation to inform how you change things. I think that's important.
Len: You've got a really great talk on YouTube that I watched, where you talk about documentation and the different types.
For those listening, calling back a little bit, when Mike is talking about "production," that means you've deployed some software code that you've written that's actually live, affecting people out there. If you do that by accident when you were intending to just keep things internal, it's a real heart attack kind of moment.
Michael: Yeah. It's the sort of sort thing that definitely loses people money,
Len: And the other thing is that documentation might sound boring, but it's actually - in a world that's basically running on software, I can't stress enough how important having good processes around documentation actually are for our quality of lives - and for things like our power grids not getting hacked, things literally not blowing up.
I've talked about this on the podcast before with people - in the way that version control is actually becoming an important part of people's day to day lives, in ways you might not know, and in ways that more and more people are getting to know.
I wanted to ask you specifically if you could talk about the three different types of documentation you mention in that talk - which are reference docs, narrative docs, and context docs?
Michael: The first one that most people are very familiar with is reference documentation. Reference documentation can be very quickly defined as the information that you need in order to get a particular thing done. It's very cut and dry. "How do I use this feature?"
An example of this would be, "How do I change my Amazon email?" "How do I change the email account for my Amazon stuff?" They'll have reference documentation that will explain that. But reference documentation is usually very dry and you won't really remember it.
A good way to compare and contrast is to the next type of documentation, which is narrative.
Can you quote a passage for me from a text book you've read recently? Particularly like a history textbook. Probably not. But I bet you can quote something from a novel you read in the last year. The reason for that is that your brain is fundamentally wired for the second type of documentation, which is narrative.
Humans have told stories to each other for about as long as we've had language. That's one of the very first things we did, it's something that's universal across every single culture - is the telling of stories. Your brain is wired to hear, process and understand stories.
So a narrative documentation says, "Okay, since that's true, let's go ahead and teach somebody something in a format that they can understand." In narrative documentation, instead of just saying, "Click this, click that," you might say, "Okay, so you're wanting to change your Amazon email. Here's where you would need to go. This is in the top right hand corner, and there are these concerns." Or you might walk through an actual story of somebody changing their email.
You've read thousands of pages of narrative docs without knowing it, which is every blog post you've ever read, probably. Almost all of those are a form of narrative documentation.
Narrative documentation tells a story. It doesn't have to have explicit characters, but it can. It doesn't have to have a specific plot arc, but it can. The degree to which you cling to those narrative structures informs how memorable the thing will be for people. The third type of documentation is context documentation. Context documentation, in my view, is criminally overlooked by everybody everywhere.
If reference documentation tells you exactly how to do something, and narrative documentation helps you to understand how it applies to you, context documentation explains to you why somebody else did something.
A good example of this would be - why does your app login require two factor authentication? Lots of apps are moving towards this, it's pretty important. The context would be, for security purposes. It's the easiest thing that they can do to reduce the incidence of abuse and security problems with their platform. So if they turn that on, they can guarantee that context documentation is put somewhere that you can find it and understand why a decision was made. Context documentation gets more important the closer you get to an additive interaction. If you're going to contribute back to something, context documentation becomes even more important.
In our field, in software engineering, very often you will come across a project and you'll look at it and you'll ask yourself - why on earth they did that? But the truth is, the people who are doing the work are very smart, I tend to assume everybody I meet is competent at whatever they're doing. Given that that's probably true, then it behooves me to try to understand why they did something that I don't understand. Because that implies that I'm missing context, which is why I refer to them as context documentation.
It provides that additional understanding, and it prevents them from rehashing the same argument. One of the ways I tell engineers that you can tell you're missing context doc, is if you get the same question about something you did five or six times - it implies that that's not clear to people from the outside, and so you should document it and make it available.
Len: That's a really great explanation. Thanks for that.
You reminded me of something that we encountered just this morning at Leanpub, which was someone unhappy that - they were trying to make a purchase, and they saw that two of their three pieces of information when they were purchasing didn't match, and so they couldn't make a purchase.
We have to do this because of, it's kind of complicated and I won't explain the whole thing - to comply with EU value-added tax rules, we had to implement this pretty complex system that we really wish we didn't have to do. But we did, in order to comply with it. And what it means is that if you're doing something - like say using a virtual private network, that tells our system that you're in one country - and then you are actually in another one, we serve up this error message, and we do have an explanation - a context explanation of why we do that, but we don't link to it from that error message. You just made me realize that if we'd done something simple, that person would have been - they wouldn't have emailed us, and they wouldn't have been so unhappy. Because they would have seen, not only what the explanation was, but that we cared enough to explain why we were doing what we were doing.
I've got a question I want to ask you about the future of automation and documentation. I was at a conference not too long ago in Vancouver, where someone who was a CEO of a company that basically provides customer support, was talking about how the companies of the future that win, are going to be those that can automate support as much as possible. That's partly because people want their problems to be resolved right away, and they're becoming more and more comfortable with the idea that if your initial interaction, if it's with like a bot or something like that, is actually likely overall to be a more efficient way of getting your issue resolved.
Because a bot might say, "It sounds like you might be having one of these three problems." And then you go, "Ah ha, it's that one." And then if that doesn't work, then you contact a person. We use something called Intercom, which I'm guessing you might be familiar with, where people can like - if you see a little bubble on the bottom right of a web page for a service, and you can type a message there, that's probably something like Intercom.
What it will do is, it makes it easy for you to turn your responses to people's questions into articles. So when people ask questions in the future, it can serve them up, "Is this article helpful?" And then you can see if they interacted with it. It's really brilliant.
I was wondering if, in your experience, with documentation - do you think that things like automation are going to be making a big difference going forward?
Michael: I think so. So when you asked the question, my first thought was, "Automating docs is really hard and dangerous and usually bad," in the sense of writing the initial doc. But what you're describing here is if the automated system can't resolve the problem, it doesn't have the context required to be able to give them the correct answer. It escalates to a human. The human comes up with an answer that is hopefully at least somewhat generalizable. And then after that, it's just available from then on.
Which is something we were pushing for at last job. We were talking about essentially building a super search across all of our different places for knowledge keeping, so that when you had a problem, you'd be able to introspect across this whole set of valuable data.
One of the things that we talk about a lot in engineering is that we tend to prefer sharing documentation verbally, over writing it down, which is good for the team to a certain extent, and terrible for absolutely everybody else. I think as we move forward you're going to see a lot more of those chat bots for answering questions and for resolving issues.
I think that's a good thing because that frees up your support engineers for the really hard, complicated, tangle-y problems, Because you're never going to get away from needing them. There will always be something that you haven't seen before. That's just a reality of software at this point.
But it's the same thing as the rest of automation. My opinion is that automation doesn't end jobs, it sets you up to do more interesting work. If you're currently spending 70% of your time doing something - you're answering the same question on seven out of ten calls - then that's not a good use for your time. Because there could be a better thing that you could do with that, whether that's improving the service or that's taking time to call back customers and check up on them and see how they're doing, or whatever makes sense in your context.
Len: Before moving on to talk a little bit about the PowerShell Conference Book that you were involved with, and then of course your course, I wanted to talk to you about another type of documentation you're involved with, which is for a tabletop role playing game you've got called Pentola.
I was looking at the documentation, and it's a really interesting exercise just reading it, but it must have been fascinating to write. I wanted to ask you - for those listening, this is going to be a very, very geeky moment - but in your game Pentola, can you explain a little bit about what it is?
Michael: Sure. Pentola is a tabletop roleplay game. Probably the closest thing that people are going to be familiar with on this podcast is Dungeons & Dragons. It's in a similar vein, but it's descended from a cousin, which would be RuneQuest - for those of you who are super geeky. It was much more popular in the UK than it ever was in the US.
It's a tabletop role playing game. The very, very loosest idea is that you get a character concept somehow. You get together with a couple of friends, and then situations are presented to you and then those situations - you are free to act however you want, and the person running the game takes the role of the world and the NPC's [non-player characters - eds.] in this traditional style of play.
What it affords you, if you've ever played like a video game role playing, and you've been frustrated with dialogue options - for example, if you've been like, "I wouldn't say any of these things." In a tabletop game you can say whatever it is that you feel the character should say, and it allows you to examine different situations, different ideas - and play through those in what I think of is a reasonably safe space.
Len: I think when I was reading some of your tweets on on Twitter, I saw that you have an interest in world building, which is obvious given that you've created a game.
I've got to confess that although I knew about the idea, I actually hadn't heard the term "world building," until I listened to, and this is now not geeky, this is I guess nerdy - I was listening to an Ezra Klein interview with the fantasy author and N.K. Jemisin, where she took him through the process of building a world.
She talked, and I'm not sort of trying to be cheeky here, I didn't really put it together, that in the science fiction or fantasy world building exercise, actually you have to do a lot of documentation, in case your characters end up in situations - you want to have thought through the physics of the world and the social structure of the world, and the politics of the world and other things.
Did you have a process for world building that you engaged in when you were developing Pentola?
Michael: Actually Pentola is a very loose descendant of a home game that's been going on for a long time, where I'd bounced in and out of it. This is like the seventh version of the rule system, or excuse me, eighth.
The way we actually generated this iteration was there's another game by Ben Robbins, I think the handle might be Lame Mage Productions - anyway, they make a game called Microscope. Microscope is a multiple player fractal timeline world building game thing, where you set a hard start point and a hard endpoint. And then from there on, you can add periods of instant scenes and super, super briefly, periods - big chunks of time. Events are smaller chunks of time. And then the scenes are exactly what they sound like, a scene within a particular event.
If we were looking at like recent American history, you might have the period of Obama's first term and Obama's second term - and then an event inside of those might have been the election. Then a scene might have been a campaign rally or something like that. You could do that in fantasy, whatever the setting - it doesn't matter.
What you do is you go around and you take turns, and each person can add a period event or a scene and you set focuses. What it allows you to do is collaboratively build up context for whatever this this idea that you want to explore is.
What we decided to do is to do this before we played a game. You set restrictions. These are things that you can never bring into the game, even if they make sense. And then you set, "Yes please's," essentially - which is, you can always bring these in, even if they don't make any sense.
One of the things that we added to that board was flight by trebuchet. So there is now the ability for you to travel between neighborhoods, by getting in a wingsuit, getting nestled into a trebuchet, and then being launched into the air towards it. It's goofy, it's fun.
We did a lot of that together, and then I went off on my own and began to document some of the stuff. Because you have kind of a base layer, you've got some ideas, you've got like a skeleton to hang onto. Now you've got to go add intrigue. You've got to add interesting information and details that they don't know, so that they can uncover those during play.
They'll have a sort of through current that they understand. It gives them enough familiarity with the world. And now we're all working together to build out the rest that world, and make it something that is usable by humans who didn't sit in that Microscope game.
Len: That's just sounds really fascinating and really fun.
Moving on to talk about the PowerShell Conference Book. This was a good-cause book, in addition to being something very useful to people who read it at the same time.
Could you talk a little bit about what PowerShell is first, and then - for people who just mightn't have absolutely no idea about what it is - and then talk a little bit about the book project?
Michael: PowerShell is the glue language of automation for people in Windows-centric environments. Even past that, because now PowerShell's cross-platform.
PowerShell changed the way that you interacted with Windows. Windows has always been an API application programming interface first sort of operating system. Which meant that a lot of the time it was really hard to write custom scripts against.
There's probably some people who remember writing VB script, which is not a pleasant experience. Batch scripting's not a lot of fun either. PowerShell gave you access to everything that you had in developer land through .net. You could just load any library, and then use the objects and methods within it. What it allowed us to do was take all these disparate things that don't talk very well to each other, don't have like a lot of good interfaces with each other - and hook them up and go.
It has really changed the face of how we manage Windows systems now. More and more you'll see this on job applications, when they're looking for people - they want somebody who's a PowerShell expert, is what they always say. But they'll pretty much settle for somebody who knows what they're doing. It underlies a lot of the technology, a lot of the interactions. Pretty much all your configuration management on Windows is going to touch on PowerShell in some way.
Len: And what was the inspiration for the PowerShell Conference Book?
Michael: The inspiration there was that there were definitely some folks who didn't get to speak at the PowerShell Conference, and there were some folks who did. Mike Robbins wanted to raise money for the OnRamp scholarship, which is through the DevOps Collective.
The OnRamp Scholarship provides travel, food, hotel, training, mentorship and networking opportunities for folks who are getting into IT operations specifically. There's lots and lots of similar programs for folks who want to go in and start being a developer, or who want to start doing testing or something similar - but there's very, very few of these for operations. Most people fall into operations, that's their path there.
What they wanted to do was say, "Okay, we have this body of knowledge, we have this body of expertise. What we want to do is help somebody jump-start their career. Give them this opportunity to get some full eight hours a day training, and then in the evening, network with all of these experts and professionals in the field, who are speaking at these events, who are running user groups etc. And then at the same time, also set them up with some mentors who can help them out during, before, and after the event - and hopefully they'll be that new set of people.
When I say, "New to IT," I don't mean just 18 year old kids coming in. I mean also people who are transitioning. So, if you used to play music and you want to do this now, like for some reason you've decided IT's more interesting than playing music for money - it's normally the other way around.
Len: Or a major in Russian and philosophy.
Michael: Yes. If you want to switch into the career, that makes sense. If you have been out of work for a couple of years and you want to get into it, that makes sense. Several of those scholarships are also earmarked for underrepresented folks, because that's also a problem in the community. It's systemic, it's everywhere - and it's more inexcusable year over year.
So Mike took a look at this and saw how many scholarships there were and said, "Hmm, I think there should be more." And so he reached out to Don Jones and the folks at the DevOps Collective, and said, "What if we wrote a book that would donate all the sales to the--?" Because I think at the time he'd already known about the Leanpub causes, and that you could essentially give away your royalties to a charitable organization.
So they said, "That sounds like a good idea." And then the way that Mike spun it out was, "Okay, I'm going to get as many PowerShell community folks together as I can who are capable of writing a chapter." The genesis for it was, "Okay, write a chapter as if it was a PowerShell talk."
There's a lot of people who cannot attend these summits. They're either out of reach, because they can't get off work, or they can't get approval to go, or they don't have the money, or the tickets sold out.
We said, "Let's write a chapter as if it's a talk, and then you'll get however many talks out of that." We ended up with - I think, 31 or so, individual, discrete chapters that cover something deep-level for PowerShell, that you could sink your teeth into.
It's spread across everything from, "How do I do chat operations? How do we interact with cloud resources? How do I troubleshoot things? What I do about documentation?" All those types of topics, written by experts on them. And then all the royalties, again, go to the scholarship.
Len: That's fantastic. Do you know how many scholarships it's funded so far? It's been a very big success.
Michael: Yes it has. It has fully funded three separate scholarships. Each scholarship was about, I think, $4000? So it's fully funded three. And we didn't quite get to a fourth one before the deadline for this year. But all the money that the book made up to this point, and all the money that it makes going forward - still goes straight to that scholarship fund. I just got tapped today to work on volume two. So we're going to do that probably after the summit in April.
Len: That's great to hear.
Moving on to your course. You've got a course called pwshop: A PowerShell 101 Workshop.
Just setting the background here before we talk about it specifically = I think this is the 100th interview we've done for this podcast, and it just so happens as we enter into this new century, that you're the very first person we're interviewing primarily as a course author, rather than a book author.
The reason this is happening, is that it's only recently that Leanpub launched the ability to make online courses, in addition to making books.
So, I'm really excited to talk to you about your experience doing that, being one of the very first people to use our new courses feature.
As I'm sure you know, at Leanpub we believe very deeply in the customer development process, which means talking to creators in order to improve things for them and for everybody going forward, and this is one of the reasons Leanpub is - when it's working well, is as smooth and as powerful as it is now - it's because of years of talking to people online, but also on this podcast. So I'm really excited to start this new journey here.
My first question is - why did you decide to choose Leanpub as the platform for this course?
Michael: I want to make one real quick detour, which is that I should have mentioned that I was a contributing editor to the PowerShell Conference book, as well as an author. I only wrote one chapter. But then the other two editors are Mike Robbins and Jeff Hicks, and they definitely deserve credit for doing the lion's share of that work.
Len: Got it, I should have mentioned that myself, sorry.
Michael: No, that's my fault. They're my friends, I should've remembered.
The reason that I picked Leanpub for the course is, I didn't actually intend to do the course at all initially. I figured I would write a book, and then put it on there. And I saw that there was a course option - "Go ahead and create a course." I was like, "Okay, well I just did this workshop at [?] in San Francisco in October."
So I said, "Well, I've already done a bunch of this work. I wonder if I can convert it into a book format?" When I saw the course, and then I looked into the course a little bit, and I saw that you had the option do exercises and quizzes, I thought, "My thing's built around exercises, that seems like a better fit." I took a look and it seemed like the right sort of thing to do.
And then I just started writing it and putting it out there. I had no idea that it was relatively new at the time. I justI was, "Oh, this is an available option to me, I'm going to go with this."
The other reason was that I write almost exclusively in Markdown. So I had to learn Markua for this.
But it's still plain text, and I'm still able to use my normal workflow, which is to make an edit or whatever, and then commit it, push it, review it - and then merge it when I'm happy.
My workflow is exactly the same as it was before, but now I'm also able to do it in a way that it's going to get me money back. Which is not the most important part. The most important part was that I don't have to do all the evangelism to find the thing, There is a place that people can go to find the store and they're going to see that there and be able to grab onto it.
My goal is to help as many folks as I can with it, which is why it's been going as fast as it has been. I want to get it up there and get it available for people.
Len: You mentioned Markua there. Just to explain to people listening - going back a further step for those who might not know what Markdown is.
Markdown is a way of writing in plai ntext. You write in a text editor that's not wrapping what you type in all kinds of code - like software like Microsoft Word would do.
Basically, any computer in the world knows what an "a" means in a plain text editor, whereas it might not in different types of writing software like Microsoft Word.
What Markdown was invented for, was a way of writing in plain text and creating web pages. So the idea is that if you want to make something a link, you put the thing that people are going to see in between square brackets, and then afterwards in parentheses, you put the actual destination - so, the web page where the person's going to go. This allows you to write out a link without needing to do any any sort of fancy formatting or anything, without having to have some software do anything for you.
You just actually type out the instructions, and if you want a word to be italic, you put an asterisk before it and an asterisk after it.
People often think that these kinds of things are very high tech and new, but actually this is an old thing.
For example, the reason you had underlining on a typewriter was not to indicate that something should be underlined, it was to indicate that something should be in italics. That was an old form of markup, and Markdown was meant to allow you to write web pages easily, with shortcuts basically, in plain text.
For many years we've had something - we took Markdown, and made something called "Leanpub-Flavored Markdown." Basically, the idea was that, the same way you use Markdown as a standard for making web pages, you would use Leanpub-Flavored Markdown as a standard for making books.
And then eventually my co-founder, Peter Armstrong, decided to write a brand new thing called Markua, which expanded to be a way of not just writing books, but also of writing courses. So, in the same way that Markdown is for writing web pages and conventional Leanpub-Flavored Markdown was for books, Markua's for both books and a spec for writing courses in plain text as well.
We're really excited. We've been planning this for so long, and we we're working actually with a team at Johns Hopkins University on constructing our courses feature over the last quite a quite a while. So it's actually quite robust, now that it's out.
Now with that long explanation over, I wanted to ask, did you find Markua easy to use when it came to the course content?
Michael: Yeah absolutely. It's easy, it's very well documented. I use the Markua spec information to work through that. I didn't have any real problems with it. It has lots and lots of similarities to Markdown. So there's a lot of familiarity, muscle memory there.
The only real complaint I had was that my text editor doesn't do syntax highlighting for me, because it's in a .txt file. Which is not a huge deal, it was just one of those things that I was so used to seeing. And so for the first time I was back to having plain text, that didn't have any any sort of syntax highlighting for me.
For those of you listening, what that will do, is if I have the text that indicates italics, my editor actually italicizes it visually for me. It lets me know that I've done the right thing. Or if I have a header, it'll make it a different color. So I lost out on that, but otherwise the editing experience was completely as I would've expected it to be, what I would've wanted from it.
I didn't run into anything where I was like, "That's dumb, I don't like the way that this works." Every time I was like, "This thing isn't doing what I need it to do," I would go look at the documentation and then see that, "Oh there it is, that's how I do it." And then try it, and then it worked and it was fine.
Len: That's fantastic to hear.
One really interesting thing about any any digital product that one's creating and selling online, is the issue of pricing. Leanpub gives people more opportunities, I would say, than most places do for pricing. We just let you update it instantly and change it whenever you want, which not everybody does. But also, another thing we do is we pay you an 80% royalty rate, which is higher than most other places, and lets you make some interesting choices.
But we also have variable pricing, which means you can set a minimum and a suggested price. Although this sounds very complicated, these are actually very powerful pools for content creators to use. I wanted to ask you what your approach has been to pricing so far?
Michael: I started the book with the suggested price as a minimum price of $4.99, which is as low as I can set it. And then I told everybody, "You can still get it for free, it's not finished, go ahead - if you grab a slider and you move it to the left, it'll go down to 'free,' and then you can grab it for free. If you don't have the money to pay for it, don't worry about that - just pick up a copy. You'll get all the updates for free, even if I set a minimum price later," which I think is a great feature.
But I had several people who, when I released it at $4.99, grabbed that slider - and instead of moving it to the left to make it free, moved it to the right - which confused me. I understand if you grab it and you just get it at the suggested price - mentally anyway, I was not prepared at all to see people move the slider to the right. Somebody moved the slider over to $20, and that's like four times what I said the price should be, what are you doing? Why are you doing this?
I like the variable pricing - if you think it's going to be worth more, or somebody's told you about it and you're excited about it and you want to make sure that that money gets reinvested in whatever, whether that be future projects or whatever from the author, you can go ahead and crank that slider over to the side.
We had that a lot with the PowerShell Conference Book - people who knew that they wanted to grab the book, they knew that all the money was going to go to a donation, so they would just crank it up to $100 to $120, and then go ahead and click submit anyway.
I got chewed out a little bit by a friend on Twitter when he saw my minimum price of $4.99, and he was like, "No, that needs to be $49.99. I promise that you're going to get more value out of it." And I was like, "I appreciate that, I'm going to tell people you said that." Plus it was on Twitter, so I could hit "retweet" and send it everybody.
I think it's so valuable to be able to set a suggested price, and to be able to have it go either way - either up or down. Because I think there's a lot of people who will just - not mindlessly, but they'll see it and they'll think, "Okay, that seems like a fair price." And they'll click it. Or they'll see it, and they think, "I don't have that money right now, I'm going to go ahead and drop it." Or they'll see it and think, "Okay, I already like the work I've seen this person do before, I'm going to go ahead and throw more at it."
The other thing I've been doing is slowly working it up to towards $10, which is what I was going to set the price at when it reached a hundred percent completion.
Len: Just to be clear to everybody. So what Mike's doing is very interesting. He's doing something a lot of Leanpub authors do with their books, which is increasing the minimum price for his book over time as it approaches completion.
Michael: In this case, I'm increasing the suggested price. I'm leaving the minimum price still at free. I will, at completion, move the minimum price to the minimum of five dollars. Part of the reason for that is that I have a voiceover actor who is doing narration for my chapters, and I want to make sure that he gets royalties for it and is able to get some sort of pay out for it. I don't want him to be in a position where it's like, "Hey it's free, you're never going to get money. Good luck. Thanks for hours and hours and hours of endless work trying to narrate a code book."
Len: Thanks for telling that story. That's so fascinating, because for almost 100 podcasts now, we've been telling people the story of people sliding to the right. That means choosing to pay more than they have to, when they could even choose to pay less. It's something that a lot of Leanpub authors have experienced over the years. And everybody's always surprised when it first happens, because we've been led by social convention to think that people are always going to try to get away with paying the least that they can for a product. This is something that's changed, I would say, in the last 20 years, not just in public perception, but in public behavior.
One of the reasons it happens is that individual creators can easily reach more people now. And so unlike in the past when you bought something, there was almost always a big intermediator - like between an author and a book sale was a publishing company, and a bookstore, and a wholesaler, and a truck, and all that stuff.
Now, on Leanpub, for example, when you choose what to pay, we actually have a little pricing slider that shows you what the author earns. And so one thing people do is they'll actually slide that around to get it to, "I want the author to get 10 bucks from this sale."
Another really interesting phenomenon when it comes to pricing, and this I think is going to apply to courses more than it has in the past to books, is that, as your friend pointed out, courses are conventionally understood to go for the tens of dollars or even more, unlike ebooks, or even books generally; most books, people want them to be worth less than courses.
We've actually got a course set on Leanpub where the suggested price is $300, and the minimum price is free. We are seeing purchases in the hundreds of dollars for it.
One of the reasons for this mysterious activity is that, often when people are doing corporate training, they feel a requirement to buy rather than use something free. Because something free seems less legitimate. And if you're putting in your professional development hours - the more legitimate that things look, the better.
At the same time there's this curious effect, that I think Patrick McKenzie has talked about for years ago now, where - you hear about this in enterprise sales situations, where people trying to sell a product into an enterprise. Which is, that it's a version of the sort of more expensive wine tastes better effect. Where, if you're pitching to some executives - "I want to get our our crack team on this training course, it's going to cost 99 cents." That manager would like be, "We're not the 99 cent team. The rival team across the hall, they've got a $1,000 course that they're taking."
Anyway, there's lots at play when you're a content creator and you're trying to decide how to price things.
Michael: I think one of the other interesting things too is that Leanpub is a very good tool, I think for a safe way for an author or a content creator to build credibility while they're working on other things. So if you check out a book that I that somebody's involved in, and it was good and it was high quality - and then they publish a course, you're very much more likely - because there's almost a more personal sort of interaction between these, because I think most authors on Leanpub are fairly accessible. And again, there's no real middleman between us.
There's a platform and there's a service that we the authors are all taking advantage of. But from the perspective of the user, they go to the store front and they order the thing and then they email a question or whatever. And then the author gets back to them, It's a very different experience, and I think that has a lot to do with how people are going to pursue content going forward. I think you're going to see more of that over time. Or at least I hope so, because I think that's how you get better content. Better, more targeted for particular audiences that says the things that they need or gives them the things they need. I think it'll probably be the same for courses too. But I don't think we've seen anybody explore that space that way.
Len: I think that's right. Thanks for confirming that. For years, the Leanpub mantra has been, "If you publish while you're writing your book, that gives you an opportunity to improve it, based on feedback from early adopter readers, who are going to be the ones who are most committed to your book's success, because they need it. That's why they're reading it before it's done." We were really hoping to see the same thing would happen with courses.
I actually saw on the forum for your course, there's already been some activity with people giving you feedback - and I think on Twitter as well?
Michael: Yes, I get a fair amount of feedback via Twitter and via email. So far almost all the feedback has been around the getting started process. The on ramp. Very little of it has been like, "Hey, this exercise didn't work for me," or anything like that.
So it seems like until I get evidence to the contrary, once they start getting into the exercises, everything works well for them. But there are those rough patches, which also tells me where to go back and zero in.
The reason that I've been trying to get the content out the door first in this case, is because it'll involve some technical rewrite stuff around set up - because that stuff I can get out fairly quickly. Once it's time for me to rework the underpinnings, that I'm suggesting that you use for the course, that means that as soon as I do that I have to go through and test everything anyway, whether or not it's already ready to publish or not,
I want to be careful before I make that change. Because what I have now - a very quick detour. The thing I have now is "deprecated," but it's deprecated in the sense of a thing that will go away in five years, not a thing that'll go away in five weeks. And so I was like, "Yes, I should move off of that. You're absolutely right." And I will do that, but I want to make sure that when I do it, I do it in a way that won't break anybody who's currently working on the project. I don't want anybody who's got a course in-flight to end up in a state where they cannot finish the course, or where the course no longer accurately reflects what they're expecting.
Len: That's really interesting. That made me think that a useful feature might be - we've conventionally got all kinds of information you can add, little boxes you could fill out as a creator, "About the book," "About the course," subtitle - things like that. It could be that creating an actual feature, where it's something like, "How to take this course."
Of course, any course author could just create a section at the beginning of their course and call it that. But if we actually create a feature, that might help prompt people to do that. Because every course is going to be a little bit different. Every course creator is going to be interacting directly with their students. And so they're going to know better what these sort of particular things are, that need to be explained for that particular course.
I'm going to add that to the queue of things for us to consider building.
Michael: Sorry, I keep adding things to that queue for you.
Len: Oh well no, that's fine actually. The background on that is that Mike has sent us an email or two with suggestions for things to do, and where there have been bugs and things like that, and we've really appreciated it.
On that note actually, my last question is - apart from all the things that you've mentioned to us already, imagine all of Markua was completed and everything that we've set out there was working, what feature could we build? Can you think of any sort of dream feature that we could build that occurred to you while you were writing it?
Michael: One thing. This is outside of Markua, and this might actually not necessarily be a dream feature. But right now, in order to review the quiz results - once I get all exercises and quizzes together, I can't review like an individual quiz-take in the UI, I have to download the data and then parse the data and look at it myself and understand what happened.
That would be useful for me, is that I could go to a particular student, preferably anonymized, and then look through what they submitted. Those kinds of things. Or the option for them during an exercise to mark - like especially an exercise, possibly a quiz, but especially an exercise - mark the exercise question as, "I don't understand this," or, "This isn't clear." Or, "This doesn't make sense," or something like that.
Because I think in a lot of cases, what people will do with exercises, is that they'll try to answer it. And they'll get the wrong answer, and it'll show them the answers. They'll say, "Oh okay, that's the answer," and then just type that in and go. Whereas if there was like some sort of mechanism for them to like give feedback, like, "This didn't make sense," that might be a feature that you could toggle off and on as an author, rather than something that you would leave on permanently. Like if your course has been finished for three years, you probably don't want to hear as much about it - or maybe you do?
Len: That's that's a really great suggestion - including the toggling it on and off. One of the reasons I say that is we are going to start trying to get universities to use Leanpub, not only as a platform for MOOCs that their professors can create, but also as a platform that they can use to provide courses to their students.
Probably universities wouldn't want students giving like, "This was an annoying question," feedback on stuff - directly, in that case anyway.
I should also mention in that context, that currently when a course creator downloads the data of the results from people's taking of the courses, all the information is anonymized.
I don't think we ever plan to change that for people who are Leanpub authors or course creators. However, if someone's a university professor and they've got an online course being provided to students in the university, then everybody would be throwing their tuition money away if it were all and anonymized. So, in that very particular sort of behind a big paywall case, there might be non-anonymized information. But it is something we'll consider. I mean, if we discover that students are often, at least for particular kinds of course, saying, "Hey, I would love the course author to be able to communicate with me and know who I am and provide me with feedback and help me out just like a teacher would," then we might consider building something like that, but it would 100% be opt in.
Michael: Two quick questions. The first is that you mentioned a MOOC, which I don't think we defined yet. So maybe that'd be useful.
Len: Yes. Massive open online course. The big platforms for this would be something like Coursera or edX. Where, anybody anywhere in the world can sign up and read some material, and then take a course. Which basically means doing some quizzes and answering some different types of questions, from multiple choice to fill in the blank, to even essay questions, in some cases. These courses are called "massive," because they can sometimes have millions of students, which brings all kinds of really interesting scaling issues with it.
Tt gives anybody in the world who's got some piece of knowledge, the opportunity to set it out there for everyone else in the world.
The conventions around MOOCs have changed - they really started becoming a big thing only about 10 years ago, and the conventions have always been changing. One convention is that you can often take a course for free, but if you want to get the digital certificate that comes with it and, say, a badge on your user profile on the website or something like that, then you often have to pay. So, if you want the official credit, then you pay for this. Leanpub actually does have certificate options for MOOC's, so that anyone who's considering creating one, can do that.
Michael: The second question I had was particularly about that that feature for sending feedback. As an author, I'm 100% okay if they know that the feedback always comes from me, and I have no idea who they are. That's fine with me, if it's anonymized back-and-forth messaging somehow, like I send them the email, and then they can reply, and it's between like an automated list or whatever - that's 100% okay with me. I don't need to know who they are. It might help me if I do, but certainly I would never want it to be anything but opt-in. I'd be fine as an author with it being anonymous, because I think a lot of people can probably take criticism a little bit more easily if they know it's anonymized, and then it doesn't feel personal at all. So I think that would be a totally reasonable like step.
Len: Okay, great. Well, thank you very much for telling us a bit about your storym and about your approach to documentation and restorative justice and your game, and the PowerShell Conference Book, and that success - and your course as well. I wish you all the best of success with it, and hope to get more emails from you with feedback.
Michael: So many emails.
Len: Thanks very much.
Michael: Thank you so much for having me on.
[After the interview, Michael mentioned his voice actor's name is Chris Allen, and he can be found at @OpeSounds on Twitter. Also, Warren Frame (@pscookiemonster on Twitter) is the other cohost/founder/organizer of the PSPowerHour, and Ken Maglio (@kenmaglio on Twitter) is the co-organizer of the St. Louis PowerShell User group - eds.]