20. Leisa Reichelt of Atlassian (Part 2)

This episode of Dollars to Donuts is part 2 of my conversation with Leisa Reichelt of Atlassian. If you haven’t listened to part 1 yet, you can find it here. We talk about corporate versus government work, scaling research, and changing organizational DNA.

I love research, I love the way that we learn things and what that means, but the thing that really drives me is seeing an organization almost like a design problem and thinking about like what do we – what levers can we pull? What do we choose to do? How do we position ourselves so that we cannot just do fun research, but we can actually really have this knowledge and this insight and this practice fundamentally change how this organization operates? – Leisa Reichelt

Show Links

Follow Dollars to Donuts on Twitter and help other people discover the podcast by leaving a review on iTunes.


Steve Portigal: Hey, and here we are with another episode of Dollars to Donuts, the podcast where I talk to the people who are leading user research in their organization. This is part two of my interview with Leisa Reichelt. If you’re just joining the podcast with this episode, I’d encourage you to go back to the previous one for the first part of our conversation.

As a reminder, my public workshop Fundamentals of Interviewing Users is happening September 13th in San Francisco. There’ll be a link for more information in the show notes. It’d be great if you recommended to this a friend or colleague. I also teach classes directly to in-house teams so reach out to learn more. Beyond teaching, in my consulting practice I also lead user research studies, so let’s talk if that’s a way that I can help your team.

Of course, supporting my own consulting work is the best way to support Dollars to Donuts. Share your feedback about the podcast by email at DONUTS AT PORTIGAL DOT COM or on Twitter at Dollars To Donuts, that’s d o l l R s T O D o n u t s.

You know, as user researchers, we love our sticky notes. A few years ago, in an article about how IBM was being transformed by design, a key achievement in this transformation was the ability for staff to order post-it notes. In some ways, that was the saddest thing that I ever heard, that IBM was so broken that ordering a quotidian office supply item was verboten, and that enabling this was seen as a victory worthy of mention. But it also was very real and acknowledged how much of uphill battle these kinds of corporate transformation efforts really are.

So this carrier of innovative meaning both in its legendary origins and in its rapaciously consuming audience, this product of the 3M company clearly struggles itself with innovation. We’ve had the weird dispensers, the odd sizes and shapes, the reverse fan fold which may be tied to the dispenser but I’ve mostly just found them showing up in the most aggravating moments in a session. I think many years ago they came out with Super Sticky notes which seems like a complete contradiction of the value proposition but I think it’s just an acknowledgement that the original formulation fell off more than we’d like. I don’t think of them as Super Sticky, just the proper amount of sticky for most uses. Anyway, the latest thing I came across really made me scratch my head. It’s a pack of bright orange Post-Its, probably part of a series of exciting new notes with the aspirational branding A WORLD OF COLOR. This particular pack had an even more aspiration and even less relevant tagline “Rio De Janeiro” Collection. I can imagine interior paint, fabric even car finishes being marketed this way but it’s so strange to see on a package of sticky notes. The post-it, for the researcher, the designer is a backdrop, a carrier for something else. It already is aspirational, because of what we’re putting on it. Making it a “collection,” associating with a far-off fabulous city, is just ridiculous.

Okay, here’s part two of my interview with Leisa Rechelt, the Head of Research and Insights at Atlassian in Sydney Australia. It was quite an in-depth interview that’s been broken up into two parts. This is part two, you can check out the previous episode for part 1. Let’s get to it!

I’d love to hear about some of the other kinds of organizations you’ve worked in and what those have been like.

Leisa Reichelt: Sure. Well, for probably 5 or 6 years before I joined Atlassian I worked in government. First of all, in the UK and then I moved back to Australia and worked in the Australian government for about months. Something like that, I think. And that was super different, super different to Atlassian. So, it was a much more kind of familiar ground for me in that it was organizations that you’d go into going we should really go and like involve people in our design process and they would go why would you possibly want to do that? So, that’s a whole different problem set than what we’re dealing with, I think, in some of the tech companies. But hugely rewarded as well. So, yeah, really very different.

