Michael Pryor is the Head of Trello at Atlassian, the visual collaboration tool that gives millions of people around the world perspective on their projects. Michael is also a co-founder of Fog Creek Software, a software development company that created popular developer tools, including Trello, and sits on the board of Stack Exchange. Michael currently lives in New York with his wife and two daughters.
John Peebles is the CEO of Administrate, and has been growing the company since 2012. A developer by background, John made the switch to executive a long time ago and has spent the past 13 years growing healthcare and education technology startups in America and Scotland.
He is passionate about education, great teamwork and technology, and often speaks on these subjects around the world. Rumour has it that he used to front a hard rock band, which would explain the hair (and dubious musical taste.)
Michael Pryor: [00:00:00] Thank you. How many people came to my talk yesterday? Just a show of hands real quick. I don't want to cover all the same things and bore you.
John Peebles: [00:00:09] So we're going to be discussing a different bent because it's the engineering track today. And I've been really looking forward to this because I'm of the age — just by way of context — I grew up as a developer reading Joel on Software and Joel Spolsky, for those who don't know, is the cofounder, with Michael, of a couple of different companies. And basically there are two strands that I got from really following the development of FogBugz that have really influenced me, and the first is how you guys set out to build an environment and a company that was dedicated to this idea that you wanted to build a place where engineers wanted to come and work at. And the second was the discussion around how you hire, mentor, find the best engineers out there. And so I guess the question that I would have for you is, how did you guys come up with that? I know you were both programmers working in tech and that you decided to start on your own thing, but how did you come up with that idea, and how did it lead to really Trello and what we more know about today?
Michael Pryor: [00:01:17] If you roll back the clock to 2000, it was quite a different era then. And I think most of the time when you were a programmer you were not really the focus of the company. Like Google didn't exist back then, Facebook didn't exist... Except maybe Google did exist. Anyway, they did exist but there wasn't this idea of like a tech company, you know, where developers were in charge, building the product, and where they were the interesting part. Like we worked at a company called Juno which kind of competed with AOL. That's how I met Joel. And it was essentially, their play was, we're going to give people free email, you know? Like AOL would charge $20 a month. Their idea was, hey we'll give away the email for free but our client will show you ads. And the way that they thought about that company was as an ad company. And so even as a programmer there, where you're the only way that people connect with the company. It was through the software, that was their entire 100 percent of the way that they they thought of Juno and the product. But the company itself thought of themselves as an ad company, and so that sort of trickled down in the culture. And so programmers were kind of support function, you know? Like oh yeah, I see you have some concerns about privacy. That's nice. You know like they weren't really paying attention to us.
[00:02:44] And Joel and I were just, I don't know, we were just frustrated and I was really young and naive. And so I thought I could start my own company, and I was too naive to realize how hard that was. We were just like — sure let's do it. And Joel and I set out to start a company for a very long period of time. It was like playing house. It was totally fake. I remember spending a lot of time thinking about our logo and getting little pens made out, like totally the wrong thing, we should not have been spending any time on that. But that was easy to do. It took a long time before it actually became a real thing. But along that way Joel was blogging about that adventure and it turned out that a lot of people were really interested in it, and also not many people were blogging then. So part of our success with Fog Creek I think was building that audience. And Joel is a great writer. It was easy to read and it was at a time where there wasn't a lot of noise in the blog world. I don't even know if that term existed when Joel started writing. So that sort of gave us a big audience. And so we built software, ideally software that was appropriate for that audience, and so this was essentially content marketing before that was a term. We didn't even know that's what we were doing. And when we built the company, the culture that we built around it was just very much from a programmers mentality of fairness, openness and transparency.
[00:04:28] I mean you see this open source stuff, and imagining that in the legal world — where all lawyers get together and share — like that would never happen. Right? It just doesn't. It doesn't exist in that world. Like it's a little bit too competitive. For some reason, programmers are just interested in that. They totally will share with other people and not expect anything in return. That's what stack overflow is built on. And so when we built the company, the way that we set it up... I mean even in the beginning Joel, who's 10 years older than me and had a lot more experience than I did, said let's just split 50/50. Which is kind of dumb. He never had to do that. But that was it. We avoided so many issues along the way because that was the way that we started and that's always been his advice. Like if you're going to start a company, just split it and don't worry. It was just sort of this equitable place. And we did profit sharing from the beginning, you know? We were like, if we make profit, we'll distribute it to all the employees. We gave people equity, which at the time was really kind of hard to do. It became easier as time went on and as options became more of a standard thing. And a lot of the stuff that we did became fairly standard, not because of us, but also because of Google and Facebook and those companies having a lot of success. So kind of the nouveau ideas that we had back then in 2000 are kind of run of the mill for a tech company nowadays. Even our compensation system, the way that we paid people was very much against the norm where a better negotiator gets paid more. We didn't do that. Now you see companies like Buffer publish transparently the entire salary structure of the company. We didn't go that far because, in my personal opinion, that creates a lot of other problems, but we were basically said, "if you have two people and they have the same experience, you're going to get paid the same amount."
John Peebles: [00:06:48] And it's interesting because nowadays a lot of those ideas are being trumpeted by other companies, and some people that were reading the blog are like, all those are old ideas from Joel and software and Fog Creek and so on, but even then it was kind of like you guys were putting into practice ideas that were really in a book called "People." There were even tactical ideas around office space and eating lunch together... Maybe just talk a little bit about that, because I think that's amazing when you're based in New York City and you put this stuff into practice, stuff that is expensive but should make a difference.
Michael Pryor: [00:07:23] Joel used to work at Microsoft and I think a lot of the practices that they had were thoughtful and like, you have an office with a door that closes for programmers. And so he had had that experience and then had gone to work at a media company, Viacom, in New York City, where as a programmer you're kind of a support function and then same at Juno. And so he saw different ways of operating. He saw a company focused on software versus a company where the software has just the support function. And so in that experience it was important for us to create a company that did take into account all the things that people are learning. So you're right, we borrowed from there and and just sort of made it more and just practiced that.
John Peebles: [00:08:21] But when I when I think about this team of you and Joel, you guys created Trello, Stack Overflow, FogBugz was a big deal, particularly at the time, and it almost seems inevitable that, oh yeah of course Trello is going to be a blowout success. But the thing I love about this story is also a number of failures along the way as well. So wasn't City Desk the first product? And that was that was a failure.
Michael Pryor: [00:08:49] Total failure. I mean if you think about it, like you said, Stack Overflow and Trello and those things came later. Like Trello was in 2011, Stack Overflow, 2010. That's a decade of failures that we learned from. And in fact, we made FogBugz in 2000 and it was like a thing that Joel had written at Viacom and carried over to Juno — we called it Juno Bug — and then we started Fog Creek so we called it FogBugz. Worst name ever. Like we were just awful at naming, we got better. But City Desk, you know we thought that FogBugz was like "aaaah yeah, bug tracking, maybe somebody will buy this." But City Desk was where we thought we would make a lot of money. And City Desk was, at the time Joel was blogging, more and more people were blogging, so we thought this content management space was really going to heat up, and we saw that people were trying to install TypePad or GoogleType. But it was really complicated because you had to have Shell access to a web server, figure out what public underscore HTML was, set up Apache so that CGI bin directories were executable, and then you had to download these perl scripts... It was a nightmare. Like the only way you could do it was if you were a programmer. So we thought we'd build a desktop app where you just add a new article, type your article and it's Wizzy Wigg. And then you save it, you push a button, there's sort of mashing up of the site, the generating of the HTML is done on your desktop and then the only thing you have to know is the IP credentials for your web server. Which is actually an interesting idea. It solved the problem that we saw, but MovableType and TypePad and Blogger, those companies also saw that problem with their own software and solved it themselves. They used the web page itself to configure the web application and bootstrap it. And so they solved that problem and City Desk just went nowhere. There was actually, I think Macromedia had a similar app, but so City Desk was a total failure. Like it was the right idea but the wrong execution. So like the idea of making a client site app was just totally wrong and FogBugz actually started the sales, we were doing pretty well. You'd make like 50 dollars one day and then you made 400 dollars the next and then you made like two dollars, so it was sort of bumpy but we made a little bit of money. And over time we used the profits from Fire Bugs to fund a lot of other failures along the way. So we learned a lot of lessons.
Michael Pryor: [00:11:27] We had another product called co-pilot which was a screen sharing tool that we needed ourselves because when we were installing FogBugz on people's computers we required complicated patchy configurations or ice configurations as you're trying to debug this stuff, and you knew that if you could just see their computer you could solve this instantly. And they're telling you what they see on the screen and you're like tell me what you see on the screen! So we thought we could use BNC to look at their computer, but that was complicated. So we bundled that up into a screen sharing tool. And at that time it was like 2006, 2007. There wasn't another tool that did it quite like that. There was like a box you could buy and install in your office for thousands of dollars. So we thought we'd build something that does this. We got a bunch of interns to do it, we made it, we actually filmed it. It took a summer and we made a movie. It's the nerdiest movie ever.
John Peebles: [00:12:25] That was the low point of the naming. I think maybe it's called Aardvark?
Michael Pryor: [00:12:29] Yeah well that was because we started naming our intern classes and they were like ABCD, so you had to pick a name that started with A, So we did animals. So they were Aardvarks. So Co-pilot was a great product, made a little bit of money, it was pretty good. But the lesson there, the big failure there was that it was the right idea, the right time, in the right market — because, you know GoToMyPC and LogMeIn came out right around there and both became billion dollar ideas — and Co-pilot, only made like 30 grand a month at its high point, which was pretty good for us. That was awesome. But that was a brilliant idea and if we had invested in it and marketed it to the right people it probably could have done a lot better. So we realized that we had marketed to customer support agents — because that was how we used it — instead of thinking much more horizontally. Like, lots of people want to get to their computers, or IT people want to get to their employees' computers, or whatever. And we just didn't understand how important that piece was, of how you're marketing it.
Michael Pryor: [00:13:47] Joel's blog was super great for us because it brought in people, but it also kind of narrowed the kind of people that we could talk to and we didn't have a muscle to talk to anybody else. Right? Because we didn't ever have to. We were like, oh great we have this audience of techie developer people, and so we were lost with how to market a tool outside that. We didn't have any Google Ad Words experience, we weren't doing any other kind of content marketing. And to actually think back to the trajectory of FogBugz, it was doing great, but you know Jira came out two years after we had started selling FogBugz and it's an eight-billion dollar company now. Right? So they didn't have Joel's blog rate, they had to just market themselves and figure that out and did an amazing job at doing that. So we took a decade's worth of failures. And when we built Stack Overflow there was like a plan for how to do it and not make the same mistakes. And that was the same with Trello.
John Peebles: [00:14:56] So walk me through the evolution then. It's basically two programmers, start a software company that's building tools for programmers. How long to the first hire? Were you coding 100 percent of your time in the first couple of years? How did that evolve out and what did you learn along the way?
Michael Pryor: [00:15:14] Yeah we didn't build the Fog Creek software to be a... The company didn't exist because we had a product idea, it just existed because we wanted to make a place that developers wanted to work at. Right? That was our mission. So the products... We were sort of ambivalent about what we sold. In the beginning we just did some consulting and we thought we would get ideas for cool products to build. That's where City Desk came from. You know? We sort of had FogBugz and though we'd package that up and sell them for a little bit. But in the early days Joel and I were doing all the programming and we sort of took turns doing the administrative stuff, like quick books and you know filing the fees and that kind of stuff.
John Peebles: [00:15:58] Who was the better programmer?
Michael Pryor: [00:16:01] Joel was. He was way more experience than I was. And so we did that for a long period of time. Joel did the admin function for like four years and then I switched and took over for four years. And we sort of co-led the company. He was the CEO, I was the president, and we had specific ideas about career progression and how programmers should progress in their careers. I don't think developers necessarily make good managers or that the skills that you have as a developer transfer over. I know that nothing I learned as a developer has anything to do with what I do today. It would not have prepared me for what I do today. It's just completely not related. So you may find somebody that's a good developer that could be a good manager, but it's not a good idea to make that career progression for developers. So we created two tracks, which is similar I think to Microsoft's setup. So we had like a management track and an individual contributor programer track, and basically all of the programmers were members of technical staff, which I think we also stole from Microsoft. And we had one distinction. We didn't want to create a lot of levels and things like that. So we had member of technical staff or senior member of technical staff. That was it. But you know there was this idea of career progression as just a developer. You didn't have to become a manager in order to progress in your career.
John Peebles: [00:17:50] So then, did you guys have a litmus test or some kind of thing that you would look out for or talk about on the team? Because I think a lot of times if you're a programmer you want to try out management just to see and if you're management... it rarely goes the other way, but you know? There had to have been that tension at times. How did you guys manage that? Because now you've managed hundreds of people through that. I think it's a question a lot of people in the audience will have. What is the thing that sets you up to be a good manager or even just to enjoy management?
Michael Pryor: [00:18:23] I think actually before I came here I talked to the engineering manager for Trello because he's actually from Edinburgh, Barry Clark. And I asked him for some tips for this talk because I think he's a fantastic manager, and so he gave me some great insights into how he thinks about it. He deserves the credit. So we were talking about CEO versus manager — and we can come back to this, because I think that as a CEO you face a whole other set of problems and need specifiec skills that management doesn't even prepare you for that — But he talked about this three month period where a lot of people figure out really quickly whether they are going to miss being a developer. Because when you're a manager, you're not a developer anymore and for some people that's actually a really hard transition. You know, sometimes I still feel bad that I don't write code anymore or feel a bit like I liked writing code, it's fun. It was also concrete. Like you made a thing. And as a manager you're just talking to people all the time. You wonder what you're doing. Where's the output? There is output, it's just you can't see it and measure it. And in fact your output is the output of the people that you're managing, right? And that's a hard thing to understand. And I think early on it's also hard for you to step back. If you're used to making and building, to step back and help other people make and build even though you just want do it is hard.
John Peebles: [00:20:12] Have you found a way to scratch that itch within the company, or even externally? I know that's something I really struggle with. I want to make something each day.
Michael Pryor: [00:20:21] Yeah sometimes it's just about trying to build. At Fog Creek we used to do these things called Creek Weeks where we would take a week and build things. At Atlassian they have a similar thing called Ship-Its, which are like a 24 hour hackathon. And I try to get into that. Once you stop writing code though, it's hard because now you're not up to date. I don't even know how to write Node JS code. I'm like, let me get out the VB script editor. You know? I can write Excel macro... I'm just so behind on the times. But for us I think letting people get a chance to manage and just understanding that you might like it and you totally might not, and that's totally okay because there's another career progression for you and you don't have to think of being a manager as the only way to be better or have a better career. I think actually being a manager, the skills that I see, Barrie has mostly just tons of empathy and caring about people, and loves being an advocate for them and trying to get things out of their way. Like Joel wrote a big blog post a long time ago about servant leadership and this idea that being a manager is not telling people what to do, because first of all you're going to be so far away from the actual problem that they have to solve. So like really you're trying to get things out of the way and empower them so they can solve the problem. That's hard. I still struggle with that today, because even with Trello I'm like, "Why aren't we building this feature, this feature is the thing to build. And we should build it this way." Right? But we have PMs that are solving problems and they have to figure out what features are going to solve those problems. And they have to figure out how they're going to be built. And the engineers are going to contribute to that. So it's a struggle, but essentially being a manager is just a support function in trying to help people and making sure that they are happy so that they can be productive.
John Peebles: [00:22:41] Another idea. So if we rewind back to the late 90s, early 2000s, I think you guys were really instrumental in this idea of a developer-first company. But there is something else that I took away as I was reading Joel's blog. He posted about once a week it seemed like. And I was in Indiana, going to school out there. And it was one of the first times where I was reading something from a technical person, obviously very accomplished, the company going places. But he was very vocal about the fact that he was gay. And I just think that that was an important thing. And did that ever manifest itself? Or did you ever see blowback? Particularly now when we struggle with diversity in tech startup land we usually talk about maybe racial diversity or whatever types of diversity. But to me that was one of the first things that I can remember in the tech industry where there was diversity, it was celebrated and it was out there.
Michael Pryor: [00:23:41] Yeah I mean I don't know about his personal experience and I'm a straight cis white male. I've had so much luck and privilege in life that it's hard for me to relay what he dealt with as he went through that. But I think that that philosophy of equality and fairness was obviously critical. If you think about the way that we structured the company, whether it was because of his experience or whether it was just because that's like the way humanity should work and treat each other... You know it's like even with Trello the idea of building a product that's super horizontal for the entire world, you can't build a product like that unless you build it with people from all over the world, from all kinds of different people. And so you know that's really important and core to the culture that we built at Trello and I think it's not only the right thing to do but it's actually an advantage for us, because it actually makes a better product. If we're going to build that product for the for the world we have to understand the kinds of problems people are facing. And so it might be language issues, right? It might be understanding how we come across in different cultures and the way that our copy is on our website or something like that. It could be a feature that we have in Trello — color blind friendly mode — like if you have labels on cards and you can't see colors, how does that work? And so one of the guys at work, the designer, just made it on his own. I think all these great things that make Trello so special, it's not because somebody told people to do this. We just found people that were creative and an amazing, and we just sort of made space for them and that's how these pieces came out. So this color blind friendly, mode which gets remarked on all the time online, it changes the colors into patterns. So if you can't see colors but you can see the patterns, you can tell the difference. So it's small things like that I think require a shared understanding of people's experience inside your company, otherwise it's hard to build a product. I don't know, if you eat your own dog food and then you usually build a product that is just for you. Right? So the more you can make your company sort of see things from different viewpoints and use it from different ways the more well-rounded your product is going to be.
John Peebles: [00:26:21] So at Administrate we've got about 60 people, and I would say almost every team — apart from the engineers — use Trello in some way. So we probably have at least 30, 40 daily active users and we don't pay a single cent for it.
Michael Pryor: [00:26:39] But you should.
John Peebles: [00:26:40] Well, how? How do you actually buy and pay for Trello? Is this a common thing where companies are running basically their whole business on it? It wasn't a choice, it just infects the company effectively.
Michael Pryor: [00:26:55] I mean, so, our marketing budget was making Trello free. We didn't actually do any marketing. All the sign ups for Trello are organic, we never spent money. But you know, we went without the money in the early days in the freemium sense. We gave a lot of value away and what we got was a very big audience of people that are huge fans of the product. And I'm confident that as time goes on and we build things on top of Trello, we'll be able to align the kinds of features that convert somebody from free to paid with somebody that gets a ton of value out of the product. So like people that use it a lot will end up becoming likelier to become paid users, and that's like the kind of relationship you want because they already understand the value and they could see even more value ahead. And then they're happy to pay for it.
John Peebles: [00:27:58] So in a sense, the strategy is you got freemium as the iceberg, right? It's where most of your effort has gone to date and you're trying to build on top of that in the future?
Michael Pryor: [00:28:07] I mean, I don't know if I would cut it up like that, like all of our future work will be paid. I think of it more like you would think about the power ups. Like the strategy for Trello is to be a horizontal product. Some people are going to want to take it in different directions that are more vertical. And so we came up with this idea that we would have power ups. So you could take a board and you could sort of turn certain things on and then it became more of a sales tool or more of onboarding or more of a developer tool. But it didn't have to change the core of what Trello was. And early on we actually had it set up so that you got this power up for free, but if you paid you got these. And we realized that that's a bad platform because then people can't actually sample all those other powers because they have to pay for them. So we changed it. So you can turn on any power up you want on any board, so you use this power up on that board, and a different power up on a different board, so that you can figure out how they all work. But if you want more than one you have to pay. And that's how it is now. I don't know if it will stay that way forever. Maybe we'll raise the limit or whatever, but it's a better way of addressing the fact that people want a more specialized experience. The next thing is, if you think about people that use Trello a ton, Trello is sort of missing some functionality in solving that problem which is like, "I've got a lot of boards, what's going on here?" And we have great ideas about how to solve that and tie that into both free and paid so that the free version will get some of those features. And we also have to figure out what the trigger is that you can get even more when you pay us. So it's intentional. But you know if you want to pay, go for it.
John Peebles: [00:29:57] We've got very little time left. Maybe you could just tell us very quickly what was the worst bug you ever had to fix that just drove you nuts?
Michael Pryor: [00:30:04] Oh I'll tell you the worst thing I ever did. I checked in code that pointed our billing software at the credit card processor sandbox, so that it looked like all of the charges were going through and we were recording all the charges and everything was happy and wonderful. But like the sales charts that were showing sales were still going up and up and up, and then in our bank account no money was shelling out. And then the worst part was to fix it. Then you had to go back to people and be like, I know we said we charged you but we didn't. We're going to charge you again. And like everyone was like "What? That's ridiculous." There's that. That was the worst. Or the time I checked in code that forgot to charge sales tax and the state came in and said "Hey you owe all this sales tax" and we had to write them a huge check. I mean like I've written a lot of bad code.
John Peebles: [00:31:03] Alright, well, thanks so much for coming in.
Michael Pryor: [00:31:05] Thanks so much for having me.