George talks with Matt Holford, the new CTO of DoSomething.org about how he approached his role and improved their tech development process. Matt discusses his three step approach of learn – plan – execute, using a faceted feature analysis (FFA) process at DoSomething.org to manage and prioritize products.
Resources from the podcast
Transcription
Episode 10
Speaker 1: This is Using The Whole Whale, a podcast that brings together stories about data and technology in the nonprofit world. My name is George Weiner, your host and chief whaler of wholewhale.com. Thanks for joining us.
Do you ever wonder who’s going to inherit your job when you move on to your next role? Maybe find all of those skeletons in the closet? It’s an interesting thought. I spent a lot of time thinking about it and I have tracked down the man who has my job; Matt Holford, the CTO of dosomething.org. Welcome to episode 10, this is going to be a two parter because the conversation with Matt is so interesting. The first part we’re going to be finding out how he approached the job in three phases and thought about project management, thought about how to manage the product and the tech team and the expectations at dosomething.org. Alright, let’s jump into it with Matt.
Thanks so much for joining us today on the podcast, who are you and what do you do?
Speaker 2: I’m happy to be here, I’m Matt Holford and I’m the Chief Technology Officer at dosomething.org. Which used to be your position, George.
Speaker 1: My position, so we’re in a fine position overall here.
Speaker 2: I know, we are.
Speaker 1: You were recruited in and I’m very happy to say that they found somebody far smarter than I am to take over the job, which was ultimately my dream. To hand off something that was hopefully working to someone who could take it to the next level. So I’d love to kind of go through this process of you know, you walked in to do something and…what where…how did you approach this? It’s a big organization, what was your approach?
Speaker 2: Well, I had gotten recruited out of a different job working at a digital agency in the commerce world, e-commerce. And that was very much kind of my angle on things and I also have a big technical background in Drupal which was the traditional platform for dosomething .org. So there was an interesting mix for me, of challenges. But this would have been the first time I had been employed by a not-for-profit. And the thing I was most, kind of leery of coming in was walking into a situation that was poorly managed, that was disorganized. That was kind of tech in name only but didn’t really have a lot to work with. The thing that I was pleasantly surprised by when I came in was that there was a long history there with building ambitious web products. And there was a long history with Drupal in particular. So that was on the positive side. I think one of the things that we had to work through in the beginning was, I kind of mixed history in terms of how much the internal staff knew of the technology they had. And so one of the challenges was to figure out kind of a relationship to consultants, to outside consultants and what we wanted to do with them. On the budget side there was…there was actually kind of a lot allocated to spend on consultants. So one of the things I…one of the points of view that I brought to the situation was I really wanted us to invest in having a staff that understood the code we were running really really well. And then we’re together able to make good decisions about what we wanted to build, what we wanted to rebuild and how we wanted to do it. So that if we did go through another big ambitious build (which we ended up doing over the last year), we would get to the other end and really feel we owned the stuff. So the investment began as thinking about staffing and trying to keep as many of the great people there that we could.
Speaker 1: Yeah, so the factors that you’re thinking… you walk in like, we’ve got the ultimate decision. We can work in-house or we can work the out-house. We can get external experts to come in, kind of like a dentist take care of our teeth and walk away. Until you realize that our core [inaudible] it seems like, was technology in this case. And so what were the factors that you weighed when thinking about…do we rely on external expertise first, develop in-house staff?
Speaker 2: Well, part of it was just what is our wherewithal? Can we actually afford to have a staff? And good staff? And hire them from places where they can bring in kind of battle hardened experience on this platform with other technologies. The answer to that, luckily for Do Something was yes, we could do that. So that was the decision we made in the beginning. We started doing some work refactoring and addressing some of the technical debt, which is a term we can get into detail if you want. But instead of farming that out to outside consultants we started to own a lot of that and started to try make some of the hard decisions ourselves, about code we wanted to rewrite, things we didn’t think were working. And honestly, things we just didn’t understand or as an institution remember why we had in the first place. It’s a big website, there is a ton of stuff on dosomething.org, and there still is! Even after we re-launched a lot of it there’s still like book reports from years ago, and a lot of the static page content, like 11 facts pages that drive a lot of traffic to the site. And things that only have an insularly relationship to the main product, which at Do Something was campaigns. So what we did was examine kind of all of that universe of content responsibility that the site had and think about how we could rebuild some of the most important stuff from the ground up while still serving this other content that was bringing in traffic to the site.
Speaker 1: Yeah, so this big launch that just happened, we’ll get into that in a second, that you know, ultimately you do this evaluation, you realize we need to focus on campaigns as you just mentioned. You mentioned also, and I happened to know from personal experience at Do Something, is there’s no shortage of great ideas running around. So the question is, what was your approach to bringing process and organization and evaluation technique to which products made it and which products were put on the back log?
Speaker 2: Right, absolutely. Well, the big picture is that I…last week marked my one year point. So…
Speaker 1: Happy Birthday.
Speaker 2: Thank you!
Speaker 1: Or anniversary.
Speaker 2: Yeah, I see my time there as split into basically three parts. The first part was about process, really looking at what we process and how we work. The second part was making the big plans to what we were going to build and redesign. And then the third part was just flat out implementation and sprinting up to the platform launch in mid-March. So the first part in process was a pretty intensive time for all of us I think. Where I had a lot to learn about how people had been working and we as a team wanted to make some decisions about how we would work. A couple of things that we did were to start to use some other documents to try to track and contain the scope of things we were working on. And one of the documents we use is called a FFA or a Fasted Feature Analysis, which is basically a big spreadsheet of features you want and features that other people suggest related to a particular product. For instance we had one main for our campaign template that was enormous. And it’s a user story followed by some notes and commentary from people followed by three columns. And the columns are the value to the user experience, the value to the business and the kind of level of effort on the technology side. And we use that for any significant feature that we have to think about as a way to come up with a full list so that everyone felt that their arguments were included. And then to whittle down to what we thought our release was. And it also, I think, slows down the process a little bit. Because as you say, dosomething.org has got a staff that is just full of ideas. And that’s kind of common to a lot of young organizations and startups. And the dangers I heard, I don’t know where to attribute this to, but the danger often to a start-up is they can drown in their own pool of ideas, in a huge backlog that eventually becomes a demoralizing factor within an organization. Because they have too many things that they can’t act on, it really feels bottle-necked.
Speaker 1: I picture this like, sort of like magician spinning too many plates and it’s like, just that final plate that doesn’t just take that home plate down but what really causes this, we spread our peanut butter way too thin.
Speaker 2: Yeah and things come crashing down, absolutely. So what we tried to do was purposefully bottleneck the process and make that explicit so that people understood that there was an order of operations that we needed to obey as an organization. And it wasn’t about the tech team, it wasn’t about let’s blame the tech team because they can’t work fast enough.
Speaker 1: First it’s definitely the tech team’s fault and you guys can’t…
Speaker 2: Yeah. totally, totally. You’ve proven that. It was…so part of this first third was about, I think, talking organization wide about what our bandwidth is as an organization. How many things we should try to do at once. And how then we translate that into actual actionable ideas and implementation.
Speaker 1: I really like the way Matt breaks this up into thirds and in this first third, he goes around talking with everyone. And in talking I also know that he is doing a whole lot of listening to every single department, every single person, their ideas and what they want to accomplish. Too often I think technologists run into organizations and it’s kind of like a carpenter with a hammer thinking that every single problem is a nail and they’ve got the solution. So Matt does a great job gathering the requirements of the different teams, now let’s hear how he takes this and moves it into action.
Speaker 2: So part of that was making the scope of things explicit. We’re in-putting what we are going to do and then thinking about the order of these big projects so we could say, “Yes, we have to do this thing, in order to do this next thing. And we’re not gonna talk about the hard dates for the next thing until we get the first thing done. And since we’ve never done the first thing before, let’s not set arbitrary dates. Let’s just start working.” So the second third of the year was spent really making these plans, backing things up, rethinking how we design stuff. One thing that happened in September, so this is getting into the second third period, was that Nancy Lublin the CEO named herself, with my kind of background encouragement, the Creative Director. And that really made us think about how we were designing things at Do Something. We did bring in one consultant for a little while, to do some design. But it was almost entirely an internal process. And it made us kind of, take a really uniform approach to redesigning things. And Nancy helped enforce a very clean, purposeful aesthetic on what we were doing and that also brought a lot of focus to the final products that we worked on.
Speaker 1: So let’s step to… I have been sitting there, project plan in hand, saying “Oh gosh, if we were to build this internally, I have no bandwidth for the emergencies and fires and sponsors and candidates that come up.” So it’s the nice versus necessary, the immediate type of work that when you’re an Agile-ish style of project management and you’re in this moment of saying let’s build it internally… How do you manage the expectation of the team at that point? Where if we’re building a new site, our bandwidth is now this.
Speaker 2: Well, it was within the tech team and also across the organization. Understanding that we’re going to make as an organization an investment in rebuilding some really substantial stuff from scratch. And so to be clear, that was rebuilding starting in November, so this is the last kind of third. Rebuilding the core site in Drupal and some other technologies when we decided that Drupal wasn’t the right answer for certain things. And we had talked about November with the managing team across the organization, starting a few months before then. So that we could do things like, not run really important campaigns in November. Not take on any new… any new good ideas of any kind in November. Reserve one of the big conference rooms almost every working day in November. And so it’s a commitment that the organization knew we were all making to reserve in this time for the tech team. Of course things came up, and we knew that too. One of the ways that we talked about that extra bandwidth you talked about, for annual emergencies, is unplanned work. Like emergencies, things go wrong in production, a bug that no one understands that’s killing a campaign, anything like that. That all counts as unplanned work so any time one of those things came up over the last year, really, we took that moment to think about, “Okay, how do we invest at this moment to address this problem and prevent it from happening again. Reducing unplanned work became a portion that we reserved in all of our sprint planning. So it’s like, we think about lopping off 10-20% of the bandwidth of a sprint to reduce unplanned work. Which really means kind of like, platform production support. Knowing these things are going to happen, but also continuing to reserve the time not just to react but to turn that stuff into positive learning that can like, prevent those problems in the future.
Speaker 1: So you’re currently on a two week sprint cycle?
Speaker 2: Yes.
Speaker 1: And you’re following basic management. Do you have a scrom master internally?
Speaker 2: Yes, there’s a person who was kind of an engineering manager, Barry Clark, you know him of course. Who I thought just had a great handle on trying to get the engineer’s team bandwidth manageable and really understanding who should be working on what and doing kind of technical project management. So he’s been kind of the de facto master. We’ve got two capital S-Scrom, capital A-Agile.
Speaker 1: What does he mean by capital A-Agile, capital S-Scrom? Well, scrom is an agile methodology commonly used in software developing. And it’s an iterative process where we define sort of batches of work in order, known as sprints. These sprints begin with a planning meeting where we figure out, you know, heck, how much work are we gonna get done? And at the end, after a series of stand up meetings along the way, you do a retrospect of well. What got done and what didn’t? What can we identify about our process and about our code that needs to be changed as a result of the work that just happened within this sprint. It’s a great way of identifying problems earlier on in the process instead of waiting you know, six months before identifying an issue in either our code or even the way we’re working together. And when he talks about Agile-ish and using this, there are entire certifications. I mean gosh, there are podcasts just dedicated to the study of Agile. Agile-ish just means they’re adopting the parts that make sense for their organization instead of trying to fit themselves into a cookie cutter. It’s a really good way of approaching it and adopting it and let’s see how they’re using it.
Speaker 2: Well we do take a bunch of these practices where they make sense to us. For instance we have sprint planning, we have stand ups daily or near daily forward projects or big initiatives where there are a bunch of people working. And we do a sprint retrospective at the end of the two week period where we talk about how things went and whether there are better ways that we could work in.
Speaker 1: And they’re using Trello, I think it is?
Speaker 2: We’re using Trello across the organization now. That wasn’t my initiative, someone started it before I got there. And it was an amazing thing to do because it started the entire organization from marketing to tech using Trello to organize their stuff. So they won’t expose their work to each other. Within the tech team, because all of our projects are in Github, we’re all using Github issues, which has been a really good move for us because it’s helped us track the different code commits, so different people’s activity against a particular issue for like institutional memory.
Speaker 1: So many of us may know Github as the best version control for our code out there. Version control just meaning that it’s kind of like track changes, where anybody who is in the code is able to say “Hey this is what I’m changing” and leave a little note. The Github issues is actually interesting because it actually allows it to become more of a project management system that’s directly tied to the code. Developers tend to love this because they can actually closely deal with issues directly within their interface and it’s easy to set it up with regards to labels, and sprints and tracking issues inside of the code.
Speaker 2: So we go back and say, “This was the problem, that was the bug and then these three people committed this code against that bug.” It’s something that plenty of other issue tracking platforms like InTools, Jira, and some related ones have. But Github issues was really simple for us to take on.
Speaker 1: Yeah, often it’s less about the tool and more about the use of it. If people adopt it, God bless it, it’s the perfect tool.
Speaker 2: Exactly. So we have two things and it’s a little bit redundant but Github issues has been really good for the tech and product team in particular to track issues in code and watch that stuff…
Speaker 1: So I’ve been watching from afar, getting the emails, the alerts and the final launch it’s been really impressive. I think maybe it was a result of you know, long range project management, great vision from the beginning. But it is the cleanest I’ve ever seen the site in terms of focus on this is what we do. Can you talk to us a little bit about what are the metrics that you’re looking at, that you’re now following? You’ve launched the site and you’re constantly on there, how are you measuring success from the technical perspective?
Speaker 2: Well, we did take a fresh look at all of our KPI’s, key performance indicators, in the beginning of the year, knowing that we were kind of re-platforming. And some of the behaviors would be different. And then also that we would have the opportunity to track certain things more cleanly. So a lot of the KPI’s have to do with how people come to the site, how they go through the kind of sign up registration flow, participate in campaigns and complete them. One of the KPI’s that we report on now is site speed, and we use two tools to measure that and actually report on very different things. One is Google Analytics and one is New Relics browser site monitoring.
Speaker 1: There’s a lot we can learn from how Matt approached his first year at dosomething.org. He broke it up into three phases: learn, plan, execute. In that first phase where he’s learning, he’s talking but he’s most importantly, listening. He’s getting the ideas and really the product vision that different departments and teams have, putting that all down and moving into the plan phase. And then within this he’s refining their Agile methodologies, he’s managing the expectations of the team. This is what we can do, this is what we can get done. Once he had that set he moved into the, finally the execute phase. Where he brought the site into where it would find the launch by using the internal team resources available.
On our next episode we’re going to hear more about how he thinks about the key performance indicators of the site as it relates to site speed, super important. Well, you can always find all of the resources from this show at wholewhale.com/pod-cast. And as always, thanks for joining us.
This has been Using The Whole Whale the podcast. For more on the topics covered in today’s show, please check out wholewhale.com/podcast and consider following us on Twitter at @wholewhale and thanks for listening.