Steve: Both those governments seem like their commitment – I guess they’re just different cases, but their respective commitments to sort of design – I don’t know, digital services seems to be the term that gets thrown around for that. But it seems like there’s been significant commitments in both those cases. I mean you’re coming into environments where someone has said we want to do this, we want to change that default. And – like in the UK what was sort of the – how did that get initiated?

Leisa: Okay. So, in the UK we had a MP, Francis Maude, late in his career. I don’t exactly know how it came to him that we could probably be doing better with our digital services than we are. I don’t fully have that back story, but it did come to his attention that we could do better. And he recruited a lovely woman by the name of Martha Lane Fox – Dame Martha Lane Fox now – to basically help him come up with an approach to how we should solve the problem of the UK digital government services not being what they need to be. Martha worked with a bunch of very smart people. In particular, a guy called Tom Loosemore, to come up with some recommendations. And it was off the back of those recommendations that the government digital service was put together. Tom and a bunch of other people that he’d worked with in various places around London and the UK came together and started working on trying to transform how government thought about approaching digital services. And they had – their design principles, I think, were really the best way of setting out what their beliefs were. And fortunately for me, and number one of those principals, was around putting user needs and not government needs first. And so yeah, culturally there was a cohort in there who were well supported within the political system and were able to really kind of make great shifts and changes and progress on that front as a result.

Steve: It seems to me, just from like watching Twitter or LinkedIn, or just who I keep coming across, that there are research people, titled researchers in every kind of nook and cranny of government services – digital and otherwise, I think in the UK. It seems like from the time that you got involved it’s built into something – it seems like it’s sort of changed the way that government is delivering services. I don’t know if that’s an accurate assessment.

Leisa: Yeah. So, it’s when I started at GDS I kind of came off the back of like – there was a lot of talk about being user centered, but I couldn’t really see exactly where the users were in the process. So, I was publicly a little bit critical of them at one point kind of saying well you know I see that you’re thinking about users a lot and you’re looking at the data that they leave behind a lot, but are you actually – actually involving getting a good understanding of them in the process of designing and transforming these services? And so, I was given the opportunity to come in and put my money where my mouth was, such as it was. And at that point there was the odd kind of researcher here and there. There were like 3 or 4, I think, at GDS at the time, and they were stretched across about 25 different projects. I remember sitting down at their team meetings and the team meetings were basically sitting in front of a spreadsheet, looking at all of the projects that they were supposed to be covering, dividing their days into quarter days and working out how on earth they were going to try to help to support these teams, not all of which were in London. So, a lot of them kind of theoretically required either quite a bit of traveling or just dealing with on the telephone. And that was it. So, they were there, but they were really not well set up to be effective. And I was not really – you know I’d worked with government as a consultant in the past and was pretty skeptical about whether or not that would be a brilliant place for me to work long term. And so, when it came time for me to say what I thought we should do I wasn’t really that worried if I lost my job. So, I was able to say what I thought we should do which is I thought we should have one researcher per team, which at that point in time was like just an outrageous thing to be saying. It was absurd. And we didn’t quite get one researcher per team, but we did get quite a big chunk of researchers and so – and the other thing that I did that I kind of look back on and think that was a really important thing to do was I put one researcher on as many teams as I had researchers and I just left the rest, pretty much unsupported. And the thinking behind that was if I could just give a bunch of people an opportunity to show what good looks like then we could create demand for that good. And if we stretched everybody across multiple things we’d never be able to create that showcase, that exemplar that let people see what they could have. And I think that kind of made all the difference. In the early stages again, speaking about getting proactive rather than reactive. One of the big challenges that we had was like how do we get people even to plan for this? Like how do we get researchers, and budget for what researchers need to do, in the projects ahead of time because, you know, people would come to us saying, “we’re starting discovery next week, I’ve heard you can help us with that.” And by then, like you know, the budgets had been approved like 3 or 4 months before. You had to like kick off an engineer to get a researcher which is always a super popular thing to do – not. And then there were things that we do where we just sort of made rules about you have to have one researcher per team, at least 3 days a week. And it was 3 days because then you couldn’t split them across two projects equally. You had to do research at least every sprint, which was 2 weeks for us. And you had to involve at least this many people. That basically gave us the formula for working out how much research would cost in a project which let us get like that number into the project budget really early on. And these are like really totally boring things that have got really nothing to do with research at all, but were hugely enabling. By the time I was leaving GSA, instead of having the problem of going you should have a researcher in there, you should have a researcher in there, I would have people coming to me, initiating projects, going I’m starting a project, I’m going to need at least 3 or 4 researchers and you go no, no, no, that’s too many, just start with one and kind of go from there. Yeah, it was something that really – I think because people were able to see the difference that it made – and researchers were really facilitators for the rest of the team. So, their job, yes was to run the research and set it up and facilitate it and do the analysis and that kind of thing, but they created these opportunities for the entire team to be able to see how what they were working on was solving problems. Or, how what they were working on worked really well, or didn’t work so well. I think that was like the most powerful thing that they did was really to be very open and inclusive in the way that the whole team was invited and expected to come along and see for themselves, first hand, what was happening. Our research labs that we had onsite we’re always full. Like our observation room, we just had to keep making it bigger and bigger all the time because so many people would come in and watch these sessions. And I think it was that – a) it’s super helpful, but b) I think it’s really – it’s great feedback that the team gets. It provides – it shows the meaningfulness of the work that they’re doing and I think that’s a really desirable thing for teams to be able to see what I’m doing makes a difference. It has an impact. It matters. And I like to think that that contributes to team health as well.

