Tony Atkins, Lean Innovation Program Manager at Atlassian, talks about what lean innovation means in a growing organisation.
Transcription
Paul: So maybe it might be worthwhile if we if we kicked off, maybe if you could give us a little bit of background about you and what you do now.
Tony: Yes. So a good job title is kind of like one of those little hats, fascinator. It attracts your attention. Anyway, I’m lean innovation program manager. The program manager part means I have a group of people who work with me and we do a bunch of projects that are all with the same theme.
So the lean part of the theme is around providing as much value to the customers as we can with as little effort. So it sounds boring, unsexy, very manufactory, very time and motion. But really, what it is kind of a lean startup approach, but within an existing company. So some people call that entrepreneurship where you’re basically applying the techniques of entrepreneurship growth hacking to an existing problem space within an existing company. So that’s the lean part, is we’re trying to fight out of our weight class, to do more with less, to use a cliché. And the innovation part is maybe more interesting is it’s the way we’re doing it.
So in a traditional team organization, you would have a group whose job it was to be cool and do new things. We are, to a certain extent that, but more our job is to build a culture where everyone does that. So right now, our global team of 120 engineers each have an hour a day where they’re not just allowed to work on new projects, they are required to work on new projects. They are required to work on what we call proactive work. So our reactive work is coming in from customers. We’re going to get that no matter what we do, but we’re protecting one hour a day per engineer where you say, “I’m going to do something that will take me away from the queue for this hour but we will prepare us for the future.”
So for example, working on a knowledge base article that fixes today’s problem but also tells the next 10 people how to solve the problem. So that’s kind of what we’re doing. We’re building a culture of innovation and teaching people to do as much as they can with as little as they have.
Paul: Yeah that sounds incredibly interesting, trying to build up this culture of innovation. I hope you don’t mind if I kind of delve into the nitty-gritty about a little bit, just because it’s going to be very interesting to a lot of people. So when you say each of your 120 engineers worldwide have an hour a day to work on something that is proactive. Is that hour, do they have to spend that as in an hour per day or can they save them all up and spend five hours on a Friday afternoon?
Tony: We treat them as team goals. So for example, one person might come work with us for two weeks, and they would take their whole team’s share for those two weeks, or a whole team might set aside two people who are working half-time on a project for two weeks, and the rest of the team is focused on the queue. So that it’s flexible enough that we can still respond to spikes in our load, to new challenges coming in that we need to react to. But the expectation is that every team has a budget and they’re expected to spend it on working together. And it’s not anything that they’re expected to spend it on. They’re expected to actually come out and hit bigger and bigger parts of those challenges, to pick good things to work on.
Paul: It’s like a lot of fun. And how’s it working out?
Tony: It’s still early days where we have the best progress. The other challenge is that we have five different offices and at least two of them are only available when you’re asleep. So coordinating with offices around the globe is a bit of a challenge. But the idea is that every office is running at least a few kind of lean startup style experiments, they’re working on a few process improvement projects. They’re all working on knowledge goals. They’re all preparing the solution today that prevents 30 issues tomorrow. So they’re all doing some activity.
We have the most success, I think, with the team that we’re awake with and interacting with constantly. But we’re spreading it out. The challenge with the other office is to build champions, people who can represent the culture, and who can have that day to day interaction. And we’re still working to give enough of them their early win, enough of them their enthusiasm for the process and understanding of the process. But I would say it’s going well in our core region where we’re working with them constantly.
It’s not that we’re selling them on ideas that they should work on. It’s that they are looking at the big challenges that we’ve agreed on as a team, and they’re finding ideas that address those challenges, and they’re building a team from within their own members to address that. And they’re coming to us only as consultants for particular things, like we need help with an approach for this kind of reporting, or we need a little bit of development resource. Where before, they would just depend on us to do it, and if we didn’t do it, then they had an excuse not to care about it. Now, they care about it and they want to make it happen. They’re pulling help from us rather than us having to push help and ideas out to them. They’re coming to us as fast as we can talk to them. So that’s a good sign. I mean, it’s a lot of work but it’s a good sign.
Paul: Yes. It sounds like a very positive sign of potential further down the road, if you can roll that out to the other offices.
Tony: And this is the other crazy part. So you hear about 5% time, 20% time depending on the company. Our goal is actually to be 80% proactive by 2020, for people to spend three-quarters of their time… Sorry, 80% so that four-fifths of their time working for the future.
Paul: I’m assuming then the lean part of your job, there was or there is an ongoing part of that that’s education, informing people what the principles behind a lean startup are, and how they can apply that in an entrepreneurships sort of way within a large organization that has existing processes.
Tony: Absolutely.
Paul: Talk us through how you go about explaining what lean startup is and how people can apply that within your organization.
Tony: Right. So we also take a bit of traditionally lean, actual Toyota lean, and we also take a bit of lean Kanban. So we take about three different flavors of lean and mash them together. But to us, that means when you come to me with an idea, you need to have some… If 15 people come to me with opinions, that’s not going to work. It’s going to be who can shout the loudest, who can maybe debate the dirtiest. It’s not necessarily the idea with the most merits.
So the idea is you get people who are used to going through and saying, “Okay. For example, how often does this happen? How much does it cost us when it happens?” So basic things like that. With those two you can say, “This idea is this big a problem. This costs us this much. And this other idea is this bigger problem.”
So even if it’s just one variable, like density, that allows them to float up so that we can seem rough prioritization. We have three or four like that, things like that. But the basic one that I tell people is, “Tell me how often it happens and tell me how much it costs us.” And cost, for us, is time – how much time we spend.
So for example, we seeded the pool by saying, okay, we’re going to do a value stream analysis, which is a very traditional lean tool where you look at your supply chain from where you get all your raw materials to your customer. And you look at every step that you interact with things along the way, and you rate it according to whether it provides value or not. And you have all of these costs that don’t provide direct value to the customer, and there are some that are unavoidable indirect costs. There are some that are completely wasted. There are some that where you don’t need to really do it, it doesn’t provide any value to the customer. You would be better off not doing it.
And that’s the little bit of Toyota lean we get is there are things that we can totally set aside and save time. So we did a value stream analysis and we said, “Look, there’s 120 of us. And we can see that about 10% of that effort goes into things that we should not be doing, that are just useless, they don’t provide any value to the customer. The customer wants the right answer to their question as quickly as possible. Everything else is waste from their point of view, every piece of time we spend reviewing their case,” etc., etc., etc.
And we basically give them this framework where we say these are the big things that we can see going wrong. And then we let them take off a small piece of it. We say, “Okay. We know that every time you reassign an issue, it’s more likely that the person is going to be unhappy with the outcome, and it’s more likely that we’re going to spend two or three times as long because every new person has to review the case, they have to synthesize it.”
So you convince them of a few of these big problems and then you let them strip it down, take parts of it. But at every stage, you’re at least saying, “Okay. Show me what the problem is and then use your idea about how to fix it. How will I know if you fixed it?” That’s the second question where you said, “You’ve got this great idea. How do I know if you made things better or worse?” So that’s the minimum that we try to get them to do in terms of metrics. And we have B.A. resources to coach them on preparing metrics, to build real time reports for them. So we have this core of B.A. resources that jumps in and says, “Okay, yeah. I think I understand the problem. I did some quick digging and there's… The way I like to explain it is it looks like there’s about, you know, $5 on the table. Even if you swiped it, 50% of that, you’re only going to have $250 in your hand, right? But if you show me, if I say it looks like there’s about $500 on the table. If you swipe and hit only 10% of that, you’re going to have a lot more.”
So we try to get them to say, “Show me the problem first because there’s a greater chance that you can succeed. Even a partial hit will show as a big benefit.” And then you also have to say, “This is how we succeed.” Right? So if you put it in those terms, then it’s not… The traditional thing is you have to make a long business case, you would have to argue with two or three managers, two or three levels of management, you would have a bunch of project management framework to fill out. And we’ve kind of distilled that down to, just show me that you’ve at least considered it.
So we’re trying to find this confluence of passion, which they all have. They really are empathetic people, they have strong opinions, and then skills, they all could be consultants out in the world. They all have a mix of development skills, database skills, admin skills. What they really need is just this little bit of business sense to say, not only what can I work on, not only, what do I want to work on, but, what’s worth working on?
So that’s the kind of bit that we try to fill in for them.
Paul: And this is actually quite interesting because of a number of things really. So if sounds like you’re using data to identify where the problem is. You can use data to identify whether I fix that problem or not. And from what you said, it sounded like it’s the B.A.s who go out and surface that data and present it back. Is that about right?
Tony: Right now, we provide the B.A.s as a consulting resource. They’ll help you do it. But what we’ve said is, okay… I said to B.A.s, “I don’t want you to just do the report. What you’re going to do is use this specific example as an indication of something that people don’t know how to do for themselves. So you’re going to break it apart into the data concerns, and you going to show them, as an example, if you want to analyze this type of thing, this is where the data is, this is the techniques you would use to get to it.” And then you also look at it is as these are the techniques they need to get to it. So you have this collection of techniques that they can learn, that are all documented as a series of tutorials, and then data that they can make use of. which is also documented as a series of tutorials.
So the idea is right now, the B.A. is doing the work, but even the second, third, fourth person coming behind, you say, “Hey, we already have materials on how to do this. Why don’t you try going through and spend 15 minutes, half an hour of your investment time working through these tutorials so that you can help your team with it.”
Paul: It is that everyone eventually it will become more data-literate, and they’ll understand the tools and techniques for surfacing the data that they need to make decisions.
Tony: So my hope is not that everyone will do it because honestly, it takes a certain type of personality to actually enjoy that. But my hope is that there will be at least one or two people within every region and hopefully one person with an average team. Because our teams are having these types of discussions. And they need to have someone they can rely on to help them tell fact from fiction. Right?
Paul: So that kind of skill sets, you can hopefully transfer to small amount of people. So we have data as one component when you’re making a decision or trying to evaluate what your priorities are. There are also other components, intuition or an experience.
Tony: Absolutely.
Paul: Where is the balance? And how do you reach the balance?
Tony: Absolutely. So when you just start talking data, it sounds like you’re using that to shut down the conversation, when there’s something that you don’t have good data around. But part of it is being humble and admitting we don’t have good data, about 90% of the questions, we would like to ask. So what you say to someone is, “Okay, let’s just do a finger in the wind and figure, like, just roughly guess-estimate how much it’s even possible for this to be, like, worst case, best case. And then you invest a small amount of time to kind of reduce your uncertainty.”
So you say, “We have no idea how big a problem this is, how much time it wastes. So we can’t spend six months focusing on this. But you can spend four hours, your investment time for the week, reviewing 200 cases to see how often this comes up, and making notes, like just qualitative notes about what this problem does. And you can help make the case another way just by putting eyes on it, reviewing it.” So it has to be a secondary goal. But I really have a soft spot for, if you can give me a project that doesn’t necessarily have the business value but that reduces our uncertainty, then that’s also really useful.
Paul: On a similar sort of vein then, you spoke about using B.A.s in the first instance to surface some of this data and hopefully giving people a toolset. Would you say there are common mistakes that people make when they come to approach, making, and trying to become more data-driven, I guess, or more data-informed at least? Are there common mistakes people make? And what would you say to someone who’s starting out in this, a good way of approaching it, to a good introduction to starting to become more data-driven.
Tony: Right. I guess in our case, we’re lucky in that we have a culture where S.Q.L. is kind of a common language that’s spread throughout. So we have a little bit of a skill base to build on. When we were dealing with people who don’t have the skills, I encourage them to play with the data in Excel. But they have to have a certain amount of numeracy and enjoy actually doing that. That’s still a bit of a challenge for us, which is why I think we’re only ever really going to grab a handful of, we call them select stars, which is a pun on S.Q.L.
So we grabbed them and we preached to them. We also laid the groundwork for them. I don’t think this would work in an environment where you don’t have someone who is curating your data. So we are working to collect new data and we’re curating that and digesting that down into forms where they can answer a lot of questions. So I don’t know that it’s possible for someone who doesn’t and who can’t draft on a B.A., who’s already done a lot of the groundwork.
But I would say to people who are starting out, the biggest thing is don’t let the uncertainty stop you. So for example, you shouldn’t spend four hours making the business case for something that would take you an hour to fix. You apply your common sense to it. But you have to be honest with yourself and admit what you don’t know. I would rather see someone saying, “We don’t know whether this is the case or that is the case. And we’re just going to take a look at it for two weeks and figure out what’s the case.”
And, I guess, I try to encourage people to think of, how could I test this without writing a single line of code? How can I test it without doing anything new? So trying to get them out of the thinking that you can’t learn anything until you spend all of the time, right? Like they say, if only you would build this new system that did this, this, and that. The other pitfall that I see really, really commonly is people come to you with two things. They come to you with an idea but it’s wrapped around the way that they think it should be solved.
So what you need to get them to do is say, “That’s a great idea. But let’s just scrape off that layer and we’ll work from there.” Because it doesn’t matter. I mean, you have to get them to be honest and say, “Okay. Yes, you come up with a way to implement it. But that’s not what we’re worried about right now. We’re worried about whether it’s worth doing.”
Paul: As someone who used to be a data modeler and design and build Star schema, selects stars is about the geekiest pun I’ve ever come across. Much kudos.
Tony: Yeah. We had fun with it. So we have a big mean culture. So it’s helpful that
people wouldn’t be embarrassed to be called a select star.
Paul: Yeah. Absolutely. Good on you. Okay. I am conscious that I don’t want to take up too much more of your time. I think one of the things I’d like to just touch on is, using this kind of lean approach within a larger organization, have you had difficulties getting buy in? Or do you not face much resistance on that? Are there things that are different to, say, doing it in a small startup?
Tony: So in our case, we were fortunate that we were building on a few key things that had by and at all management levels. So, I guess, I say about two-and-a-half. three years ago at this point, we had a big spike in our demand with the successful release of one of our big products. And it really shook up a lot of things. So we started to realize that our biggest challenge was to scale, without having to spend all of our time hiring and training. And I guess we place a high value on culture, on the type of people that we hire. So we wanted to be able to hire a core of really passionate, dedicated, talented people and have them really be able to succeed rather than just working them to death. Right?
So we want, we knew that scale was the problem, we knew that data which we could get the right people was a limiting factor. So we said, “Given those two constraints, we need to do things in a different way. We can’t just take every new issue that comes in and work at the same way we’ve always done it.” So that was pretty widely accepted at the upper levels of management. And I think over time, we hired the type of people who believed in not just doing the same thing over and over again. So we did a bit of it through hiring and training, and honestly a little bit through attrition. But we ended up with people who, on balance, 80% of them believe that, okay, we can’t just keep doing the things the same way over and over again. Right? And that once you got that core to build on, then it’s just basically steering it towards something that they’re passionate about that needs to be worked on. Right?
Paul: And so finally, it could be inspiring to hear a case study, or at least, a walkthrough of how this process typically works so that we can get a real flavor of how the process works, and some of the benefits over traditional methods.
Tony: Sounds good. So in a traditional method, you would have the managers decide based on charts, trends, graphs, what they see going wrong. And they would make a big project, somebody to investigate it. There would be maybe consultants brought in. Our process looks a bit different. Every single engineer has a button that appears in context when they’re working on our system, our support system, where they can walk what we call an urge, which is, this is going to sound funny, but we had an engineer perform Inner Circle last year where you could log issues against anything in the real world. And those were called “dirts.”
So we actually made it a real thing on our support system, where anything that bugs you in real life and in your daily work, you just log it. So we say, “Don’t worry about what happens with it. Just let us know about it.” So we would start by grouping those things, look at patterns of them that appear. We would look at how big a change they are, whether they’re an idea that needs evaluation, and whether we can just fix them, whether it’s just a broken window. Right?
So we would do early wins. We would say, okay, five of you said that the mail sucks because it’s doing this one thing. We fixed it this week. Or all of you are expressing concerns about this part. We’ve got a project to look at that or we need someone to help with that. So we built up this body of stuff from the teams, things that they are noticing in their daily work, and then we separate it out into what we call broken windows, things that we can just fix, that you don’t need anyone’s management direction to tell you the window is broken or that you should fix it.
But then, you have things that are changes, big changes, and we gave them a process for evaluating them. We say, “You run it as an experiment. You find the core of the problem. You find an idea to fix it. And you test whether it’s going to fix it. And then you run expanding pilots of that, where you have the first system may just be a new process that you have written down a piece of paper, where people manage the information on cards. The second process, you may have some automation to support it. The third, it’s a real plugin that runs in the system and works seamlessly for everyone. And you keep extending out the size of your experiment base as well.”
So we give them a process from going from, it’s just an idea, no one’s done it, to a few people have done it, to half the team has done it, to everyone is going to start doing it for next week. So that has worked well for a couple of areas. We’ve had a few teams that have basically had early wins, they’ve gone through to actually take an idea, design an experiment around it, implement a prototype, get it out in front of people.
And then even better, they’ve gone on to seed other teams where they’ll break up and say, “Okay, each one of us is going to be a consultant for another team to get them running their own experiments.” And even with only one or two teams that are at that level, you can make a lot of difference. And you can start laying the groundwork for bigger and bigger things.
Then you start to have problems of coordination because you have a hundred experiments running at once. And we’re starting to address that now as well. But I would say, in general, ideas come from everyone and they self-organize to fix them. It’s kind of a cellular system, a little bit of anarchy. But we give them just enough rules around it that hopefully they can self-organize in the best way to do it.
Paul: Thank you very much for that. I’m sure it’s going to be quite interesting to a lot of people to hear how things run, particularly when you get to that sort of size as a company. With 120 engineers, it’s not small change, is it?
Tony: No.
Paul: So that concludes it.
Tony: Thanks for having me.
Paul: Bye.
Tony: Bye.