The Leanpub Blog: On Writing, Publishing, Self-Publishing and Ebooks
published Oct 05, 2016
Scott and I launched Leanpub back in April 2010, with the goal of creating the best way in the world to write, publish and sell in-progress and completed ebooks. Our first customer was this up-and-coming guy named Eric Ries, who was advocating a strange idea called “The Lean Startup”. We made a Leanpub book out of Eric’s blog. This led to our second customer, Babak Nivi, who let us make a similar book out of his and Naval Ravikant’s blog, Venture Hacks. Eric, of course, went on to write The Lean Startup, and Naval and Nivi created this small thing called AngelList.
Eric wasn’t just our first customer, he was also the reason for the name Leanpub. After my experiences writing two books, I realized that Eric’s Lean Startup principles had great applicability to the way that authors should write and publish books – that as an author, you should publish your book in-progress, using lightweight tools and many iterations to get reader feedback, pivot until you have the right book and build traction once you do. I called this approach Lean Publishing, wrote a manifesto and book about it, and talked about it wherever I could. Leanpub was a reference to the idea of Lean Publishing – and if you wanted to do Lean Publishing, then Leanpub should be your obvious choice.
Leanpub’s positioning and our traction from the launches of Eric’s and Nivi’s books helped us gain an initial customer base with agile and computer programming book authors. It helped that these authors were highly technical – since our books were authored in Markdown, our user interface was terrible and our book generation was flaky, to get past all these hurdles and actually finish a book it really helped if you were a computer programmer.
Since these humble beginnings, we’ve grown steadily, and today thousands of authors from around the world use Leanpub to publish early and publish often. We’ve paid over $4.4 million in royalties to authors, and we currently pay over $100K in royalties to authors every month.
Leanpub is a powerful platform for serious authors. This platform is the combination of two things: a publishing workflow and a storefront. Leanpub is more than the sum of its parts, however – by combining a simple, elegant writing and publishing workflow with a store focused on selling in-progress ebooks, it’s something different. Leanpub is a magical typewriter for authors: just write in plain text, and to publish your ebook, just click a button. (You can click a Preview button first if you want!) Once you’ve clicked the Publish button, anyone in the world can instantly buy your ebook from Leanpub, and read it on their computer, tablet, phone or ebook reader. Whenever you want to distribute an update to all your readers, just click the Publish button again. It really is that easy.
Our workflow is flexible. Authors can use our simple in-browser editor or upload completed ebook files, but most choose to write their manuscripts on their own computers, using either plain text (formatted using Markdown or Markua markup) or Word documents. These manuscripts are synced with Leanpub using either Dropbox, GitHub or Bitbucket. From these manuscripts, we generate ebooks formatted in PDF, EPUB and MOBI which look great on all devices. This is a fully-automated process: authors literally just click a button. We also automatically generate print-ready PDF and InDesign files, so that authors can easily create and sell print books on sites like Lulu or CreateSpace. (The InDesign files are for a book designer to make a custom book, but the print-ready PDF files are exactly that: ready to be published as a print book.)
Our storefront is an elegant way to sell in-progress or completed ebooks. There are lots of good places to sell completed ebooks, such as Leanpub, Amazon or Apple, but the Leanpub storefront is the best place to sell in-progress ebooks. It includes attractive book landing pages, variable pricing with minimum and suggested prices, analytics and mailing list integrations. Our variable pricing feature alone earns many of our authors thousands of dollars of extra money. Just as people love backing projects on Kickstarter, readers love supporting authors – and our pricing sliders which show the author royalties make it clear to readers how buying a book on Leanpub does just that. Readers often voluntarily pay much more than the minimum price of a Leanpub book. In fact, our bestselling book by lifetime revenue, R Programming for Data Science, has a free minimum price!
One of the most interesting features of the Leanpub storefront is the royalty rate our authors earn: 90% minus 50 cents royalties per paid sale; free for free sales. On Leanpub, a $10 ebook sale earns $8.50 in royalties, and a $20 ebook sale earns $17.50 in royalties. Respectively, those royalty percentages are 85% and 87.5%, which we’re very proud of. By the way, in case you think those ebook prices are higher than what Amazon “encourages” you to charge, or what you hear from publishing industry commentators, you’re right: the average paid ebook sale price on Leanpub is over $14. Now, a $14 ebook sale earns $12.10 in royalties on Leanpub, but would only earn $4.90 on Amazon KDP – while Amazon KDP essentially pays 70% royalties for books between $2.99 and $9.99, it only pays a 35% royalty rate for books which cost less than $2.99 or which cost more than $9.99. Many books on Leanpub cost more than $9.99, so Leanpub authors earn a far better royalty percentage on those books than they would on Amazon KDP.
Our royalty rate is better than Amazon’s and Apple’s royalty rates for any book over $2.99, and it is far better than Amazon’s royalty rate for books over $10. Leanpub exists to support authors, and our royalty rate does just that – regardless of what minimum and suggested prices an author chooses for their book. Since we adopted this royalty rate in 2010 we haven’t changed it, and we are not changing it now.
Today we are changing the pricing of Leanpub. Until now, Leanpub has been totally free for authors to use. We have earned all of our money from our portion of the storefront revenue. (After the author royalties, PayPal fees and chargeback costs, our gross margin on the storefront is about 8% – for every $100 of book sales on Leanpub, we earn about $8.)
Going forward, it will cost money to create a new Leanpub book. Here’s the cost:
$99 per book.
That’s it. This is a one-time charge, not a subscription. This price includes all the features of Leanpub, and is the price regardless of what writing mode you choose. We are charging the $99 at book creation. Like any Leanpub purchase, it will have our 100% Happiness Guarantee: for 45 days, you can get a full refund by clicking a button. (Refunding a book writing purchase deletes the book if it has no sales, and archives it if it has sales.)
Leanpub authors have created tens of thousands of books. We are, of course, grandfathering every one of these books: they will have all the features of Leanpub, for free.
For new books, there are discounts available based on lifetime royalties earned. There are also special discounts for translations.
We want to reward loyal authors who support Leanpub through their storefront sales. So, we have two discounts based on lifetime royalties earned across all your Leanpub books. Once you’ve earned at least $1,000 in royalties, creating a new book costs $49 per book. Once you’ve earned at least $10,000 in royalties, creating a new book is free. Hundreds of Leanpub authors will immediately qualify for one of these discounts, and we hope thousands more do in future.
Authors can create translations of their Leanpub books for $19 per book. Some Leanpub books are translated into a large number of languages, and at $99 each this would add up fast. (Of course, if you’ve earned at least $10,000 in lifetime royalties, creating a translation is free.)
To be clear, regardless of what you pay (even $0) to create a Leanpub book, this one time charge includes all the features of the Leanpub workflow and storefront. For example, there is no charge to create packages or bundles. (Packages let you sell extras with your book, like videos or code samples. Bundles let you sell your book bundled with other Leanpub books, at a discounted price.)
Again, the royalty rate for authors is unchanged: 90% minus 50 cents royalties per paid sale; free for free sales.
If you’re a publishing company, our publisher program just got a lot simpler. For any new book created by a publisher the price is now $99 per book. Our publisher program helps forward-thinking publishers like TidBITS Publishing easily produce dozens of professional ebooks using Leanpub’s simple, proven workflow. Publishers own their ebooks and can sell them wherever they wish. If a publisher chooses to use the Leanpub storefront, we pay 90% minus 50 cents in revenue per paid sale. Using Leanpub for ebook production is a pragmatic choice, like using a third-party printing press for print book production or using AWS for web hosting.
Why We’re Doing This
We haven’t changed our pricing since 2010, so we’re not making this change lightly. We have thought really hard about this. This pricing change will help us address a number of the challenges we have been facing:
First, where we were earning our money and where we were creating much of our value were different places.
Leanpub is the combination of a publishing workflow and a storefront. We have put years of work into the workflow, and it creates much of the value we provide an author. We were giving away the workflow to drive author growth, but this was only being monetized by the storefront. Now, when we were working on storefront features, there was an immediate connection to increased revenue – for example, adding a shopping cart helped us sell more books. However, when we were working on workflow features, there was a huge delay between a workflow improvement and increased storefront revenue. We have a viral loop, but it takes a lot longer to write a book than a tweet! By making our workflow a source of revenue, and not just the main reason that authors use our storefront, improvements to the workflow will also have an immediate connection to increased revenue.
Second, we’re a bootstrapped startup, so cash flow actually matters.
Leanpub has raised exactly $0 in investment. We’re based in BC, Canada, and while startup funding climate in BC is improving, it’s not exactly Silicon Valley. Since we’re bootstrapped, work on the startup is fueled by revenue from either the startup itself or from us doing consulting work for clients. So, the timing of revenue matters. For Leanpub, a successful book will earn a lot of money over its lifetime in our storefront. Almost all of this revenue is for its author(s), as it should be. But some of it (about 8%) is for us as well. However, we can only spend our portion of that revenue once we actually have earned it, and much of this is deferred for months or years. By charging money when a book is created, we can spend that money on development or marketing as soon as its 45-day refund period elapses. This means we get our first $99 of revenue from a book months, or years, sooner than we do today. (Currently we don’t earn $99 from a book until it has been published and earned about $1200 in sales.)
Third, our pricing didn’t work well for authors who only want to sell their books directly.
Since we have created an amazing book writing and production workflow, some authors naturally wanted to use Leanpub to make books, while only selling those books on their own websites. This is perfectly legitimate. There are some good reasons to want to own the customer relationship. Some authors put a lot of work into developing an entire range of products, of which their books are only one component. For these authors, a purchase directly from their website is more valuable to them than a purchase on Leanpub, Amazon or Apple. For example, when an author sells a book on their own website, they can require the reader to share their email address. With Leanpub, readers need to opt in to share their email address with the author.
We need to support these authors. Leanpub authors own the copyright to their work, and are free to sell it wherever they want. Just as we value reader privacy, we value author control. However, the current situation was sub-optimal. For us, not only did we earn no money from those books, there was a support cost as well. For the author, they were stuck doing cheesy things like only previewing their book, and putting it in stealth mode so it didn’t show up in our store. Worse, there was a feeling of guilt: we’ve had multiple authors ask us to invoice them for our services, which is a hassle for both us and them. Charging money on book creation makes using Leanpub just for our workflow a guilt-free transaction for these authors: they’re not freeloaders, they’re customers.
Fourth, our pricing didn’t work well for publishers.
Just as some authors want to only sell their books directly from their own websites, many publishers want to do this as well. With our previous pricing, we used to make publishers choose when they created a book whether they wanted to use the Leanpub storefront. If they did, the book was free; if they didn’t, the book cost $299 to create. We had good intentions here, but basing a pricing plan on punishing honesty is a bad design choice. Making the price be $99 per book for every book created by a publisher is both simpler and fairer.
Fifth, books which did not earn a lot of revenue were costly for us to support.
We are genuinely helpful people who enjoy building tools to help authors write books. We also sincerely try to provide good customer support via email to email@example.com, via Intercom, and via our Google Group. There are many reasons to write a book, and direct compensation from author royalties is only one of them. But since the only way we earned money was from a percentage of a book’s storefront revenue, providing good customer support was problematic. With this pricing change, we earn money from every book, right when it is created. This will help us pay our support people, so that we can help any new Leanpub author to get started using Leanpub.
We thought really hard about this pricing change, and considered many alternatives. One thing we really don’t want to do is charge a monthly or yearly subscription fee per book. Books take a long time to write, and when you’re starting a book it’s hard to predict when you’ll finish. We don’t want authors to feel that they’re on a clock, or that they can lose access to their book once they’ve started it. We also want to keep things simple. Authors shouldn’t feel that they need a doctorate in Leanpub to understand what it costs.
This is really important to us. If we price Leanpub fairly, and if we can convince enough people to pay this fair price, then we can earn the revenue needed to go much faster than we have to date. We can build all the features we want to build, for both the author and the reader experience, much sooner. We can even spend money on marketing, helping the entire flywheel turn faster – which will drive us to grow and develop features much faster than we have in the past. If you’re a member of our Google Group, you’ll definitely appreciate this. As an author, paying to create a Leanpub book is an investment, since we will be spending that money to improve your experience using Leanpub.
Scott, Len, Braden and I would like to thank every Leanpub author who has helped us build our platform over the past six years. Without you, there’s no Leanpub. Thank you very, very much. Our sincere hope is that this change to our pricing helps us go a lot faster in the years ahead.
October 5, 2016
published Oct 04, 2016
Don is an expert on Microsoft’s business technology platform and a popular conference speaker. A co-founder of The Dev Ops Collective, he is also the author of The DSC Book: Second Edition, which teaches “everything you need to know about Microsoft’s Desired State Configuration technology”.*
This interview was recorded on July 21, 2016.
This interview has been edited for conciseness and clarity.
Len: Hi, I’m Len Epp from Leanpub, and in this Leanpub podcast, I’ll be interviewing Don Jones. Don is a leading expert on Microsoft’s business technology platform, and a popular speaker at technology conferences, and he has received Microsoft’s Most Valuable Professional award since 2003. He co-founded The Dev Ops Collective and powershell.org, and is currently a curriculum director for Pluralsight, which offers online video training courses.
Don is a prolific author who has written over 40 books, including PowerShell in Depth and Learn Windows PowerShell in a Month of Lunches. Recently, he published his first book on Leanpub, I think - *The DSC Book: Second Edition. His book is focused on the topic of desired state configuration - or DSC, which we’ll be talking about a little bit later.
You can follow Don on Twitter @concentrateddon, and he blogs at donjones.com. In this interview, we’re going to talk about Don’s career, his professional interests, his book, and his experience self-publishing an in-progress book on Leanpub.
So thank you, Don, for being on the Leanpub podcast.
Don: Thank for having me. Good to be here.
Len: I usually like to start these interviews by asking people for their origin story. I’ve read a little bit about your story on you blog, and I was hoping you’d talk a little bit about how your career got started, and how you got to where you are now.
Don: Yeah, so I was working for a company called Electronics Boutique, which has since been purchased by GameStop. They’re a video game retailer. That was my first IT job. I worked in one of the stores for a while and wound up with a job at the home office in IT. I was an AS400 operator, but I’d always had a programming hobby background, and so it wasn’t too long before I was doing a lot more than just helping run the AS400. And from there, I’ve worked at companies like Bell Atlantic. I’ve worked for Microsoft training partners. I’ve been independent. I was independent for about 12 or 13 years, I guess.
I did a lot of consulting and a lot of work for different clients - all kinds of different stuff - and a lot of writing. That’s, I think, when I did probably the most writing, particularly in the long-form published books. Then a couple years ago I took a job as a curriculum director with Pluralsight, which kind of gives me an opportunity to reach out a little bit further than myself, and help work on large projects, and help other people becoming better trainers and reach people. So it’s been a lot of fun.
Len: I read on your blog that your first job was working on military jets, that you were a military jet mechanic? Is that right?
Don: I was a civilian employee for the Department of the Navy, for their depot-level maintenance which is when they pull the airplane all the way apart to nuts and bolts and rework the whole thing. The Navy guys don’t do it, just because it takes so long. By the time you’d finish it, your enlistment is up and you can get out. So I was a four-year apprentice, and worked on A6’s and F14’s.
Len: This is going to be a little bit left field, but it just occurred to me when I read that. As someone who used to work on those jets, I was wondering if you have any thoughts about the F15? (Note: Len meant the F35, not the venerable F15 - eds.). This controversial fighter jet that’s been developed over the past few years - and has run into so many hurdles, but may have jumped the last one recently.
Don: So the 15 has actually been in service for a long time. That’s an Air Force aircraft, and it’s kind of a contemporary of the 14 I worked on. I forget what the number is - I know that - think it’s the F32, or something like that? That’s the one they were going to develop one airplane for all four forces. And I don’t know. I’ll believe it when I see it. It’s a tall order, it’s tough to do that. You’re taking an aircraft that the Air Force wants to be able to fly and do their missions, which is great, and they have a lot of things - when they design an aircraft, they want to be able to change an engine in 20 minutes, and have all these metrics for how the airplane has to be serviceable, which is hugely important to their mission. The Navy on the other hand, basically wants it to be able to crash land on a floating postage stamp in the middle of the ocean - which is a totally different aircraft. Bigger landing gear, much bigger thing - maintenance is often harder. So it’s going to be really interesting to see if they can pull that off.
Len: When you say a postage stamp I assume you’re referring to the aircraft carrier, obviously. Did you ever have an opportunity to go on one of those?
Don: Yeah. Not for anything where they were in combat or anything like that, but as part of our apprenticeship, we got to go take a tour. I think it was the John F. Kennedy that we got to go on to, and see the airplanes that we were working on in real life and operation.
Len: That’s really fascinating to me.
Don: Yeah, they’re amazing machines.
Len: Two nuclear generators on some of the bigger ones, is that correct?
Len: And they’re powered for like 50 years or something like that?
Don: Oh yeah. They can go forever. I mean, they go out to sea for incredible lengths of time with their fleet that travels with them - six months, eight months is pretty common.
Len: Another totally from-another-direction question - you write on your blog about how you became attached to being independently employed, in spite of the uncertainty and the risk. And I was wondering if you could talk a little bit about what it was like to have that kind of independence? I assume you have quite a bit under Pluralsight now, as well. But I’m just curious about that dynamic - about being an independent consultant, versus being an employee.
Don: It’s tough. I mean, the upsides are - when you want to take off, you take off. So if you’ve got nothing going on on a random Tuesday afternoon, and you want to go see a movie - you’re free to do that. You don’t have to hang out and just put in your hours at the desk. So there’s a lot of upsides. If you work really, really hard, and you take on a lot of work, and you get it done well, you get to keep all that money. So it’s not like working for the man where you can really bust your butt and not necessarily come out any further ahead.
On the other hand, you’re the only one making the money. So you’re kind of constantly worried about, “Am I getting today’s job done? Am I marketing for tomorrow’s job? Am I making sure I’m lining stuff up?” You have to kind of get used to when your valleys and your peaks are so that - maybe you have to pile on really hard at a certain time of year, to cover a traditional slump at another time of year. And you have to be able to really manage your money. It’s not like living paycheck to paycheck, where you can spend this one because you know there’s going to be another one just like it in a couple of weeks. That’s rarely the case. The money tended to flow very, very, very unevenly. And so you have to really plan things out.
I enjoyed it a lot. You have to come to accept that you can’t ever be more than you are. So if you can produce a certain amount, you can get paid a certain amount for that - then that’s probably all you’re ever going to be able to do. You can optimize, create some efficiencies here and there a little bit, but only to a point. So if you’re the type of person who really wants to work on big stuff - bigger than one person can do, you wind up being with a company and a team.
And I’ve enjoyed both - the environment at Pluralsight really sets everybody up to be their own little entrepreneur. So you get that impact of working for a large team, but you still get to call your own shots within whatever it is that you’ve been trusted with. And that really, really fits my personality well. So it’s been a good match.
Len: And as a curriculum director at Pluralsight, what is it that you do? It sounds interesting.
Don: We have several curriculum directors that are on different branches of our library. I’m in charge of the stuff that applies to the IT operations crowd. So Windows server, SharePoint server, Linux servers, Windows clients - all that type of stuff. Not software development; that’s another whole chunk. And then we have another whole chunk that’s creative stuff. Your CAD/CAM software, your Adobe software, stuff like that.
So my job is to do research, plan our curriculum, decide what courses it is we should have - either to meet specific customer needs - or to make sure that we’re leading the customer, that we’re going to have the right training that they’re about to need, and maybe they don’t realize they need yet. And then I work with our acquisitions editors to recruit authors to produce those courses.
I work with our authors to get the proposals together, and get the courses outlined. And I work with our editorial and production teams to make sure that the courses eventually do get done and published in the right sequence. So it’s kind of a big coordination job. But I really, really enjoy instructional design - so it kind of fits into a little hobby thing that I’ve touched, on and off again for years.
Len: Speaking of instructional design, one of the topics that often comes up in the interviews that I do with Leanpub authors, and partly because I bring it up, is the - not necessarily the tension, but the relationship between the burgeoning field of online training and learning, and more conventional ways of learning and training. Like actually enrolling in a college or a university, and going there and taking courses. And I was wondering what your thoughts are on that? Do do you see online training replacing entirely some university degrees?
Don: I’d like it to. Particularly in the IT field, and particularly because I’m an American, and we have a particular situation and worldview around it. I don’t have a degree. As I mentioned, I graduated from an apprenticeship, so it was very vocational. I think there are colleges out there that do a fantastic job of preparing people for a job. In the US, it tends to be community colleges and vocational schools.
And they’re very lean, they’re very agile. They’re able to update their curriculum fairly frequently to keep pace with what the market demands. And a lot of times they’re only after you for a couple years. You’re after an associate’s degree or something like that. And a lot of employers, for entry level jobs, that’s what they want.
But we have a situation where kids are going and spending $30,000, $45,000 a year for a four-year degree - and they come out insanely in debt. They’re a couple hundred thousand dollars in debt. And they have a degree that is essentially useless in the marketplace, at least in the IT field. No one cares about it. “Okay great, you’ve got a degree. That means you essentially know nothing other than how to sit in a classroom for four years”. Well, that’s kind of an expensive way to be taught how to sit down for four years.
And it affects our economy, it affects it deeply. We have a lot of millennials who are in that situation, who are not buying homes, because they’re already under a crushing amount of debt, and the last thing they want to do is take on another 100 grand on a mortgage. And home buying is one of the things that deeply drives the fundamental core of our economy.
And so you create this whole situation where everybody feels like they have a degree - because everyone has a degree, it’s not special anymore. So you spent all this money getting something that’s not special whatsoever. It doesn’t differentiate you in the job marketplace. And in the process of doing that, we’re creating this horrible economic black hole that is eventually going to have to collapse in on itself.
So I would really like to see online training - whatever other types of training, particularly for jobs. Just completely replace that. At The DevOps Collective, we’ve put together an educational program that was designed to help someone get the skills they need to get an entry level job, say on a help desk, in a common IT organization. Now, that’s a job that, in the US, pays $35,000 to $45,000 a year. If you’re 19, 20 years old, that is kick-butt money for a first job. And IT tends to promote from within. So once you’ve got that job, you’re going to learn on the job and you’re going to get a $60,000 job, an $80,000 job - and eventually more.
So it’s an inexpensive program that someone can run themselves through. We don’t run it, we just kind of point to where you can go get it yourself, and we’ve laid out the curriculum. And I think over time - I hope that counselors at schools, and career advisers, will start to direct kids to some of these other options. If you want to be a doctor or a lawyer - yes please, go to a lot of school. Go to tons of school. But if you want to be an IT guy, it’s just not necessary. And I hate that we shove it down kids’ throats.
Len: And for those who aren’t familiar with the reasons, what do you think the reasons are that university education has become so expensive in the United States?
Don: Because they can. We live in a market economy, and if people are willing to go take a loan for 45 grand - and other people are willing to loan that money, then that’s how much the universities are going to charge. I mean, they’re going to literally charge as much as they can get away with. Particularly the private schools, and particularly the private career colleges - the University of Phoenix and things like that.
The public schools, the in-state schools, especially ones where you can get your in-state tuition - [they’re] financially [a] much better deal - community colleges. The problem is, those guys just - they’re academia. They’re designed to change at the rate of physics, which rarely changes. And they can’t keep up with really fast, quick changing dynamic fields like IT. So I mean, literally by the time you start - even if they have a brand new curriculum for you on your freshman year, by the time you graduate it’s useless. It’s all changed. And what they haven’t done is taught you how to keep up. And so it just doesn’t work out so well.
Len: One thing I’ve found out of a lot of the people that I interview who are Leanpub authors, and are in tech in some way or another, and I would say, probably at most half of the people I interview studied in school, what they ended up doing eventually in tech. And it seems that people have all sorts of paths to where they end up, and formal training and what they end up doing doesn’t really correlate.
Don: No, it doesn’t seem to.
Len: I wanted to ask you specifically about AR, and what you think the possibilities are in that space - augmented reality for online training.
Don: It’s hard to tell. It’s still something people are playing with. I look at the first video training that was available ten years ago, eight years ago, and you look at where we are now. Back then, it just wasn’t there. And everybody said, “This is going to be the new wave, and the new wave”. And eventually it was, but it took it a really long time, almost a decade. And people’s learning preferences and how your brain learns are really, really fickle. And the new shiny [thing] is not necessarily going to actually work for people’s brains.
I mean, there’s still tons of people out there, thank God, who buy books. They don’t want to go to a class because they don’t learn well that way. They want to be able to sit, read, play with, come back to it. And a book works for them. There’s other people who just hate to read books. So I look at new training modalities like that, and I worry a lot less about, “Is it cool? Can we do it?” And I worry a lot more about, “How does this actually serve someone’s learning needs? How does it fit the way someone’s brain is going to be put together?”
I’m sure there’s a lot of fields, like aircraft mechanic, where it would be fantastic to be able to sit down with a giant visor on your head, and actually work on a thing in virtual space. There’s probably a lot of mechanical, physical fields like that. You get into something like software coding, you could already sit down and do that right in front of you. You don’t necessarily need a honkin’ thing on your head. So if it’s applied well and to the right spaces, like everything else, “right tool for the right job”, I’m sure there’s probably a good future for it.
Len: I’ve seen one or two examples online where it seems like people are using AR to kind of replace training. Where essentially what you do is like you’re looking through these glasses with an overlay of video, or design of some kind. And it’s kind of just like telling you, like a little arrow like pointing at the distributor cap, “Pull this up”. And then it’ll point to your left and say, “In your tool box, there’s another distributor cap. Pick it up. Put it here”. Have you come across anything along those lines?
Don: Yeah, and I think it highlights the difference between training and teaching. I hate the word training. as it applies to anything I try and do. Trainers are for dolphins and dogs. And if all you’re doing is teaching someone to perform a repetitive set of tasks, then that’s fine. If you are the person being trained to do that, and it literally is as easy as someone saying, “Take the distributor cap and put it here”, you have to wonder how long it’s going to be before we just have a robot to do that and then we don’t need you anymore.
Teaching on the other hand is much, much higher level. It’s synthesis, it’s application. It’s helping people change the way they think. So that as a problem comes up, their brain is geared to deal with that problem. And - again - the modality doesn’t matter there, so long as you’re presenting the information in a way that makes sense to someone. But it’s always going to be really difficult to do that with any kind of rote, computer-based, just simulation-type thing, because a simulation can’t do anything really but train you. It might be a great supplement to teaching, but teaching is always still going to be a uniquely human endeavor.
Len: And you spoke earlier I think about course design. I was wondering if you could talk a little bit about that. When you’re designing a course, are you thinking about a certain type of student, or how to accommodate multiple types of students at the same time?
Don: We start with an audience design. I think that’s the most important thing. I view teaching as a story, and you have to know where your - your learner is the hero in your story. They’re the ones who are going on whatever path it is you’re taking them. And you’ve got to define exactly what that path starts as, and exactly how that path ends. Who are they at the beginning, and who are they going to be at the end? And so long as you know that, you can then start structuring a path that has as few distractions, as few gullies, as few hills as possible, and try and anticipate where those hills are, and pre-smooth those out by presenting the material in a sequence that leads them nicely up a slope instead of running them into a cliff that you then have to climb them over.
I think knowing who your learner is, who you want them to be, having reasonable expectations - if you’re trying to do a four hour course, you can only so much. And it might not be the last course they watch. But for this course, what’s the beginning and what’s the end?
And so we spend a lot of time working with the authors at Pluralsight on that. It’s something that I’ve done a lot in my books - “The Month of Lunches” series that I created that Manning Publishing runs, even in the DSC book I’m doing now. Even though it’s being produced roughly a chapter at a time - is when I tend to release updates. I had a plan for that from the outset. I knew what the path was.
Now, given that it’s lean publishing, I might be able to go back later and I might be able to take the skeleton path that I created in the first path, and then start filling in. Maybe some more examples. Maybe covering other scenarios that are a little divergent. So I can go flesh that out and make it a little fatter, but I’ve still got that path from the beginning to the end.
Len: I’d just like to ask you one more question before moving onto talking about your book and the way you’re publishing it, which is - you said the learner or student is on a journey. Do you set that - or do you encourage the course authors to set that up?
Len: End at the beginning. So you sort of set the stage for what the journey is in the first course?
Don: Yeah. And given that my audience is IT operations, we’re a very pragmatic people. We just want to make it work so we can go home. And so I try to have every course start out with a very clear, upfront motivation. “Hey, you know how it sucks when this happens? Well we’re going to learn how to fix that”. So that someone can immediately say, “Okay great, I can relate to that. I know the situation I’m in. I can start to impute some of the problems that are around the edges of this. And so I can get a feel for where we’re going, just with that one sentence. And yeah, that sets the stage for someone. That gives the learner an expectation. And the clearer you can make that, the more likely they are to be happy with the outcome.
Len: Yeah, that sounds really effective. Putting people in a situation where you’ve communicated to them, “Here’s where we want you to start, and where we want you to end. So you’re on a shared narrative.
On the subject of your book, I was wondering if you could explain a little bit about what DSC is, and who your intended audience is for the book?
Don: Yeah. Desired State Configuration is a part of Windows management framework. Which is what includes Windows PowerShell. So DSC actually builds on Window’s PowerShell. It’s kind of a high level part of PowerShell. And its idea is, if you’ve got a computer, maybe a server or a client computer, you tend to want it to be configured in a certain way. And the way we’ve approached that typically in the past is - maybe we’ll write a script, so we don’t have to manually configure the server.
When you set it up for that first time, you’re going to provision it somehow. And you get it the way you like it, and then you put it into production. And then invariably it starts to change. And so organizations spend a ton of time - and there’s management frameworks - COBIT, ITIL, all these other things that create - there’s huge processes around change management. So the idea is, you put something in place, it works. How do we make sure it never, ever changes - ever? So that, because - if we don’t change it, then it should always keep working the same way.
Desired state configuration is designed to kind of flip that on it’s head. You start with a computer and human-readable description of what you want the computer to look like. And then you hand that to the technology, and it builds the computer that way and then it makes sure it stays that way over time.
And if you change your mind - okay, well now we want the computer to look like this. You just change that document. And the technology goes in, and fixes it or alters it or whatever else - and then maintains it in that state. So it’s really kind of, not bleeding edge, but it’s definitely at the leading edge of where IT operational management has been for a couple of years. And this is Microsoft’s flavor of that.
Len: And how does it make sure things stay the same?
Don: It scans the machine every so often, and checks every single thing that you’ve said you want to be true - and makes sure that it is still true. And if it isn’t, then it’s got code underneath that remediates that and fixes it.
Len: You mentioned already that you’re publishing the book in-progress, and I wanted to ask you a few questions about your strategy around that. I think it’s something that other Leanpub authors, or potential Leanpub authors too, would be interested in hearing about. So you mentioned before I think - you had a pretty definite plan before you published for the first time.
Don: Oh yeah. I have a very detailed outline. Down to like second and third level headings. And that’s pretty common for me when I write a book. And I got in that habit for two reasons. One is that, with a traditional book, once you hand a chapter off to the publisher, it’s really kind of a pain in the neck and outside the process to change it. So you kinda have to know what the whole plan is. It’s not like you can get to chapter twelve and go, “Crap, I forgot to mention that back in chapter three”. It’s painful to go fix that. So I’m very used to this kind of top-down design approach.
That made it a little bit easier to just jump in and know what I was going to do. The difference is, instead of releasing a chapter at a time to the publisher - who then saves them all - I just publish it. And sometimes it’s a little ugly, sometimes there’s an error or two. But I think people in the space now are comfortable, so long as they feel they have a way of reporting that to the author, and they see progress. And Leanpub obviously gives people - I’ve gotten emails from people that said, “Hey there’s a typo on page blah, blah, blah”. “Okay great”. I fix that in the next update. That just gets pulled in, and now it’s fixed.
Len: So did you give you email address to readers?
Don: No, not yet.
Don: I need to set one up where I do that. And we’re about 50% through the book’s initial pass, so I need to do that. But I’m not that difficult to contact either. Most of the folks who are reading this know how to get me on Twitter, or they can find me on powershell.org. Or through my website, donjones.com. So most of the folks reading it at this point have found the book because of me, and they already know how to get hold of me.
Len: And you enjoy those interactions with them?
Don: Oh yeah, absolutely.
Len: That’s something a lot of our authors talk about. Some will actually put their email address in their introduction, and say, “Email me”, which we see as obviously a very good thing. But one of the things we’re thinking about is trying to optimize that relationship. Would you prefer to be contacted like through Leanpub or something like that? Or do you prefer it the way we’ve got it working?
Don: Yeah I think large scale, it’s probably a little easier to have some bottleneck, where everything can come through. Because obviously I’ve got a job. I’m doing this in my spare time. And so it’d be nice to have it in a queue that I could say, “Okay, once a week, once a month - whatever. I’m going to sit down, and I’m going to start running through all of this”. And that creates a good expectation for people, and you can tell them, “Look, if you send something - don’t expect a reply for this period of time, because I tend to process them in these batches”.
So I do that with my email organization right now. But it would be nice to have something in the platform. And I think it would give people a better perception that there is a feedback mechanism. This is the person I bought the book from, this is the person who wrote the book, and they’re going to help me - all talk to each other.
Len: Before I ask this next question, how much of your book had you written when you’ve first published it?
Don: The first chapter.
Len: The first chapter. So is that about 10% or something like that?
Don: Probably less than that. It was - honestly - the overview, it was probably 2,000 words.
Len: Oh, wow. Okay. Were you trepidatious about that, or did it just come naturally from you to publish something so early?
Don: No it - I write really quickly. And I think the majority of the folks who are accustomed to my work have a good expectation of what it is and how quickly I tend to produce. So I felt fairly comfortable doing that. We didn’t sell a ton of copies right away. It was one or two copies. It was when I hit the 50% point, and I think did a couple of things to make specific commitments to my productivity - that the sales started to spike up a little bit, which really does help keep the project moving.
Len: When it comes to the project moving, this was the question I delayed. I was wondering if you would like to be able to show to readers a sort of history of your progress somewhere on Leanpub. Would that be like, “I released the first chapter on this date. I released the second chapter on this date. Here are the things that I updated when I - or added when I did that. Here are the things I corrected”.
Don: That’s probably a good idea. It would at least show readers that you’re serious about it, and this is a real thing. And if an author publishes a chapter and then vanishes for three months, then readers have reason to be trepidatious - unless there was some commitment otherwise. So yeah, I think that’s reasonable. It kind of makes you a little bit accountable to the audience, which is good.
Len: One of the [things] we’re thinking about is sort of establishing that trust. So someone comes along and sees a book is 30% complete, and maybe they’re not so familiar with Leanpub and the concept of publishing that we’re trying to spread. And then if they can see, it’s only 30% done, but it’s like one chapter per week for the last 3 weeks. That’s a pretty good sign that I should trust that this author is going to complete what they’re doing and that they have a plan.
I was wondering, how did you - this is a big question for self-published authors - how did you decide pricing for your book?
Don: I’ve written a lot of traditionally published books, and so I know what a book of this length - and I’ve got a really good idea what the final length is going to be - I know what that’s usually going to be priced at. And so that’s my target price. I’m actually not priced at that right now as we speak, I’m priced a little lower. I decided to start with kind of an early bird price, to reward the people who jumped in early and helped support the project initially.
When I cross the 60%/75% point, I’ll bump the price up to its final [price], and it’ll be a little bit cheaper than an equivalent, traditionally published paper book would be, because there’s no paper costs. I’ve always felt that the majority of the value in the book should be the material in the book, not the paper. Not the copy editor, not the things that really don’t add a lot of value. So it should be about 20% less than a traditional published book of the similar length.
Len: And why did you decide to publish this book on Leanpub, rather than with a conventional publisher? Which - pretty clearly - you could’ve done if you’d chosen to, you’ve done it so many times in the past.
Don: This technology, like a lot of them, is extremely agile. It changes a lot and it changes fast. And there’s literally no upside to working with a traditional publishing model. I can write a book, I mean if I sit down and take the time - like if I took a sabbatical from work for a month - I can write a 300, 400 page book in a month. I write quick.
And that would be fine, except then it’s going to take two months to copy edit and two months to dev edit. Another month for a tech editor to go through, and then two months in layout. And then, even though it took me a month, it’s nine months to a year before the stupid thing gets out. And now it’s changed, and now it’s not good anymore.
So I really started looking around. I mean obviously there’s sites like GitBook, and Penflip - both of which I’ve used. PowerShell.org’s free e-books are dual-published. We publish those on Leanpub, and on GitBook. And I think GitBook is great for the model, but it’s non-commercial. I mean that’s kinda the whole point of it. Is that there’s no - there’s no storefront. There’s just all open source books.
That’s fine for powershell.org, it’s a non-profit, it’s a community organisation, not looking to sell those books. But this was something that if I wanted to be able to maintain this over time, there needed to be a financial reason to do it, because although I do enjoy writing, and I like getting this stuff out there. If it’s something I’m going to have my head in every month, I’m going to lose interest - unless there’s a - if I can take my family out to dinner once or twice, that’s a financial motive. So sure that works. That keeps me going.
And Leanpub was really kind of the combination of those. It lets me treat the book a lot like an open source project. Meaning, it isn’t open source obviously, but it has a lot of the same characteristics, in that I can make changes to it as often as I want to, or as often as I need to. But it still puts that commercial end on it, so that there is a financial arrangement going on that keeps me interested.
Len: Your book is currently priced at $39.99. I should mention, anyone get the deal now, if you’re listening. And of course, we don’t do DRM at Leanpub.
Len: And so you’re selling a $40, self-published, DRM-free book. We’ve actually got someone else, a guy named Nick Russo, who’s selling his book for a minimum price of $200, and a suggested price of $300 right now. So it’s offering something of a - for a book, a pretty high monetary value, something that people could easily not pay anything for.
Len: Is that something that you think about? Or do you just not think about?
Don: Not any more. I mean first of all, there’s no such thing as DRM. One of my first PowerShell books - some Russian guy bought it, shaved the cover off of, scanned and made a beautiful Windows help file out of. And that was online. I have never ever written a printed book that wasn’t pirated almost immediately. Any DRM can be stripped off really, really easily.
All it does is inconvenience your legitimate customers. It makes it harder for the people who did pay you money to take value for what they got. So I’m not going to punish the people who are supporting it. My experience has been - at least with the audience I work with - that they’re pretty upright people. And if they find value in something, they’ll pay for it. Now my price - my minimum price is $39.99. I’ve had more than a few people pay 60, 70 bucks for the book. So they’re paying what they feel the value is.
And if somebody’s out there, and they’re working with this stuff, and they’re in a country where $39.99 is two months’ salary, and so they’re going to grab the thing pirated some place - that’s fine, okay. Maybe they’ll do well someday, and maybe they’ll take their appreciation and go to DevOps Collective, and make a charitable donation to a non-profit that’s helping kids learn technology. So if that’s their value, it’s fine. My feeling is that it’ll all square itself out in the end.
You don’t write books to get rich. I’ve been doing this since 2001. There’s reasons to write books beyond the money. And so long as there’s enough of a financial thing to make it worth my time - and so far there has been - then that’s fine. I’ll go with that. But I think most people in the industry are accustomed to paying for something of value.
I’ll give you a really good example. I mentioned the free e-books on powershell.org. We put those on GitBook, which is very useful. But a lot of people are blocked at work from accessing GitBook, and one of the reasons we decided to also dual-publish them to Leanpub, was because we can set a minimum price of zero, and let people pay for the book if they want to. And it becomes a charitable donation really, because we give the books for free already. 90% of the people who get the book from Leanpub pay for it. Maybe they’re paying two bucks, maybe they’re paying four bucks. But I think people are willing to pay for it if they find value.
Len: Thanks for that, that was a great response. I agree, there’s so much in there that we agree with, and it’s great for us to hear that we built that, it can accommodate that. Our bestselling book in terms of copies and revenue last year has a free minimum price.
It’s just a fascinating thing to watch how our variable pricing model is succeeding for authors in this way - that they can offer the book for free and for money at the same time. And so do both those things that you can do as an author, two of the big reasons to write - the main one is to get whatever your message is out there to people. But one of the main advantages is to gain an audience. And the other one is to potentially make some money. And the idea that you can combine those two by making a free minimum price, but also having a suggested price that allows people to pay, has turned out to be very powerful.
So was one of the reasons you chose to publish your book on Leanpub rather than with a conventional publisher - was obviously, sort of ease of production. But was it that freedom to set your own price, and maybe play around with your pricing - did that - was that part of the reason as well?
Don: Yeah, that was a factor. And honestly another factor is - publishers just don’t do much to help you sell books, but they keep the majority of it. Most authors are getting 10%, 12% and that’s not a lot. So you’ve got this massive machine that really, in a lot of cases, doesn’t add a lot of value.
I’ve been very happy with Manning. I think they’re a great publisher. And for the “Month of Lunches” series, they’re a great fit. But this is a niche technology, it’s a very high-end technology. There’s never going to be 5,000 copies of this sold.
And it just made sense that if I was going to do this, to do it on my own terms. I’m going to be responsible for bringing the most readers to this. That and word of mouth. And so I don’t see any reason why there should be a giant publishing machine skimming 75% of the revenue off the top, when I and my audience are the ones who are going to have to do most of the work on it.
Len: Are you intending to make a print version when it’s done-done?
Don: No. I mean people can get a PDF and print it if they want to. But I’m not planning to traditionally publish it.
Len: Great, it’s interesting actually. I’ve just got to tell a little story I heard from my co-founder once. I think this was a Leanpub book. I was just reminded of this when you mentioned that it was someone from Russia who pirated your book once.
We had a story about a guy who published a book, and then someone from Russia translated it and was selling it. And so the original author - instead of getting mad, pointlessly, and trying to do something that you can’t do about that, got in touch and said, “Hey, would you like to translate my next book, and let’s sell it together?” And of course the translator was like, “Of course, I’d love to do that”.
It was interesting that something that a segment of the authorship community sometimes sees as a big threat, other people can see as a potential new connection. Building an audience for them.
Don: Yeah, and I’ve done similar things in the past, and I would do so again. I think you get a lot further creating opportunities for people than creating barriers. And I do have just about five more minutes too, so–
Len: Just one more brief question while I’ve got you here. If there was one thing we could build for you that would help you, what would that be? Or if there was one thing we could fix, what would that be?
Don: Gosh, I don’t know. It’s been working so well and so smoothly. I would say - oh man, I don’t even know. The one thing that I’m not doing in this book is any kind of professional copy editing. And it’s the one thing that I feel a little bit guilty about, because it does put it on the audience to do that. And I’m very patient with it, and I try to be very responsive when they point out errors.
But I’m not sure how I would collaborate with an author. Because I’m using the Dropbox publishing method, we basically [could] just have a shared Dropbox. I’m not sure how to loop an editor into that, like if I was going to use an editor and kind of notch this up a bit. It’s the one thing I feel little bit guilty about, that I wouldn’t minding putting a little money into.
But I worry about it just really slowing down the whole workflow. I’d want to release a chapter to the editor, let the editor do their thing - and then release that to the publishing queue. And the next time I hit publish, it grabs everything in that queue, and makes a new version. So that it’s - there’s a clean hand off back and forth. Or I can have two or three people working on the same document at the same time.
Len: Okay thanks, that’s a really great answer. We’ll think about that. I know your time’s about up, so thanks very much for being on the Leanpub Podcast, and for being a Leanpub author.
Len: We really appreciate it.
Don: Oh thanks for having me. Have a great day.
published Sep 27, 2016
Ben Frain is the author of the Leanpub book Enduring CSS: Architect and maintain large-scale CSS codebases. In this interview, Leanpub co-founder Len Epp talks with Ben about his interesting career path, his book, and his experience self-publishing on Leanpub.
This interview was recorded on July 13, 2016.
This interview has been edited for conciseness and clarity.
Len: Hi, I’m Len Epp from Leanpub, and in this Leanpub Podcast, I’ll be interviewing Ben Frain. Ben is based in Cheshire, England and is a senior front end developer at bet365, one of the world’s leading online gambling sites, with over 19 million customers. Ben has previously published two books with Packt Publishing: Responsive Web Design with HTML 5 and CSS 3 and Sass and Compass for Designers.
He has spoken about web development a number of events, and on various industry podcasts. In a previous life, Ben was a TV actor and technology journalist, and he has an ongoing interest in writing screenplays. He blogs about CSS web development and other tech subjects at benfrain.com, and you can follow him at @benfrain on Twitter.
Ben is the author of the Leanpub book, Enduring CSS: Architect and maintain large-scale CSS codebases, and we’ll be talking about his book a little bit later. In this interview we’re also going to talk about Ben’s professional interests, and at the very end, his experience using Leanpub, and why he chose it to self-publish his book. So, thank you Ben for being on the Leanpub Podcast.
Ben: Thank you. Thanks for having me.
Len: As I think you know, I usually like to start these interviews by asking people for their origin story. And I know from an interview I read about you that in your case, the path to where you are now is perhaps a little more circuitous than it is for most people, and I was hoping you could talk a little bit about how you came to where you are in your career?
Ben: Yeah, okay. Well obviously I’m primarily a software developer now. And the closest I got to software development in my younger years was, when we had a BBC Model B computer when I was a young boy, and we used to get computer magazines here in the UK. I don’t know if you had them in the States? They contain a program, which you could basically spend four or five days of your life typing out. And then, hit go and they never worked. So that was sort of my initial foray into programming.
I basically started my career - I always wanted to be a film director. So, from sort of young teens, that was where my head was. I did film directing at university, and tried desperately to get into that career. Where I live in the UK isn’t exactly a hotbed for the film industry, but off the back of doing that at university, I used to do a lot of acting as well. An agent took me on for the acting, and so I followed that path for a short time, and did about five years of TV acting here in the UK - none of which set the silver screen alight, but sort of soaps that are well known over here, like Coronation Street and the like. I was in that a couple of times.
The frustration with that sort of career was that I was imagining myself getting alongside Bobby DeNiro - and I was actually getting 10 lines in a not-so-great soap opera. So my idea of where I wanted to be in reality weren’t measuring up. I’d got to a point where I’d started to write my own stuff. I’d written a screenplay, and I wanted to try to get that off the ground. I’d done short films before; the same time I was doing the short films, was when I started to be sort of tallied in with the beginnings of web design. This was about sort of ‘98 - something like that, or ‘99. A lot of people do websites for their band; my first website was one for a short film that I’d made.
And so these two lives started to develop - one where I was furthering my web development skills, and the other one was where I was trying to get this film career going. And the reality was that on a long enough timeline, what I wanted to do didn’t pan out, and what I never planned on doing, did. So, that’s kind of where I ended up.
I tried to get films off the ground, myself, tried to get them financed. It was very tough and I basically failed. I was into writing screenplays, and that made no money, but at the same time I was writing for technology magazines here in the UK and abroad. So that was where I was making my money at the same time. So yeah, I was making my money making websites for other people and writing for magazines, and then actually trying to get these screenplays off the ground, that never saw the light of day. So eventually, it just came to the point where I was so much better at the web development, that was taking off, and that’s kind of the path that I followed.
That kind of brings us up to about 2011, something like that. I’ve been doing web development freelance for quite some time, and then decided to try my hand at a book.
I did a couple of books with Packt Publishing. I’ve always enjoyed the writing process, because I feel like I probably learn as much by writing something for other people, as I do just trying to learn for myself. There were good things about writing for a publisher, and there were lots of bad things. And we’ll get to the bad things later on, maybe? That kind of gives you the versions of my torrid career path, I guess?
Len: I have a question specifically about the process of getting a screenplay funded. Maybe like some other listeners, I’ve written a couple myself, totally amateurishly, and entered them in screenplay contests or passed them around to friends, but I was wondering, when you say you tried to get them off the ground, what does that mean? Does that mean approaching producers that you’ve been introduced to? Or trying to get introductions to people with money who are interested in producing a film?
Ben: It was a bit of both. I’d done a bit of screenwriting, and I managed to get a literary agent as well off the back of that. So much like my acting ideals didn’t match the reality of what agents wanted me to do, it was the same case with the screenwriting. They wanted me to be writing episodes of soap operas, and I wanted to be writing blockbuster films.
But throughout the course of the different people that I knew in the industry from doing what I did for some time - it was basically any producers that would let you bend their ear. There were production companies, as well, that - you probably had a very similar experience. You get a lot of responses from people that sound quite promising, but ultimately end up in nothing. And so when you’re in the beginning of that journey, you always feel like you’re on the cusp of something happening. And for me, at least, it never actually did. And so I got better at recognizing those situations.
But the one that I was going to try and make myself, what I planned to do was find 1,000 people to each put in 1,000 pounds. And so everyone would have an equal share in this million pound, low budget film. But I just didn’t anticipate what a skill producing is, and how difficult it is to actually go out and get money out of people. It was basically something that I never considered that would be the difficult bit. So I spent all the time on the script, and the director, and the cinematography, and storyboarding - and all that sort of stuff. And I just sort of thought, “Well, of course people would want to put in 1,000 pounds to be part of a film.” I just thought that would be a given. And nobody did. So it didn’t pan out that well.
Len: That’s really interesting, it sounds like having a screenplay and trying to get it produced is a little bit like being a startup and approaching venture capitalists. Almost none of whom will ever give you an outright “no”.
Ben: Yeah, yeah.
Len: And certainly, unless you’re a total basket case, they’ll want to maintain positive relationships with you - and with everyone they meet, in case something pans out. And that’s interesting, the sort of crowdfunding model that you’re describing. Have you ever thought about using Kickstarter or something like that?
Ben: Well there was a thing a while back, when I was last seriously dabbling in it, called Trigger Street - I don’t know if it’s still going. I think it was something that Kevin Spacey had set up. That was quite interesting, because you put your screenplay in, and it was voted on by other members of the site, and the highest ones each month got put before a panel. And so, things like that are potentially - I think the truth of the matter is, Len - at the point I’ve moved past it mentally. I’ve got two young sons now, and I think that the one remaining thing that I’d like to do for them is to try and write a novel for them, in few years’ time. My belief in that I could get one of these screenplays sold is sort of fading every day, sadly.
Len: It sounds like quite an adventure though, a definitely I think we should all live our lives aiming for what we most desire. It was interesting - speaking of moving on - you’ve written about the change, or at least there’s an interview I read online about changing from being a lone wolf - working for yourself - to being an employee for a company, and I was wondering if you wanted to talk a little bit about how that affected you, and what you’ve lost and what you’ve gained?
Ben: Yeah, certainly. Like I say, for about ten years I worked just for myself, freelancing - essentially like a sole worker. And that was all absolutely fine. I think the rub of that is that what you actually like doing is just one portion of your day. Today obviously, you’ve got to chase jobs coming in. You’ve got to chase payment, and all that sort of stuff people in the freelance trade don’t like, particularly. And I certainly didn’t either.
The good parts about freelancing is obviously, once you organize yourself, and you know how to put structure into your day, there’s a leeway that if at four o’clock one day you just know that your brain’s not working very well, you can go out and get a cup of coffee or whatever. So that feeling of being like you imagine an adult would be, where you’re in charge of your own destiny day to day - that’s what’s really nice about it.
But the flipside - I was approached to join bet365 by, it was like a recruitment agency in the UK, and when you’re a freelancer doing public-ish work on the web, recruiters are contacting you quite a lot of the time. And so that was no surprise, but the thing that they described to me was quite interesting. And it was fairly close to where I live. And they didn’t say specifically who it was at the time, but they said it was a large company. And there’s only two really big companies near to where I live - one of which is bet365, and the other one is JCB, who’s - you know like you’ve got Caterpillars there in the US? The big monster trucks or cars? Are you Canada or US?
Len: I’m based in Canada. The way I describe it, I live on a Canadian island in the Pacific Ocean.
Ben: That sounds pretty good.
Len: Called Vancouver Island, yeah.
Ben: Oh yeah, Vancouver. Yeah, I’m not a complete hillbilly. I do know where Vancouver is. So yeah, so it wasn’t JCB, because I’d already been in and spoken to them. So it turned out to be bet365. Anyway, so I joined them fully believing that I would be there maybe a couple of weeks, and somebody telling me what to do every day would very quickly wear thin.
But it turns out, it was - there’s a quote that I’d heard from somebody and they said, “People don’t leave jobs, they leave bosses”. And I always think that’s quite interesting. Because the guy who took me on, is still my sort of my boss. He’s just a really good guy, and I get on with him very well, I enjoy working with him. And I think that sort of thing is the part working for a company that I’ve missed but didn’t realize I missed.
So I’m working with like two or three people pretty closely every day, and I enjoy that. I suppose it must be like people who are in a band, being able to sort of bounce ideas off people, which is what you miss when you’re working for yourself, and what you really gain when you’re sat face to face with somebody. And that’s not to say you have to be doing that all the time, but it’s nice if you’re doing anything creative to be able to stop and sit around a table and put some sketches down and go, “This is what we’re thinking of doing”.
Being able to bash that stuff back and forth is the stuff that I actually enjoy doing the most. I suppose it’s probably the closest to the creative side of things, that you’ll have done in terms of screenwriting and that sort of stuff. The real buzz of it is when the ideas bounce back and forth, and you come up with something that no one person would have come up all by themselves.
Len: Speaking about buzz, I’m not sure if everyone listening to the podcast knows this but in England it’s more or less legal to bet on anything. I think I’m correct, right?
Ben: Yeah, that’s right, yeah.
Len: I actually lived over there for 9 years, and I’m familiar with the sight of the oddsmakers and things like that. I was wondering if there is any special buzz around working for a betting company? Is there an extra kind of pressure or constraint on you?
Ben: No, I mean I think it’s more - the funny thing is, I was never somebody who ever bet on anything. I was never brought up with betting in our family at all. That’s not to say that people in my family don’t. But I can remember distinctly thinking, “I don’t know if I’m comfortable with a betting company”. It felt slightly weird to me, almost like a tobacco company or something like that.
But the reality is, yeah it’s very much a cultural thing. It’s just not a big deal here. It’s not considered weird in any way. It’s sort of normal day to day, I suppose in much the same respect as people would go out and have a drink in a bar, and 99% of people are absolutely fine. You occasionally get people that don’t respond well - when you get alcoholism and all that sort of stuff. And by the same token you get the odd people - in terms of gambling, that go the same way. They get addicted to it. So it’s a really difficult subject to really feel out the edges of.
But in terms of what I do day to day, which is build the interfaces for these things, there are very few applications - if you want to call them that - on the web, which are, by necessity, as complicated as a betting application needs to be. So that does present some unique challenges, which are pretty exciting for what I do, to try and solve, to try and figure out - and architect, and all the rest of it. And so from my point of view, it’s a good thing, because other than that, I’d be doing the same sort of brochure sites, and magazine sites, and all that sort of stuff that are much more common.
Len: Yeah, it sounds exciting to me. I met a couple of people who worked doing the odds, and they could be literally anything, right? Like when will Charles and Camilla get divorced?
Ben: Oh yeah.
Len: And the idea of just putting odds on that - I just imagine that the user’s interaction with something like that must be kind of particularly - tense.
Ben: Yeah, the thing that I’m most involved in it’s, called, “The Sports Book.” Which is - it’s betting on live sporting events, or sporting events around the world. It was unbelievable to me when I got there and saw the scale of what they do. I mean, as an example you might go onto the site and there’s maybe 18 live soccer games happening right now, and we let you choose any one of those games, and we’ll either have a live video feed of that event happening, or we’ll give you an animated, interactive kind of like computer version of it - showing you what’s happening right now as well. So at all these events around the world, there’s guys and girls feeding back exactly what’s happening at this game at this point in time. And based upon that, the odds are updating, which lets users choose which opportunities they want to bet on second to second. Like I say, that’s the level and scale of interactivity that you just really can’t find in many other areas.
Len: Yeah, I’m looking at it right now, actually. It looks really good. I see there are e-sports as well - are you a part of that?
Ben: Yeah, all that sort of stuff. Like if you go to mobile - primarily, if you go to mobile.bet365.com on your phone - what you see there is the sort of stuff that our team prototypes, builds up. And then we have another team of devs as well, that take it and mesh it in with all the live data and all the rest of it. And we’re just constantly putting new things in there. Just when you think we thought of everything, there’s another whole set of features we want to write in. So it certainly moves really quickly, it’s a competitive market to be in. And so yeah, it gets me out of bed every day, which is good. If it keeps your brain challenged and keeps you solving problems, that generally makes me quite happy.
Len: It’s a really fascinating industry.
I was wondering - I kind of have to ask the obligatory Brexit question. But I guess it’s kind of reverse Brexit question - which is, as far as you know did the EU ever try to put limitations of the British cultural practice of betting?
Ben: Well, funnily enough, it’s across the whole of Europe. There really isn’t anywhere that doesn’t allow betting. I think if anything, America and Canada are kind of unique. China tries to say it doesn’t allow betting, but China’s obviously always been massively into gambling and betting and all that sort of stuff. And so, there’s actually quite few places around the world that don’t do betting as standard. There’s occasionally bits of legislation that are particular to different areas. Like, Italy has a certain set of specific requirements for in-play bets and things like that. But by and large, they’re all at it.
Len: I guess that just speaks to my own limitations. I mean having spent so much time in Britain, and seeing oddsmakers everywhere - but when I would travel in Europe, I guess I just probably didn’t notice that that was a practice elsewhere as well.
One more question, about the switch from working on your own, to working for a company.
I made this switch about a year ago from working remotely, to working in an office. And you’ve written about how much you enjoy being able to set up your own physical environment, and how sometimes there are things that you can’t do in an office, that you might be able to get away with doing at home. And I was wondering if there’s one or two things, sort of pro tips you can give for setting up a physical environment - things that you’ve thought about and found solutions for.
Ben: I guess the main thing is to try and get people to understand your whims. Particularly if you’ve worked for yourself for a long period of time, you know how to have things the way that you want them. And so - I mean, I’ve got to be honest - there aren’t many things that I’ve wanted at my current place of work, that they haven’t accommodated in some way.
I suppose the key difference for me is, if I was working for a company and it had a crummy, horrible monitor I had to sit in front of, and they weren’t prepared to buy a new, better monitor - I would quite happily buy my own monitor, and bring it in if they would allow me to. Because I’d rather do that - have a nice working environment - than I would use crummy tools. Because you sit in front of these things every day, and that’s how you ply your craft.
Obviously whether they should or they shouldn’t buy something better for you is a different question. But I’d rather just buy the things that I want to use to do my job, and accept that as a part of my professional outgoings, if you like. When I think about people in other trades, and what they have to pay for the tools that they need…. The sort of stuff - like the absolute crème de la crème of kit - you can get a top of the line MacBook Pro for a few thousand dollars, massive cinema displays for same sort of money. In the scheme of things, compared to other professions, it’s not a great deal of money.
Len: That’s very true. It also sounds like in an environment where one is getting recruitment calls all the time - I imagine there’s a bit of an incentive on the part of companies to accommodate a programmer’s needs. One of the things at Leanpub that we really like to provide is actually - this just reminds me - is really nice noise cancelling headphones, so the programmer can just go into their zone and stay in their world. One of the interesting things about it is that putting on the headphones is code for -
Ben: Leave me alone.
Len: “Leave me alone. I’m in the zone. I’ve built my stack in my head, and let’s be productive now.”
Just switching topics, your book, “Enduring CSS” is about a method, I suppose we could call it, that you’ve developed for organizing, and doing CSS architecture on big projects. And I was wondering if you could explain a little bit about how you came to develop the approach, and what the approach is?
And what happens when you move to something of size, and something with a lot of people that are all working on that code base? I guess that historically, you’re always told to lean on the Cascade in CSS. So you make some styles, and you inherit from those styles as much as you can. You try and write as little CSS as you can, and therefore when you want to, you make a pattern of things for your site, and when you want to change something across the whole site - the thought being that you go back to that one thing that everything inherits from, and you make those changes.
Which is all well and good, but what I found once I started on these sizable projects with many, many different visual components - it wasn’t just a brochure site - was that often these things that started life looking quite similar, often needed to transgress as time went on, and develop their own life and identity. And it was actually a major inconvenience to have to - you would make a change to one thing, and it would end up inadvertently changing something somewhere else. Which, on something of scale, is really, really problematic, because you need to be quite confident when you’re committed into a large code base. That the changes you make are going to make just those changes, they’re not going to start visually changing things in other areas.
The core principle, and there’s been a few sort of methodologies over the years, like BEM is one, which is Block Element Modifier, and then there’s been things like OOCSS. The two main ways of approaching CSS at scale, are you either go for a kind of atomic approach, which is categorized by atomic CSS, where you make a little class for every single permution of CSS. And so, at some point, your CSS can’t get any bigger - but the downside of that is that you have to write 10 or 20 classes on every single note in the DOM, to get it to appear the way that you want. So that’s one approach - the benefit being that your CSS stays quite small.
The flip side of that is you try and contain styles. And so by doing that, you put one particular class on each note in the DOM. And then every single thing that’s needed to isolate and contain, and render that thing perfectly, is put on that class. So you’re going to get a little bit more repetition - maybe a lot more repetition because you’re going to be declaring things like the display type, the colors, background colors. Lots and lots, but things like gzip, when it’s all smashed together - nullify a great deal of that. And so the ECSS methodology is based around the idea of isolation and containment. So the principle is that by isolating these things with a namespace, and various other characteristics, there’s no danger of styles leaking out from one component into another.
Len: You also talk about stylesheet entropy. I was wondering, is that something in what you just described? Or is that something else? It just sounds like a really interesting idea.
Ben: I’m not sure the exact context of where I’ve said that. It sounds like the sort of thing I would say, certainly. The place where I came to look at the styles on a big site where for months and years people have been working on a CSS code base. It grows, because nobody has the confidence. It’s back to that thing I was saying before, of, people are too afraid to make changes to existing CSS, because they don’t know what it’s going to affect.
Nobody seems to know what changing a class 200 lines above is actually going to do. And so, they don’t do that. And they use a very specific site, and they write some more CSS. And so you end up in this situation where the CSS only ever grows, because nobody has the confidence to fully understand what the existing code is doing. And that’s kind of what I’m talking about. And so, once you develop a very clear set of guidelines and principles for how you’re going to architect this stuff - it becomes very simple, manageable to deal with those styles or update them, remove them, knowing full well you’re not going to destroy everything.
Len: I imagine the target audience for you book is people who are either on large scale projects that have suffered from this kind of entropy, or people who are scaling up, and who might want to adopt a best practice before they proceed?
Ben: Absolutely. And I think, with all these things, there’s trade-offs. There’s no right way to do anything. There’s just a set of problems and the solution that fits those problems. And so, I’m quite clear and quite vocal about saying, “Before you do anything, you need to understand the problems you actually have”. Don’t go and pick a methodology - whether it’s mine or anybody else’s - and just think, “Well, that sounds pretty good”, and slap that into your situation, because you need to know what your situation is. You need to know exactly what the problems are that you’re trying to solve before you try and fit something to them. And so for me - obviously - it’s a methodology that works perfectly for what I do. But people need to understand the problems they’re solving before they try and apply stuff - that’s my take, I guess.
Len: You’ve got a section where you talk about - and forgive me if I pronounce this wrongly - “Pin Cing Do” - which you say translates roughly as “the way of pragmatic coding”. And it means, more or less, solving the problems you actually have. But you immediately then go on to say, “But the problems you have might not be the problems I have”. And as pragmatic as one individual might be, there’s still the problem before them, there’s this sort of combined problem of collaborating.
Ben: Yeah. I think, as well, it’s a bit of a bugbear of mine. We tend to be a bit like lemmings in web development, and we just kind of follow what somebody decides is the next hot thing, without actually stopping and deciding if it’s the right thing for us. And so that’s what the whole “Pin Cing Do” thing is about, is about having the confidence, and developing the confidence to know what suits your particular circumstances - and knowing what things to concentrate on. Some of that takes time, but some if it also requires conscious effort to do that, I think, and not just get carried away on the latest hot technology.
Len: On the subject of writing and creativity and publishing, I wanted to ask you - so you’ve written previously two books for what we might call a conventional publisher, and you decided to switch to self-publishing. Before I ask you specifically about Leanpub, I was wondering if you would like to talk a little bit about why you decided to make that switch - at least for this book?
Ben: The things that are good about a traditional publisher, is obviously that they’ve got the scope and the avenues to get your book out in all the right places. Which, if you’ve never written books before, there’s some advantage to doing that.
The disadvantages are - they take a massive chunk of your royalty, you have to use horrible tools generally to write the books, you’re working in Word templates and the like. And you’re also stuck to a contract, which means you’ve got to do stuff to a certain timeline - to certain conventions, and all that sort of stuff. That can be a good and a bad thing. In fairness, I don’t think I would’ve written my first book if I hadn’t signed a contract, because that motivated me to write it.
Sometimes not having the things that you’ve got to hit, means that you never actually end up doing anything. And so having something in place is good, but for me, it was perfect to move to Leanpub, because having done that a couple of times, I sort of understood how to structure stuff and get stuff done, whilst at the same time I could move more quickly into my own pace, because I didn’t have a contract to worry about.
That’s the other big thing that’s a real annoyance with typically published books: no matter how fastidious you are with the detail, once that thing is published and you find those little four or five things which are wrong or need fixing or are slightly out - but you’re done. They’re going to stay there and irritate you and everybody else forever. That’s really frustrating. And what’s lovely about Leanpub is, a reader can email me, and within 10 minutes, I can have the revised version up and live for people to re-download. And that feels like how it should be in this day and age.
Len: I couldn’t agree more. I have the same sort of attitude towards seeing a mistake and wanting to fix it, especially if you believe that it ought to be technically possible.
You made a comment about Word, and so I imagine that you wrote your book in plain text using our Leanpub-Flavored Markdown syntax?
Ben: Yeah I used Sublime text data - that’s where I spend like 95% of my working day, is writing code, so it’s very easy for me to just flick open a new tab, put it in Markdown syntax, and away I go. And so that’s generally how Istart writing anything - it starts out as Markdown, whether it’s a blog post or a book or anything really, a bit of documentation that I’m writing for work. And so, it just suited me perfectly, because that’s the way my mind works.
And the only time I got - well, not even frustrated, because it was kind of a think above and beyond - but I wanted to have an online version of the book as well - ECSS.io. And what I wanted to try and do is use that same Markdown text to generate the HTML, so that I only ever had to update in one place. And there’s just a couple of things which I wanted to be able to do, in terms of like putting classes on things, which I couldn’t do in the Markdown once it had run through the converter. These are sort of minor things. Maybe I’ll bug you about another time.
Len: The last question I always ask people is - what can we do for you that we haven’t done, or what can we fix that was broken? So we’ll get to that in a few minutes I think.
Ben: But by and large, it’s just been incredible, because I’ve been able to put the book up on Leanpub. And obviously, I think I started off saying it was like 70% complete or something like that. So I kept chipping away at it, till I got it to a point that I was happy with it. And then once it had run on Leanpub in a sort of finished state for a while, it’s easy to then go and stick it on Amazon, or stick it on iBookstore. Like literally within an hour, you can have generated the right files and the right stuff that they need to get it out there. And it’s just incredibly liberating, when you’re used to dealing with the massive machinery of a big publisher.
Len: That was actually going to be my next question. Did you publish it in-progress? And that sort of related to switching from working for a traditional publisher to self-publishing - is the issue of motivation and timing and stuff like that. A lot of self-published authors talk about how they like the freedom, but sometimes you miss the pressure, because it helps you get motivated to finish.
One thing we’ve tried to do is sort of replace that with the concept of in-progress publishing. So you publishing something that’s 70% finished, and then you maybe start getting readers before you’re done, and then - the fact that you have readers, and that your book is out there - provides you with some motivation.
Ben: Definitely. It definitely did for me, Len. Because I’ve got a sort of weird thing where - it only had to be one person buying that book at the 70% stage, and I felt a debt of honour, if you like, to finish that thing for that person. So the more people that buy it along the way, obviously just adds the weight. And they become like the contract, if you like - or that’s certainly the way it felt to me.
Len: I know your book is on Amazon, as well as available in the Leanpub bookstore. And for all kinds of reasons, I can see that the pricing is different. One is that Leanpub has variable pricing, wo you can set a minimum and a suggested price, and people can choose to pay anything above the minimum, including above the suggested price. But on Amazon, your book is set at $9.99. I imagine that’s partly because Amazon starts to punish you…
Len: …if you make your book worth more than $9.99. I was wondering if you could maybe explain a little bit about what that’s like for you as an author - to have your book available in two different places, for two different prices?
Ben: Yeah I mean, the reality is, it probably won’t be on Amazon for much longer, because it only went on about 10 days ago, and I didn’t really realize at the time that that would be the case. It’s incredibly frustrating, because obviously they take a massive chunk of the money anyway, that they kind of strong arm you into setting it at a certain price.
Len: I was just going to say - as I understand it - I mean there are all sorts of complications to Amazon’s royalty structure. But one of the main divisions is that you can earn up to - I think - a 70% royalty on a sale, if your book is worth up to $9.99. But after $9.99, it goes down to 30%. [Editor’s note: it’s 35% above $9.99, which isn’t much better than 30%, but is a bit higher.] And so, if you price a book at $11.00, you can make less money than you would if you priced it at $9.99.
Ben: Exactly, yeah.
Len: And this is a particular issue for people who are writing technical books, or books that have a higher inherent value, perhaps that you might say - to the reader, than other types of books. Because if it’s for your work, for your career - to solve a problem that can make an entire organisation more efficient, then that book might be worth $1000, not $9.99. And Amazon is inherently structured to not be friendly to books of that kind.
Ben: Yeah absolutely. And like I say, it’s something that - I wanted to get it on there for an experiment to see how it’d do, to see whether it would sell substantially more units that way. But like I say, it’s been on there about 10 days and it’s not sold any more than I have on Leanpub, and obviously it’s a much more frustrating process. In time, once there’s reviews and stuff like that, whether that makes a difference, I’d be keen to know. But that’s sort of something I’m saving up to talk to you about.
Len: I’ve just got one more question before we jump to that, which is, you’ve mentioned making corrections, and you’ve published in-progress. I was wondering, is engaging with readers something that’s been important to you throughout this process?
Ben: It is, and I think definitely, Len, with the subject of this book particularly, because it’s not like a simple, “Do these things, and there’s the answer and it can only be one answer”. It is the sort of book where, if you’re a CSS developer, you’re starting down this road. You’re going to have a lot of questions, even after writing that book. And so, being able to have back and forth with people and, yeah, that sort of thing.
You basically have to meet people on whatever medium they want to do. Whether you ask for it or not, some people are going to email you. Some people are going to reach out to you on Twitter. Some people are going to put a comment on the site’s page. So you just try, and have to be, as vigilant as you can to meet people wherever they are, I think.
Len: That’s an approach that a lot of people take. It’s one of the reasons that we produce output in PDF, EPUB, and MOBI - so that people can put their books up for sale on other places, and try that out - if that’s something that they want to do.
Ben: And I think the other thing, honestly is - well, I’ve found incredible - is the variable pricing. I remember seeing that and thinking, “Oh that’s ridiculous, nobody’s ever going to pay more”. And all the time people do, and bless them for doing it, because it’s just lovely. Because literally I’d say every one in three, is probably somebody who puts a little bit more than you’ve even asked for. And from an author’s point of view, that’s obviously fantastic. I never would’ve imagined that in a million years.
Len: Yeah, we also get people who have bought a book and then read it, and then approach us saying, “Hey - can I now pay more?” which is essentially a kind of tip afterwards. Because since people can choose - I have a strong opinion about this - it creates a very different commercial relationship between the customer and the thing they’ve bought and the person or people who produced the thing, because it introduces choice on their part, about what to do. And a choice on their part about value. And that can change. That can be different from what yours is as an author, and it can actually change after they’ve had an experience reading the book.
Ben: Yeah, it’s fantastic. I mean - I don’t care however famous people are, it’s always nice to get an email from somebody saying like, “Thanks for that, good job”. Or, “Really enjoyed it”. Or whatever. It makes your day. And so, anything that makes that easier to do, is fantastic - to open that dialogue with people.
Len: That gives me an interesting idea about a feature we obviously could add to our tip jar, when we do eventually develop it - which will be sending a happy message to the author. It’s something we probably would’ve done anyway, but it - you just made me think about what a good feature that will be.
Moving on to the final part of the podcast. What is it that we can do for you that we haven’t done, that you think would be a good addition to the process?
Ben: I think just reviews are the main thing for me. I know so many people that, when they look at something, particularly books, without any kind of testimonials and reviews of the book - it just makes it more likely to go away and have a think about it. And I think that’s the only thing. I’m sure you must have thought about it 100 times.
Len: Yeah we have. We have thought about it. Amazon made online reviews famous, quite some time ago now. The only reason they don’t exist yet on Leanpub, is because we’re a small team and we’re bootstrapped, and there’s just always an endless number of things to do. But definitely reviews. And more broadly reader-author and reader-reader interaction is a big part of Leanpub’s future, and doing more work around that.
Currently the substitutes for reviews are the reader testimonials that authors can add, which are obviously all going to be positive. But it puts a face in the name to a claim about the book, which is a positive thing. And we also make it possible for people to make samples available through download, so that someone can download a sample of the book, and have a look. It’s sort of the equivalent of being in an old time-y paper book store, and taking something off the shelf -
Ben: Yeah, I’m going to flip through.
Len: And having a flip through. And the last thing is that, we have our 100% Happiness Guarantee, which means that with a couple of clicks, people can get a refund within 45 days of purchase. Not everyone knows about that when they come to Leanpub, and when they buy a book. But people who do know, do understand that buying the book is actually risk-free. And so they might be more likely to just buy a book, without a recommendation, because they know that it’s risk-free. But reviews are definitely something that we need to add.
Ben: Yeah I mean other than that, the only thing that I can really think of is maybe more possibilities for extending the Markdown output. But that’s really niche - really - because I don’t think most people will be making an online version of the book. So that’s certainly not something I worry too much about, because like I say, I think I’d put that at the bottom of the stack, if I was on the other end.
Len: It sort of is in a way for us as well. And there’s a bit of a theoretical reason around that, around the sort of concept of Lean Publishing - which is that 99% of one’s work, as a writer, ought to be going into writing. And especially before a book is finished. Formatting is kind of - it’s sort of like - I guess, literally ought to be an afterthought, because if you’re doing too much formatting while you’re writing, what you’re probably doing is procrastinating. But that being said, of course we want to have an awesome online reading experience. And we want our books to look really good. So it is something we - when authors come to us with a suggestion for something to add, it’s something we think seriously about.
Ben: But by and large, I’ve got to say, not just because I’m on the podcast, but it’s just been incredible. Like I would certainly - anybody listening who’s thinking about - doing Leanpub, I would encourage them to do so. There’s very, very, very little negative I could say about the whole experience.
Len: Well thanks, thanks very much for that. We really appreciate it. Actually I have one last, last question. Which is - you have an awesome book cover. How did you get that?
Ben: Funnily enough, the boss I mentioned earlier - he designed it for me. He’s just one of these irritating people that can do everything really well. And so,when I said I was going to do this self-published book, and all the rest of it, and I didn’t know what to do for a cover, we had a couple of iterations of it. The first one he did had like isobars. Like you would look at a map and see isobars, sort of hinting towards that idea of sort of terrain and topology and stuff like that.
But ultimately, we sort of felt that was maybe a bit of a vague notion. And people won’t understand it, and think it was just squiggly lines. And so, the new one - with the landscape - hopefully attests to the notion of - writing your CSS code, it’s going to last as long as the hills. Which obviously - not quite. But hopefully you get the notion.
Len: It’s a great idea for a cover, and it just looks awesome. So thanks, thanks to your boss as well from me I suppose. Just to wrap up, Ben - thanks very much for being on the Leanpub Podcast, and for being a Leanpub author.
Ben: Not at all, thanks for having me, and thanks for making such a great product.
published Sep 20, 2016
Daniel Dib and Russ White are the authors of the Leanpub book Unintended Features: Thoughts on thinking and life as a network engineer. In this interview, Leanpub co-founder Len Epp talks with Daniel and Russ about their careers, their book, and their experience self-publishing on Leanpub.
This interview was recorded on July 12, 2016.
This interview has been edited for conciseness and clarity.
Daniel Dib and Russ White
Len: Hi, I’m Len Epp from Leanpub, and in this Leanpub podcast I’ll be interviewing Daniel Dib and Russ White. Russ is based in North Carolina and has been working with large-scale networks for more than 20 years and written a number of books, co-authored over 40 software patents, and spoken at many different venues around the world. His blog is called Network and you can find it at ntwrk.guru. He’s currently on the architecture team at LinkedIn, where he works on next-generation data-centric designs, complexity, security, and privacy.
Daniel is based in Sweden and is currently Senior Network Architect at Conscia Netsafe. Daniel has worked on some of the most demanding networks in Sweden, and is committed to mentoring new and promising engineers. He is a Cisco Learning Network VIP, and a Cisco champion. You can find his blog called Lost In Transit at lostintransit.se.
Russ and Daniel are the authors of the Leanpub book, *Unintended Features: Thoughts on thinking and life as a network engineer. Their book is focused on helping people who are building careers in networking technology, and helping them think about their knowledge-based skills and experience in an informed way. As such, it’s not a book so much about technology, as it is a really valuable and generous contribution from experienced professionals who want to help other people improve their careers in either network engineering, or information technology more generally.
In this interview we’re going to talk about Russ and Daniel’s professional interests, their books, their experience self-publishing using Leanpub, and at the very end maybe one or two ways we could help improve Leanpub for them and for other authors. I said Russ is based in North Carolina and Daniel was based in Sweden, but currently they’re both coming to us from the Cisco Live event in Las Vegas.
Thanks guys for being together in the world to do this, and for being on the Leanpub podcast.
Russ: Thanks. I mean, I think you pretty much covered the whole thing, so we can just quit now.
Len: Thanks Russ. Russ, why don’t we start with you? I usually like to start these interviews by asking people for their origin story, so could you tell us how you first became interested in being a network engineer, and how your career got you to the point where you are now at LinkedIn?
Russ: I actually kind of fell into it, accidentally, it wasn’t something I was actually planning on. I started my life doing graphic design and doing electronic engineering, and ended up in electronic engineering in the Air Force, working on airfield systems, radar systems, and BOR’s … and stuff, and somehow or another ended up in this small computer support center, probably because I’d learned how to code, and they needed a coder to do some odds and ends. So I ended up there building systems and fell into the project of helping replace the core network - the optical fiber ring at McGuire Air Force Base - and replace the telco switch, which is an old 1960s telco switch, for which our primary troubleshooting pool was WD-40 in the physical rotary switches in the frame.
Russ: It’s pretty old isn’t it?
So from there I went into networking intentionally. I went to a small company, then went to BASF, and worked there for a while. Then I moved to North Carolina on a lark with no job, and ended up at Cisco Systems in the technical assistance center. I was at Cisco for 16 years, then I went to Verisign Labs after that, because I thought it was time to move on and do something different. And then I was at Ericsson for two years working in the engineering area.
And by the way, when I ended Cisco I was actually working in engineering, I was actually working on the coding side of things rather than the network design side of things. Specifically, I was kind of in a mixed role in the engineering department, doing coding and network design and stuff. And then from Ericsson, I got to know some folks at LinkedIn, and they pulled me over on the architecture team to do next-gen network design, next-gen data center, hyper scale design, which has been really interesting and fun so far.
Len: Many of our listeners are themselves software engineers, and I was wondering if you could tell me a little bit about what - Daniel actually, I’ll ask you a similar question about from your career later - but what’s a day in life like for someone who’s doing network design at LinkedIn?
Russ: So, LinkedIn is a little bit different because we’re a hyperscaler, so we don’t do normal network design. It’s kind of hard to explain. But hyperscalers, we’re all about simplicity - and just getting a lot of boxes into a single data center, and figuring out how to make the network as much as possible. So it’s kind of a little bit odd and different from doing enterprise design, and service provider design, or transient service provider design - which I’ve done before as well - in that we’re much more concerned about how our control plane interacts with the apps guys, and the application side, and the microsegmentation, and security, and stuff like that.
So I have a little bit more interaction with application and the house security guys, and etc., than I would possibly at an enterprise shop. But it’s also very interesting in that I’m also more involved in how the sheet metal is bent, and what type of chipsets we’re using, and things like that, which you don’t normally get into necessarily in the enterprise side.
Then life for me is mostly throwing interesting ideas on the white board, and see if we can make them stick. Talking to partners, talking to vendors, figuring out how we can get where we want to be from a five-year plan perspective, helping the ops guys understand what we’re trying to do, doing training. And for me I do a lot of ITF work, which is in LinkedIn’s best interests, and B2B security, and talking to people in that world on a regular basis, trying to figure out how LinkedIn participates in the larger community, rather than just being our own little closed-in network that nobody really pays attention to.
Len: Thanks for that. That’s a really, really great answer. Daniel, now it’s your turn. What’s your origin story? And where are you in your career right now?
Daniel: My background came from growing up with a Nintendo and everything. Then I started to get an interest in computers. So I was using the Commodore 64, and then the Amiga, and then I moved on to the PC world. And then I progressed through school technical education and then I moved on to the university, and I found an interesting program there, and the university was Cisco Academy.
So that’s how I kind of got involved into the networking world. And I caught on quite fast, I figured out that this was really interesting and that it was something that I wanted to work on in the future. So I completed the program in the university for three years, and then I started my career as a network engineer, in the networking industry, and working for a service provider at first. And then I moved on to another role, where I also did a bit of design and working on different customer projects. And about a year ago I ended up working for Conscia Netsafe.
So I’m working as a network architect, meeting with customers and discussing designs, doing a lot of writing and diagramming, and explaining to people, and also acting as a subject matter expert in different technologies, helping my customers on different projects. So I guess that’s where I’m at right now.
Len: Thanks very much. One question I like to ask people who’ve formally studied IT, is, do you think, if you were to go back, would you do it again? And I’m asking because I find that actually about half of the people who I speak to did have a formal education in IT at university, and half didn’t. And about half of those who did have a formal education in IT, say they wouldn’t do it if they went back. And I was wondering if you would- if you would do it again?
Daniel: Yeah, from my perspective I would definitely do it again. That’s mainly because of two reasons. The first reason would be that it’s a lot about the soft skills you learn at universities. You learn how to consume information, digest it, and do proper writing, formatting, and those are skills that are really useful if you want to move into an architectural role in the future. And the second reason is that I really like the way they had the program set up, with a lot of hands-on and stuff. So we actually got to do a lot of work on real devices, and learn from the basics - how to cable stuff, how to configure stuff, and so, I think it’s a good way to learn the basics.
Len: I guess things might be a little bit different in a world where you’re dealing with very complex - where you’re going to be given the responsibility of dealing with very complex networks, with very large and established organizations, as opposed to, perhaps, being a developer for a start-up.
Daniel: Yeah, sure.
Len: Russ, on the subject of education, I saw from one of your bio’s that I think you’re working on a PhD right now?
Russ: Yeah, I’m working on a PhD in Philosophy. I was at dinner Monday night or Sunday night, and somebody asked me, “So how does a philosophy degree make you a better engineer?” My answer was, “Why do I always need to be a better engineer? Maybe I just need to be a better person.” But my answer for that is pretty much the same as Daniel’s. Doing a PhD has helped me understand a lot more about ethics, and about how the technology is applied. And it’s also helped me a lot with my research skills and writing skills, and just having the tenacity to go on and do what needs to be done, and to be more of a whole person.
And I’m asked all the time, “Should I get my certification, or should I get my degree?” I always say, “Both”. And then people say, “Well, should I get my third CCIE, or should I get my CCDE, or should I get my degree?” And I always say, “If you have a CCIE and a CCDE, go on and get a degree. Don’t continue piling up certifications. Spread out and do other things, because those are important things to do in your life”.
Len: I’ve got to say I’m a personally very much on the same side as both of you on this question. I got a doctorate in English Literature, before becoming an investment banker. and to me the value of - in addition of the things that both of you have said, the value of taking a few years to engage in a highly focused way, with a large subject is in itself just inherently rewarding - and informs everything else one does in one’s life. And there’s no substitute for that, I would say.
Russ: I would call that developing intellectual virtue. To go to an Aristotelian term - since I’m doing philosophy, you always have to find a way to work your Aristotle and Plato into this - but this whole concept of intellectual virtue, the ability to learn how to focus, and to learn how to learn - I mean to learn how to consume information very quickly. I think that’s part of what Daniel and I are trying to address in this book, is that, we engineers, we tend to go, “Oh, I know how to work a CLI, I’m kind of done now”. Well no, you’re not really done now.
Len: On that subject, you’ve got a section on culture. And there’s a story about General Howe’s Dog, and I was wondering if one of you wouldn’t mind telling that story, and explain why it’s so important.
Russ: Yeah, it’s this little bitty book called, General Howe’s Dog that you can find that explains the whole thing. Essentially at one point General Howe and General Washington - in the American Revolution for anybody who’s not up on their history - were facing each other over a battlefield, and General Howe’s dog, which was some sort of a small terrier, actually slipped across the battle lines, and was captured as an enemy combatant, and taken to - I guess he was biting the soldier’s heels or something? Anyway, so he was taken to General Washington. And General Washington actually sent a soldier back under flag of truce with a very, very nice letter - you can read the whole thing, it’s available online - explaining that they had found this dog, and someone had recognized it as General Howe’s dog - and returning it to him.
And I think the significance of that in our world is, we get really combative about what we believe in and what we do. And if you can actually find two people who are fighting each other - literally to the death, and sending men to their death - but yet they had the humanity to figure out how to return one another’s dogs - with a nice note, under sign of truce, I think maybe we can all learn how to get along better, and not treat each other so nasty in the middle of big arguments over technology and stuff.
Len: And you had a specific experience you related that to, I think it was you Russ, in your career in the Air Force. I was wondering if you wouldn’t mind talking a little bit about that.
Russ: Yeah. I think that was the Banyan VINES fight at the McGuire Air Force Base. We were deeply involved in an absolutely huge, knock-down, drag-out fight between Banyan VINES and Novell Netware. And I was on the Banyan VINES side - believe it or not - even though I was at C&E at the time. And I was studying for my CBE, but I thought VINES was a better technology - and so did pretty much everybody else on McGuire Air Force Base.
But we were basically overruled by the headquarters. And they said, “No, you, thou shalt use Network Netware.” And it actually ended up ending several people’s careers over it, because the reaction on it was so, so bad. And I wonder sometimes, I think part of that was just political scapegoating. But sometimes I think that’s just because we get emotionally invested in technologies in ways that are really, really unhealthy - and technical solutions in ways that are really, really unhealthy. And it helps really a lot if you can disengage from that, and just realize it’s a tool. It’s just a tool. It’s nothing else. You don’t fall in love with your hammer, and shouldn’t fall in love with your router.
Len: And what does it mean to have your career ended in the Air Force? I’m actually curious about that. When I read that in the book, I’m not exactly sure what that means?
Russ: Well, people were given low performance reviews for their participation in the whole project on the VINES side. Which essentially stops you from ever getting a promotion again. So the next time you’re going to re-sign up, or re-contract with the Air Force, re-enlist, you might as well not bother, because your career is stopped, you’re dead.
Len: And why do you think people fall in love with their router?
Russ: Because it’s such a beautiful shade of blue. I don’t know? I think that this is an ownership issue, and I think it’s healthy in some ways. There’s a pride in building a really nice building. If you’re a carpenter, you go out and you build a really nice building. Or if you’re an artist, you draw a really, really beautiful picture. And there’s pride of ownership in that - that’s really important, that drives you to excel, and that’s really good.
So in a technology situation it’s really good to fall in love with the technology enough that you really, really focus on, “How am I going to do an excellent job, and do the best I can to make this technology fit in my network, and do the best job that I can?” But the problem is that you need to be emotionally detachable in a way that allows you to say, “Okay, in the end I wasn’t right. That wasn’t the best solution”. Or even if it was the best solution, “I was overruled by somebody who thinks they know better, so I’m just going to do my best with what I have”. So I think it’s more a matter of, if you build the house, you own it. And because you own it, and you’ve built it, you have an emotional attachment to the work that you’ve done in that space, and I think that’s the way we treat technology.
Len: Daniel, there’s a section in the book on personal integrity, and I was wondering if you wouldn’t mind talking a little bit about what the both of you are saying in that section, and how it relates to one’s career as a network engineer.
Daniel: I think personal integrity is a lot about having values that you follow. So you should do learning in a proper way, not try to take short cuts, because if you do that, you’ll end up being punished later. Every time you try to understand a new technology itself, and based a lot on previous technology, so if you take your time in the start - and learn the basics, and learn the protocols - you’ll do a lot better further into your career.
Len: I actually had a question that’s specific about Cisco. I interviewed Nick Russo, who I believe both of you know, very recently. He’s got a new Leanpub book as well. And so, Daniel for example - you work for Conscia Netsafe in Sweden. But here you are in Las Vegas at a Cisco conference. And I was just curious about how that relationship works?
Daniel: Yeah, so we’re a systems integrator and a Cisco Gold partner. So obviously we try to keep up with everything Cisco is pushing out. So we usually have, like, four or five guys every year that goes to the US conference to pick up what’s new and what’s trending. Then we try to bring that knowledge back home and train our other staff, so that they get up to speed on those technologies as well. So yeah, always trying to stay ahead of the curve, and seeing what’s new.
Len: When we were speaking just before we started this interview, Russ, I think that you mentioned that there were 25,000 people there at the US conference?
Russ: Well, I actually don’t know what the number is this year. I know last year it was 25,000, and I think it’s probably that size or larger this year. I haven’t heard an official number, but I know that they’ve taken up the Mandalay Bay Convention Center, and it is - they’ve taken up every stick to the floor space in the entire Convention Center, and it’s huge.
Len: If someone listening was considering going into a career in Network Engineering, I mean it sounds like obviously it’s a massive industry, would you recommend it? Is it something that’s growing?
Daniel: Yeah, I think it’s really, really a nice industry to be in, because there’s a lot of things happening right now. In the last couple of years, it’s really starting to pick up pace with all the new technologies - and trying to move towards more automation and software-defined networks and everything. So it’s kind of interesting place to be. A bit scary at the same time, but also really rewarding if you take the time to learn these new technologies.
Len: Why is it scary?
Daniel: Because if you have a current set of skills and then there’s new job role sets asking for a new kind of skills, and if you don’t have them yet it can be, it can feel a bit scary - if you can learn those new skills or not….
Russ: Yeah, in the networking industry there’s a couple of things we always say. One is nobody has a job more than two years. I mean you just don’t know what it’s going to be in two years. So you just might as well plot your own career path, and not be too freaked out about, or too concentrated on working for one company for the rest of your life. Because it might happen, and that would be nice. But it might not happen, so emotionally prepare yourself for that not to happen.
And the second thing is we always have this thing about the half-life of any skill being about two and a half years, so anything you learn today is generally useful for about two and a half years, then it starts to taper off in its usefulness. In about five to seven and a half years, it’s generally old enough that no one cares anymore, and this actually speaks to the whole concept of what Daniel was talking about before.
When you learn a protocol, or when you learn something from new - you need to learn the theory, and try to understand it. And understand it at a level that helps you relate it to other things, so that you’re actually building a level of knowledge that’s not just surface knowledge. I don’t just know how to configure something. I actually know how it works, so then a new technology comes along that’s similar, I can take that knowledge that I have, and I can actually push it into the new concept or the new technology - without having to relearn a whole lot of information.
Len: Going way back, Russ, can you think of an example of something that was extremely important at the beginning of your career that has disappeared? Maybe because of that two and a half year half-life?
Russ: How many do you want? X25, Token Ring, old SONET. Although SONET’s still around today, but it’s really more DWDM. And let’s see, ATM. Oh my goodness, ATM is like, in horrors. When I first learned networking, we were actually using Token Bus and Tap Ethernet ThickNet, which doesn’t exist anymore. And we were using Tommy Conrad ARCNET stuff, which is so far gone, that nobody even knows what I’m talking about when I say, “Thomas Conrad ARCNET” any longer.
So yeah, I mean there’s a ton of these things. But to make that example full - if you think about it - Tommy Conrad ARCNET stuff, or ARCNET, actually worked a certain way on the wire. It used a certain signaling pattern - and carried things in a particular way, and stuff like that. Well, those things really haven’t changed, even with DWDM and things like that. The principles are still the same. The bits are different, the techniques are little bit different - but the basic principles are the same. So in learning ARCNET in depth, and Ethernet ThickNet in depth, I’ve actually been able to apply that general concept of knowledge to everything I’ve learned since then, as far as physical media goes.
Len: You guys will have to forgive me if maybe one or two of the next questions I ask you are actually totally irreverent, because I’m not an expert in your field. One of you mentioned something about scariness. I was reminded of a recent pub table conversation that I had, where the concept of a giant solar flare destroying all the networks came up. I’m sure you’ve probably heard that one. It’s out there in the popular culture that something can happen that can fry all of our networks. Now I’ve got twp experts - and so I want to ask for all the pub table conspirators out there, is that true?
Len: Oh no. And why is that? Why is that true?
Russ: Well, every piece of wire acts as an antenna, and if you get enough power on the wire, you can fry the receiver that’s attached to that wire. So if you get a large enough solar flare, or what’s called an EMP - whether it’s natural or man-made, or whatever the case might be - you can actually fry all the receivers on all the wires, in the entire world, or in a particular region, pretty quickly - which would take all the networks down.
Now, you try to do things like using shield cables and stuff like that. There’s lots of ways you can try to work around it. But for the most part, these things are so fast and so powerful that it’s very, very difficult to counter them. There’s actually an incident in US history where this kind of thing happened in the 1800’s, and it took out all the telegraph receivers.
Len: In the country?
Russ: In the country. It took down the entire telegraph network in the country. Just this way.
Len: And so is this a once in a century, or a once in a millennia - or a once in a - a kind of epoch kind of event?
Russ: That’s a very good question, and I don’t think anybody actually knows the answer to it.
Len: Okay, okay. Well now we can all be a little bit scared.
Daniel: I know that Russ has worked with radars as well, and I’ve seen some incidents in that space, and I think it’s like somewhere around every six to eight years they have some kind of incidents due to like the solar energy effecting the radars. So it can happen.
Len: And would it affect undersea internet cables?
Daniel: Not sure about that. I doubt it, but–
Len: Well thank you very much for answering that question. I was wondering if either one - or both of you - has an opinion about how the world will change for the general consumer, if and when we get to a point where we’ve all got gigabit per second connections?
Russ: Well, tough question. So we’ll all be uploading videos, and there’ll be so many videos, none of us can watch them.
Len: Live streaming all the cats in the world at once, or something like that?
Russ: Yes, that’s exactly right. We’ll all put little cameras on our cats, so we can all watch each other’s cats all the time. And no one will be watching anyway, except the other cats. I don’t know? You almost wonder how much more information we can tolerate. We’re already sipping from a fire hose, and I just wonder how much more we can tolerate. I mean, you think - well - there’ll be machine-to-machine, sure. But then that’s almost scary too right? Because now I have machines looking at things I’m not looking at, and making decisions about things that I’m not sure I want them making decisions about.
Len: So are you on the Elon Musk, Stephen Hawking side of worry about AI then, Russ?
Russ: Yeah, actually I am.
Len: It’s a really hard question, and I think it is something that people should be concerned about.
Russ: Well, go back to philosophy, right? That’s one of the things - we all know our networks, and we know our technologies. But we don’t think about the ethical impacts of those things, and what it means philosophically and culturally. And, so we tend to just run off and go do what we can do, and we don’t think about what we ought to be doing. So that’s one of the reasons I find philosophy so fascinating.
Len: On that topic, what is the subject of your thesis, if you’ve decided one yet?
Russ: Oh wow. Thesis, dissertation or degree? The degree is in Apologetics and Culture. The dissertation is in the unintended side effects of the technological revolution. As a matter of fact, that’s actually what I’m writing on.
Len: And what are some of those unintended facts that you’ll be focusing on?
Russ: I’m looking at things like the Stanford Prison Experiment and the Panopticon, and how people change under observation, and how that impacts our social interactions on a personal level. My professor - my major professor - actually will not buy things from online retailer, because he values the personal interaction of actually walking into a store, even if he doesn’t know the person on the other side of the cash register at a personal level. He just values that human interaction so much, that he refuses to do a lot of things online as far as buying goes.
So, I’m trying to look at those types of things, and look at how communities react, and whether or not it fragments communities, or, in what ways does it solidify communities, in what ways does it fragment communities? And then going beyond that - that’s the problem side of it, but maybe eventually start thinking about, well, how do you try to ameliorate some of this? How do you actually try to counter this in a way that’s intelligent? Or can it be countered? I’m not really even sure it can be, but–
Len: You mentioned the concept of the Panopticon. And for anyone listening who’s unfamiliar with that idea - it was developed by Jeremy Bentham, I think, in the late 18th century? Maybe the early 19th century? If you’ve ever seen an image of a prison that’s in the shape of a circle, and there’s a guard in the center - who can just, kind of, turn around - and then see all the cells arranged around the periphery of the circle, that’s a Panopticon. Or one version of a Panopticon. And the idea is that, you can make it so that everyone can be simultaneously observed. I guess this is one way of explaining it.
Russ: Without the guard being observed. That’s the interesting thing, is the original one was set-up with all these mirrors and stuff. Well, it was never really built, but it was designed with mirrors and stuff, so that the prisoners could never tell when they were being observed, but the guard could. One guard could observe every prisoner.
Len: That’s right. I forgot that very important part of it. The sort of brilliant and terrifying efficiency of the idea was based on the idea that the guard couldn’t be seen by the prisoners themselves. So they could actually be in a situation where they’re not being watched, but they don’t know. So they have to behave as though they’re always being watched.
Len: This is a fascinating metaphor, and I think extremely relevant in our era, where people are walking around - not so much with Google Glass, although that might come back now that Pokémon Go is a thing - but people are walking around with their phones everywhere, and those phones have cameras on them. And in a sort of analogous way, anything you do on social media can immediately make you a global villain or celebrity. And because everyone can suddenly see it, there is a sense, in which, in our world nowadays - I guess unless we’ve plugged out in some way, or we’re avoiding people - we sort of all have to act like we’re being watched, and I guess there might be a connection between that, and what you guys are writing about in your book - in your way. Which is it’s sort of a set of guidelines for how to behave in a professional context, where one does need to act like everything one does is going to be assessed, and is being watched.
Len: I guess there’s not a question in there, more of an observation. But yeah, on that note - what led the both of you to blog about these subjects, and then to get together and write a book about it? I guess Daniel, if you wouldn’t mind answering that question?
Daniel: We’ve both been blogging for several years, and I kind of started out blogging when I started studying for my CCIE. And as I progressed in my career, I got more interested in network design and architecture, and more about some of the soft skills. And I noticed that there wasn’t a lot of people writing about these things, and I thought that some of the things were missing for people, to be able to get the information on how to develop their careers and their thinking.
And then I started to get to know Russ, and I had noticed that he was like the main guy writing about these things. Like the General Howe story, and these kind of interesting blogs about how to think. And I got in contact with him, and asked if he wanted to do some writing - and that’s how we got started. So we started to take all of the stuff we had already written. And then we did some new writing, and starting to edit it, so it could flow a bit better in a book form, and hopefully people find it useful. We’ve already received some feedback from people that it’s kind of unique content, and that they’re enjoying it. So hopefully it’s a decent-size book that’s easy to consume, and that will help you progress in your career and thinking, and that’s the goal of the book.
Len: And if you had some advice to give to any budding engineers listening to this podcast - if you could just get one thing into their heads at the beginning of their career, what might that be?
Daniel: I think that goes back to what we mentioned earlier. To take your learning seriously, and learn the protocols - so that you can apply new knowledge later. Try to think about why things work in a certain way, and not just learn the bits and bytes about things. Because then that will keep you from progressing your career as rapidly as it could be if you were thinking about these things.
Len: Russ, I was wondering, you’ve written a few books, and also you’ve co-authored more than 40 software patents - I was wondering if you wouldn’t mind telling us a little story about maybe one of the bigger challenges that you’ve had in your career, where you overcame something?
Russ: A challenge. That is a hard question. So let me think. In the soft skill side, one of the hardest things for me to overcome is I’m actually a pretty big introvert, and so I’ve had to school myself particularly in public speaking. I started doing public speaking maybe 20 years ago almost now, and it’s still nerve wracking, many times when you’re up there dealing with things.
So I think one challenge I’ve had to overcome in my life is that - this whole thing of just not liking crowds, and not liking being in front of people and speaking - which I have come to peace with, I’m okay with it. And the biggest way I did it was just - if you’re afraid of heights - you go to the Empire State Building, and you walk out on that glass thing. And you look down, and you go, “Hey, I did that and nothing happened. I didn’t fall, and I’m okay - so maybe heights aren’t necessarily so bad”.
I wouldn’t say it’s that easy to overcome. But what I have found, is when I face challenges like that, I just need to practice and be intentional about it - to be intentional about what I’m learning. So I think that’s one thing; when I first started, I was really afraid of being in front of people, and being around, and being in big crowds. And I went to the ITF, and I pushed myself to go to the microphone and make comments. And I was called stupid, and I’m still called stupid today - so that’s okay, I don’t really care anymore though.
And so, I think that’s one of those things that you have to overcome - the emotional connection to your work. The first time I wrote a book - you almost feel like crying the first time it comes back from an editor and it’s all completely red. So you go through that a couple of times, and you just have to learn how to emotionally detach yourself from those situations, enough that you can work effectively, and be good. So I think those are the types of things that I think I’ve had to overcome in my career, that have taught me more about being consistent, and being intentional when I’m learning, and how I’m learning.
There’s technical challenges. I mean there’s always technical challenges that you run into, and it’s that same skill set. You’ve just got to pursue, and just keep going, and keep trying to learn things - to get to the point where you feel like you’re skillful enough to actually do the job.
By the way, we all feel like imposters. I don’t know if anybody has ever brought that up on your podcast, but every engineer in the world feels like an imposter. So if you have a listener out there who’s listening to this podcast, and says, “Yeah, but I’m not as smart as you” - yeah. Well, I’m not as smart as you think I am either, so it’s fine. We’re all imposters.
Len: That’s really interesting. I don’t know if anyone has brought that up before. On that note, I was going to ask - I mean, one of the things about people who come to Leanpub, and who we then interview on the podcast, is that they’re like the both of you. They’re writing, and whether it’s easy or not, putting themselves in public, and being called up to speak at conferences and things like that. I was wondering, is that conventional for people developing careers in your field, to do what the both of you are doing? Like blogging and making books, and speaking at conferences, and things like that - or does that make you exceptions? And you can brag if you want.
Daniel: I think blogging is probably a lot more common than writing a book. Writing a book takes a lot more commitment, and it can be challenging - like Russ mentioned, to go through all of the editing and stuff. And normally it’s not very rewarding financially either, unless you’re writing something for the masses. So people don’t really see a big return on investment from a purely financial perspective. But on the other side, you go through a learning process. And also it can be a good way to meet with people, and to learn to connect with other people. And also it could be nice to put on your resume, that you published something.
Len: And did you both go self-impose an editing process on yourselves for this book, or did you get the opportunity to forego some of that this time around?
Russ: Yeah. I think we kind of cross-edited each other’s work in a way that was helpful. Finding things that needed to be fixed, and making it flow better - that’s a skill in and of itself. So we actually did not hire an editor, but we did cross-edit, and we did pay attention to what we were trying to do a little more carefully than we might have perhaps with a blog post, or something like that.
Len: Thanks very much. That kind of practical knowledge is really important to people who are setting out to write books, and to know that it can be achieved that way, and that you can get quality work in the end.
Russ: Yeah. I think it’s important if you’re doing co-authors to have each person cross–read the other person’s material, and edit it. Because you want to get as close as you can to one voice in that situation, which is pretty difficult to achieve in a lot of cases.
Len: Yes, definitely. I can only image how the interaction must have to work in order to write a book with someone else that way. I have one question about - sort of a selfish question, to ask both of you - about Leanpub. Now that I’ve got you here, if you could wave a magic wand, and have us build a feature for you - or fix a problem for you, what would you ask for?
Len: The answer can be nothing. I mean that would be kind of fine from our perspective.
Russ: I think from the publishing end it works really well. I mean, you could guarantee each author 10,000 sales, but I don’t see how you’re going to do that, so–
Len: We’d love to be able to do that.
Daniel: I think it’s been easy to work on the platform, and it’s nice when you’re co-authoring something, because some of the other platforms won’t let you do that easily, and split the income and stuff, so yeah.
Len: Oh, thanks for that. Yeah. That’s something we don’t think about all that much. It’s just something we built when it was pulled out of us by people asking. And we’re like, “Well of course, people should be able to coauthor books easily”.
I guess I just have one last - and I’m switching subjects pretty dramatically - but one last question about your work, is related to energy sustainability - it’s something people read about in the media when it comes to network architecture. Is that something that both, or either of you, takes into account in your work?
Daniel: Do you mean like green IT, or something like that?
Len: Yeah. I mean that in a very straightforward, from-a-place-of-no-knowledge perspective. I mean, is that something that day-to-day one has to build into one’s designs or concerns?
Daniel: Well, I’ve seen some cases where we could like, propose to our customer that they buy new switches, and the power savings alone would - they would have return on investment for, like, five years just by the power alone. So that’s kind of a good way to both be a bit more environmentally friendly, and save some money as well, so there’s definitely some use cases for it.
Russ: Yeah. In the hyperscale environment, of course, the data centers are built all around energy usage - it’s a huge, huge deal for us, how much energy we use per server, per amount of compute, process type of things. We’re very tightly controlled in our data centers on how much energy we use to do a particular task.
Len: Okay, well, thanks very much guys, for taking time away from the exciting conference to talk to me. I really appreciated it. I certainly learned a lot. And it was great to have such a wide ranging discussion about so many things. So, thanks very much for taking part in the interview, and for being Leanpub authors.
Daniel: Thank you, Len.
Russ: Thank you, Len. This was great.
published Aug 06, 2016
Janelle Klein is the Austin-based author of Idea Flow: How to Measure the PAIN in Software Development. She is the CTO of the recruitment consultancy New Iron and founder of Open Mastery, a network for peer mentorship based on data-driven mastery of software development.
In this interview, Leanpub co-founder Len Epp talks with Janelle about her career, the ideas and experiences that are the inspiration for “Idea Flow”, the concept of “Idea Flow” itself and how it can transform the relationship between developers and management to profoundly improve productivity and quality, and at the very end, Janelle also talks about her experience self-publishing on Leanpub.
This interview was recorded on May 27, 2016.
This interview has been edited for conciseness and clarity.
Len: Hi, I’m Len Epp from Leanpub, and in this Leanpub Podcast, I’ll be interviewing Janelle Klein. Janelle is an Austin, Texas-based NFJS tour speaker and technical mentor. She’s the founder of the Software Mastery Circle [which is now branded as “Open Mastery” - eds.], which is dedicated to data driven software mastery and aligning the interests of business and software engineering. Janelle is the CTO of the recruitment consultancy, New Iron, that specializes in building software teams.
Janelle is also the author of the Leanpub book, Idea Flow: How to Measure the PAIN in Software Development. The book is about the hugely important topic of technical risk management and presents, in Janelle’s words, “A modern strategy for systemically optimizing software productivity with a data driven feedback loop by measuring the pain, or friction, in developer experience. People can identify the biggest problems, understand the causes, and run experiments to systematically learn what works.”
In this interview, we’re going to talk about Janelle’s professional interests, her book, her experiences using Leanpub at the end of the interview - and ways we can improve Leanpub for her and other authors. So thank you, Janelle, for being on a Leanpub Podcast.
Janelle: Thank you for having me.
Len: I usually like to start these interviews by asking people for their origin story, and I was wondering if you could tell us a little bit about how you first became interested in Agile and software development.
Janelle: Sure. I’ll start from college - well, slightly before college. When I graduated high school, I ran off and married my high school sweetheart. Not the best decision I ever made. But that got me running off to California to be a professional song writer and following my dreams.
And then I got into college, and I started to realize what a career in music might actually be like. And it just sort of sucked all the passion out of me, thinking about having to write to make money. And I knew absolutely nothing about software development. We had a computer growing up that I played lots of games on. So I’ve always been a huge, avid gamer.
And my ex-husband at the time - he was in the military doing network management, computer-y stuff, kind of a hardware geek - he’s like, “Let’s take this assembly programming class. That’ll be so cool. Assembly’s like awesome. It’s all this low level cool shit, right?” And so I was like, “Okay. That sounds like fun.” So we went and took this assembly programming class, and I was like, “Programming my calculator in math class, I can figure this out.”
I got basic instructions, and I started writing reams and reams of assembly code. I wrote the game, Breakout, with the paddles, and all that, completely in Assembly, with the full 256 colors and little music and beeps when the thing hit the wall - just completely in Assembly. And my teacher was like, “Well, at this point, just show me what you’re working on. You can work on whatever you want, and you get an A.” And I’m like, “That’s cool. I should take more classes like this.”
But that moment really changed things for me, because it was this moment of unlimited exploration - where I can go and create anything I could dream of. It was this ultimate kind of artistic medium, and that’s when I fell in love with software development. I’ve had one experience after another, that’s been this giant open-ended problem of following whatever dreams that you might have, and turning ideas into awesome tools. As I’ve learned how to do that with other people, it’s been one of the coolest experiences imaginable. And really, software development is very much a love of my life.
Len: That’s a fantastic story. When I’m interviewing Leanpub authors, many of them are in software development, and it’s curious - I think at this point, it’s now less than half of the people I’ve interviewed who end up in software, took something like computer science in university. People come into software development from so many different directions. I was wondering how you ended up at New Iron doing consulting work?
Janelle: So I ended at this kind of strange company, New Iron, doing - I mentioned it’s a software niche recruiting company, or you mentioned that in my intro - I started working for New Iron just as a contractor on this project at a semiconductor company. I got really involved in semiconductor, and lean manufacturing and supply team optimization and process control. And doing back end, high volume data automation stuff, and problem-space wise, it was really cool.
But as I started to learn more about lean - because the company was all about everything lean - I started to get involved in their lean consulting program, and teaching lean practices around the company, but in the context of software development. After figuring out how to solve the problems on my own project, and just getting better at software development, and how to figure out what your problems are, and turn around a failing ship, I got really good at helping other people to solve those problems.
And so it was never really that complicated in consulting. The main thing I discovered is that the job of a consultant is essentially to come in and identify the elephants and point to them. Usually, if you just listen to what people are saying, they’re already talking about what all their problems are. A lot of the time, I’ll just echo the same things that the team is already saying, and just explain it to management - but with a nice Keynote and explaining things in management-speak.
And suddenly all these communication problems where engineers couldn’t talk to management became my niche. It was figuring out how to communicate all this pain with metaphors and stuff, so that I can bridge that gap. A lot of the failures of projects are caused by these problems, with this inability to communicate. And so, with consulting, it was kind of a natural niche for helping out with that.
And then with New Iron, since we specialize in technical assessment and developer mentorship, I’ve got to focus on teaching people, doing a bunch of stuff with community, mastering the art of technical assessment, and teaching people how to build more effective teams. I mean, it all kind of went together with consulting.
In school I almost got my PhD, but I decided not to, because I was really eager to get into industry, and I really enjoyed like all the HCI kind of stuff. I always had this love of science and research. And I thought about going back to get my PhD, and then realized, “You know, I don’t need a need a degree to be a scientist, right? If I want to go and do research and learn about problems, I can just set up my own little research lab and learn about problems.”
And so I started treating developers kind of like guinea pigs, and set up a little lab in my work environment, and then started codifying the things I was learning about how to teach the art of software development into patterns and principles using these tools. A lot of that learning created the basis for Idea Flow. So I didn’t scare everybody away. I decided to write my book as kind of a first person narrative story of my own experiences, so it didn’t read like a dissertation.
Len: I’m really looking forward to actually talking to you about your book. It’s really interesting. I just have one question I’d like to ask you before we get to that though, which is about - there’s a line, I think, on New Iron’s website that says, “Being a good developer doesn’t make you a good interviewer.” This is something I’ve been reading more and more about in the tech press lately. It’s become a little bit of a meme, I guess, especially in relationship to people with various kinds of disability. I was wondering how you would recommend people hiring software developers to approach giving interviews?
Janelle: I think the main piece of advice I would give developers, is to focus on testing decision-making abilities - rather than current, active skills. The profession of software development is all about being a professional learner. It’s knowing how to find and look up information - how to break down problems, and how to learn your way out of a broken situation.
And so what I eventually came to is, that we need a method of technical assessment that focuses on assessing a person’s capability to reason about problems and navigate trade-off decisions. As opposed to, “Do you know what TDD is?” or “Can you write a unit test?” Because at the end of the day, it’s not about what you can do right now. It’s about what you can learn when you’re on the job. Because you’re never going to be faced with the same problem and the same challenges.
I mean, this industry changes so fast. We’re professional learners. We’re professional problem solvers. And that’s what makes people good, is their craftsmanship skill, that comes from years of intuition based around problem-solving, is really what skill is. And that’s what we need to be assessing for. So the main thing I do is put real problems in front of people. And then I ask them lots of questions to poke into their reasoning process, as opposed to, “Can you get from A to B?” It’s about, “What kind of options are you exploring?”
Len: Do you recommend doing things like asking riddles to see how people respond to unfamiliar questions?
Janelle: I’m not good with riddles, so it’s hard for me. Yeah, probably not answering riddles. I would hate to be given a riddle in a - I guess the other thing I’d say, is that when people get nervous, their ability to make intuitive leaps to solutions generally shuts down a bit. But their recognition skills don’t. If you put something in front of somebody, and they don’t recognize that there’s a code smell of sorts, or some problem with things, then that’s usually a sign that something is actually wrong or missing.
Whereas, just because somebody can’t come up with a right answer - it’s just the world is not that black and white. And I know technical assessment is really hard. For example, with respect to certifications, we’ve been working on a way to systematize technical assessment, so then I could teach other people how to do my interview technique.
It’s taken us a decade to figure out how to do that. But a lot of people punt on the whole certification problem, because, “It can’t be done, it’s too hard.” There’s so many problems with commercialized certification in our industry, that everybody is like, “Oh well, we shouldn’t even try, because it’s just going to cause so many problems.”
I think we need to move toward more of a model, where it’s open certification. Where we’re testing decision-making skills, and it’s an industry public debate about working on getting better at this, as opposed to just giving up on the problem, because it can’t be done. And just make technical assessment a free standard, almost, that we work on together as a community. Because we all benefit from having a clear definition of what good is. I mean, we need that.
Len: Yeah, definitely. In that context, I’m curious what you think about nervousness in interviews and things like that? Because the interview is a situation that the person will never find themselves in again - more or less, if you hire them. They’re going to then be working. And so people can be nervous in interviews, but not nervous when they’re not doing their work.
Len: I was once interviewing someone who’d just finished a masters in maths at Cambridge, and failed to do basic arithmetic in response to a question. So I knew what the interviewee was capable in normal circumstances, but not in the stressful circumstance of an interview. And so even the best certification or qualification - or something like that - that someone comes into the room with on paper, can sometimes not translate in an interview, but can in work. I was wondering if you advocate giving people problems to take home and solve or something like that as part of the recruitment process?
Janelle: I don’t really do take-home problem solving kinds of stuff. I mean, I certainly see the benefits. But the main problem I have the take-home thing is that it takes too long, it’s too much work. In a market where everybody’s hiring, and there aren’t enough good people, the last thing I want to do is go an create more barriers to entry to hiring the right people.
And so we’ve basically focused on, how can you get the maximum amount of information to make a quality decision in a limited amount of time? Because the take-home thing has to be scheduled around life, it’s much easier to get people to show up for a scheduled one hour call. And then I basically do that with video sharing and stuff, so I can throw code up on the screen and ask people about it. We’re all about optimizing the time spent in that.
And then the other things I do, for the onsite, are a code pairing interview, and then something that’s more design-focused. So I tend to focus on core skills, as opposed to, “Do you know whatever trivia?” Like whether you know ordering of some… I don’t know? There are some things that are just - Computer Science-related kinds of questions, that are so far removed from what we actually use on a day-to-day job - I’m much more interested in people’s everyday problem solving skills. Can you refactor this code? Can you work with the people on your team? Are you an asshole? Those kind of things.
Len: That’s a really great and very practical answer. I don’t know how much of your work actually is recruiting people in Austin, but I can imagine the competition for good developers there must be really high.
Janelle: Yeah. We pretty much only work in Austin. We have some stuff going on in other states from clients that have multiple sites in most locations, but we’ve always been very central here. And then since our company is run by software folks - it’s kind of interesting how we ended up in software development.
New Iron used to be a product company that built a first generation web services stack. We’re out in California, and I thought, “Oh, we’re going to build this awesome product, and everyone will buy it because it’s so awesome.” Obviously that wasn’t a very good business strategy. And so we’re sitting around going broke, basically, and we got a call from an old client that we used to work with, and they’re like, “Hey, can you guys help us on this consulting project on the software?” And we’re like, “Money, no money.” And so, easy choice, right?
And so as we started consulting there, they’re like, “Do you guys know anybody else that can code?” And since we already had a vendor agreement set up, we just started talking and recruiting all our friends. And we did full-on interviews for everybody, not having any idea how the recruiting industry was supposed to work - that nobody does this kind of thing.
And so we started getting really good at technical assessment. And that sort of became our niche. Because it’s hiring people, and figuring out what skills you need, versus what’s available on the market - and having unrealistic expectations about hiring Superman, and that you can instantly take all these things that you’re deeply familiar with and say, “Oh, now you do this job.” There’s so many companies that have so many unrealistic expectations about it. Because hiring isn’t a first priority in a lot of companies, so people don’t necessarily put the time into it that it needs and deserves.
Yet it’s so important and causes so many problems when you hire the wrong people for the wrong things. And so we got a lot more involved in understanding what our clients actually are trying to accomplish as company, as a team, and help them to come up with a realistic strategy that they can actually find a gap they can fill, as well as the gap that they can sell. Beause in this kind of market, if you have a job for, “Oh, this is a Java development position like so many other Java development positions.”
Len: One thing one reads about in the press around recruitment is the way that employers or recruiters will sometimes look into a person’s internet history. And I was curious if that’s something that you recommend employers do?
Janelle: Internet history in terms of, like, what they post online?
Janelle: It’s not something we do in that, generally speaking, we focus on whether the developer has the skills, is able to demonstrate the skills, as opposed to any kind of past history kind of thing. I think since we have a really good process for technical assessment itself, it’s like everything else is almost irrelevant. In that, if you’ve got one year of experience, but you can bring it when it comes down to sitting in front of a computer and solving a problem, you know what? I don’t really care if you’ve only been programming for a year. I’ll just think you’re awesome.
Len: That’s a really fantastic answer, I’m glad to hear that, that sounds very reasonable.
Moving on to the subject of your book - which, by the way, I really liked - you start with a pretty dramatic story about your experience working on a statistical process control system for a semiconductor factory, I think. And you mentioned the elephant in the room before. In that particular experience there was, I guess, a sort of invisible elephant there. I was wondering if you could talk a little bit about that experience and its impact on your approach to complex software engineering projects?
Janelle: Wow. Okay, that’s a big question.
So in terms of the experience, I was on this project with this really great team - really smart people. We had test automation, CI, great team, disciplined practices. And despite doing all the things that we’re supposed to do, our project basically crashed and burned and hit a wall. And by hit a wall, I mean we brought down production three times in a row, and then didn’t ship again for another year.
And the third time this happened - this is a 24/7 operation, so downtime is a really big deal. And the last release, the third time we brought down production. Not only did production go down, the rollback failed. And then the feature toggle that disabled the broken stuff failed. And so we were up at like three in the morning hacking out a patch fix to, just so we could get the software out of production while everything was down. It was the most miserable experience you can imagine.
And this was shortly after I’d been out of college. This was my second job out of college. I was kind of a little hotshot, and had my head in the clouds, and thought I was awesome and that I was pretty much infallible. And I had this great idea that would improve performance to basically flip the architecture inside out and do this massive set of changes. And, of course, I put that all in production all at once.
It’s just one of those huge lessons in your career that you never forget. And that really fundamentally changed the trajectory of my life. Especially since all these things, I was like a super TDD zealot-type at the time. And so I was convinced that our success was all about whether we were following the right practices, and whether we were doing disciplined TDD in our project. That was the thing that mattered.
And when I was doing all this great stuff, and I failed anyway. It was the most foundation-shattering experience that I could’ve ever imagined. And so we got together as a team, and we’re like, “What the hell are we going to do?” Because we’ve been doing everything right, but we’re failing anyway. And so we built this tool that could detect high risk changes in the code, because we thought the problem was technical debt building up over time. Same problems we always talk about are causing the pain.
We thought we could use this tool to let us know where we needed to do extra testing, by identifying the areas where there are changes by tech debt code. But what we found was that most of the mistakes were actually in the most well-written parts of the system. And so we started digging around in the data, trying to make sense of what we found. But there weren’t any answers that made sense and correlated with what we knew about software development, and what we’re supposed to be optimizing for.
The correlation we did find in the data was that a lower familiarity with the code tended to increase the likelihood of mistakes. And while that made some sense, it seemed like there had more to the story than that. Because when we had to work with complex code, it was really painful. And so we started down this path of trying to understand, “Well, what it is that makes development feel painful?” And so as we are working, we started collecting all this data on where we were experiencing pain, and then talking about the specific things that were causing the pain, and keeping measurements about how long all these various things took, and just writing up the things that seemed like our biggest problems on a whiteboard.
It wasn’t until we started down this road of collecting data, that we realized that we’d been essentially solving all the wrong problems. We had all this test automation, but the test didn’t catch our bugs. And we had well modularized code, but it was still really difficult to troubleshoot all the defects. And then we started looking at the specific things that were causing our pain, and learning with the data-driven feedback loop, we realized that most of the problems were caused by human factors that were, how a human interacts with the code while they write.
And so that’s where this whole technique of measuring development experience came from as a means of feedback. Because it was the only thing that seemed to really matter at the end of the day was whether it was easier or harder to do our jobs. And if we measured that, data became this unifying force on our team where it really brought us together in learning how to learn together.
And at the time I had this experience, I couldn’t put what I’d learned into words. But I knew that I wanted to teach it to other people. And so after I read Peter Senge’s book, The Fifth Discipline, about how to build a learning organization, I was so inspired by these ideas that I was like, “Alright, I need to figure out how to write this down.” Because this is the essence of what Peter Senge is talking about in his book – these five disciplines of a learning organization, and learning how to learn together.
Essentially, I found this really tight correlation between science and learning organizations. And then when we start using this scientific method-ish process to learn and examine the data and have a shared direction of better, that we’re all reaching towards, that suddenly it unifies a team in a really cool way. And I’ve been fortunate to have some really incredible experiences working with just amazing engineers, where we learned how to learn together as a team.
And so it wasn’t about what practices we were using. It was about whether we could identify the right problems to solve. And once I learned how to identify the problems, the rest of it was easy. I got a team of professional problem solvers. So that turned into the skill that I wanted to figure out how to teach. Even though it was hard - even though we didn’t have words in our vocabulary to describe the things we’d learned - I was determined to figure out how to do that, and to teach these things to other people.
Len: And when you talk about the data gathering, I know from reading your book that there’s very specific things around that. I was wondering if you could explain a little bit about what the data is, and how the gathering takes place.
Janelle: Sure. So I’m measuring, specifically, troubleshooting, learning, and rework. And we have tools that integrate with the developer’s IDE that are partially automated, partially manual. From a time-tracking perspective, it’s a lot different than managers wanting us to track our time in JIRA, because there are tools created by developers for developers to use to understand what their problems are.
So we’ve always kept management out of the data. It’s like, “We’re doing this for us, go away.” We’ve come up with better ways to automate things over time, but essentially - let’s say, when we’re writing code, we go through this cycle of, you write a little code and work out the kinks over and over again. And when you get to that point after you write a little code and you’re validating things, you’ve kind of got a prediction in mind of what you’re expecting the code to do. And at that point, there’s a decision point in our brain. If the code does what we expect it to do, we write a little bit more code. And if the code doesn’t do what we expect, we go into this troubleshooting mode.
And what I found is that, moving forward, modifying more code, learning - basically figuring out what you’re going to do, can take a whole lot of time, especially now that 90% of our software’s built from existing parts. Or, if you’re unfamiliar with the code, learning is a substantial part of our work that gets in our way. And on the troubleshooting side, we’ve got to troubleshoot the problem and then do rework to put things back in place before we can move forward again.
And so this flow of ideas between the developer and the software, and the friction in that flow - I’m measuring in terms of troubleshooting, learning, and rework, and then actual duration of those times. Then, we have a general rule on the team where anything that takes longer than 20 minutes, we talk about, and try and understand what the causes are that made this incident so painful. And it’s always a kind of gut-feel type factor. In some one case, 20 minutes is not much time. In another case it’s way more time than it should be. And so you kind of just talk about the things that are worth talking about. Don’t talk about - it’s just kind of noise.
Len: I find the importance that you place on pain to be really fascinating. I have a sort of specific question I’d like to ask about that. But first I’d like know if you could maybe define a little bit about what you mean when you talk about pain?
Janelle: So in this context, I’m relating pain to friction in idea flow. The reason why I use pain specifically is for a couple of reasons. One is that I want people to focus on the symptoms, as opposed to the cause. Because one of the problems we having our industry is automatically assuming what the cause is of the pain - like it’s this ugly code I have here, as opposed to focusing on the symptoms, and our experience, in working backwards.
And so, I use the word pain specifically to get people thinking about, “Well, what are the symptoms?” And then let’s have a richer conversation about what are the potential causes. Because usually most problems have multiple factors. And I think that’s one of the places that developers tend to get stuck on best practices, as it’s very solution-focused.
The other thing is that intuitively - just from experience - pain is associated with this idea of something that we want to avoid, and figure out how to have less of or reduce it. And from an optimizing, idea flow standpoint - that’s kind of the message I want to relay. There’s this thing that is a threshold thing that we want to keep in check to a level that we can deal with it. It’s not about eliminating pain. It’s about figuring out how to optimize and manage the pain so it’s at a tolerable level, and stays that way.
Friction - even though I’m associating it with pain - it often doesn’t totally correlate with what developers are using that word for now. For example, one of the perceptions that’s usually really far off in software development, is just our notion of what takes a long time. And one of the things that happens is when we’re busy working on a problem and doing stuff, time seems to zoom by really quickly. Whereas when we’re waiting on something to happen, like waiting for something to execute, it feels really painful, because we have to wait all that time for that thing to get done. And time seems to go really slowly.
And so when you start looking at things in terms of elapsed time, we feel like that thing that took five seconds was like an eternity, and that that was really painful. But then we’ve got all this time that we spent troubleshooting, that we don’t necessarily associate with pain - even though it takes an order of magnitude more time, in terms of human cycles. But because we’re busy doing stuff, and problem solving is fun even - doing things that are fun, we seldom associate them with being painful, right? And so I was trying to create this mapping visually, to sort of remap our pain sensors to something that is explicitly defined, that we could all share this universal definition of, What is pain? Being things that slow down the process of idea flow, even though it takes some remapping of our pain sensors.
Len: It’s really interesting to me. One of the reasons why I liked your book so much, was that you talk about addressing pain as a problem, and you were saying just now that pain is something we want to avoid. One of the reasons I find it so compelling is that, that’s so often not true in management practices.
My brother told me a great story where I had a kind of apple-falling-on-Newton’s-head moment. When he walked into a big box store, there were two employees - one of an earlier generation, and one of a later generation. They were handing out flyers or something, wearing little vests. The younger person started walking off, and the older person said, “Where are you going?” And the younger person said, “To the bathroom.” And the older person said, “Make it snappy!” What occurred to me in hearing that story was that pain is something that people often use in managing others - in a sense, positively, right?
Len: They use pain as a tool to get the work done. I was thinking about what I’ve read about slavery, and the way there’d be an overseer watching people work, and cracking the whip, and making sure that they stayed active. And I just saw this line from that all the way to this box store, and these two people in vests, and in the way observation, and the infliction of pain is so baked in to various kinds of management practices. We don’t even kind of notice it, it’s so obvious.
I was interviewing someone recently, who said, in his first software job, he was a tester for the Australian government. [Editor’s note: this was actually at a call center, not as a tester for the Australian government. Sorry, Australia!] And whenever he left his station, he had to log why, including going to the bathroom and for how long - the humiliation built in to that.
Anyway, just to finish, the thing I find so interesting about managing software - and especially in a world where software is eating the world, and everything is being driven by software, it’s become this really important form of labor, but it’s invisible.
For example, imagine you’re in that long ancient tradition of the manager who watches, right? It doesn’t matter if you’re watching people sowing seeds or reaping the wheat, or working on a factory floor in an assembly line. You can develop all these practices around watching people. But with programmers, they’re just sitting there, right?
You can imagine being from that tradition, and then you get hired to manage programmers and you’re like, “Well, what’s there for me to do?”
What you’ve done in your book and your ideas is that you’ve like completely flipped it around, and abandoned this form of management - that’s so universal and so inappropriate for a world where software is important. People have attempted in so many ways to try and do metrics and things like that around the wrong things. And what you do, in my opinion anyway is, that you’re looking at exactly the right the thing, which is taking into account like the pain that people feel when they’re doing types of work, and then really thinking that through. So, anyway, I just wanted to say, I think that what you’re doing is actually quite revolutionary.
Janelle: That’s an interesting story and take on the management side of this. One of the other big target audiences I had in mind when writing my book was managers, and helping them to get a feel for what it’s really like to be a developer in this world. I don’t think - if you listen to the way managers talk and the way developers talk, it’s almost like we’re speaking two different languages. Developers use words like “beauty” to describe the code and “elegance” and “firefighting” and “explosions”. And all of our metaphors are in terms of art and war. And if you listen, it’s all about money and profit and bonuses and ROI, and all this money-related stuff.
And I think what we have to realize is that as software organizations, we’re basically building a business that sells profitable artwork. You need to think about the economy as a giant art contest. With software development, it’s very personal in that we very much invest our hearts and souls as software developers into our work. And then seeing your creation get stomped on by all this organizational dysfunction is an emotionally damaging experience.
And so there’s all this cynicism and struggle, and a feeling of helplessness that turns into contempt within our organizations. And we get these divided cultures, where you’ve got a management culture that’s all trying to raise morale through celebration. And there’s all this fake happiness, for a lack of a better word. And then defensiveness around not wanting to shatter the perfect illusion bubble. And so management is often really resistant to talk about problems and pain and things that are going on. Because then it seems like an reflection on them if they’ve got little red marks on their status updates, whereas–
Len: I can’t stop thinking right now, when you’re talking like this, there’s this infamous photo of the Yahoo executive team dressed up in Wizard of Oz outfits, that was being presented to the employees as this sort of like motivational thing. Like the leaders are all on board and sort of superstars, and then the total disconnect in the use of that image, and what’s really going on there.
Janelle: Yeah. I see so many managers that are really concerned about talking about the problems, and that they believe that it will bring down morale if they talk about the problems. But in fact it’s quite the opposite that usually occurs. Especially when you have data to have a conversation about, putting the pain on center stage, as opposed to fighting each other, and blaming other people for the problems - you have a beast to conquer. And then when you go and conquer the beast, then it builds camaraderie within your company, and it brings people together around seeking truth, as opposed to this culture of imagining the world that we wish we had and trying to will that into existence through celebration. Or the after work drinks and bitching about our jobs, and how nothing’ll ever change and how everything’s hopeless, which starts to breed this undercurrent of contempt in our organizations and, emotionally-speaking, people are very much going to war.
I see a lot of these problems in organizations across the industry, where our software problems create cultural problems, and have a huge effect on the lives of human beings. I’m hoping that these ideas catch on from a standpoint of a strategy where we can bring the art side of the world together with the money side of the world, and realize that we can have both.
Granted, it takes a lot of work to figure out how to get there and how to learn together to optimize the whole. But at the end of the day, you build something beautiful. And software organizations become about working together to bring something awesome into the world. And then when you’re competing in the world’s art contest, you make money because you built something awesome. At the end of the day, I think those are the kind of things that human beings really care about - it’s having the opportunity to do something that matters, and to experience that with other people.
Len: It’s sort of central to your vision, your insight, into what people are actually doing when they’re engaged in software development. It flows directly from your basic premise - that things like pain, and things like the human element matter because it’s a human activity. It’s so interesting that we live in a professional world, where talking about the human element immediately requires a little bit of defensiveness or something like that, right? Because that’s supposed to be of secondary importance, and just a problem to avoid.
But your idea flow metaphor puts the human activity - it’s sort of like ontologically at the heart of what is really happening, because, as I understand it, the idea is that - well, I’ll quote you here: “That interaction with the code as a stream of ideas, flowing between me and the software, is a correct description of what’s actually happening in coding. That I have an idea that I try to express it code. And then that code is then used to carry out various things. And you can see whether my idea was translated properly by me into the code, and then properly read by the machine reading the code. And then the next step is when someone else is reading my code, have I correctly flowed my idea from its origin within me into them?”
I just find that so compelling because that actually is what’s happening, that we need take into account. I mean, one can say the human side of things, but just that it’s consciousness that is engaging with the machine through code. And to try take and consciousness out of it, is to completely misunderstand what this process really is. And that’s why it flows naturally that concepts like pain actually become scientific metrics to measure, because that is actually what you’re looking at - is a process of consciousness engaging with something.
Janelle: Yeah. One of the interesting extensions - I mentioned early on, using mentorship, and creating a developer lab to test these ideas - one of the ways I’ve been looking at idea flow as mentorship being, I have an idea in my head about how to optimize productivity, say. And how do I teach that idea to somebody else? That’s another type of idea flow, of sharing that idea. And the thing that I learned from that is that the only real difference between communicating something and teaching something is whether we take responsibility for whether that other person actually understood the idea or not.
And so, likewise, I came up with a method of testing whether a person understood by testing their ability to think through and make trade-off decisions in a variety of staged scenarios. That led to my technical assessment technique, too. This whole underlying concept of “What does it mean for an idea to get from my head into somebody else’s head, and how do we come up with an explicit, sort of scientific, method for testing whether that has actually occurred or not?” - has given me a feedback loop for learning how to become a better mentor as well.
Len: On that note, you talk about communication, which becomes very precisely defined in this kind of circumstance. You talk about the importance of metaphors. I was wondering if you could talk a little bit about why you think metaphors, and good metaphors, are so important for this process.
Janelle: So, I had a couple key influences with that. One of them is a book I mentioned in Idea Flow called Metaphors We Live By, which is a theory on human understanding as a fabric of metaphor, and that essentially everything we understand is in terms of other things we already understand, and that we build up understanding through relationships of metaphors. And so one metaphor, how it relates to another thing through metaphor, and then how those things are similar and different.
The book goes through a whole bunch of a examples in our languages, and comparing cultures, and how when you have a different foundational metaphor, you get a fundamentally different understanding at the cultural level. All of this cultural difference analysis - it’s a fascinating book, and it fundamentally changed the way I started looking at learning and improvement and communication, in that I started to think of my brain like a shape toy, and that I’ve got all these shapes that I know in the world. When I see a square, I sort of shove that into my shape toy brain, if you can imagine that. And in order to be able to recognize something else from my experience, I basically need to define a new shape. And so one of the feedback loops I discovered was that by explicitly defining new vocabulary - like looking at my experiences and then saying, “Oh, this is this pattern” and making up all these new pattern names for types of mistakes or for different strategies or problems in the code or that make troubleshooting take a long time or whatever it is - I basically built a massive taxonomy of patterns.
But in the process of doing this, I realized that I started to recognize things in my experience that I never noticed before, and that there was this feedback loop of, the more patterns I could develop in my vocabulary, the more detailed my observations were from my experience, and the faster I ended up learning. It was like I had amplified what I could learn from each experience, as well as giving myself all these awesome tools and connections for synthesizing information I’d learned.
And there was one metaphor that had a huge impact on my thinking. So Ash Maurya - he’s got a book coming out really soon called Scaling Lean - I went to a workshop of his like three years ago, when he first started working on this book, and he introduced this metaphor he calls “the customer factory”. So Ash focuses on lean startup practitioner-related material.
Essentially what he’d done is codify a method for practicing everyday science, and then mapped lean manufacturing to kind of a customer experience model. So if you imagine your business is like an amusement park, and you’ve got people lining up to the entrance of the amusement park, when they want to use your product and then, their first experience of taking the rides - that kind of thing. And then he came up with this way to measure and model the flow of different experiences through the business, and measure that and optimize what he calls “happy customer flow”.
And what was so fascinating about this, is it was like an experience business - sort of an experience-based supply chain model. And since all the stuff I started doing was in developer experience, as I started looking at the problems, I figured out how to build a supply chain model, mapping the same kind of metaphor idea to software development. But rather than the process flow that we normally think of as the supply chain, I was using the software dependency supply chain with experience-based data on top of it - how you experienced changing a particular software component, for example, and modelling across software dependencies.
And once I figured out how to do that, and optimize idea flow across the idea flow factory as it were - since my background is in process control and supply chain optimization from the manufacturing world - suddenly it was like everything I had learned from lean manufacturing, like clicked together with everything from Lean Startup. That clicked together with everything I’d been doing with idea flow, snd it was like this massive synergy of patterns that suddenly went together, and they were all linked together through metaphor.
Whenever I discover a new metaphorical link, it’s like all of these new discoveries and ways that you can make associations just fundamentally shifts. And I think the major revolutions in our industry always come with some kind of metaphorical shift.
Len: That’s a really fascinating way of putting it. I mean, you used some great metaphors in there as well - like the brain as shape toy interacting with the world. And customer experience as being like an amusement park, and that’s just amazing. I think you sort of proved your point by using those metaphors so well. Because it’s sort of like, when you successfully use a metaphor, it’s like a shortcut to communicating not just a set of facts, but a conceptual structure around viewing facts - and understanding what you’re actually looking at in a practical way.
In your book, you also talk about addressing the root cause of project failure in the software industry, and this is something I think is one of the most important things facing industry, I guess, generally today - is that as everything becomes software-driven, understanding the issues in software development becomes more important. In particular, we all see in the popular press these catastrophic software failures.
One of the ones that first come to mind for most people would probably be - or at least in the West - would be the Obamacare roll-out and how that failed. Up here in Canada, we’ve had our share of these catastrophic failures as well. I was wondering, in the context of your concept of idea flow and your book, if you could maybe explain what you think the root cause of project failure is in the software industry, and then by extension all of industry because it’s driven by software?
Janelle: I think there’s a few different core problems, but I’d say the one that’s probably more of the root would be our inability to share knowledge as an industry. We’re sharing this solution-centric knowledge with one another, and what I found is it’s not enough. The things that we really need to know in our industry are largely tacit knowledge, and they’re largely learned through mentorship.
As the industry is growing, and more people are getting into the industry, they’re not getting the kind of education they need in school to know how to do these things. We end up with more and more projects with people that don’t have the skills that they need to do their jobs, and don’t know how to communicate these things to management. And management doesn’t know how to understand what’s happening on the software project to make it be successful.
And the combination of what I’m referring to is the “wall of ignorance” between the management world and the engineering world - and how we’re basically trying to explain and describe our problems being completely understood, being one major factor. The other one is not being able to share our knowledge as an industry, or have any kind of universal definition of “better” that we’re aiming for. So it’s like we talk about brevity and modularity and test coverage, but all of these things are really kind of a means to an end, and we don’t have a way to describe what better really means, as the center point in that conversation.
I think that’s one of the big things that idea flow brings to the table. It’s that it gives us a way to share our knowledge on how to do this stuff. Because these projects that fail - it’s just sad. Especially when the taxpayers get stuck with the bill, of just mismanaged projects from people that are running things that don’t know what they’re doing, when that knowledge of how to run a successful software project, is very much knowledge that is within our industry.
If we could do a better job at, one, sharing our knowledge, and then even taking responsibility for public service based projects, and potentially running these things as open managed projects by the industry - as opposed to having the government having no idea how to build software and then running these broken software projects. It’s a tax burden and stuff that is completely unnecessary, because we can solve these problems. It’s not - I should say it’s not that software isn’t difficult, it’s that sometimes the failures are so unnecessary.
Len: It certainly looks that way from the consumer end of things.
Janelle: It depresses me a little bit that we end up wasting so much of our money on things that - for example, if we ran healthcare.gov as an open source project, I think things would’ve turned out very differently. If you basically had one, we could’ve had the thing happen for free, basically based on voluntary support. And because it was something that’s important to the people - I’ll bet you, people do a good job at managing that project. Just because a lot of people care. And we can build societal support based on just humans caring about each other, and helping each other to build the stuff that we need.
Len: It seems to me that - well, with government in particular, there’s the challenge that being skilled at getting government contracts, and being skilled at building software, are two very different, and perhaps, incompatible things.
You talk about the “wall of ignorance” between sort of people doing software development and managers. I think that from conventional management perspectives, there are so many things about software development that are just new and counter-intuitive.
For example, if you’re a typical manager - and I’m going to just stereotype negatively here - you want to have more people underneath you. “I’ve got 10 people underneath me.” “Well, I’ve got 100, you loser,” would be the talk over the bar, right? But in software, it could be that having more people is worse, and actually lowers productivity, and lowers the quality of the work that you’re doing. And you can’t just have more people doing the planting or working the machines or something like that.
For example, a person just sitting there thinking, might be way more productive than a person typing or doing something active. In a very straightforward way, less is more, right? You want the smallest code base you can get, not the biggest. A manager might brag, “Well, my project has eight million lines of code.” And you’re like, “Well mine only has 10,000.” But it could be that what you’ve achieved with those 10,000 lines of code is superior to what the other group achieved with 8 million lines of code.
And so I think that a lot of the ways people measure success are out of alignment with the ways we ought to be measuring success, and that that “wall of ignorance” is partly there. You say ROI and money are the terms that managers are living with. And then the developers are living with - say beauty and efficiency, or something like that, and it just seems to me that one of the reasons those big, especially government, projects fail, is that there’s this concept that management and work are these fundamentally different things, and that’s there from the start. So the sort of the whole thing needs to be thrown out, in order for it to be improved.
Janelle: Yeah. I–
Len: You don’t need to agree with anything I said, by the way.
Janelle: I was just thinking in terms of management. I haven’t really run into any managers that were concerned about trying to measure lines of code as a measure of progress. I think we’ve moved past that era. What I see happening more is, the first problem you brought up definitely, of not realizing the impact of adding people to the project, or assuming that you can replace one developer with another developer. And not realizing the impact and the learning curve, in the effects of familiarity on a team.
Part of the problem I think is that - back to the metaphor of technical debt, that has us kind of thinking about the problems in terms of an interest rate, or like a predictable stream of interest payments over time. And when we think about interest, we think about, “Oh, we’re paying 10% interest, 20% interest”, and it’s this steady, predictable thing. It creates the illusion that we can throw more people at the problem, and distribute the cost across more people - when in actuality what’s going isn’t a problem with a predictable increase in cost, it’s a problem with chaos and a loss of control. And that metaphor is failing to explain the true nature of the problem that we’re trying to solve.
I realized this when I was in a business coaching session with Keith Cunningham, and I was talking about technical debt. And none of these people in the class knew anything about software. But I was trying to explain it in terms of these metaphors, and how technical debt was such a bad thing and what it was like. And the response was, “Well, that doesn’t seem so bad.” And I’m like, “What? Don’t you even want to know like the interest rate or something?”
And what I learned in that world, was that, the way these guys do math, and make decisions at the investment level, just seems so crazy, because it’s so far removed. But it’s like, “Okay, we’ve got revenue minus cost equals profit, and our goal is to raise profit by 10%. Well, how are we going to do that?” Well, you have to basically come up with an investment strategy of how you’re going invest money in all these different buckets to make this prediction come true.
And what I realized in this class was that what makes investment decisions more difficult isn’t an increase in cost, it’s a reduction in predictability. And that chaos and the loss of predictability is much scarier than an increase in cost. And when I started talking to management, I started framing everything in terms of a risk-based decision. As in, “the deadline will be here either way.” And the decision is about where we want to be when that deadline gets here. It’s not about - as soon as you start negotiating things in terms of time, you get back to that metaphor of “How can we throw more people at the problem to make it go faster?”
And then the other thing I still see is people thinking about developers like a commodity resource. And what’s fascinating when you look at the effects of a loss of familiarity on the team, I have one case study in the book I did with this team that was an awesome team. But basically it was like post-exodus phase, where all the original developers left, had this huge breakdown. And then they got new management which brought in some great people. But they had this code base that nobody understood.
And the lack of familiarity cost - 80% to 90% of their time was spent figuring out what to do. And the cost when familiarity walks out the door is insane. I mean a lot of rewriting your software is just to reestablish familiarity, because we can’t work when we can’t relearn the system. And you just get stuck in that state of 80%, 90% friction. And I don’t think - we’re talking about interest rates - you don’t think about stuff that’s taking up 80% to 90% of your capacity. It’s unreal when you start looking at how much time we waste for all these problems.
Len: It’s interesting. You talk about technical debt, getting us to see as nouns what we should be seeing as painful verbs. I really like that, and I was wondering if you could explain - on the subject of technical debt, a little bit more about what you mean by that?
Janelle: Sure. This kind of goes back to the metaphor mapping thing. We’ve got different metaphors that we map in our brain. We’ve got objects, which are basically thing-patterns. We’ve got spatial relationships and context-type patterns. And then we’ve got process-patterns, or things that happen over time. And all these different metaphors have these three basic types.
One of the things I realized is that technical debt is a noun. And the effects of it being a noun mean that we look for things that are noun-like in our experience. And generally we look at, “Okay, so this part of the code is a noun - this technical debt thing. And this is a painful technical debt. This is a low pain or a high pain.” But it’s all one-dimensional. We bucket our experiences in terms of high-pain and low-pain technical debt. But idea flow is a process of understanding and extending the software. And so pain occurs in the context of a process.
And once we shift from a thing-pattern to a process-pattern, suddenly we start seeing our pain in terms of a journey. We’re in these situations. We make these decisions to navigate around obstacles, and have to dig through different areas of friction and break down constraints. And you start to see the problem solving experience, and the true complexity of what’s going on, because we can start relating to journey metaphors, or things that happen in time, as opposed to just one-dimensional things.
If you look at the patterns in my book, they’re patterns of mistakes and patterns of causes of troubleshooting time. They’re not like any patterns we have in our vocabulary at all. They’re patterns in development experience, that I didn’t start to discover until I’d shifted my foundational way. I started thinking about pain as a process, and what were all the factors along my problem-solving journey that ended up affecting my pain?
Len: I’ve got one last question about your book. I was wondering if you could say, for example, to someone who is listening is or has or will be managing a software project - how they can use the concept of idea flow to improve their work?
Janelle: So would this be for a developer or for like a manager?
Len: For a manager.
Janelle: Okay. One thing I’d say is that the techniques I’m proposing in my book need to be developer-owned, in that the development team needs to take responsibility for identifying their problems, understanding what they are, and figuring out how to fix those problems. Learning how to do that and discovering the right problems takes time. If we don’t allocate time to figure out what the right problems to solve are, then we’ll inadvertently end up solving the wrong problems whenever we try and work on improvement.
And if management can agree to let the development team work on the most important problems to solve - whatever those might be, and the development team agrees to gather data to identify what the biggest problems are, and then share the things that they’re learning with management - we just set aside capacity to do that, and that becomes the contract between management and development. Then you can start working your way to a better place, and then shifting that ownership of making those decisions and gathering requirements and solving those problems to engineering. And we can start steering our projects.
We talk about the importance of empowered teams. But it’s not just about self-organizing and figuring out what we ought to do, because we’re all too busy to do that. And so we just shortcut all the structural things, and do what we need to do right now - and worry about all the process stuff later. Because we’d much rather write code.
I think we need to have that structure. And it’s worth putting some time into designing our organizational structure - more like its architecture, and having that be a first class responsibility - of understanding the communication dynamics in our organizations. And start creating more human systems architectural roles, if you will.
I’ve also got some diagrams of modeling using software as a metaphor for human systems design, and some of the design problems in our organizational structure that cause pain. I think using that as a template, even if you do nothing else, and take absolutely nothing else from the book - that one change will make all the difference in the success of the project.
Len: Thanks very much for that. That’s a really great answer. I was just wondering what the next step is for you? You’ve got the book and you’ve got these great ideas that you want to spread, and I was wondering what your next steps are?
Janelle: Wow, I’ve got so many next steps. Right now, I’m doing a speaking tour with No Fluff Just Stuff. I’ve got a five talk lineup that I’m doing, breaking down these problems of how to do data driven software mastery. And then the organizational side, how to build a learning organization. And then my business, to get time to work on it - I’m a very firm believer in that you just get up and do it anyway. And you don’t grow without stepping outside your comfort zone. So I’m learning my way through it. I’ve had things that I wanted to share for a long time. And this book, too, took me five years to write, and rewriting things over and over again, and failing to communicate. Because all this stuff is really abstract. And I can iterate a lot faster on stage too, I’ve found. But it’s kind of a challenge.
But the thing I’m working on right now is building a community at Open Mastery around these ideas, which is an industry peer learning network focused on data-driven software mastery - essentially companies and individuals that are interested in trying out these ideas. I’m working on spinning up local communities, where we can start working on implementing these practices in our organizations iteratively, and then coming together in a local community group, and talk about lessons learned, and codifying what we learned into patterns and principles.
And then we’re building a new vocabulary of patterns on Wikipedia. And we’re hanging out and talking over Slack. And we’re writing blogs, … we have every day, to build a community around - but my goal is to lead an effort in learning how to learn together, with the pain on center stage. And there’s so many problems in our industry with broken feedback loops between the education system and our economic system, and between management and engineering.
If you start looking at a lot of the problems and pain in the world, it all kind of comes back to broken feedback loops. And so, what I’m trying to lead is an effort in learning how to learn together - as an organization, and as a community and as an industry. And hopefully, if I can get this going, as a species. So that’s kind of what I want to do with my life. And I’m hoping that I can find a group of people that are interested in learning along with me. Because it’s a whole lot of fun, but it’s a whole lot more fun to do it with other people.
Len: Thanks very much for taking some time in your life to do this interview. I hope it helps spread your ideas, and helps you achieve that. And I really hope you succeed, by the way.
I guess I’d like to ask you one question about Leanpub, and that’s, why you chose Leanpub for your book? Obviously, something that took five years to write, how you distribute it, and how you publish it, is a very important decision. I was wondering if you intend to keep it on Leanpub as permanently, or are you looking for a publishing contract?
Janelle: So your first question of why Leanpub - I mean, being in software development and Agile and lean being so central to my life, I live and breathe “iterate”. And having a platform that was really easy to get started with, that I couldn’t get in my own way with all the excuses I would make of not doing this is just like - I remember first reading the Leanpub documentation, and how writing your book in Markdown without all these formatting things was a feature.
And at first I was upset that I didn’t have all these fancy tools. And then I started to realize, “Oh, I get what this means now,” of how much I get in my own way from writing my book. Because I’m sitting there fussing with what things will look like, as opposed to just writing the material. And I came to really like the flow and the way that the tools are organized in your content’s organized - it’s just really straightforward and easy to work with. And you focus on writing your book, as opposed to anything else. I’ve very much enjoyed that aspect of the experience. It’s been great. And then I can easily publish drafts and get feedback on things, which I very much needed. My book wouldn’t be anywhere near what it is today without five years of feedback. And some of it not the nicest feedback that you want to hear, but it doesn’t mean that it’s not what you need to hear. But yeah, I’ve been thankful for the tooling, and it’s awesome.
Len: Cool, thanks. I guess I have a tendency sometimes to ask two questions at once, but are you going to be looking for a conventional publishing contract and distributing the book through a conventional publisher at some point?
Janelle: I am. I’m working with O’Reilly right now, so I ended up taking my book and splitting it into two, because I just had way too much content. So what I’m working on right now is - I’m like 80% of the way through a second book, for which my tentative title is, How to Build a Learning Organization, which is kind of the learning framework side of Idea Flow. I ended up focusing Idea Flow just on how do you measure pain? And then the learning framework itself, I’m splitting into another book.
So one of the things that I’ve learned in trying to sell these ideas, is that I’ve got a two-sided audience, one of them being developers, and the other one being management. And so my second book, I’m going to focus more on looking at the problem from a top-down standpoint of what managers need to do to support engineers, and what does the organizational protocol look like from each side of the organization? And then, how do we start building an integrated organizational learning process, so we can create a steering wheel of sorts at the organizational level - which is a hugely complex problem.
But I’ve got an initial set of blueprints as a starting point, and then I’m using Open Mastery as a vehicle to get the community to take ownership of getting from point A to point Awesome. And so, let’s see. What was your original question, I forgot.
Len: It was, are you going to be looking for a conventional publishing contract?
Janelle: Oh, yeah. So I’m working with O’Reilly, and I’ll keep my book on Leanpub probably as long as I can. But my main goal is trying to get my book in front of as many eyeballs as possible, more than anything else. And working in partnership with a giant marketing machine has its advantages.
Len: I just wanted to say on that note, for us at Leanpub, when someone starts their book on Leanpub, and then ends up going in the end with a publisher, and retiring their book on Leanpub, almost nothing makes us happier. I mean that is just a fantastic outcome for the author and for us, because part of our goal is to open up that time when a book is normally hidden in stealth mode on a person’s hard drive, to the public and to people.
If all books were published while they were progress, and then get taken up by publishers at the end, it’s a win on all sides for everyone, including readers and authors.
I guess my last question is selfish. I mean, speaking to someone who thinks so much about improving processes, if there were one thing that you could ask us build or to improve about Leanpub, what would that be?
Janelle: Probably the thing that I feel like I’m missing the most, that I’ve been trying to make up for in other kinds of ways, is the ability to build a community around the book, that’s integrated with the tooling. I know there’s kind of email list setup, but when people buy the book - unless they check the little box of share their email. it’s really hard to create relationships out of that. And I’ve tried to come up with some other ways to work around that with signups through other kinds of tools to collect emails, so I could stay in touch with the community. But that’s probably the big thing I feel like is in my way as an author is, building, getting the community of people around the book talking to each other, as opposed to just this one-way communication. And I realize there’s discussion comments and stuff, but it just has a very different kind of feel to it.
Len: Thanks very much for that. You’re the second author I’ve interviewed just in the last couple of months to talk about community when asked that question. So that’s a very strong signal, and it’s actually something that we’ve been thinking really hard about. Hopefully, somewhere in the near to medium term, we’ll have a better community experience. As you noted, we have a sort of double-blind “email the author” process if people want to use it that way. And we’ve got Disqus comments if authors don’t turn it off.
But there’s just so much more we know we can do around that, including from our perspective, we’re sort of building the world’s first library of in-progress books. And what does that look like? And what is the importance of community around that? There’s lots of interesting questions around, for example, reviews, right? Back to 1996 Amazon. But what do you do with a review of an unfinished book, when a new chapter is added, or something like that? There’s an interesting aspect of time that’s involved. And it’s just so interesting to think around building community throughout that time, and around an unfinished thing.
Janelle: Yeah, I can see that being a really difficult challenge. I think about some of the early feedback I got that was just awful feedback - stuff that you’d never want to make public. Like, “I have no idea what this book’s about, or what you’re trying to say.” It was like, “You just need to rewrite this whole thing from scratch. It makes no sense.” I mean, feedback like that, you don’t really want to necessarily be a big public spectacle that you can never get rid of. I think there needs to be some privacy around certain aspects of feedback, especially - I don’t think you’ll get the kind of feedback you need in a lot of cases unless it’s private.
Len: That’s a really good point.
Janelle: It’s like there’s two different– Yeah, I’m not sure. It’s an interesting challenge you guys have.
Len: Well, that’s a really interesting. I hadn’t thought of that before. Because yeah - one of the processes that’s pretty commonly used by Leanpub authors, is to put their email address in the introduction to their book, and say “Please email me.” And then that is almost always a private communication. But I hadn’t put it together, that one of the reasons that’s actually - it sounds so clunky - but the reason it works so well is that it has this value of being private.
Len: That’s really interesting.
Well, I think this is my first feature length interview! I want to thank you very much for your time, and for all your great answers to questions - and for your book as well. So, thanks very much for being on the Leanpub Podcast and for being a Leanpub author!
Janelle: Thank you for inviting me. This was really fun.