Steve: What’s the difference in the culture of government vs. software technology companies where that kind of response, that kind of commitment and engagement can happen?

Leisa: Well, I was going to say governments don’t have growth teams. They do have behavioral scientists though – behavioral economists – which are kind of a similarish type thing, but they tend to still experiment on letters more than they do on digital things. But I think that it’s a few things. I think that people in government feel – it’s such a generalization. I don’t even know if I believe it 100%. Certainly, in places that I’ve worked people in government have felt their responsibility to the people who are the service receivers and the idea of experimenting on them is something that you would approach much more carefully then what we see, I think, in a lot of other sort of software/technical organizations. I think that’s one part of it. I think the other thing is very few people that I met in government thought that they could do my job. They didn’t know that my job was a thing and they didn’t think that they could do it probably as well as I could. Whereas I find in tech companies there’s a lot more of that. Like everyone’s got some kind of research background. Everyone feels a little more confident and capable at doing this stuff themselves. And I know that that’s not universally true. I know there are a lot of companies where everyone is terrified of going out and talking to customers. But I do feel as though in tech companies – some tech companies – there is a lot more kind of over-confidence about your ability to go out and do this, especially this – and I don’t want to sound like I’m a complete downer on the lean sort of thing because done well it’s great, but I think that has really encouraged people to think that there’s not too much too this, that anyone can go and have a chat with a customer and that’s what we do. I think there are probably a few other things that are really different.

Steve: That’s a good comparison. Can we go back in time a little bit further maybe. I’d love to hear about how you found research as a thing? How is it that you ended up in this field?

Leisa: Well, I was one of those people who growing up didn’t know what I wanted to be. I briefly wanted to be a vet, but that was mostly because of a popular television show that was on in Australia at the time.

Steve: Which one?

