Lauren Peate, founder and CEO of Multitudes, joins the home team for a conversation about how managers and executives can support their development teams through ethical data and analytics practices. Plus: What it’s like to launch a startup in a smaller country like New Zealand.
Multitudes helps managers and CTOs create happier, higher-performing teams, using data they already have. Multitudes is focused on software development teams to start, but their bigger vision is to make it easier for any manager to understand and improve their teams’ culture and performance.
“Developers in our audience have expressed skepticism or dismay in the past about software that tracks performance or output,” Lauren explains. Multitudes’ approach is to break down an organization’s approach to ethical team analytics in order to balance delivering value to management with respect and support for the individual developers whose work is being measured. How does that work? Read Lauren’s blog post about data ethics.
Lauren founded Multitudes based on insights she acquired running Ally Skills NZ, which supports organizations in building equitable, inclusive teams. Before that, she worked with high-performance, fast-growth companies in Silicon Valley, the Middle East, Southeast Asia, Latin America, and New Zealand. A Stanford grad, Lauren is passionate about making equity the default both at work and in the wider world.
Check out Multitudes’ success stories or explore their blog.
Connect with Lauren on LinkedIn or Twitter.
[intro music plays]
Ben Popper Automate, scale, and transform your day to day processes. You can build and test automation with five attended, five unattended, five test robots, and access to all automation cloud services. Try UiPath free at account.uipath.com. It's available for individual use and small business.
BP Hello, everybody. Welcome back to the Stack Overflow podcast, a place to talk all things software and technology. I am Ben Popper, Director of Content here at Stack Overflow, joined as I often am by my wonderful co-hosts, Cassidy Williams and Matt Kiernander. Hi, y'all.
Cassidy Williams Hello!
Matt Kiernander Hello!
BP Today we are going to be chatting with Lauren Peate who is the CEO and co-founder of a company called Multitudes, and they work on tools that allow you to understand what is happening inside of a software engineering team and to make some ethical decisions about improving wellbeing, collaboration, team effectiveness, all those kinds of things. So I'm excited for the conversation. Lauren, welcome to the show.
Lauren Peate Thank you. It's great to be here.
BP So the first thing we like to do is just get our audience situated. Tell them a little bit about who you are and how you got into the world of technology and software.
LP Yeah. So I'm very much an accidentally-in-tech person. I grew up in Arizona and then did my college degree out at Stanford. So you would think that would've sucked me in, but to be honest, my first view of startups there was like, “Oh, this is a lot of hype. I'm not really sure what's under the hype.” I ended up having a pretty winding pathway and after graduating thought I would go down the route of getting a PhD in economics and I did some Fulbright research in Morocco. And then anyway, I landed with being in San Francisco and that's where I got sucked in and was working with some really large tech companies. And then ironically I actually left San Francisco to then work with startups and was out working with startups in the Middle East and that's where I really caught the startup bug and found my love for startups, and it was because I got to work with really amazing companies that had all the grit and the determination that we see with startups and that I love, but even more than that, that were building their companies with a lot of heart because they'd seen problems in their community and it felt like a pathway that they could contribute back to that community. So that's what pulled me in, and then the last kind of piece of my background before doing Multitudes is that I also founded and ran a diversity, equity, and inclusion consultancy, working mostly with tech and product and engineering teams, and that was based on having worked with a lot of different teams around the world and seeing things that were working and things that weren’t.
CW I love that it's not only a variety of jobs, but a variety of locations too. That's cool.
LP I love that. And a few languages along the way. Some of them are rusty now, but yeah.
CW Programming or speaking?
LP Both to be honest. And self-taught in a few. Probably more self-taught than formally taught as well.
CW That's awesome.
BP Tell us a little bit about your involvement to the degree that it happened in learning software and writing code and then what was the inspiration for this company? Like you said, you were doing consulting, you were meeting lots of different startups, you realized there was a passion there. What inspired this product and company idea?
CW We did it!
BP Shout out to the community. Yeah, we did it y’all.
LP But yeah, so the beginning of Multitudes, there were a few things along the way. I’d seen all these types of teams and throughout I had noticed that I was working with teams that were all made up of incredible people, so individuals who were smart, who were motivated. But I'd seen over and over that sometimes when you put those people together it was clunky and I could see that there were people who were being underestimated or being left out. And then sometimes when you put those teams together it just flowed. And on those teams we would set goals and we would smash through them and also it was just a nicer place to work. And so I'd been personally really interested in why, and had been exploring some of the different research about it and came across the Project Aristotle research from Google about psychological safety and obviously the importance of diversity, equity, inclusion, and all of that. But then the real trigger for Multitudes was, and this is when I was doing the DEI consulting work, a company where we were having conversations about their team dynamics and they had been running all these initiatives and it was sort of the big flashier initiatives, but they were really trying and they thought they were making some progress. And then the following month they were in the news for a toxic workplace culture and some really horrible things that had been happening inside the company. And it made me realize that there are well-intentioned people who don't have a great pulse on how things are really going, and so Multitudes really began as a way to get lightweight analytics on what's actually happening with our teams and to get the holistic picture. So not just what's happening with the flow of the work and where is it getting blocked, sort of the team performance things, but also how are the people doing around that and who's not getting enough support and feedback on their work, or who might be at risk of burnout because of the long hours that they're working.
MK From what I've seen in my kind of brief four or five years in tech, there is a lot of very well-intentioned people trying to do the right thing, but it sometimes just doesn't quite land the way that they want it to. And it's frustrating because if their efforts were directed in the right way or the most impactful way then we would have good things. I'm very curious, what are some of the mistakes that you've seen throughout your career in doing the DEI work? What are some of the biggest mistakes that you've seen companies make when it comes to DEI and can you give any advice bundled around that?
LP So I'll do a super quick definition just because I know we toss this word around, but just to make sure, and then I’ll dive into it. So, diversity, equity, inclusion. First, there's a great quote from Verna Myers about how diversity is being invited to the party, and then inclusion is being asked to dance. So diversity– who's in the room. Inclusion– are you actually including them? And then the equity piece, there's a little add-on from a social justice advocate named Meg Bulger, which says that equity is a system that makes sure that there's equal access to opportunity for everyone. So it's the systems and structures. And so some of the things that I've seen go poorly, first of all, what's really hard is that I think most people do care about DEI. And again, I've seen this over and over but it's so easy to deprioritize it, so that's a common thing that happens. Another thing that is a very common mistake is people think of it as like an initiative that you do over there. So it's a people and culture thing, or you hire someone and they do it over there instead of weaving it into everything that a company does. And one of the things we're particularly passionate about at Multitudes is what does that mean for product development in particular? Because the people that we do our user research with, the product decisions that we make, what we choose to build or not, within our product we're setting up our own little systems and structures and those can either treat people equitably or not. And just on that one, we've seen some massive failures over the years. I'm sure you all know the AI tools that couldn't identify black folks, their hands, and so the air dryer wasn't turning on. There's some, both laughable, but actually tragic videos and examples that have come up around this and so I think it's a big part of the responsibility that we have as tech companies because we're building these products that are so scalable and can touch so many people so we need to think about and design for all the different types of people who'll be using those products.
BP You mentioned that you had been at startups and seen some things that worked and some things that didn't and also participated. And then you wanted to build a tool that did that in kind of a lightweight analytical way and with a sense that it would evolve as we learn more about what the right considerations are and what the right data is, because DEI is a relatively young field. So what did the MVP look like and how did you build this in a way that makes sense for the people who want to gather the data and make improvements, but also for the folks who are being monitored for lack of a better word.
LP So the product itself and how we do that, over time we've layered in more of the team performance side, because really DEI is part of how we perform well and how we build a trusting team. So the first version of it, we were really diving deep initially into Slack data and kind of the patterns of conversation. So who was getting invited into conversation, a lot around share of voice and which voices were we hearing and which ones we weren't, and then also some of the patterns around how we were talking to people, who we were going to with questions, who's seen as the holders of knowledge in organizations. So we got some really great insights from that, but yet we just realized that we know that there's a clear link to the team performance side, and also to the people who really care about this anyway, it's really helpful for them to be able to then link the people side to the impact on the team performance side as well, because that's how you make sure that there continues to be the time put towards this work. And so that's where now with Multitudes, the way that we think about it is, we started with GitHub data, we're adding in Linear and Jira as well for that issue tracking side of things. And our goal is one, help people on teams surface what are the interesting things that are going on, so what are the outliers, what's changed, and then to set people up to have a conversation about that. So that's one of the key things that we think about in terms of it being less reductive and reducing the likelihood that this will be used for harm, is within the product, reminding people that the data's actually not the answer, it's a starting point for conversation. And so one of the things we've released earlier this year is dynamic conversation starters that consider the data, consider trends and outliers and benchmarks, and then based on that, suggest conversations that you might want to have starting with one-on-ones and then we'll be weaving that into retros as well. We know we need to be an opinionated product, and as part of that being opinionated, nudge people to add that human context. So that's one piece of trying to move away from the creepy side and towards the empowering side. And then the last thing I'll say on that too, there's a really great point from Laura Tacho. She runs an engineering effectiveness course and she pointed out that –her words were different– but essentially she said the difference between the use of data being creepy versus being empowering is really where the locus of control is. And so that's really important for us too. The reason we call it team analytics is, yes, it’s analytics about teams, but more than that, it's analytics to be used by teams to make decisions for themselves. And so we have really strong nudges and guidance around that this is a tool for the whole team to use. If someone on the team doesn't want to use it, that's also fine, we're okay with that, it should also be a team decision whether or not to even use some tooling like this. And then the team using it, that means those team conversations and that joint team decision around, first of all, what does it mean, because different people will have different context, and then what actions do we take?
MK I'm very curious. So with Multitudes as it stands, do you have any kind of success stories that you can share with us where Multitudes has been integrated where there was a problem and Multitudes helped solve or work through that with the team?
LP Yeah. So I have a couple that I really love which shows how much that the people side and how we support each other matters for performance. So there was a team that we were working with where they pulled in our data and one of the things we really dive into is those collaboration patterns. And interestingly what they saw in the data was that their seniors were doing an amazing job of supporting others, but weren't getting as much feedback from other seniors. And so they had a really interesting conversation around, “Okay, great. We're glad we're lifting up other folks, but what does this mean for the ongoing growth and development of our senior developers?” And so the CTO was able to use our data to advocate for pulling one of their really senior folks out of the usual flow of work and then moving them into more of a float role where they were going around and specifically mentoring and working with other seniors. And it was amazing, within the first month we saw I think like a 50% increase in the amount of feedback that seniors were getting from other seniors, but then more than that, over the following months there was a reduction in the lead time, so they were getting the work out the door much more quickly too. So that's one that I love because it shows it's worth it to invest in that support and growth for people. The other one I love is– I'll give an example that relates to why it's so important to put the locus of control in the hands of people themselves. So this was another team that we worked with where in the data on this team –this is a different senior involvement example– but there was a senior who was giving much less feedback. It's always about trade offs and they were contributing in lots of other ways on the team, but in terms of contributing to reviews they were doing less of that. And they actually raised it. So the company had a really clear growth framework and they knew that for themselves to advance they would need to show how they were helping mentor and grow others on the team, and so in a one-on-one they had a conversation with their manager and set a goal that they would start jumping in more and doing more of that reviewing for others. And over the course of a month, and this is a pretty impressive stat, this is definitely an outlier, they actually 12x-ed the amount of feedback that they were giving to others so they really doubled down. And of course there was a flow-on effect to others so you had all these other folks on the team, the more junior folks, who all of a sudden obviously were getting a lot more feedback. And it was such a huge change that we had a conversation with the manager and the person after, and what was the most amazing is that the manager said that it came entirely from this person. So the manager was there supporting and cheering them on, but the manager never said, “You have to do this,” or pushed them for it. It was just by that person having their own feedback loops. And we could see it, they were checking every week, they were jumping in, they were looking at how they were tracking. They were able to take control of that and then make their own changes that they wanted to make.
CW Having that kind of boost, not just in this particular case, but in general where it's backed by numbers and can push it, fosters such a good culture in general because when you have that level of communication encouraged– not just like, “Hey, make sure you talk more,” but actual numbers and something that you can work towards and see and visualize, it's so good not only for the people who are communicating more but the people who are receiving feedback and especially trying to grow in their careers.
MK When you're having conversations like that with your manager and you're wanting quantifiable data around mentorship especially, which is quite a subjective thing sometimes, that's all incredibly useful for stating your case, whether or not it's for a promotion or just to track how you're actually aiding the junior members of your team.
LP Absolutely. We do have an anecdote or two where we know that there's a team member who's used some of our data as part of making their case for their next promotion.
BP Mmm, that's interesting. So what percentage of the metrics that folks are using would you say maybe seems like a more traditional software team analytics? I saw on your site time to merge was one, and then looking at an increase in the number of bugs, or the number of PR comments written, but then other ones that were new to me like a feedback flow or time out of office. So can each individual team, talking about how the team owns it, do they toggle and select those? Or how do you decide which parameters are important?
LP So I'll start with the first one in terms of the split, and we think about it pretty balanced, pretty half and half in terms of the metrics that we're showing on more of that team performance or process side as we like to call it, and then the metrics that we show that are more on the team dynamics, kind of that people wellbeing collaboration side. On the team performance side, we lean quite heavily on Accelerate, the DORA DevOps research, because it's great research. And one of the things we love most about that is it's connected not only to the financial performance of companies, but it's also connected to the psychological safety of teams. So its values are really aligned with us and kind of that more holistic view of it. So that's on that side. And then on the people side, all of our metrics are research-backed but we have taken inspiration from a lot of different places. There's an interesting thing that we often do where one of our metrics is one where we're looking at how often people are working outside of their usual or their preferred working hours. And so with that one, we know from the research that when people are working really long hours on a regular basis it's linked with burnout. We kind of don't need research to say that, but we have the research. And we did the translation to say, “Well, here's the research. How do we map it to the behavioral data that we have coming through?” But that was really the inspiration for that one for example. And some of the support ones, and we've done this in a subtle way, but we've also woven in the research around equity at work. So one thing that we know is that folks from marginalized groups get less feedback on their work. So just period, they get less feedback, and on top of that, the feedback they get is usually less helpful. It's less specific, it's less actionable. So that was the inspiration for one of our feedback measures where we're looking at how much feedback people are receiving because we wanted to be able to highlight that whatever the reason is, the outcome is that these people are getting less feedback and that's going to limit their ability to grow and develop in the same way as other folks on the team.
CW I love how rich all of this data can be in using it. You're describing things where I'm just like, “Oh yeah, that makes sense,” but I never would've thought to put it together that way so that's really, really cool that you're building this and it's working and is successful so far. This is not a question, just a comment. I think that's awesome.
LP Thanks. Well, I'll actually go back then. Just going back to the DEI point too, I think one of the things that's really unique about our team is that we do come from such different backgrounds. So the thing I was most recently doing was this DEI consultancy and so I have so much research in my head now on all the DEI stuff. And then we have other team members who've just gone really deep into building data pipelines or have been on the scaling pathway for other startups before, and then we even have one team member who's coming out of a PhD in quantum computing.
LP Yeah, everyone is like, “Ooh!” He actually did a lightning talk for us on an intro to quantum computing. But it means then that when we're talking about it, we all kind of have different reference points and so I think it just gives us a really great breadth of inspiration for what we weave into the product.
CW I know that you mentioned that the startup is based in New Zealand. Is everybody there in office or is it a very globally diverse team as well?
LP Yeah, we're a remote distributed team. We were a company that was born during COVID, so I think for any company that was, you're remote, flexible, it has to be that way. There's no other way to do it in this day and age. And so many people have had this now, but I had so many team members with the classic where you have team members where you've worked together for months, you know them so well, and then six months in, nine months in, you finally meet them face to face. So yeah, most of our team is in New Zealand, not all in the same place, and we have some team members in Australia, and then I'm increasingly spending more time in the states these days as well.
MK I was going to ask kind of along that same vein, New Zealand is a fantastic place and I love it dearly because it is home.
CW You are biased!
MK Yeah. But it does come with some challenges in the sense that the economy and the infrastructure, the networking, all of that stuff is much more condensed than it is in the states. So I'm curious, with your experience hopping around the world and now being in New Zealand and getting a startup started from New Zealand, have you encountered any different challenges trying to launch that from a smaller economy?
LP There's definitely pros and cons. So yeah, there's definitely some challenges and there's some things that are really great. The great things are that I think because it's smaller, one, it's really easy to get connected to people here. So if there's someone I want to talk to, a hundred percent, I can get a warm intro and they will probably make time for a conversation too. So that's really lovely. There's a lot of excitement around seeing companies that were born from here succeed on the global stage. So I love that there's kind of this close-knit community that's really lovely. The flip side for sure is definitely a smaller market. So this year is when the borders have opened up with New Zealand so I've been able to go back to the states a lot more, and one of the things that's really struck me about being in the states, which I love and has been so important for me as a founder, is people in the states just have a lot more of the belief that we can make the impossible possible. Like, “Let's go for the moonshot!” You know, kind of that American optimism.
BP We're all just dreamers.
LP Yeah! But you know what? As a startup founder, I don't think anyone would do this without quite a bit of dreaming and a lot of hard work, but quite a bit of dreaming on the way. And so it's been a really lovely emotional boost to get that. Whereas one thing that I have found in New Zealand is there's a little bit more of like, “Oh, well that's going to be hard,” or “That's going to be tricky.”
MK You are so right. Yeah.
LP And I’m sort of like, “I know it's hard. Don't worry, this is my full time job thinking about what's hard.”
CW Please believe in me!
MK I can for sure second that as well, because anytime you tell someone in New Zealand, “Oh, I'm going to start this business,” or do something kind of slightly out of the ordinary, you're met with I think a lot more skepticism. Whereas over in Canada or the US or whatever else, it's more like, “Oh, cool! How are you going to do that and make it happen? I can connect you to so and so and so and so.” It's a lot more of an encouraging atmosphere. The tall poppy syndrome is very real in New Zealand, but it's something that I have definitely appreciated of the North American culture for sure.
BP All right, everybody. I am Ben Popper. I'm the Director of Content here at Stack Overflow. You can always find me on Twitter @BenPopper. Email us, email@example.com with questions and suggestions. And if you like the show, leave us a rating and a review. It really helps.
CW I'm Cassidy Williams. You can find me @Cassidoo on most things. I do developer experience at Remote and OSS Capital.
MK I'm Matt Kiernander. I'm a Developer Advocate here at Stack Overflow. You can find me online @MattKander. That's me. Lauren, finish off the show.
LP I'm Lauren Peate. I'm the CEO and Founder of Multitudes, and you can find me online @LMPeate. It was great to be here, thank you.
BP Thanks so much for coming on.
CW Thank you.
BP All right, everybody. Thanks for listening.
[outro music plays]