PREROLL: Collaboration between different disciplines in your organization can be difficult, and finding clarity and alignment on both the right problem to solve and the right solution design is even more so. We each approach improvement from our own (limited) perspective, without taking into account the whole story. How is that effective? Paul Rayner's EventStorming Facilitation Virtual Workshop is a multi-day online event that promotes collaboration between different disciplines in order to solve business problems in the most effective way. This virtual workshop with Paul consists of 4 sessions on Sep 28-Oct 1 from 9am -Noon (MDT) each day. To register and get 20% off your ticket, visit virtualgenious.com/events and use the code VGGTC. In this highly hands-on and interactive virtual workshop, you'll learn advanced EventStorming facilitation skills spanning from large-scale business discovery to collaborative solution design at the team level. Also, Paul is great. That's my personal opinion. Once again to get 20% off your ticket, visit virtualgenious.com/events and use the code VGGTC. Jacob Stoebel: Hello, and welcome to episode 198 of Greater Than Code. My name is Jacob and I'm here with my co-host Rein Henrichs. Rein Henrichs: Thanks Jacob. And I'm here with my co-host, Jamey. Jamey Hampton: Thanks. And I'm really excited to introduce our guest for today. Ravs Kaur is a chief Technology Officer, is responsible for leading Product and Engineering at Uplevel. Prior to Uplevel, she spent a decade in the Developer Division at Microsoft building tools to make the every-day lives of developers easier. Following her time at Microsoft, she was at Tableau and led the core Visual Analytics teams to help people discover and share their insights through data. She brings together her empathy of developers, passion for data, and experience with engineering leadership challenges in her current role at Uplevel to build the product she always wanted for her own teams. Ravs lives in the Seattle area with her husband and two kids who share her aspirations of becoming a pianist someday. They are usually found planning last-minute travels and love experiencing different cultures. Thank you so much for coming on the show Ravs. Ravs Kaur: Thank you for having me. Jamey Hampton: So you might be ready for our first question, which is, "What is your superpower and how did you acquire it?" Ravs Kaur: That's a great question. I would say my superpower is learning to learn. And I didn't really realize it was a super power that I reflected back on my career and my journey and all the phases of my journey and career and things that sort of with the most memorable and important me were always things that were a little outside my comfort zone that I had to learn a whole, you know, set of skills or technology to be successful in it. And I just found that I grew the most there. And over time, I recognized that pattern that I was the most excited and the most successful when I learned new things and I figured I'm actually good at this learning stuff. [laughs]. So I'd say that that is my super power. How did I acquire it? Just practice. I think, it starts with saying yes, if there's a new opportunity or, you know, a new experience, just be open to it and saying, yes, I found was a great way to be in the situation and, you know, to be successful or fail you still needed to try, and to try you needed to learn. So I'd say that's been really helpful for me. Jamey Hampton: I like the idea of success or failure. Like, you're still learning. Do you feel like you get a lot out of trying something new and failing at it? Ravs Kaur: I think so. I think sometimes even more than being successful at it, and that is just a value that I instill in my teams as about. Because a lot of people, if you're afraid of failure, you just don't try. You want to be safe and you don't see the growth or the innovation. My ideal is, find a way to fail fast, so recognize when it's time to move on, or we might want to switch directions or things like that. Even as I considered moving from Tableau to Uplevel, it was a big risk. I'd always been in big companies and my safety net, you know, never been with a startup. And for me, one of the things that excited me about it was the journey. You would see all these statistics, I'm a data person, not a lot of companies have chances of being successful at small startups, but even in the case that it wasn't going to be successful I knew that I would learn a lot. So that really, really factored in my decision of moving. Rein Henrichs: Would you say that now that you're a CTO, that part of your job is to make an environment where it's safe to fail and to learn for the people in the engineering org? Ravs Kaur: Absolutely. It's a big part, especially in a small startup, you're going to have a lot of ideas. You're going to have to pivot a lot. You're going to have to try different things. We're still trying to find what our customers value the most and constantly innovating to give them the most value. And so for that, some ideas are really great. Some ideas not so good. Again, I keep coming back to that for myself and my team, which is, let's try this, let's put it out there and let's get the feedback. And if it doesn't work, we have one more data point, which is useful for us in our journey. So it's not wasted effort for sure. Rein Henrichs: I've got a really simple question for you. How do you do that? [chuckles]. Ravs Kaur: [laughs] That's not a simple question at all, Rein. [everybody laughs]. Rein Henrichs: It was simple for me to ask and that's what's important. [everybody Laughs]. Ravs Kaur: You know, it starts with giving people planning time to explore the idea. So we have hackathons, we have budgeted time to just do different analytics things that were like, Hey, what can you find that's interesting in the data that might be valuable? And we can, you know, do time boxes, we do hackathons, we do daily demos. And, you know, even during our hackathons and daily demos, we're constantly having, you know, feedback cycle, right? So somebody presented an idea and said, "This is as far as I got it, doesn't have promising", but we celebrate it. Right. It's actually a celebration that we went and looked into that direction. We did a demo. There's a lot of kudos. We tried. So it's not just planning and making sure that people understand this is time for explorations. Like, there's no expectation that you're going to come out of this with, you know, our next unicorn feature. And then even if things people try and they don't really work, having that environment of celebrating those wins and failures is really important. Jamey Hampton: I think you said earlier was about failing fast. And I think that that can be like one of the really frustrating things about like failure is like, even if you've kind of come to the terms emotionally with yourself, that like failure doesn't make you like bad or stupid or anything, but it can still be really frustrating to like waste a lot of time on something. Like, how do you ensure that you fail fast and not get wrapped up and fail very slowly? [laughs]. Ravs Kaur: I think from a product perspective, it's really getting as many data points about your idea as fast as possible. So, what you don't want to do is just look inward, build something for three months and then come out and say, Hey, is this useful? Right? You really want to get feedback along the way. That's super important. I can give you an example. When we moved to working from home, cause pandemic, my company at Uplevel, we care a lot about engineering and develop team efficiencies, right? A lot of our customers, we're curious about how it's going working from home. And we have a lot of data. We have a lot of data about how things were before working from home and since working from home. And we seek out challenges that people were having. And so a lot of them were around this notion of being always on. So people are being burnt out because there's no physical boundaries between work and home and people are juggling too many things. And just being on and at work for long periods of time, because, well, they have nothing better to do. [laughs]. Or you know, there was this term of zoom fatigue, right? Like, just being in back-to-back video meetings was a different kind of mental stress then having in-person meetings. Or people were just curious about is work happening at the same rate as it used to. So we heard a lot of these challenges and we started digging into data about, about these things. And we had prototypes for zoom fatigues or back to back meetings and being always on and those kinds of things. And what be hard [of me be sick, right? 00:09:27] Early feedback on our prototypes. What be hard for, you know, this notion of zoom fatigue from our managers was, this is really important and great to look at, but I don't really know what I can do about it. Like, you know, the meetings are back to back. What we can do is they realized that maybe we should give sort of a 10 minute transition break between meetings. So it's almost like the walk to the different conference room break, or, you know, we started doing things like walking one-on-ones. So, you know, if you don't have to be in front of a video and you could just chat, let's get out, walk around the block, get some fresh air. So, there were a lot of things that people did to sort of reduce the zoom fatigue. But the feedback was once we've done that and we've shaped our culture to be respectful of not having so many back-to-back meetings over video, it's not as useful to look at on a regular basis. We've sort of fixed that problem. So we did, you know, more like a one time analysis for people and customers and, you know, they did their corrective actions and it's working well, but we didn't invest a whole lot more in going deeper on that. But the other one, which was around being always on, you know, we started to show people just how on their team is and how those levels changed. How long of the day it really is for them before and after working from home. But the feedback we heard from our customers was, it wasn't as important for them to see that on a daily or weekly basis, it was more of a quarterly. Maybe see if things are improving or things are the same, but, you know, I don't need to see what my zoom fatigue problem is on a daily basis or even a weekly basis. So we chose to not invest deeper in that signal and that metric for now contrasted with another one that was a challenge for our customers, that was this notion of being always on. So once we all started working from home, we and our customers started hearing no physical separation between work and home longer days, do many distractions. I just feel like I'm always working or I choose to always work cause I don't have anything better to do. [chuckles]. And when we came up with our analysis on that and showed some of the customers, it actually validated their gut off how people were feeling, and that was something they were really interested in monitoring on a more frequent basis, because they did not want to get to the end of their sprint or marathon and see that people are burnt out. They just thought it would be really good to monitor this on an ongoing basis as an early warning indicator of burnout within their teams. And so that is something that we are, you know, where we shipped. We are still working on improving and getting data around and just going further in there. So coming back to your question of how do you ensure, you know, a fast failure validation of your ideas [chckles], getting really frequent input from not just internal discussions, but external validation of customers via validated with people and our users who are not our customers too. So just having separate voice of the customer sessions that can give us input, we're not customers. So getting some validation from there. And also making sure that the people you talk to the set of people, there's a diverse set, different companies, different cultures, different genders, different races, all of that is so important in making sure you have a good product. So keeping an eye on those things has been helpful for us. Jacob Stoebel: I think that that concept of really fast iterations that you're talking about is really valuable. And at the same time, I think we've been trained. I think I've been trained from an early age like that. That's not something you should do like you should, you're supposed to turn in polished work and you're not supposed to like bring it to other people until you're sort of ready to show your absolute best thing. And I think that's a really hard habit to break. Ravs Kaur: I would agree. I'd say that we had to get over that hump ourselves as well. So we are in very early stages of the company and the product. So for us, we do not have a choice, but to get early feedback. You know, we started with hackathons. We used to have one week hackathons. And what we found was, we'd work on an idea and then get back to the other work that we had planned and not really get feedback or get that hackathon idea to a place where we can make a decision of whether to pursue it further or scratch it. And so what we did in our last two or three was, we gave it two weeks. So one week was about iteration of the idea and getting feedback internally every day and just developing it out further. And the second week was all about getting it to a spot where we could get feedback from the customers, right? And so it was not polished. It was pretty scrappy, but it was also an expectation set of the customers and users that, this is not a final product, this is us seeking your valuable feedback on whether this is the direction we should head in. And what that does is it really sets the expectations for even somebody who is giving the feedback that they don't expect the polish and perfection, which we would induce once we decide to ship it as part of the product. And you'd be surprised there's a lot of people, you know, the early adopters, the people who love to be on the front end of technology and trends and the ideas they love seeing this kind of stuff. They love the fact that you're showing me something scrappy that I can give feedback on, and then to actually see it polished and being part of the product in ways that has incorporated their feedback is really gratifying to them as well. So they're like, Hey, I made this happen. You know? And so keeping that in mind also helps with getting over the hump of this is not really that polished and I can't really get it in front of customers. And when you do it, you know, a few times and you see that it actually is a great thing for the people giving the feedback and us, it becomes habit from that point. And, you almost start to get into, maybe this is too scrappy [laughs], you know. Maybe I should put in more effort to make those presentable. So you then do swing on that spectrum. Jamey Hampton: I like the idea of learning something that has that kind of self-fulfillment. Like, I'm trying to train myself to get better at this. And I see that as I do it, I'm having like a positive experience. Ravs Kaur: Yeah, for sure. What we do also in our team is, we have the developers who worked on that idea, just listen in on the customer conversations. So it's not just customer support people or leadership trying to get feedback or product people, it's the actual developers. And they love it. They love hearing what customers have to say about the thing that they put out there. And I think that is so important because having developers understand how customers use the product and what they like, what they don't like, just helps them in the building and getting creative and understanding how do I evolve this further? This is one of my favorite moments when I see, you know, the brains of the developers on the call sort of spinning and daydreaming and, Oh, I could go do this and I could go do that. And so it's just a great culture overall. Jamey Hampton: I think it's like a great way for developers to like, have empathy for the people that are using whatever they build. Like, cause those are real people on the other side of the screen. And I guess I wanted to like specifically use the word empathy because you use that word in your bio and then you also use that word in some of the topics you were thinking about talking about. So I guess like, I'm interested in maybe like talking about the concept of empathy, if you're up for it and like what that means to you. Ravs Kaur: Yeah. Empathy is one of those that I think is such a crucial skill. It's a crucial life skill. You know, it's even more important in leadership, but just as a real life skill. And what I have found in general in leadership, you know, leading teams is, if I am able to really understand my team's motivations, what drives them? What kind of work they like to do? How they like to be rewarded? Like, really understand them as a person, their values and then align sort of the work they're doing to business needs. Something that keeps them motivated that they really passionate about that, you know, helps them grow in ways they want to, and align that to what my business or company needs. I feel like my job is eaisr [laughs]. you know, it's just, you create a very sort of magic in the teams where everyone sort of brings each other up. There's this energy., People love what they do and that's sort of my ideal place to be. Right. One of the interesting things about empathy is you, like I said, it's a life skill, right? So I grew up in Kuwait and you know, in 1990, when we had sort of the Iraq Kuwait war, I was only nine years old and we had to find a way to leave the country to be safe. [laughs]. And so we were trying to find our way to India. And through our journey, I very distinctly remember, I had an older brother who was way wiser I. and whi;e my parents were trying to figure out how do we get, you know, food, water, and basic staples across with us so that we can survive the journey, I was this brat who really cared about making sure that my Barbie dolls and kitchen sets were with me as I left the country [laughs]. You know? And I think back to my dad ,who at that time sort of put his foot down and said, "Well, if she wants it, that's what we're going to take. Like, that's "what's important to her. And I think of that as real true empathy. There wasn't this, like, I know better than you, or this is not important. Or there was a true acknowledgement of what this nine year old needs and what this nine year old wants. And even though I think back, and I was like, that made no sense at all. If I were the dad or mom at that time, I'd be like, just chill. Like that's not happening [laughs], we're carrying cans of food, but that didn't happen. Right. I did get to carry my, you know, select toys that I wanted to take across with me. And so again, I just, you know, I draw inspiration from everyday events like that. I remember my son was probably three or four and my daughter was, you know, between one and two. And we were talking one night and she comes and says, "This kid at her daycare broke her legos." And she's like, "What should I do?" I'm like, "Well, it might have just been an accident." And she's like, "But what if it wasn't. Like, should I be breaking her Legos or", you know, things like that. As like, "Well, let's think about how you felt, right? So if somebody broke your Legos and sort of made fun of it, how did you feel? And would you want the other person to feel the same way." And do my shock and surprise my, you know, I think three year old or four year old at the time, he was just listening to the conversation and he steps back and he's like, "So mama, are you saying she should have empathy?" [laughs]. And I had not translated it that way. I was just giving my mom's free love, you know, think about your actions and what, you know, how others would feel. [chuckles]. And my son says like, "So I think what you're talking about is empathy." And I was like, first I had to get over the shock of the fact that he actually knew the word, but you know, once I got over that, I was like, well, that's true. And so you really think about having empathy, not just making you a better leader and helping your teams, but just making you a better person. So it's just something that, again, super important to me that I see or seek in day to day life events. Rein Henrichs: I think empathy is often defined as being able to feel what other people feel, that sort of thing. But I think if you think about it, that sort of obviously not possible, right? We can't actually do that as far as I know, telepathy doesn't exist. I think a more useful way to think about it is that, you can sort of simulate in your own mind what someone else may be feeling. And then what you're interacting with is that stimulation. Right? And the reason I think that distinction is important is because it implies that it's not some talent that you're born with to peer into other people's minds. Right. But instead of a skill that you can develop as well. Ravs Kaur: Absolutely. You're 100%. We can never truly feel what the other person is feeling, you know, but we can try our best to simulate, as you said, and we get better at it. Even if we stop to ask ourselves before any of our actions, what would they think? Or what would they go through? Or what would they feel? And many times, like just having that open conversation, you can guess. But you know, when it comes to managing teams or things like that, I often have conversations that are, how would you feel for if something like this happened? And then you just, again, learn more about the person, learn how they react to certain things and you get better at understanding, or maybe even guessing how something might go over for this person, but that does involve understanding what that person, not just likes or dislikes, but what that person has gone through in life, it actually gives you a better perspective. Very recently, one of our good friends, we've been friends for awhile. Shed, you know, some stories about his childhood and his growing up. You know, it was a moment for me that it just made sense. Like, he had true values of helping friends and being a giving person and all of those things. And, you know, it's sort of like that puzzle just came together for me. And, I understood a lot more about why he is the person that he is and, you know, his background and experiences he's had as a kid, led him to be the person he is. Right? Now, I can probably guess better if some certain situation arises, you know, is that going to be against his values, how he might react. And as you said, simulating what that person might feel or go through. You learn more about that as you get to know the person better. And it's something that you can develop for sure. Rein Henrichs: I also want to tie this back into learning from failure, like we were talking about before, because I think that empathy is absolutely necessary to learn from failure, because one of the things you have to do to learn from your failures, you have to try to understand why it made sense to do that thing at the time. You have to be able to put yourself in the position of the person who made that decision and understand why they thought it was a good decision at the time. Because the alternative is assuming that people are incompetent and just trying to sabotage your company. Ravs Kaur: Absolutely. I couldn't agree more. And I think I've nothing great to add to what you said [laughs], but you do see this like very, you know, you'll come across this code base and like, how did we write this? Why did we like this? You know, this makes not a lot of sense, or this is not going to scale, but you have to just pause and remind yourself that, you know, at the time this was written, it's ten years ago, right. These were the circumstances. And for that, it made complete sense. It was the right decision. It was what led us to this point and be able to have grown this company and product to a point that then years later we were super successful was because of decisions like that. So again, not a failure, but it can feel like one, if you don't step back and think about what was the situation at the time this decision was made. Rein Henrichs: Sidney Dekker calls this, getting inside the tunnel, trying to position yourself as where the work was being done, you know, trying to see what they would have seen. Ravs Kaur: Yeah, love that phrase. Rein Henrichs: We'd like to take a break in the show to let you know that tToday's show is sponsored by strongDM. Managing your remote team as they work from home? Managing a gazillion SSH keys, database passwords, and Kubernetes certs? Meet strongDM. Manage and audit access to servers, databases, and Kubernetes clusters, no matter where your employees are. With strongDM, easily extend your identity provider to manage infrastructure access. Automate onboarding, offboarding, and moving people within roles. Grant temporary access that automatically expires to on-call teams. Admins get full auditability into anything anyone does: when they connect, what queries they run, what commands are typed. It's full visibility into everything. For SSH, RDP, and Kubernetes, that means video replays. For databases, it's a single unified query log across all database management systems. strongDM is used by companies like Hearst, Peloton, Betterment, Greenhouse, and SoFi to manage access. It's more control and less hassle. strongDM. Manage and audit remote access to infrastructure. Start your free 14-day trial today at strongdm.com/SDT. Jamey Hampton: Are you free to tell us a little bit about what you do at your company and what your company is all about? Ravs Kaur: Yeah, absolutely. So I lead the engineering and product teams Uplevel. And what Uplevel is, it's essentially an engineering effectiveness platform. What we aim to do is give the ability for engineers to do their best work, right? We want to empower them to do their best work. Now, productivity and Judgement is this term that sometimes is associated with number of commits and number of requests, a number of things you worked on. And being in engineering and development, it's really obvious that that never tells you the full story. You know, you just, that's almost like a bad measure off how productive your team is, or yes, how green or red, you know, the numbered and sort of comparisons of that. So we've taken a different approach to thinking about effectiveness. Our assumption is the developers are smart people who want to do a good job. And how do we provide insight to things getting in their way. So if you think about a day in the life of a developer, they might start off doing some work and get interrupted with various slack and team messages, and then go prep for a meeting and come back from it and go have lunch and then have half an hour to work and then go for another meeting, and then come back from it. And, you know, you're sort of trained to be creative and be a builder, right? And so what we want to do is give you insight into those kinds of things, right? Are developers having time to be builders? Do they get enough deep work time to get their work done? How much of a meeting are they in? Also like when it comes to your software processes, what are the bottlenecks and roadblocks? It's not about number of PRs you've committed, but are you blocked? If something goes to another team, does that take longer? Or what are your practices just within your team that might be causing you to slow down? Right. So really thinking through the enlightenment and shining a light on what things in the environment like across product development, across people, across process, teams and organizations can work on. Like an example that I talked about earlier was this risk of burnout, right? If you think about team dynamics, if somebody is burnt out, they're obviously not going to be very effective. So we, again, take sort of a lens of not just data science, but even how effective teams work and the science behind that, and try to, you know, leave that through our product. Rein Henrichs: So it sounds like, there's sort of two levels here. There's the, how the work is done level, you know, rules, policies, procedures, like flows, things like that. But then there's also this sort of context. That's really more about like wellbeing and flourishing, and I've heard it called there's a paper that calls it the engagement of the human spirit at work. Ravs Kaur: And if you really think about it, you can not think about effectiveness without thinking about the engagement of people or the human spirit. You cannot think about effectiveness without thinking about how work is done. So it's absolutely two faceted that way. And, you know, you just step back and, you know, often like engineers and managers and exact leaders are thinking about, am I going to make my deliverables? Are they going to be of quality? And if you just think about the factors that go into that, it's not just, you know, is your code moving through? Are people blocked? You know, the sort of rules and procedures and the throughput of the team, but it's also, does my team have capacity? Are they actually getting time to work on the deliverable that they need to, or are they dealing with customer fire drills and support issues. Is the work that comes to our team very much in line with what we need to get done? Or do we get incoming, you know, either requests from other teams or security related things, or, you know, some on call fire that is again, added scope to my team's work, but you don't pause enough to think about how is that going to impact my deliverable deadline. And, you know, we don't raise those flags early on enough because we don't understand just how much is it impacting our team. I feel like we're eternal optimists. [laughs]. And so just, you know, seeing tens and data and bringing, again, like two things that get in the way of what maybe I had planned to doÙˆ not saying the other things you worked on weren't good, but just, this was something I had in my plans and what is going to alter my plans and what good active actions do I need to take, whether it is help developers get more deeper time or, you know, reduce scope of the project or add capacity in some ways are all things on the table when you think of going and meeting that milestone. Jamey Hampton: I really like about the way that you've been talking about this is that, when it comes to talking about productivity in that way, it tends to stress me out sometimes I'm probably not alone in this because it feels like there's like a judgment value placed on it. Like, Oh, well, like, like why aren't you being productive? And like, I feel like, well, what could I be doing better? Why am I not doing this as fast? And like, I like that you've really kind of made a point to not put a judgment value on it. And I noticed it specifically just then when you were like, not that the other things you're working on aren't importanthe, they're just not the thing that you, that was in your plan. And so I really like that. [laugh]. Ravs Kaur: Yeah. Again, we put so much thought into that because it's not about stack ranking developers or reading them in any way, shape or form. It is really about understanding what the deem goes through. And we use Uplevel at our teams ourselves and we have individual developers. And so, you know, we have to walk the walk, we have this question every time, we're trying out a new concept and we have a very open and transparent culture. And, you know, our developers would tell us, I don't think that's something, you know, I'm either comfortable having presented for, you know, a metric that is on me that I'm not comfortable or just, it could easily be used in a value judgment point of view. And so through our planning, through what we show, through even the visuals, like, should this be a bar chart or maybe a pie or some other thing that doesn't lend itself to the other side of the conversations with data. But I think it really does. You're absolutely right. We focus a lot on just the environment and what the team is and what developers are dealing with on a day to day basis, dancing. You had five commits yesterday and, you know, do today, what's up. [laugh]. Jacob Stoebel: I would guess there's a lot of new discussions in the last six months. It's dependent. Ravs Kaur: Oh yeah. For sure. [laughs]. Because the way we do work is changing, right? One of the things, as an example, one of the things that we measure in our product and showcase is just interruptions that a developer has to deal with. So imagine Jamey, you know, I messag you in the middle of your work time and you respond to me, right. And you're just really helping me out. I'm unblocked and that's a great collaboration, but really what that meant for you is that, you got taken out of the context of what you're doing. And there's a lot of studies about how long does it take for you to get back into the flow of work that you were doing before you helped me out. So we can bring to light like, yeah, Jamey was actually interrupted a lot of times and, you know, lost maybe two hours to do sort of interruptions. Right? And so what we saw once we head into working from home is that, across the board interruptions were higher, you know, deep work as a concept for developers whereas reducing interruptions were higher. And you step back and you think, well, that's the new way we're doing work. So earlier when I could come and tap Jamey on the shoulder and say, Hey, can you help me out with this thing? Now, I actually, you know, send you a message and we probably hop onto a call and get, so we're capturing those interruptions better. And to even give a better idea of how work is done. And actually we saw that in our data too. And we instituted things like no meeting redness days and a no expectation of response block between sort of 12:00 to 01:20. Because again, as understanding that we've parents and, you know, other responsibilities for our employees, they need to check in on other stuff. Like we just got to embrace it and give them the time to do it. We often term this, you know, we call it "Draining our shallows". You do have to get through, you know, the things, whether it's that email or the review where you check your to do's of your posted notes [laughs] before, you know, as developers, you're like, Oh, I'm going to go to bug that really difficult bug that has been haunting me for days. Right. And that's where you need your creative juices and high cognitive efforts to go and fix that. So work has changed a lot, like just in terms of not just how we collaborate, but also thinking through and discussing, you know, how do we keep innovating if everyone's remote? Like, we would have very, you know, Seattle, co-located office in person culture as a lot of our customers. And so thinking through those types of things and remote work in general is a really big. It has always been a big topic, but even more so now. And, you know, I add that, we usually see these waves [laughs] when we talk to, you know, managers and leaders, there's an initial wave of is work happening, right. Are my teams getting work done at all in this new environment? And then once you get over that panic and you're like, you know, we're actually being effective. We actually getting work done. We actually shipping stuff, you're, you know, producing. Then it gets to, okay, how is it different and how can I optimize in this environment to keep that going? Right? And so you go through that phase and now I feel like I'm in a third phase of conversation, which is, is innovation at the same level. Like, what happens when, you know, you're in person, you can go design on a whiteboard together, or you are having a casual conversation with somebody in the office over the water cooler and some ideas sparks. And, you know, there's a seed planted in somebody's head that blossoms into something that's really nice. I don't know if replicate is even the right thing to be thinking about, but how do you, cross-pollinate some of those ideas are things that are in people's heads and just bring awareness in general, because now we have meetings and [ecolab] very intentionally, like, I need this from you, so I'm going to talk to you. It's not as ad hoc as it used to be in person, so does that actually affect, you know, the culture of innovation? So I feel like, I've seen sort of different concerns and phases of thinking through team effectiveness and just efficiencies in general, through working from home. Rein Henrichs: It's so important for the tech industry to start taking human performance seriously. You know, the stuff we're building has immense potential to cause harm to people, to economies, you know, all sorts of things. And I think we have a duty to start taking it seriously. And by performance here, I don't mean productivity. So it just makes me really happy to see, you know, like you that are doing this in this space. Ravs Kaur: Yeah. I'd say it's a value that runs in our company and I'm really happy and proud about it. Like every person that we have taken on in our company shares the same kind of value system. You know, this is about people, it's not about again, lines of code. And so, how can we help people be their best? And, you know, I was having a flashback to one of the leadership sessions I was in, when I was back at Tableau. And they also drilled it into us. When you think about a bad performance, as an example, on a team and as a leader, you, you know, maybe there are natural instincts to go and say, okay, this such and such person is not performing, but most cases, the real cause of it is not the person, it is something upstream. Right. Does the person understand what is expected? How does the person feel in the team? Like, you know, can they- do they have an environment where they can trust each other and they have the support of other colleagues moving up, right? Like, what other roles and responsibilities moving further up? Like, do people believe in the mission and vision and what we're doing are they actually engaged in the work? So there is a natural tendency to say, okay, such and such person is not performing, but you've got to dig through the whys. You've got to understand the problem is often deeper, it's not what seems like at the surface. And as leaders we have the responsibility to debug through those deeper layers and understand, because that's our job. That's what we can affect. So I agree with what you're saying. Rein Henrichs: There's a paper called the ecology of human performance and it's great. And it's exactly this, that human performance isn't an individual at all. It's about community. It's about context. It's about environment. Ravs Kaur: Exactly right. Couldn't agree more. And that's really what we're trying to showcase through our product. Rein Henrichs: I love it. I think that's great. Jamey Hampton: Let's talk about #Rust! Sep 15, at the live@Manning conference; in one Rust-full day go from ways to learn it, to where and how to use it; from game-dev to aerospace and beyond, right from the pincers of expert Rustaceans. Finding Rustaceans weird but intriguing? Secretly wanting to become one? Tune-in, Sep 15, to the live@Manning #Rust conference to find your #Rustlang pincers! Striving to build reliable and efficient software, but finding your language of choice lacking in some key departments? Find the solution with Ferris the crab and the Rustacean tribe. When? Sep 15, at the live@Manning Rust conference!Rein Henrichs: I am kind of curious. So we were talking about measuring kind of like how the work is done level stuff, but also this higher level stuff. And I'm really curious, how do you measure wellbeing or engagement? Like what kinds of things let you measure that? Ravs Kaur: It's a great question. One of the things that we want to do is just use ambient data. Like companies and teams have lots of engagement surveys and polls that people fill out to tell you how they're doing and tell you how they're feeling. And one thing we want to do is, say, can we derive that, {chuckles} with the data that we have? So what we do is we, like I'll give you an example of a couple of things that we look at. So I've already talked about always on, but as another example, we look at just the amount of context switching that a person has to do and how that may or may not relate to their happiness level. So backing up to actually how we do what we do is we take data from messaging systems, calendar, {inaudible} and get sources, we sanitize them to protect privacy and then we stand up our analytics. So we know how many different groups of people have you met with, or how many different projects were you involved in or how many different code repos did you check on or how many different people did you message in any given day. So again, we're trying to metricize something that is a subjective of concept and we can get a pretty good idea of just how much context switching your brain has to go through. Now, this is humans, so for some people, they love that environment, they love the ability to context switch and be involved in 10 different things and that's what makes them thrive, and that's great. For some other people, they want to focus, they want to work on one thing and they want to get that through completion and not deal with 10 different things at the same time. So what we do is we'll show you just the amount of context switching or the type of work that an individual has been doing over the last three months or six months, and whether it's same, or has there been variety in work. Again, as conversation starters, we're not putting value judgment on the saying, this is good or bad. What we're doing is saying this person seems to be context switching a lot, or this person has been working on primarily bugs and customer fire drills for the last three to six months. As conversation starters, like as managers and leaders, we should check in on our people and have those conversations about, is this something that actually they love or they want to try something new? And having that in a data oriented way brings that safety and openness and transparency, and even actually to be super blunt, puts it on top of mind for managers to go and check in on the employees and how they're doing and how they're feeling. Through data, some of our customers have given us their engagement data as well. And so what we'll do is we'll run to see if there are correlations with the engagement data and what we're seeing in just how people work. We found some interesting ones that are very like that show leader and team behavior. So as a simple example, multitasking, we found that leaders and managers who multitask during meetings have team members that do that. And it sort of seems obvious in hindsight, but just seeing that in data was an example of, yeah, that's the culture of the team. And as a leader, when you do it, you're saying that it's okay to not be focused and be on your devices and laptops during this meeting. We looked at where the managers having regular one-on-ones with their team members, how does that correlate to their engagement levels in the surveys and other things like that. So that's some of how we try to metricize things that are subjective, but then also use data and engagement surveys and things to see whether there are common patterns that correlate and emerge. But more importantly for us, it's about, again, bringing visibility into these concepts that affect human performance and human engagement, and really encouraging the teams and managers to have a conversation about it. Rein Henrichs: So you're sort of trying to use found data, sort of almost ethnographic sort of stuff to say, all this data where people are using applications to do their jobs, what does that tell us about their work? Ravs Kaur: Exactly. I'll give you another example. So we analyzed collaboration patterns when we headed into the pandemic and one of the teams, what we found was, as we were talking to the manager, like one of their team members was just really isolated compared to pre pandemic or pre work from home. The graphs had lesser lines and thinner lines. And so again, it validated the manager's gut on some level or a concern that they had, which was, am I involving this person enough in discussions? It's really easy to, if a developer is working on something and they're self-sufficient, they're doing this and sort of being in a home environment, you assume that they're probably being pretty effective and they don't have distractions. And that's a good thing. But on the flip side, if they're not feeling like they're part of the team or regular communication flow of what's happening and having them involved in the ambient chatter on some level, that can feel isolating and alone when you're not seeing people on a day to day basis. So again, all those things about, it's really complex and very obviously, I love thinking about human psychology in general and sort of what helps in team effectiveness and how we can bring light to that with data. So that's, again, like collaboration patterns, things like context switching, being always on, burnout, those types of things are some of the things that we try. Rein Henrichs: So this reminds me of process tracing, which is a methodology in cognitive task analysis. And the goal of process tracing is to sort of trace the path that a person makes through the socio-technical system to accomplish tasks. And one of the things that process tracing does is it looks for what they call externalizations and these are things I have to do in the world to affect my goal. So for example, if I'm looking at a dashboard, like some steps for the web service or whatever, and I have to click to a different tab to find the right graph, that's an externalization. I can track the clicking on the tab and then try to reason about why they clicked on the tab. And one of the ironies of process racing is that better interfaces that present the right information more readily are worse for analysis, because there are fewer externalization, because if it was already right there when I was looking for it, I would've clicked on it. Jacob Stoebel: Again the program anticipated what you needed, so you didn't have to take any action to indicate what you needed. Rein Henrichs: There's nothing there for me to measure. Sorry. I didn't have to do anything to accomplish my goals, so there's nothing in the world to measure it, to indicate what my thought process was. Ravs Kaur: That is very fascinating. As a product builder, you strive to not have people click. Like information is right in front of you and if I am able to provide you information you wanted at where you are when you needed it, that's success for me. And it's really fascinating for me to think about sort of the flip of that, how do you measure externalizations in that world and don't get a glimpse into whether you actually got what you needed or whether this was so useless that you just didn't do anything [inaudible]? Rein Henrichs: You just make your products worse. It happens. Ravs Kaur: That's amazing. I did not think through that. This is really cool. Jacob Stoebel: You've been saying that you're more interested in, I think you called it ambient data, is it because you don't want to burden workers with the additional task of also tracking what they're doing or is it that we're interested in the actual behavior that workers do as opposed to what they report that they're doing? Or why are we more interested in that? Ravs Kaur: It is a great question. One, definitely more interested in ambient data because we don't want users and customers to do something different. Like you're doing your normal thing, we're going to try and get a sense of how things are going with you doing what you do and not doing something atypical or out of the way, or placing a burden on the user to do, again, do something different for our product to work. But the other thing is lot of people, you get a survey question and you report on how you're doing and answers are going to vary by time of day, whether it's sunny or rainy outside, whether you just yelled at your kids for doing something, like it's just so variant and a point in time that if you're able to take ambient data and look at it over longer periods of time, we believe that you can get a more consistent and truer idea of what's happening. But that doesn't replace actually asking people how they feel, which is why we take in the engagement data as well and try to analyze that as well. But again, ambient data just looking forward and future, is probably going to be more telling than surveys as an example. Although I feel even in the survey space you see this difference, like they used to be yearly polls, then they became half yearly polls and quarterly polls. And now you hear of like this micro bug, does a question every day to the employees to get, a more regular bots. And so what that's really telling me is it's important to see the continuation of this, like a point in time, a question and answer, it just has a lot of variability. So those are some of the reasons why we want to just use ambient data. Jacob Stoebel: I feel like there would be question fatigue. I'm completely speculating here, but I would guess that like, if I'm asked the same question every day, it wouldn't be hard for me to be truly thoughtful about how I truly feel about it. Ravs Kaur: And where its like people just stop responding, what's the point? Because some of these things are so cultural and they take time to change and if every day I'm just saying, this is not great, it really comes down to okay, like let's see some improvement and see some of that, I'm a big believer if you ask people to do something, you should show them something right away. Like their effort needs to be converted to value to them, and that process should not take that long. So they're incented to give you that feedback. But I think of my patterns too and I'll get all these surveys about how did you think about this quality of this call? And if there's a way I just can say not now and skip, how to do that. But there are others that block me from doing anything else before [laughs] you know, five star survey as an example, which I find a little annoying, but I understand why they do that because people otherwise don't give in their input. So if you rely on people's input, you either have to find a way to make that little more mandatory or put an effort to make sure you get that signal and feedback from them. And again, like when you get back surveys, you often hear, well people who are more disgruntled are more incented to go and fill out the survey and people who are really happy, they may or may not, like it may not be that big of a deal. So are you getting skewed results or is this general trend? Rein Henrichs: Surveys are also just really hard to design, it's hard to avoid confounding, they're really hard to analyze to actually get meaningful results from. I mean, one of the problems with surveys is what you're recording isn't what someone thinks, it's what they want you to think they thought. Jamey Hampton: That's similar to what I was going to say too, which is like, it's really hard to like put a number on a question where the answer is not really a number. Like if you asked me like how satisfied are you? And then you give me a bunch of numbers. My answer is like, I don't know Ravs Kaur: You're so right. This reminds me of the time, so we have an organizational psychologist who is part of our team, he's a scientist, and when we went remote, I was actually designing a survey or I wanted a quick belts from people to just gauge their comfort level around if and when things come back, are people looking to come back and more importantly, while at home, do they have what they need to be successful? Or is there something that we as a leadership team and management team can do? So I put some really basic questions out there. Like I thought they were great and they transcribed what I was thinking, but I had him review it and he understands the nuances of these survey questions really well, and so he comes back with, okay, with this question, if they had this response, is your takeaway going to be that they don't have the tools or the fact that their environment is not great or is it other distractions? And I'm like, well, you're right, I don't know. It's sort of catchall question and so going back to your point about survey design, there's a lot that goes into making those questions great in a way that you can actually take away some of the things that you think you can. Rein Henrichs: You know the strongly agree strongly disagree five point scale, I can't remember the name but it starts with an L, but.. Jacob Stoebel: Like heart? Rein Henrichs: Yeah, literally hundreds, probably thousands of pages of research has been done on whether it's good or not. I don't think anyone in tech can hope to construct a survey like this and have it represent real results. It's a really deep and like I'm so glad that you hired an expert because none of us are experts. Ravs Kaur: That's right. It's a really complicated thing. And my take away from doing that little survey was, I'm not good at this, I should just have that conversation and check in that way because, or have him design the questions really, even better. Rein Henrichs: So my trick is to try to steal one from a paper that is good and then hope that maybe applies, which is it self fraught. One that I've been trying to figure out how to use is, the paper I was referencing before is on meaningfulness, safety and availability and the engagement of the human spirit at work. And the goal of the paper is to measure three sort of factors that they think contribute to engagement. One is meaningfulness in the work, two a psychological safety and three is availability of psychological cognitive, emotional resources and see how the different factors contribute. So would try to get quantitative data about the varying weights of these factors. And so they publish, there are methods, there's the survey questions and then an appendix and there are things like there's five point scale and it's things like I feel emotionally drained at the end of the day, or I believe that my supervisor is looking out for my best interests, just a whole bunch of stuff. And I've been trying to figure out how to operationalize that, like in this context, because I don't think it will be simple, but I really want to measure that thing that they're trying to measure. Ravs Kaur: It is so relevant to what we think about and do also. We're on that journey too because, like this is, you pick any framework and they all sort of have this very similar underlying components to the ones that you just talked about. And those are so important for team effectiveness and feeling engaged at work. We're on the same journey. Rein Henrichs: Once you see this, you start to like, it's kind of like, I feel like I can see the matrix. Like I look at engagements, like people talking at work and I'm like, oh, you're low on that, oh, you don't feel like the work you're doing is meaningful to you. I can see that now. Ravs Kaur: Doesn't that sometimes almost ruin what, you know, you might, like just see an observation and not really going on like, okay, I think this is what's happening, like.. Rein Henrichs: It sucks, because then like, I don't really know what to do about it because it's a systemic thing and I can't fix it by myself. Ravs Kaur: That is tough. Cultural change is one of the hardest things like just change management in general. Alluded to a Tablo leadership training that we went through and we went through a lot of different modules, but one of them was specifically dedicated to change management just because of how difficult it is. What can you do? There's also this mindset, it's like, I can either do this or this. And then you really have to look inward and think, is there a third option here? Is it really just two options? Rein Henrichs: It's really interesting that we're all taught this analytic decision making framework, like think about multiple options and then compare them across all these different dimensions. But like no one does that, even experts don't actually do that. Jacob Stoebel: Should we transition to reflections? Rein Henrichs: I can go first, as is my want, I have two. The first one is that we need to take human performance seriously and we need to take the engagement of the human spirit at work seriously as leaders. And the second is we were talking about change management and I was just thinking about Steven Schrock's model of change to, change for, change by and change with. So change too is when the leader comes up with a plan instead of you have to go do this now. And that's very common. Then the other end is sort of change by, which is where you empower the people who need the change to make the change. And I think that's a really good way to look at how you're trying to make a change happen. Which one of those most applies and which one do you think would be the most effective? Jacob Stoebel: I'm really curious to think about, I am not a manager in my job, but I am curious about how can I be thinking more about ambient data that is already present at work for me, for my team and how I might be able to observe and act upon it because it is a very difficult time right now for almost pretty much everyone, personally, as a parent, that's probably my biggest barrier like source of interruption. And I'm curious like what conversations that could lead to at work and what outcomes could come from that? Jamey Hampton: I want to go all the way back to the very beginning of our conversation and reflect about failing fast. I just started a new job and so I'm learning a lot very quickly and I'm in kind of that new job mindset where I don't feel confident about what I know, but I'm learning and I think that this idea of like failing quickly and providing a lot of feedback could be something that's really important to like keep at the front of my mind a lot. I think that like when you're in that situation where you don't feel extremely confident, that's like exactly when you might feel afraid to start like unearthing things that you don't know about, but that might be like exactly the time when it would be really beneficial to do that. And I actually received an email from my work while we're recording this podcast about implementing like in progress PR so you can like put, Oh, this is only 30% done, so like it can't be merged and there's all this stuff that's like preventing it, but I still want to put it out and get like early feedback. And so it was kind of interesting that we had this conversation about failing fast and getting early feedback, and then I got this email and I was like, Oh, that's just what we're talking about. So I think I'm going to bring it into my life. Ravs Kaur: I've got a lot of great pointers for just papers I'm going to go and look at on the... Rein Henrichs: I'm sorry. Ravs Kaur: I love it. Thank you. I was making notes of it while you were talking. So for me a couple of things, the validation and the energy and discussion around humans and team effectiveness, which obviously we're basing our product on, but going even further and deeper into those papers and seeing whether there are ways that we can actually bring some of those and helping our customers, trying to measure some of those things. Another just fascinating one for me, again, from a product building perspective, has been the conversation around externalizations and process tracing. How do you know if you've built a great product if you don't have a way to measure or get a glimpse at what people are either clicking on or what they're trying to find and things like that, have you done your job or have you really failed at it? Great one. Rein Henrichs: Well, it was really fun. I feel like I was just mentioning papers a lot. Ravs Kaur: And thank you for that. I had a lot of fun talking to you all. It was a really great conversation. So thank you for having me. Jacob Stoebel: Like wise. Jamey Hampton: Thank you so much for coming on. We really appreciate it, for having come for a conversation like this.