Leisa: It was called A Country Practice and it had a character called Vicky who was the vet and I thought she was the bees’ knees. But then kind of beyond that – that was like when I was in primary school and then beyond that I honestly really don’t know what I want to do when I grow up. After high school I went and did a university degree in communications and I could have gone and done a bunch of other different degrees. I kind of applied for like this variety of all different kinds of things in different cities. Like it was a toss-up between doing music in Melbourne or communications in Sydney. In the end I chose communications in Sydney because they had 9 hours face to face time and it was pass/fail and I thought that sounded pretty cruisey enough, after being a bit of a study nerd in high school. I thought maybe I’d earned a break. It was not my best thought out decision and I didn’t really know what I was doing there. And then I was working at the same time. I really didn’t know what I wanted to do at all. I met the Internet at uni for the first time and then in one of my kind of weird jobs that I was doing, I was working for a legal services company and the guy who had started that company, one of his kind of big market advantages was this software that he had had designed basically, which ran all of the kind of logistics of his company. And the guy – you know as software does sometimes, it just stops working or it needs changing. And the guy who was in charge of the software was a supplier and when he couldn’t be bothered coming on site to fix stuff he would ask me to do it. So, I got to understand a little bit about kind of how software happened. And then we started thinking about doing internet stuff and it morphed into a really early E-commece offering and I was asked to be the project manager of that. And I thought to myself, this internet this – this is it, right? This is why I didn’t know what I wanted to do when I grew up because the Internet didn’t exist when I was growing up. So, I thought that was really exciting and then I went and worked in some digital agencies. I had a job called a producer and a producer basically did everything except for writing most of the code and the visual design. So, you did the project management, the account management, the interaction design, the information architecture, all of that sort of stuff. A lot of the sort of project strategy stuff as well. This was in the early days when agencies were still kind of really small. And then over time I just kind of got rid of the stuff that was less interesting to me to focus in on the stuff that was very interesting to me. At the time it was information architecture and the research that goes behind that. And I kept doing both of those things for quite a while. At one point I was working on this huge project in Australia and trying to get budget to do some research. And it was a tiny, tiny budget that I wanted and I had to fight so hard for it. And it was a project that was being run by an ad agency and I’m pretty sure they spent on lunch every week what I was asking for, for research for the entire project. I got very frustrated. And that was basically what kind of drove me to go and move to London. I could see that they had agencies there where they had lots of like like me working in the same company, which just like sounded extraordinary and I wanted to go and see what that was like. So, I moved to London and went and worked for a place called Flow Interactive, which at the time was filled with what I thought were the smartest and most interesting people I’d ever met in my life and I learned loads from that experience. Then I started getting to the point where I realized that in a lot of large organizations, if you stayed in one place long enough the same brief would come around over and over again. And that you could have a great time doing research and nobody would do a blind thing with it. And that stopped being fun when I realized that it was fun to do the research and then nobody would do anything with it. It was good the first few times. The third time I’m like, hmm.

And then I was – my boss at the time apologetically said to me, “I’m really sorry Leisa, but I’ve got this friend and he’s got this start-up, would you mind – can you do me a favor? I know it’s not very glamorous to work on start-ups, but would you mind working on this start-up?” And so, I did and I remember sitting in the usability lab doing usability testing, as you did, and in the observation room was the entire team, which was amazing that the team actually turned up. Not only that, but they were changing the prototype as I was doing the testing. So, like compared to the other companies that did nothing with anything ever, like they were doing it as I was doing the research which was surprising, but you know, but good. And that was it. From then, I just sort of decided I need to go work with people who are actually going to use the research and that led me into working with tech start-ups for a long time. Yeah

Steve: You worked for yourself as a consultant?

Leisa: Yeah, I had my own business for a long time and worked a lot with tech start-ups in London and then also with some larger companies as well. It was like some big publishing companies and universities and places like that too. It was actually a combination of all of those things over time led me to believe that actually probably the biggest, most important challenge is how you change the DNA of the organization that you’re working in. That you can do the best research project in the world, but if the company that you’re working for, the organization that you’re working for doesn’t have the motivation to actually do something with it, then it’s kind of pointless. I remember looking back on like of work and just going what have I got to show for this? It felt like very little. It was not long after that actually that the opportunity to go join GDS emerged and I thought to myself, right, well this – if I can’t have an impact at this organization I can’t have an impact anywhere. Because, like you said before, it was so full of people who were really smart and really orientated to do the right thing. And super meaningful work as well. And I think that’s where I still find myself today where I love research, I love the way that we learn things and what that means, but the thing that really drives me is seeing an organization almost like a design problem and thinking about like what do we – what levers can we pull? What do we choose to do? How do we position ourselves so that we cannot just do fun research, but we can actually really have this knowledge and this insight and this practice fundamentally change how this organization operates?

