In this Episode
Heidi Helfand is the author of the Leanpub book Dynamic Reteaming: The Art and Wisdom of Changing Teams. In this interview, Leanpub co-founder Len Epp talks with Heidi about her career, her interests, her book, and at the end they talk a little bit about her experience as a self-published author.
Heidi Helfand is the author of the Leanpub book Dynamic Reteaming: The Art and Wisdom of Changing Teams. In this interview, Leanpub co-founder Len Epp talks with Heidi about her career, her interests, her book, and at the end they talk a little bit about her experience as a self-published author.
Part way through, this interview is interrupted by the appearance of a snake on the California hillside where Heidi was sitting outdoors. Everything works out ok.
This interview was recorded on May 8, 2017.
This interview has been edited for conciseness and clarity.
A Note About the Leanpub Frontmatter Podcast
This summer we split the old Leanpub podcast into two distinct podcasts:
Frontmatter, which is a general interest podcast where you can listen to Leanpub authors talk with Leanpub co-founder Len Epp about their books and their areas of expertise, from data science to molecular biology, to the history of labor and management. And for those interested in the nitty-gritty of what it takes to be a successful self-published author, at the end of each episode Len asks the author about how they made their book and how they are spreading the word, and othe publishing shop talk.
Backmatter, a new podcast focused specifically on the publishing industry and its latest trends. In each episode Len interviews a professional from the publishing world about their background and their insider's perspective on what's happening in the huge and evolving world of book publishing.
Len: Hi, I'm Len Epp from Leanpub, and in this Leanpub Podcast, I'll be interviewing Heidi Helfand. Heidi is an Organizational Relationships Systems Coach, a consultant and speaker with over 17 years of experience working with cross-functional teams. She is also the author of the Leanpub book Dynamic Reteaming: The Art and Wisdom of Changing Teams.
It's a book that describes practices for reteaming effectively, and at the same time offers great stories about how successful software companies have thrived by changing up their teams, rather than keeping their teams the same. The book makes the interesting point that keeping teams static instead of dynamic actually carries risks related to attrition, learning and other important elements of delivering great software in the long term.
In this interview, we're going to talk about Heidi's career, her professional interests, her book, and at the end we'll talk a little bit about her experience self-publishing an in progress book. So, thank you Heidi for being on the Leanpub Podcast.
Heidi: Happy to be here.
Len: I usually like to start these interviews by asking people for what I call their origin story, and I was wondering if you could talk a little bit about how you found your way to being a team coach. I looked you up on LinkedIn, and saw that you studied linguistics in university.
Heidi: I studied linguistics, and I studied linguistics in Spanish. It's actually how I discovered it. I wasn't sure what I wanted to major in in college, and so I kept taking Spanish classes. I became interested in syntax and the grammar of languages through learning about it in Spanish. As time passed on, I was like, "Oh my gosh, I'm about to earn a degree in Spanish. I'm a course away," just because I kept following that.
And then I thought, "Well maybe I'll take some courses about linguistics in English?" So I earned a double-major in Spanish and Linguistics, and became very interested in the structure of languages.
One of the things that we would do in linguistics is study different languages. We'd have data sets from these languages. We'd transcribe them using the International Phonetic Alphabet, and then we'd study these data sets, to see what patterns existed - so that we could explain how the language systems worked.
I was really fascinated by that, and thought I would get a PhD in Linguistics. And then, after a little bit, I talked to one of my professors, and he said, "You should really study Applied Linguistics, because if you're going to get a PhD in theoretical syntax, you might want to be balanced with more of an applied approach, as well. Because then you'd be more marketable - you'd have a better chance of getting a professorship. So I said, "Okay."
So then I went to the University of Illinois, Urbana–Champaign, and I studied Applied Linguistics. Specifically, how to teach English as a second language. When I was at the University of Illinois, it was a interesting time. Mark Andreesson was there as an undergrad at the NCSA, and I was teaching English in a computer lab. And one day, I was in the computer lab, and we had new software - and the software was called Mosiac. It was at the beginning of the World Wide Web.
And so I was teaching a English writing class in the computer lab, and suddenly there was a big shift in my interest, because HTML was just released - like HTML 1.0, or whatever we called it at that time. And just naturally, I started teaching people HTML and how to create - writing through web page creation. So essentially it was a merger of teaching people English, and applying the language knowledge that I had, as well as [thinking], how can we reach a larger audience with our writing? Well there's this thing called the web now. If we learn this markup language, we can reach a larger audience.
And so then my degree shifted to computer-assisted language learning, and specifically, how do we use the internet as a tool for helping us learn English, and for reaching a wider audience with our writing and doing things with reading etc.?
That was the very beginning for me. I did a Master’s thesis on using email in teaching English. And that I had to fight form, because one of the professors thought that email was going to be a fad.
I would up completing the degree, and then I started teaching at different universities. I started teaching English. I was at the University of New Orleans. And then I found my way to the University of California, Santa Barbara. I've stayed here for about 20 years now.
So my first career was in teaching English. I co-authored a book that's in print, called, Internet for English Teaching. It was published a few times, and we gave it away for free through the US Department of State. We gave it away for free outside the US.
So my first career was really using the internet as a tool for teaching language, English in particular. And so I found myself in California. It's kind of a long story.
Len: It's an interesting story actually. Obviously there's something quite interesting about being there at the beginning of the web - the same place where Mark Andreesson was.
Len: I just wanted to mention - I think there are probably people listening to this, who wish your professor had been right about email being a fad. But in doing some research, I noted that you did a State Department project overseas for a month, I believe? It might have been in 1999. I was wondering if you could talk a little bit about that experience? I know it was about American literature. I have a Doctorate in English Literature myself, and I actually remember in the mid-90's, or the late-90's, doing my Master's, and this was a time of - it was a heady time in English literature, with this whole internet thing happening, with all kinds of wild, even metaphysical theories about what a link was.
I was wondering if you could talk a little bit about that experience that you had, using American literature to teach English, I believe was part of the project.
Heidi: Yes, that was interesting. I had started speaking at conferences in the space of education and teaching with the internet. Back in the day, our online communities were really listservs - so we'd have these email lists according to different topics. I remember I started meeting people online, and I received an invitation at one point, just from the exposure of being active on listservs at the time. I received an invitation by a regional English language officer in Malaysia.
He worked for the State Department, and at the time - I don't know if they still do this - they had regional English language officers across the world, with specific sets of objectives, I think related to teaching English and whatnot.
And so I was invited. I went twice to Peninsular and also East Malaysia, on top of Borneo. I went to Sarawak, and Kota Kinabalu, Kuala Lumpur.
I had lecture tours, in which I was teaching people how to create web pages. On one of the tours, I worked with the Malaysian Ministry of Education, and I worked with them on building their first website. So I taught them HTML or whatever tools were around at that time, and helped them create their first website.
On the first tour, I did not take any literature with me. On the second tour, I was requested to take a few anthologies of English literature. I have them actually in the other room here.
the goal of the second trip, which is written up online somewhere, was about sharing English literature with the idea of creating websites about English literature. And the interesting thing emerged was that the students in the class - it was awesome. They brought their Malaysian literature. And so the result was some sort of hybrid with literature from the US, and literature from Malaysia, as I recall.
It was really a very interesting time. I was delighted to be able to have these two trips, and to meet the teachers, and to share. I visited teacher training colleges. I was at the US Embassy in Kuala Lumpur doing training.
We had paper airplane tickets at that time. So for both trips, I was mailed a stack of airplane tickets. And then I was just turned loose, and flew off to Southeast Asia, and went from place to place teaching. At that time, I would teach about the internet - without the internet, because the connections were not there all the time. I met some incredible people, and it was definitely a very interesting time for me.
I was teaching at the University of California at the time,and they were very supportive of this type of short-term activity. I came back, and I was teaching at UCSB University of California.
And then, an interesting shift happened for me. They let me design my own courses in combining educational technology with learning English.
So I created this course, which was called, "Communication Through New Technologies." The idea was that, these are very advanced students of English that were coming over as exchange students from various countries. (This is at that the University of California, Santa Barbara.) I was teaching this course that integrated, how to give an effective presentation, how to find online community. The texts that we would read were about online communication.
And so we'd read, write, listen and speak - which are our English skills about these technologies. It was motivating for the students, because there's just so much happening with the internet. I guess it was in '97 and '98, when I was doing this.
During this one particular course, I remember one day I was looking and trying to [decide] - alright, what are we going to read next? And I found this article online about this screen sharing technology.
And the idea was - imagine, you could be at your home, and you could connect to your office computer, and you could see the screen and control the computer remotely. It was this technology known back then as "Buddy Help," and I was blown away by the technology. I brought the article in, and we read about it. I think they had some prototype online that we could play with.
And the more I got into that particular text with students, I learned, "Oh my God, this company is in Santa Barbara." And so we'd played around with the screen sharing, we were just kind of blown away. I mean, that technology existed in a different form, called, "PC Anywhere," but this was different, because this was through the internet. Imagine seeing and operating somebody else's computer through the internet. It was magical to me.
So I looked up the company. They were in Santa Barbara. And I remember one night, I was sitting at my desk in my tiny apartment. I thought, "You know what? I'm just going to send them my resume." And I got a call the next day from one of the founders of the company. He said, "Hey, I saw your resume, and you know what? We're looking for a writer." So when I was teaching English, I was kind of the one with like the computer skills. But at this tech company, they saw me for my English abilities. And they said, "Why don't you come in for an interview?" I'm like, "Okay."
So I go over there, and it's this small company. It was called, Expertcity, expertcity.com. It was a start-up, and there were about 14 people there, and they hired me as a writer. So I switched my career from university, to joining this startup. It was a big shift for me. It was like a fork in the road. And I remember, I'd been invited to go to Indonesia, through the State Department, to do another lecture tour. And it was like, "Alright, do I go there - or do I go with these startup people, and go on this thing?
And so I turned down the trip to Indonesia, and I decided, "Well, I'm blown away by this technology, so I want to be with these guys."
It was a fun environment. PAnd people were very into it. It was co-founded by a UCSB Computer Science professor, with two of his students. And I thought, "Alright, who do I want to hang out with all day? Okay, I'll be with these people." And so that was like a big fork in the road for me.
Len: And what did you write for them initially?
Heidi: At expertcity.com we were creating an online marketplace for tech support. We were trying to be like the eBay of services. So we were a small team. I was the 15th employee. And I basically wrote the words. If you went to our website, I would write the words. I would partner with the software engineers. If they needed text for inside the applications that we created, like any error messages, [I would] pretty much convert it into [English], like an interaction designer.
So I worked on UI, UX and any kind of writing. That was a very motivating and exhilarating time. We created this first product, but after a while - I remember, I have this photo of myself that I put in some of my talks. I'm sitting in my office at Expertcity, and I've got all these UI flows, and printouts of the website on my wall. And one day, the CEO came into my office and he said, "Heidi, this marketplace is not working. Nobody's buying it. We have to stop working on it."
For me, it was really difficult. I was pretty junior in my software career, and I didn't really understand. We had all these hopes and dreams for the software. But they pulled the plug on it, because the company was going to go under if we continued that way.
At that time, I really didn't understand what was going on. The CEO was like, "Don't start any new work that you think you're going to have to maintain. We're going to have to regroup. We'll get back to you. So just go to the beach, if you don't know of anything to do." And I was like, "What do you mean, go to the beach?" And he was just essentially , "Hold tight, we'll let you know the next steps in a few days."
And so that's when one of my first experiences with a dynamic reteaming situation emerged. Because the founder of the company, Klaus Schauser came to me, said, "Alright - we have to pivot our company. We're going to create a new team, and you're invited to be on this team." He took people from various existing teams, and he pulled us off to the side, and he put us in a room. And he said, "You guys are going to work on a new product."
It was actually the original product he wanted to do when founding the company, but it wasn't, I think, attractive enough to investors to get the funding originally. He said, "We're going to work on something else here. Basically what we're going to do is really go and pursue - instead of this marketplace for tech support, we're going to create a consumer product, in which people can access their computers remotely."
And essentially we created this product called, GoToMyPC. And so it was like an online way to see and access your computer remotely, similar to that very early prototype that I saw, but we figured out an online commerce flow, where people could buy it online, or try it. We essentially were this small team, off to the side. I call it like an "innovation by isolation" reteaming pattern - we're a small team, put off to the side. We had process freedom from the rest of the existing teams that were at the company. And we were able to iterate on the fly and get a working version of the software out that became very successful.
I think that shift in the company - that reteaming by isolation, to create something really new - without any constraints, back in the day, this is early. We were doing Waterfall development processes. We had very heavy design culture. But with this team off to the side, we got to innovate and not do any of that stuff. Everybody else was told to leave us alone. And we were able to really fly.
Klaus has interviews online elsewhere, that say, "We learned through 10 million dollars that if you're going to start a new company, and you're going to build software, you'd better see if there's a market for it first." So we learned the lesson of market validation. And since then, we've all become students of Steve Blank, Four Steps to the Epiphany. This is the precursor to The Lean Startup book by Eric Ries.
So before that movement even started - we, in Santa Barbara, were implementing some of the ideas from Steve Blank, Four Steps to the Epiphany, by doing market validation. Then we went on to create GoToMeeting. But we validated the market before we full-on built GoToMeeting and GoToWebinar and GoToTraining, and the other products that followed on.
Len: I'm curious, ,id you eventually move on to being a Citrix employee?
Heidi: After a while, the company was acquired by Citrix. So our start-up essentially became Citrix. And so I was there, I was at the company for eight years. From my perspective - I was on the web development team at that point, I might have become a Project Manager. I was like an editor, interaction designer - and then I became a Technical Project Manager. So I worked on the first versions of GoToMeeting, GoToWebinar, GoToTraining, as the Technical Project Manager - pairing with product, people in the business side of the organization.
And I think after we were acquired by Citrix, I believe we released GoToMeeting - if my timeline is straight. And when Citrix acquired us, I think it worked out really well, because they left us alone. We were really a separate division, and we - it felt like the same start-up, it felt like the same company. And I have only positive things to say about that shift. I thought it was done really well.
Len: That's really interesting, because one of the jokes that goes around is that, the best way to kill a good product is to have a big company acquire it. It's really interesting to hear that there may have been some internal understanding when you were acquired, that it was the dynamics that you had on your team. I guess that's kind of a loaded word in this conversation. But that was part of the success.
Before moving on, I have a couple of questions about that. I actually wanted to circle back briefly to the question of market validation, and I'm curious - how did you go about validating the market for what eventually became GoToMeeting?
Heidi: There was a point person, he's a wonderful colleague. He went onto found a company that's also in Santa Barbara, called, ProductPlan, Jim Semick. As far as I remember it, so Jim Semick was our lead on market validation. He worked with Klaus Schauser and others. Basically, we had a prototype, and if I recall correctly, it could've been even as simple as a clickable PowerPoint.
It was the idea of having online meetings. And so, they had a clickable prototype, and they would have phone calls with prospective customers for this solution, and basically wanted to find out, if we built something like this, would it solve your problems? Are you in enough pain to buy this? If so, what are the types of features that would be useful to you - and how much would you pay for it?
The idea is to have a bunch of phone calls. And they did it on a phone. I remember they invited people from the engineering group - myself included, to sit in on these validation calls. So, the development team - we rotated into these calls. And there were probably more than 25 calls. It's important to have the calls with people you don't know, and maybe these are people that - I'd have to ask Jim how it went down, because I don't remember, because I was just an attendee in some of these calls.
But basically, the idea is: talk to prospective users of your product, and try to convince yourself that it's not a good idea to continue on. You want to try to prove that this can fail. And if it doesn't fail, then you press on and it's a good idea, and then you get an idea of, "Okay, if we build this thing, and it might look like this, how much would you pay for it?"
So essentially you sell the concept, before you actually build it. But you don't mislead people to think it's ready, or anything like that. I mean, it's very clear that we're trying to validate whether or not we should go this route. But it was definitely the Four Steps to the Epiphany, like the guidelines from Steve Blank, were really, really key.
Steve Blank has a podcast. He interviewed Klaus Schauser, and he pretty much said that, suddenly he had this demand for his book in Santa Barbara. And he talked to his wife, and he was like, "Oh my God, I think I might be onto something here. Because suddenly we're selling hundreds of books to this person in Santa Barbara named Klaus."
It was very interesting. Basically we convinced the company that we should go in this route. I can't say enough about like the founders and the leadership of Expertcity. We became a division named, "Citrix Online." Back at the time, this was like - the first seven years of that whole experience, they learned. It was like learning about what not to do. They really learned from spending the 10 million dollars on the expertcity.com product that failed. They didn't want to do it again, they wanted to survive. They wanted to keep going - and so they did.
So with GoToMeeting, and then GoToWebinar - I think more than a year after we were acquired by Citrix, Klaus - one of the founders, left. And after a while, some of the other leadership left. And one day I noticed that - hey, some of the early developers that I loved working with, had started working at another startup, which was an offshoot, created by Klaus after he retired, so to speak. He left the first startup and he retired - but after a while he went and he created another startup, which was the second one I was at. And I was there for nine years. The second startup was called AppFolio.
Len: And what was the product from that startup?
Heidi: This was actually also founded on the idea of market validation. Klaus Schauser, founder of Appfolio, partnered with another local entrepreneur named Jon Walker. Those two co-founders got together, and they thought, "We're going to build software for auto repair shops." And so what they did, is they got together, and they did market validation of building software for auto repair shops.You go in, you get your car fixed - what kind of software do they use? They thought - there's an opportunity there. I think Jon had the idea.
And so they thought, "Okay, well let's see if this would make sense." So they did market validation, and they went from auto repair shop to auto repair shop - physically, in person, in Santa Barbara and some other areas. And they convinced themselves, you know what? The auto repair shops are not in enough pain to buy a new software solution for us. We are not going to build software for auto repair shops.
So then they had an idea for another type of software. They thought, "Oh, property management software." So, software for companies that manage rental units for owners. They started market validation for that, and they realized after doing the market validation interviews - I think probably on the phone and in person in this case, that - you know what? A lot of these property management companies are in pain with existing solutions. We think there's an opportunity here to come in and disrupt these people, to disrupt the existing solutions.
And so they found this with developing property management software for small businesses, and so the idea for AppFolio Property Manager was born. There was a very small team there, and after a while they raised some funding. They raised some money. And then I was able to join after they received some funding. I joined as a Scrum Master.
Len: And how did you make that transition from writing to being a coach and a Scrum Master?
Heidi: In the early years I was writing and I was doing interaction design. I was an individual contributor within a development team. After a while, I just started stepping up and becoming a Project Manager at the first startup. I think spent five out of the eight years as a Technical Project Manager. A very, very traditional Technical Project Manager. I mean, I didn't have Gantt charts or anything. I always made flow charts. I was like a hub of information, more like top down management.
But then the industry shifted, and it was a move towards a more bottom-up methods of working with teams. And so - again - lesson learned from the first startup to the second startup. The founders decided, "We're going to start this AppFolio startup, and we're going to use extreme programming in Scrum." So it was a business decision to do a different process: extreme programming for the redundancy and sustainability of information and people.
At the first startup, we had these towers of knowledge. Like, one guy would be in charge of the printer software for example. If he left, the knowledge left in his head. We didn't want to make that mistake again at AppFolio. We wanted that knowledge redundancy. So we paired 100% of the time. For a while we had 100% pair programming. And then we relaxed it, so people would choose whether they paired or not. But overall, people really pair in that environment.
Pivotal Labs came with our startup. They were with us for more than a year. We had two consultants with us at a time. For our very first team, we followed a Pivotal process.
I was hired in as a Scrum Master, but fulfilled a role like an anchor or tracker in the team. So, really helping the team to keep the stories moving within Pivotal Tracker - it was before it was sold as a product - and to help the teams reflect and get better. So there was a shift due to a business decision, and how we worked with Pivotal to have more of a bottom-up approach.
I learned from my Pivotal consultants for more than a year how to not be a hub and top-down Project Manager, how to be more of a bottom-up servant leader to the team. And so it was a process of acquisition of my skills, I think of more than a year. I took a Scrum Master course with Ken Schwaber, one of the co-founders of Scrum. Just as a quick 2 day thing.
But I think really the knowledge that I gained from being embedded in an XP team with XP coaches for more than a year, is really where I got my education and how I wanted to be. I was at AppFolio from one team to 30 teams over a course of nine years. Our process grew and evolved through reflecting on what we wanted to change going forward in our process.
Len: Slightly switching gears before we move on to the subject of your book, and speaking about improving, I saw that you recently gave a workshop on high performance via psychological safety, and there was a reference in the description of this workshop to how psychological safety was very important for high performing teams at Google. I was wondering if you could talk a little bit about what psychological safety is?
It gives a little bit of context actually. This subject - if I'm correct about what it's referring to - comes up pretty regularly in my podcast interviews. We have a fair amount of coaches and Agile people and things like that. But it also comes up in discussions about labor generally.
I'm just reminded of something I listened to recently on a Slate Podcast, where it was - who in the White House said this? One of the statements was, "What you really want to do to find a winner, is throw a bunch of high-performing people into a really high stress context and let them fight it out and see who wins."
I think one thing we're seeing in our culture - like in the last 20 years with software eating the world, and the rise of the importance to our global infrastructure of software and software development - methods for managing people's work have this new significance. If we get it wrong, you end up with, let's say, making a nationwide healthcare service that blows up in everybody's faces, and causes something worse than a scandal.
And so I was wondering if - as you discuss psychological safety, if you could maybe have that context there, to the discussion of how important managing software development is in our time.
Heidi: I think if I could really bottom-line this topic, it would be what W. Edwards Deming said, which is, "Drive fear out of the workplace." A leader's job is to remove fear. We want to be able to show up fully at work. We want to be ourselves. We want to be able to make mistakes, try things out. Be safe to fail experiments. We want to be able to ask questions. We want to be able to bring up a problem if one exists. We want to really operate - bring our full selves, and be able to operate fully in our environments. We want to have full participation from all of the people that we bring together on these teams.
I think how people show up as managers and as leaders and as good co-workers, is really important. Am I able to do my best work? Or am I editing myself, because I'm afraid of what Joe over there is going to say to me if I express my opinions? It's like, how can we remove obstacles out of the way of all the human beings, so they can fully contribute, not be afraid, and that it can be an enjoyable experience?
Of course we have to ensure that we're building the right things that are validated. The right things for our customers, and we want to deliver at a cadence that delights them and everything. So all that market validation stuff is one thing.
But - like, modern Agile, right? We need to make safety a prerequisite. And we talk about that - Josh Kerievsky, one of the main drivers for the modern Agile movement - we want to make safety a prerequisite. And one part of having awesome teams - making people awesome, having awesome teams that deliver the right things continuously to customers, is, we feel comfortable in our work, to really bring our all. To not have any kind of strange interpersonal distractions in our way.
So how can we do that with our teams? We need to really read the emotional field of what's going on in our teams. Are you in a meeting, are you in a planning meeting and the conversation is dominated by two people, and everybody else is silent? What's going on there? It could be a variety of things. Do these people feel safe to speak up? We get curious when we notice pockets of silence in our teams, because it could be a sign that maybe something isn't safe. Or maybe that the team is too big, and maybe we need to split it in two, which is a very common pattern written about in the book called The Mitosis Pattern.
But we need to really come from the sense of - how are the people doing? Are they able to contribute fully? Is it environment that is really stimulating and allowing people to bring their best? Or are people editing themselves because they're afraid?
Len: That's really interesting, particularly with the example of Google, who are well-known for trying to gather data on employee performance. Does the presence of the idea - that we're analyzing the data, help make people feel safe in their work environment? I'm just curious about that dynamic. Because I can see in a scenario where someone's like, "Oh I'm not just being subjectively judged by my boss. My boss can't undermine me for interpersonal reasons, because there's an objective process here."
Is that something that plays a role? Yyou mentioned emotion. But emotion is this inherently subjective thing that's of course very important, but the more subjective, I guess - I'm just floating the idea that the more subjective things get, the less secure someone might feel. Because it starts to appear arbitrary.
Heidi: That idea of, what does success look like in my role, and how am I evaluated in my company? Performance reviews are very common in different companies. If you go back to Deming - and I think he originally wrote this in a book in 1983, it's called, Out of the Crisis, he talks about performance reviews being one of the components that creates a lot of fear in the workplace. I think a lot of companies have good intentions. But sometimes even with that, we can be unskillful on how we deploy these types of things.
We want to make a difference in the work that we do. We need to know what success looks like in our roles. And frankly, I would try to take it to the team level. What does success look like for our team? Okay team, like let's talk about that. What is our success criteria for how we work together and what we do? And engaging the team in coming up with ways that they measure their own success. These are metrics for the team, by the team, as opposed to somebody else from outside trying to come in and judge the team. Maybe they're too far away to do anything useful? I'm not a fan of metrics that roll up - it's a very sticky or murky area.
But I do think it's great to engage teams to talk with each other about, what is our baseline, and how do we want to get better as a team? How do we as a team want to measure ourselves? And then maybe we want to try experiments to get better as a team, and then take a look a little bit later, and compare to our benchmark. Did we get better or not? I prefer kinda stuff like that - metrics that are by the team, for the team - that help them get better in a way that they agree on.
Len: It's interesting when you talk about the problems that can come with an outsider coming in. You have a phrase, I think I saw on your website, of, "poorly done foreign aid." I really loved that metaphor.
It reminds me of an example I heard of. I mean, this is pretty common. But one problem that can happen with foreign aid, is people can drop the food in on parachutes, and then the local strong man grabs it, aand sells it to people, even though it was meant to be distributed for free. It's just an example of how good intentions - maybe in this context, it might be providing people with all these great tools - doesn't necessarily work if it's not deployed properly and with an understanding of what things are actually like on the ground.
Heidi: And what they actually need - and actually, that phrase, "Poorly done foreign aid," goes back to my aid work with the State Department. When I went to the Malaysian Ministry of Education, and I did a workshop on how to create websites, I remember - I got into the room, and I was with the participants in the computer lab. And I gave my opening or whatever, and I had just assumed the participants would choose the area of the website tht they wanted to work on.
And after I gave my intro, one of the leaders stepped up, and he went around the room and he said, "You will do this part, you will do this part, and you will do this part." And I was like, "Oh," thinking to myself, "Oh, okay, this is how it's going to go down. Alright, I'll just go with it." Because the leader had a certain idea of how he wanted this to be organized. And the lesson that I learned from that, was that I had made an assumption. I had made an assumption coming in, that they would be organized the way that I thought was appropriate as an outsider. Not necessarily the way that might have worked best for them.
And so I discovered it through that process. I learned that, I really need to do a needs analysis when I go into these contexts, so that I can be in alignment and on the same page with the leaders, and with the people, and try to deploy the best solutions. So, I talk about poorly done foreign aid for some of this other stuff, because it's like, a consultant or Agile person, or whoever, an excited engineer might come in, and try to get a team to do something. But it might be completely inappropriate for what they need.
So I think it's really, really important to be with the people. Acknowledge that however we're working right now, there's certain things about it that undoubtedly work really well. So if we visualize where we are today, agree to pursue incremental improvement, or the quest for getting better, and engage with the people on what that might look like. I think you'd have greater success, and less of a chance of trying to bestow upon a team a solution that makes no sense for what they're going through. So it actually ties it back to what I was saying before. A correlate, "I don't want to do it, and I can see it when it's done."
A lot of the time, people have really, really good intentions. I think the bottom-line learning there is: get in touch with the people and what they need. Start where they are, and then go from there.
Len: Moving on to the subject of your book, Dyanmic Reteaming. I know you could talk about this for hours. But I guess maybe we could focus in on, just as an example, The Mitosis Pattern that you invoked earlier. Could talk a little bit about what that pattern is, why this mitosis happens, why it can be good if it's managed properly, and at what cadence this sort of team division should proceed?
Heidi: I would love to.
All the patterns in my book are derived from data. The mitosis pattern happens to be one of the most common patterns that I've encountered.
When I call something a pattern, it's because I've seen it three or more times. The fact is, when our teams get - I'm talking software development teams now, and that's the teams in the book - when the teams get to a certain size, when they get bigger, maybe it means more than seven people on the team, seven or more - typically, I think I've seen around maybe from 10 to 13, is when splits happen.
When teams get big, stuff gets harder. It's harder to make decisions. It's harder to hold meetings and have retrospectives, because you need to change your facilitation, so there's more equal participation with all the people.
If you have a discussion with four people, you don't really need to like break out any sticky notes or anything typically: the conversation kind of flows, because there's less communication channels. When you get bigger, to like 10, 13 - some people say more than seven - you might notice that things are harder, standups take longer, it's more painful to come to decisions. Maybe you have those pockets of silence on the team, where you all try to meet together because that's what you're used to doing, but only three people talk.
So then it becomes, how can we make the meeting more engaging? And there's certain facilitation things you can do to try - work in pairs and then share out - but it seems that naturally teams just start to split, and then things become easier.
I was just with a team today at a client site that just split today. It's almost a forcing function for having less work in progress, as well.
So you might see on a big team, if it's a software development team that has software engineers, and typically one QA person on the team - if they're working in such a way that they have to pass through the QA person before they get the software out to deployment, that QA person will be crunched because there's multiple streams of work coming to that person. It's lessened when you split because there's just less work in progress. There's other ways to solve that, but -
Len: I imagine it's highly context-dependent. For example, if you've got a team of 14 people and you decide - okay, it's time to do some kind of split, how do you decide who goes where? And I guess, how is that decision-making process surfaced best? Do you give people a sense of some power in the decision that's being made? Do they have input in, "I really like working with so and so. We really get along. Maybe you haven't noticed."
I'm just curious about how that process works. I guess it's normally not best to just show up one day and say, "Hey everybody. We're splitting you in two - you seven over here, you seven over there."
Heidi: I think typically someone notices that there are maybe two or more missions at play, or areas of work that we could do. So someone has the idea, "Hey, I think we should split the teams," or, "I've noticed things are hard. If we split the teams, team A can work on this feature, team B can work on this feature."
Let's say you have feature teams, just for simplicity, you have a bunch of feature teams.
People might start talking, maybe a tech lead or a manager, or a coach - someone, one of the engineers - that there's two distinct sets of work, and if we divide the team in half, it could be easier. So there's some noticing at that more macro level.
But then it's like, "Okay, well how do we get the people on the teams?" And there's different ways to do that. They have different levels of transparency.
One way that I like a lot is doing self-selection where, "Alright, we have these two areas of work, and you can facilitate an activity where everybody is together, and talk with people about, Alright, if we have 8 engineers, maybe we'll have four on each team? We'd like you guys to figure out who wants to be on each team." And they can do an activity putting themselves on avatars on two regions of a whiteboard, and they can figure it out.
There's a book called Creating Great Teams by Sandy Mamoli and David Mole that I usually point people to, because it gives a very tactical how-to. If you want to engage 50 teams in a self-selection, how do you do it? They have great tactical guidelines.
Freedom is a value of mine. I like to give people choice. I think people get more motivated when they have the freedom to choose where they want to work, and it's really a sweet spot when the company matches that, right? When the company feels like they'd be good there, and they would be good there too. And so there's stories in the book about different self-selection stories.
There's a story in the book, I was talking to Kristian Lindwall - he's an engineering site-lead at Spotify in San Francisco - so, he was working with a tribe - and a tribe consists of, let's say, four to five squads or teams - and they noticed at one point that some of the missions were overlapping, and they really had to reset the missions for each of these squads. So they came up with a graphic and they put it on a whiteboard.
So they said, "Okay, we think we're going to have these five squads, and these are the missions." And people were able to explain what the missions were. And then they engaged the whole group, and they took all the names off of the squads, and they engaged the group in, "Alright, which squads do you want to be a part of?" And after a period of two weeks, after an initial kick off, they had one-on-one discussions. People put their preferences - it was all very visible, because it was in a whiteboard in a common [area] - visible during their coffee-hour period called a "fika". [Note: There is a good explanation of a fika here - eds.]. And so they figured out the teams in a very visible way.
If somebody was working on something already for like four months, they still take their name off the squad, because that person might want a change of pace and to do something different. I think these visible ways of reteaming that enable people to have choice, that don't put people in a box like, "Oh, he does that. He's the printer guy" - that printer guy might be sick of the printer, so let him choose something else. I think that's really important.
The polar opposite of that is - what I've also seen in other contexts is, when somebody assigns the teams, and you're put on the team and you don't even know who put you on a team - because it's so abstract.
Len: I was just going to ask you, one of the principles that you discuss is avoiding abstraction, and I wanted to just dig in a little deeper into what that's going on about, because it sounds like you had defining missions - for example, might be a place where that principle could apply. "Achieve synergies," or something like that, "deploy deliverables." Is that what you mean when you're talking about avoiding abstraction? Not onlyhaving something that's too generic, and something that's too disconnected from what's actually being done, but also something that comes from the outside rather than the inside?
Heidi: I think that in some of the writing in the book so far - again, the book is alive, which is the nice thing about Leanpub - in terms of avoiding abstraction, it's kind of related to - of the company is so large, or is working in such a way that the team members are assigned and re-assigned by somebody far away - generally you have communication problems.
As a consultant, I was with a company that every quarter, they'd reset their priorities of work. And suddenly, people would be disappearing from the teams, because their manager told them they got reassigned to this other team. And then the team that they left, they didn't even say goodbye. So it was like a sudden reteaming by abstraction by somebody like really far away. And so the proximity just isn't there, and the caring just isn't there.
Again, everybody could have really great intentions, but we can be unskillful in doing these things, especially if we're dealing with a great number of teams and the decisions about who's on what team are made from far away. I think if you're closer to the team, if there are more local decisions of this kind of thing, it's generally more understandable by the people that are impacted.
Len: On the subject of a living book, I think the last I checked, your book is about 70% complete. [Note: The book is now marked as 90% complete - eds.] I'm just curious about how your approach to in-progress publishing - have you been adding stories as they come in from people?
Heidi: Yes. Basically I have a flow, and the flow is - it's kind of linguistic research. You get a data set, and you analyze it for the patterns, and then you write about the patterns. So I interview people from different companies all over the world for an hour about how their teams have changed over the years. I have a very general prompt, do an interview, and I get it transcribed. And then I read the transcription - I listen to it, and I code it for themes. And I see what's present there.
Does something in their story support an existing pattern? Or does it suggest a new one? And then I integrate their stories into the book. Right now I have kind of a pile-up, I have probably like eight transcriptions that I need to analyze and get into the book. I'm trying to work in small batches, so that I integrate something - like, I just added an isolation pattern, it's on my computer, but hasn't been uploaded to Leanpub yet.
I have an isolation pattern story that I've integrated in. I went over the data over the weekend, and there's some compelling stuff to add to the book. So I'm trying to keep it small and then release it. Small batches, just like we try to advocate in software development. You want to work small so you can have more of a continuous release, continuous deployment.
You get in trouble when your batches get really big and then you release a big chunk. Last month, I had a big batch problem. I let it get the best of me. But if I can work in these small chunks and then continually release, I think it's better for everybody.
But I don't want to annoy my readers and update them too much with emails. You guys have a warning that says, "Watch out. Don't be sending an email every day." I don't want to spam people.
Oh my God, there's totally a snake - I've got a rattlesnake right there.
Len: A rattlesnake?
Heidi: He was like a - I'm going to go inside.
Len: Yeah, that might be a good idea.
Heidi: Yeah, it's either a kingsnake or a rattlesnake. I'm outside in California and it's hot.
Anyway, yeah. You want to work in small batches and continuously release them. That being said, I have been trying to go more global with my data. And so I am looking for participants, like, I'm trying to schedule a call with someone I met from Italy so I can get a different global perspective.
I have a map and I have points on the map of where all the participants are from. And so I'm also looking for some participants from Asia. It's a lot of California, Europe, I've got Iceland, New Zealand. I'm trying to go more global with my data set.
Frankly I'm really enjoying this whole process, because it's a process of discovery. It's really about - there is an outcome of this which is the book and people can get it on Leanpub, but it's really a delightful process of learning. The whole thing - it's all emergent.
Len: Speaking of process, you not only have your email address presented, I think, in the introduction to your book, but you actually have it in the footer all the way along. So no matter where anyone is in their book, they're being invited to give feedback. I was wondering if you've been getting feedback from people and how that process has worked for you?
Heidi: You know frankly, I've been getting feedback from some people. I think there's like early adopters, or people that are really into it, that are giving me feedback. I get feedback when I give talks. I created a Slack channel that I think I advertised once in the email, but it's still an up-and-coming Slack channel - it doesn't have much traffic. I would like more feedback. Pretty much, I get the feedback when I ask for it.
And I think people are busy. Maybe they don't have time unless you build a relationship and ask for feedback.
I do iterate with participants. For example, the isolation story I just wrote is about the story of the development of a team within large Citrix after I left Citrix as an enterprise - a reteaming story where they created this app called Convoy. So, this innovation by isolation pattern. I wrote up the story and I'm validating that I got it right with the participant who I interviewed. So I iterate with the participants for sure, just for accuracy. And yeah - I would like more feedback, and I think that's something to look into.
Len: Thanks for that suggestion. It's something that we know we can do a lot more work around. And it is really an interesting moment in publishing, generally, where feedback can take place - and this has been true for some time, technically - but people are getting more accustomed - and we see it in Leanpub, with the idea of authors and readers interacting in a very productive way - and in particular, with something like Liberate, Leanpub books are so easy to update.
A reader loves it if they make a suggestion, "Hey, I found a typo on page 72," and it's fixed in the next release. It gives them a sense of personal contribution. And it's sort of the opposite of someone feeling like they're doing work for someone else for free. They feel like they're actually participating and improving something.
The process itself, if we can make it better, it can be something that really not only gives people a positive experience, but actually improves the quality of the work that's done.
My second last question is, how did you find out about Leanpub in the first place, to choose to use it? If you happen to recall, I'm always curious to find out about that.
Heidi: One of my friends suggested that I get a Leanpub, that I do a Leanpub. He's also in the software industry. And so that was in the back of my mind. And then I figured out a flow. I use Scrivener on a Mac, and I learned about Scrivener from him as well. And I just kind of figured out a flow to export my Scrivener into Dropbox, and everything's in Markup in my Scrivener, I converted it to - or Markdown, sorry?
Len: Yes, Markdown.
Heidi: Converted it to markdown. And I've got a flow that goes to Leanpub. And then I'll generate the previews and check them out.
So I've got a pretty good flow. It's somewhat manual, it could be automated, like scripted - but it works really well, and I'm really happy with it. And I feel safe with having my book on my computer, and also in Leanpub, and then also in Dropbox. I've got three copies of my book, so I feel really safe about it, like I'm not going to lose it.
Len: That's a really interesting process. I'm always curious to hear about - probably because so many Leanpub authors are technical, they just really love optimizing how they do things.
I should mention, when it comes to safety, that we've got a somewhat hidden feature called "Versions," that you can see - it's one of the menu items in your Book Tools, where whenever you preview or publish, we actually save the manuscript.
It's this extra level of security. And someday we'll add more features, like we'll give a name to the version, rather than just a date, which is what we currently store. And then you can imagine release notes being automatically generated from a change log or something like that.
Heidi: Oh, cool.
Len: There's all sorts of really fun paths for us to go down in the future, but I'm glad that - that was a particular hobby horse of mine. Because what you were talking about, that sense of security from having your writing stored in various locations - is something some people might worry about more than others. And I think I worry about it myself more than others.
Heidi: Yeah, and it feels good. I'm really grateful for all of it. I think it's a great - I love Leanpub. I love what you guys have set up.
Len: Oh, well thanks.
Heidi: And I really mean it. I think it's been really, really a great experience for me.
Len: Thanks very much for that.
My last question, on that note, is as good as I suppose it may be - and it's battle-hardened, and it's taken a long time to get here - you know, working with authors over the years. But if there were one magic feature we could build for you, does anything come to mind? Is there something that was maybe, rather than maybe stuff we've talked about around feedback? Or maybe automated, is there something that you've found yourself wishing you had that we don't provide?
Heidi: Community. Like a reader community. That email that I send out with version notes or, "Hey, guess what? New version." - it goes to all these people, and I think - I don't even know how many readers I have anymore, but there's a certain number of readers. It would be great if those readers could opt in to some kind of community, or opt in to have discussions about the book or something.
Len: Thanks. That's a direction that we're being pulled in more and more. I think it's partly because we've got the process sort of stable now, of making the book and releasing the versions, that people are like, well now it's the community around it where we should perhaps be focusing our efforts. It's something that we've actually thought a lot about, and it's something that we do intend to address.
I can't make any timing promises, but even simple things like getting a notification in Leanpub rather than only in email, so that if you're already in Leanpub you might see the little red circles that we see everywhere now, with a number going up. And then you can check and see - oh, there's a communication from the author that's not necessarily as intrusive as an email might be. It might make more sense as a notification in Leanpub.
And then can you have a place where you can go where people can themselves participate in a discussion around the book, things like that. So it's definitely something that we're thinking about.
I wanted to say, Heidi, thanks very much for taking the time to do this interview. I had a lot of fun. It's the first time there's been an adventure with a snake when I've interviewed someone, which I must say you dealt with with aplomb.
I also wanted to say, thank you for being a Leanpub author. If there's anything we can ever do to help you out, please don't hesitate to get in touch.
Heidi: My pleasure. Thank you so much. Keep up the great work. I love what you guys have created; it's really empowering.