Steve: That’s a great arc that you just articulated for yourself. It’s really fabulous. So, let’s go back to you were describing sort of the make-up of the team at Atlassian and you talked about two pieces which are unusual but may be worth digging into a little bit. One was research ops, which is sort of an emergent practice. I’d love to hear you explain a little more about what that looks like for you all. And that market research is part of the team as well. Let’s talk about both of those.

Leisa: Sure. So, our ops component is relatively new. I was fortunate enough to convince Kate Towsey to come and meet me in Sydney and start sort of really building that capability for us. At the moment it really comprises kind of three main bits, I think. One is the recruitment thing, so how do we create a really good infrastructure for doing what’s for us mostly kind of B2B research recruitment, which is pretty tricky, in a way that serves the needs or our organization. And that’s – you know that turns out to be interesting in a lot of ways in terms of set out an infrastructure for that. But also seeing that as potentially an opportunity to try to help shape that kind of who’s doing what kind of research when thing. It gives us visibility into what the current activity is? What kind of stuff is happening, which is good. We don’t really have a good infrastructure for taking every bit of demand and shaping it because that would be a huge bit of work. And also, going back to the time stuff. So, recruitment is one bit of it.

We have another part which is really looking at the technical infrastructure. There’s actually, these days – there’s a big technology component to setting up research well in organizations. Whether it’s how the recruiting happens? Where it’s where the data goes? We run kind of the large-scale surveys out of our organization as well. There’s a surprising amount of tech involved in doing that reasonably well also. So, we have somebody whose job it is really just to completely look at the research tech side of things. And then we also have what we call an engagement and impact team which is a new experiment for us. And this is really looking at how can we try to build a really strong muscle around making sure that the work that we’re doing in the team that’s not embedded is consumed and understood and acted on by the rest of the organization. So, this might be some of the customer happiness surveys that we’re doing. Or it could be their top tasks work or some other sort of strategic work that we’re doing.

How do we make sure that when everybody’s got their nose to the grindstone, focused on the thing that they’re interested in right now, they have this kind of curiosity and interest and understanding for how this other research that’s happening that they haven’t commissioned could be useful to them? So, yeah. So, that’s interesting. And so, the ops thing for me is really thinking about like how can we help make sure that the researchers are really focused on research and not all of the kind of logistical stuff around it. And then secondly around thinking about scale. How can we try and make sure that the work that we are doing in our team scales out to the rest of the organization and that the things that we do at scale are of good quality?

Steve: So, you described in your own arc how you discovered that the change of the DNA, changing minds, was maybe the most compelling part of the research for you. But in building up that third piece, the engagement – and, I’m sorry, there was…

Leisa: Impact.

Steve: …engagement and impact part of ops – you’re sort of asking researchers to not be involved in that part of it as much.

Leisa: So, in the way that we are setting up our team, and it’s a work in progress right now, we have chosen – I have chosen to centralize a bunch of the work that we are doing. Mostly in order to create the opportunity to do the work that I think we need to do that wouldn’t come naturally out of demand within the product teams. So, to do some of this work that steps back from the features and gets to this really kind of grounding understanding of what the needs are. So, we chose to do that because we would never be asked to do that by the teams, but I felt that we really needed to do it. Increasingly now we also have researchers who are working embedded in the teams which is much more like what we did at GDS and DTA and other places. And so, the engagement impact teams are really looking at supporting the work of the centralized teams, but because the people that are embedded tend not to need it so much. They have really close collaboration with their product teams and they’re doing – they’re either meeting the demand or really kind of closely shaping the demand in the teams for the research work that’s happening. But I think what we want to do over time is really have this kind of good, creative tension between the crosscutting strategic research, all that sort of foundational work, and the stuff that’s happening in the teams as well. When you have a large – Atlassian is really not that big. We’re about three and half thousand people. So, tiny compared to some organizations, but quite fragmented. Like lots of products, lots of product teams. When you have that kind of complexity in your organization you have to work really hard to make sure that all the people who should be seeing the thing see the thing and that they understand why it’s important. Because a lot of

people don’t make the connection. Like for us when we do the research we go ah, it’s completely obvious why that person over there should find this really interesting. But they are so focused on something else, they often see the work and then go why should I care about that? So, you often have to really do that sort of bridging exercise as well. So, that’s where engagement and impact are really focused on, I think, is looking at really supporting the crosscutting work, the work that’s not done for any one particular team, but actually is super relevant to them if we can get them to attend to it.

Steve: I think ops in general brings up lots of interesting questions about where do you delineate what a researcher does? I appreciate your point that it depends on the context of the organization and what they’re sort of – the optimal remit for them is to lead to this larger kinds of change. So, if I’m a researcher I want my research to be consumed, to be relevant. I don’t think you’re doing this, but were I to be completely isolated from the people consuming it then I don’t get that feedback loop. You’ve talked about sort of that feedback loop of the researcher is an important thing. That being said, if there is a team that can support me, or that I can support to help drive impact, to help drive that interaction, then that enhances the researcher’s ability to kind of reach people. You’re hearing me thinking out loud about where is an ops person an enhancement to what the researcher can do versus – ‘cuz a lot of ops, like the way I hear people talk about dev ops is like it’s stuff we don’t want the developers to be doing. I don’t know. I think there’s things that research ops does that, in my judgment, I want researchers to be doing. And maybe it’s about building up infrastructure to help them do that better, not take it away from them.

Leisa: Exactly. So, the idea is definitely not that there’s like a handover point that the researcher goes here’s the insights and then engagement and impact take those and spread them out to the world. That’s definitely not what it is. I see engagement and impact people as being people who know how to get things seen by the right people and know how to bring people with interest to come and pay attention. And so, a lot of it really is about making those connections. But the other thing is like I find in my organization I’m one of very few people who has got visibility across everything, across all of the research work that we’re doing and lots of things that are happening in the organizations. And so, I can draw connections that other people can’t draw. But I’m just one person and I spend most of my time in meetings. So, I’m kind of hoping – and it’s very early days for us with this whole engagement/impact thing. So, we’re shaping it on a weekly basis right now. But my hope is that because these people are tasked with having really good visibility across what’s happening in the organization, and they’re helping to facilitate these connections between the researches and the organization, they’re going to get a similar view to what I have where they can start also to make these connections. Because I feel as though that’s one of the opportunities that we have in a research team, looking out across the entire organization, is to be able to see opportunities for connection, to reduce duplication, to sort of build sort of sense making from seeing things from all these different perspectives. To connect people to things that they didn’t even know existed that would be really useful to them. And so, I’m kind of hoping that that’s something that over time this team will be able to build as well is that ability to see where the opportunities and connections are across the entire organization that really nobody else, except for me right now, can see.

Steve: I see a parallel with the design education effort where there’s all these things anyone who has worked in research for any amount of time and says, “oh yeah, we have a lot of responsibilities. In addition to doing the research we have to be teaching people and we have to be trying to advocate for our research and planning.” It seems – I don’t know I’m inspired the more you explain this because you’re basically saying yeah, if that’s a responsibility, maybe we need a team. Maybe it has to be somebody’s job. As opposed to sort of bearing it. And when we make it all part of one person’s job we don’t necessarily even acknowledge that hey, education is part of my job. Hey evangelism is part of my job. Hey driving impact. By creating a team to me it makes me more mindful. Like oh yeah, that’s a thing that you could spend fulltime on. And it doesn’t mean, to your point, you’re not taking it away. You’re creating specialties for all the different facets of – we talk about research, but it’s so many different things.

Leisa: Absolutely.

Steve: And you’re naming and staffing specialties that I haven’t seen named and staffed before.

Leisa: Yeah. It’s really interesting to try to get people to take these jobs because they’re like what’s the career path for this? And I’m like I don’t know. I have no idea what the career path is for this. Let’s work it out together. So, it requires really special people to be willing to take these roles and to kind of – to believe in what the opportunity is and what the purpose is. But we are taking a lean approach to shaping the team, but like I said, I always think about this as a design problem. I’m always thinking like what’s the need. And like we talked before about the huge amount of specialism that’s involved in being a great educator. So, the idea that you can just do that in your spare time, in between projects, is just not realistic, I don’t think, if you want to do a good job at it. And it’s the same with the engagement piece, right. As soon as – like you’re always under pressure to get a project wrapped up and there’s always something that you should be starting next. And so, it can be really difficult for the researchers to go, right, now I’m going to do the engagement and impact part of my job and I’m going to spend 3 weeks just making sure that everyone knows. I’m going to go and do all of these town halls and I’m going to go and run these workshops and I’m going to write these blogs – I’m going to do all of these things. Like that’s – it takes a lot of work, especially if you’re exhausted from all you’ve just done – all of your analysis work. You want to crawl under a rock somewhere and rest for ages and now you have to go out and do all of this like roadshowing of what you’ve learned. They still – the researchers still have to do most of that work, but having engagement and impact there I think can make it so that it’s much more streamlined. We don’t have to sit down and go alright, who do we have to go and talk to? Like when are they having their meetings? How can we get into their team meeting and just present there? Part of what this team is doing is just really having all of that knowledge and going right, okay, so what you want to do after you’ve done a project is this, this, this, this, this, this. And it just takes a lot of that repetitive effort out and it means that the whole process of engaging and being impactful becomes more streamlined.

Steve: I talked to someone a little while ago and they described hiring a librarian, like a reference librarian. We had the conversation about the data repository and they’d come to the realization that it’s not about the infrastructure, it’s about having someone own it, advocate for it. It’s the same thing. Here’s a problem that we have, that we always talk about, what would happen if we created a role for that and could take the pressure off the other people that have other things to do.

Leisa: I have a research librarian on my list of roles to hire yet. I was just waiting to get the headcount for it. But yeah, I completely, completely agree with that point of view.

Steve: So, now market research. That also is part of your group.

Leisa: Yeah, yeah. Market research came about because I inherited NPS and that’s a mixed blessing, obviously. But I wanted to kind of embrace it as an opportunity because it was something that particularly executive people in the organization cared about a lot. It was a good way – it was a good sort of vehicle for getting access at the highest levels and getting people’s attention at the highest levels. But obviously we were pretty – I was pretty unhappy with our methodology which was really surveying way too many people in product when they were trying to get their jobs done. And also, the methodology behind how we did the analysis of that. So, we spent a bunch of time thinking about what we wanted to do that was different to that and when we sat down and thought about the kinds of people that we needed to run a better program of work it became really clear to me that, certainly in Sydney, we don’t have quantitative user researchers. I don’t know, in the valley you can hire them fairly – well they exist. People acknowledge them as a thing. It’s not a thing in Sydney. And so, the closest thing that I could get to that was to look at market research and particular kinds of market researchers who would have that ability to actually really design good surveys and to have really strong skills in thinking about how to analyze them and share that information back as well. So, yeah, so that’s – we’ve gone kind of large on that now and that team is now pretty much staffed with people who have got market research background. And it is really that ability to bring in the quantitative analysis that has made a big difference. And it opens up all kinds of opportunities for us. So, we now are able to work super closely, for example, with our brand and marketing part of the organization because we have skillsets that they value in our team now. We can start to pick up research that they would either have built a separate team for or would outsource. And I think having those opportunities to have, you know, what might have been a voice of the customer team, what might have been a marketing research team, all in the one place is super exciting for us and we would not have been able to do that without bringing some marketing researchers into our team. So, that’s been something that I probably – like if I had not inherited the NPS probably wouldn’t have naturally thought to do. But it’s one of those kind of happy accidents that I’m really, really pleased has happened and I would definitely do again in the future.

Steve: The phrase mixed methods research seems to be sort of a – like a hot term right now which to me is about the collaboration between these different types of research tools or research professionals or research teams. I mean the term seems newish. I’m not sure that the practice is that new. I don’t know, is that – so, with these different capabilities that you have is that part of how you’re able to work?

Leisa: Yeah, absolutely. And I think also it gives us a really strong conduit into some of the other more quantitative parts of the organization as well. So, working much more closely with product analytics is part of what we’ve kind of naturally had to and being able to do as a result of the work that our quant researchers are doing. So, yeah it does, it really – I mean this is something that we’ve talked about a lot as well is trying to look at these mixed methodologies and looking at all the different data sources that we have available to us. And that includes people like our support organization and our kind of field and sales operations as well. But yeah, so I think – I think that having – yeah, having that particular capability in the team has been really critical to helping bring the other sources closer to ours. And we’re starting to get into a much better place at being able to sort of cross-reference each other’s wok and demonstrate that being able to do that is a good thing and kind of go back to the reliability question again, right, that that’s something that you should look for when you’re looking to the reliability of the work that you’re doing. Like can I actually see this in other data sources in this organization? Well, yeah, I can. Okay, great. Then I feel like I can rely on them more.

Steve: If we were to have an episode of Dollars to Donuts in in 2025, let’s imagine that there’s still podcasts and there’s still Atlassian, and you’re still in the role, like what would we be talking about? What would you be highlighting?

Leisa: I don’t know. Hopefully a whole, new different set of problems than what I have right now. I have a picture that I drew. I call it my FY20++ next gen research plan, vision type thing and it has a whole bunch of different kind of sections, components to what a research and insights team might look like, that we would build over the next couple of years. And I – so, that’s – I have kind of a sense of where I want to get to with it but can’t – I’m not yet at the point of being able to anticipate what the problems would be then. Here I am assuming that we’d be talking about the problems and not all of the great accomplishments that we’ve had since then.

Steve: But that’s – I mean that’s the way I think a research leader – your response isn’t unique. I think finding problems that are big ones and tackling them is why – of course that’s our response because that’s the kind of person that ends up in the role that you’re in.

Leisa: The thing that I would be most proud of, the thing that I’m really looking for as we go forward is across the organization for us, whether it’s in product teams, whether it’s at executive level, whether it’s in like the sales or the support, wherever in the organization it is, I would really love for us to have developed this natural tendency to talk about problems and opportunities from the users and the customers point of view, and not from our own product or feature point of view. That for me feels like the big transformation that could make a huge difference. And so, a lot of the things that we’re working on now is how do we build that understanding? How do we build the connections between that understanding and the things that we’re working on – the things we’re thinking about working on – what are the big things and the tiny things that we can do to start to change the way that we think about things? And so, I remember when I was at GDS one of the tiny things that we did was we just said it’s not user testing, it’s usability testing or user research. And tons of people will listen to this and go, “it really doesn’t matter.” But what it did do is by getting people to do that little correction in their head every time they accidentally said the wrong thing, or accidentally almost said the wrong thing, and they’d go we don’t test users, we test ourselves. We test our work, we test our ideas, we test our designs. That, in a government context, was a really super important thing. And so, it’s that kind of – it’s almost that linguistic correction of like making sure that when we talk about things we don’t – like I often say to people that I’m working with at the moment, like if you can’t describe the problem without saying an Atlassian word then you don’t understand the problem. And so that’s what I’m looking for. I’m looking for a future where when we talk about things we don’t talk about it by the product name or the feature name or some other kind of internal, buzz wordy thing what we have, but we use language that clearly comes from an understanding of our users and our customers and the needs that they have and the problems that they are trying to solve. That’s, that’s – that’s my kind of mission, I think, more than anything else right now because I feel like that will have the biggest cultural impact.

Steve: That’s fabulous. Anything else we want to talk about?

Leisa: No, I think we’ve done it to death, Steve.

Steve: Alright, well thank you very much Leisa. It was really interesting to talk to you. I really appreciate all your time.

Leisa: Thank you very much. It’s been fun.

Steve: Thanks for listening to Dollars to Donuts. Follow the podcast on Twitter, and subscribe to the podcast at portigal dot com slash podcast, or Apple Podcasts, Stitcher or Spotify, and the rest. The website has transcripts, show notes, and all the episodes. Get another copy of my books Interviewing Users and Doorbells Danger and Dead Batteries from Rosenfeld Media dot com or Amazon. Thank you Bruce Todd for the great Dollars to Donuts theme.

About Steve