How to become a data-driven organization with Pluralsight Flow

Updated on May 16, 2023 | Read time: ~3 mins

At Pluralsight, we believe that becoming a data-driven organization is beneficial for all levels of your company. Using data to make decisions on workflows and processes will help increase productivity and efficiency. But more importantly it helps team leads advocate for their employees and improves the overall developer experience.

Recently, we shared how our own engineers use Pluralsight Flow, our engineering insights platform, to drastically reduce queue times while also improving communication. Our teams understand that all of the metrics within Flow work together holistically, but it can feel overwhelming to approach an insights platform from day one and use every aspect instantly.

With that in mind, we asked our engineering leadership which metrics they found most helpful from the word, “Go.” Focusing on these data points can not only help transform your software development team into a data-driven model of efficiency; they also are easy to understand and work with while you grow accustomed to some of the finer points of Flow and overall team health.

• Coding Metrics: Tracking Coding Days
• Collaboration Metrics: Addressing Unreviewed PRs
• Collaboration Metrics: Improving Reaction Time
• Ticket Metrics: Analyzing Cycle Time
• Ticket Metrics: Streamlining Queue Time

Flow proposes the idea of Coding Days as any day where an engineer contributes code to the project. There are many different forms of engineering work: writing code, reviewing others' work, discussing specs and architecture.

Coding Days gives an overall view of “do people have time to create solutions in the code base, and are they following best practices around small/frequent commits?” This is also tied to the health of continuous integration and continuous delivery practices where technologists focus on small and frequent commits.

It’s important to note that if a team has a low week of coding days, it’s not necessarily a bad thing; there are nuances to what impacts coding days. The point is to use Flow to alert you to that status, and then talk with the team to figure out those nuances.

 

In an ideal world, PRs should always be reviewed before they’re merged. Even if they’re small or made by senior developers, unreviewed PRs can be a huge source of bugs. That’s why every time a PR is merged without review, a manager should know about it.

Simply put, this data point is an indicator of risk. You don’t want large numbers of unreviewed PRs merged, as that’s more likely to cause a higher change failure rate or poor performing customer-facing code.

This data point looks at the time it takes for the reviewer to respond to a comment addressed to them. Are team members unblocking each other, and quickly, to get code into production? 

Reaction Time is tied closely with two metrics we’ll discuss next: cycle time and queue time. When you work toward driving this number down, it will have positive implications on your overall ticket metrics.

Cycle time is the time between when a ticket enters an Active status, to the final Done status in its life cycle. Any tickets that are currently in a status marked as Not started or Active, will not have a cycle time calculated for them. Cycle time updates when tickets move backward from a done state. 

This metric should be used to determine how long a ticket took to complete. Cycle time only captures the time engineers worked on the ticket. It does not include lead time where product managers, designers, or stakeholders provided requirements before the ticket entered an Active state.

Queue Time is the total time a ticket is in a waiting state. The engineer working on the ticket may need to wait for feedback, QA, or review from team members. Queue time captures these moments in the ticket life cycle to help improve efficiency and remove barriers for engineers. 

In general, you can think of these two delivery metrics as, “How long is it taking us from the time we start a piece of work to when it gets to production?” They help determine where process inefficiencies can be found and where code is sitting with teams for longer periods of time, which allows teams to adjust when appropriate.

Adam Sockel: You are listening to Perspectives and Leadership, a podcast for tech leaders presented by Pluralsight. I'm your host, Adam Sole, and every episode we'll sit down with some of the industry's most future-focused minds, learn about their experiences in tech and how they approach leadership in an ever evolving world. If you like what you hear, be sure to subscriber, have you listened to podcasts? And take a minute to leave us a review cause it helps other technologists find our podcast a little bit more easily. Let's get started. Hi everybody. Welcome back to the podcast, Adam here. This was a fantastic conversation that you were about to listen to that I had with someone I consider a good friend. Now, Kristen Foster Marks, who is a senior software engineer here at Pluralsight. 

 

We are going to talk about Pluralsight's engineering insights platform flow. Uh, it's the tool that we're really proud of that helps improve, um, not over, not only developer productivity, but also developer satisfaction and a whole bunch of other stuff. In this conversation, we talk about things like the data that you should be paying attention to and how you can use that in your daily standups, in your one-on-ones, uh, and how it can improve not only the quality of the product that your teams are creating, but also the quality of life and work and everything that, uh, can be taking place for individual contributors. Again, obviously Kristen and I both work here at Pluralsight, so we're talking about a plural site tool. Of course, you know, I'm gonna say the quiet part out loud. We would love it if you were using our tool, but even if you are not currently a Pluralsight customer, uh, the conversation we have here is really applicable to every software developer or software development team. Uh, you're gonna hear lots of interesting nuggets about how you can improve again, those daily processes and, and really improve, uh, not only individual workers experiences, but also collaboration and just really everything, all, all once. 

 

So, you know, obviously, like I said, we would very much like it if you checked out Pluralsight Flow, but regardless, the conversation is perfect for every technologist, every software developer, uh, whether you're a team lead or an individual contributor or somewhere in between. Okay, that is just about all of the quick housekeeping here. As I mentioned in the introduction, if you are enjoying the podcast, uh, be sure to subscribe so you don't miss any of our episodes as they get released. And leave us a quick review and a five star rating. If you are enjoying the content, it does help other technologists find us a little bit more easily. That's all from me. I hope you enjoy this conversation with Kristin Foster Marks on perspectives and leadership of Pluralsight podcast. 

 

Adam Sockel: Hello everyone. It is Adam again, and I am so, so excited. I love doing every single one of these interviews, but I especially love getting to do them with someone that I became really, really friendly with over the past couple weeks and months at my time here at Pluralsight, because they are also a plural cider. I am joined by Kristen Foster Marks, who's our director of Engineering and Value Delivery, and I'm gonna let her kind of explain what that means in just a moment. But first, Kristen, thank you for joining me today. 

 

Kristen Foster-Marks: Yeah, absolutely Adam, thanks for letting me come on. And I'm glad that you like referenced, uh, just like that we've kind of become work friends mm-hmm. over the last couple months. I actually remember your first couple weeks here and kind of bonding over the running thing. I know you're a runner and fellow writers and, uh, yeah. 

 

Adam Sockel: Yeah. And so one of the reasons to give people complete context, one of the reasons that I wanted Kristen to come on is a, because like I said, we, we became kind of fast friends, but also when I first started, when I was getting a, a hang of everything that happens here at Pluralsight, I was listening to our other podcast, which is called All Called All Hands On Tech, and Kristen was on there and gave us like wonderful sort of background of her career and how she got into software engineering. So this is all also tell everyone listening, if you want a full background of Kristen, you can go to the All Hands on Tech podcast and listen to it. But what I would love to do is if you just kind of want to introduce yourself and sort of give people an idea of what your role is here at Pluralsight, and then we will dive into all of our topics. But just like a, a high level Kristen Foster Mark's introduction, and then we'll go from there. 

 

Kristen Foster-Marks: Yeah, Absolutely. So, okay, so I started a plural site a little over two years ago now. Um, and for the first year was an individual contributor on the team that built out the flow delivery module. Um, and then about a year ago moved into the director role. Um, so I've been on the same team working on, uh, you know, the same part of the application for the entire time that I I've been here. And so the delivery module reports are, they're kind of my baby at this point, Um, so yeah, now I'm leading the team and, um, uh, yeah, I mean outside that's, that's, that's pretty much it. I'm just like mm-hmm. leading the team towards just like delivering some value to our customers and, and the value that we deliver is like helping our customers deliver value. So there's kinda like this, uh, this meta aspect of, of the reports that we build, right? 

 

Adam Sockel: Uh, So along those lines, so for people, I, I know a lot of people listening in may be familiar with what flow is, uh, and they're all, there's probably gonna be a lot of other people who are just enjoying our kind of leadership conversation. So for people who don't understand flow is Pluralsight's kinda engineering insights platform. It's just a wonderful tool that a lot of, uh, engineering leads and actually really any technologist in a organization using the product can use to get some incredible insights. And so we're gonna be talking a lot about data or data depending on how you like to say it, And so the first thing I want to ask you about Kristen, is what data do you think managers should be paying attention to? 

 

Kristen Foster-Marks: Yeah, and that's a great question. So, I mean, I think there are a lot of products that, that aggregate and visualize lots and lots of engineering data, you know, a lot of stuff out there on the market right now. Um, and of course managers are often collecting and tracking their own metrics and in often time consuming ways. Um, and it can be hard to kind of sort through it all and determine which metrics provide really meaningful and actionable insights. Um, in my experience as both an individual contributor and an engineering leader, um, I think there are a few that, that I think are really extremely important to pay attention to mm-hmm. Um, so first and foremost, um, I think managers have got to be really mindful of their folks' overall, uh, overall wellbeing as well as their happiness and contentment at work. 

 

So I think, you know, this is kind of the, the dev satisfaction, uh mm-hmm. metrics that we're seeing written about a lot these days. And I think these dual exigencies of, uh, a global pandemic and a, uh, pretty antagonistic political climate has made us all super aware of how things happening outside of work. Mm-hmm. impact our overall wellbeing and, and thus our ability to focus on work and, and perform to our utmost potential in, in my own experience, um, being able to be open and honest with my manager when my life outside of work is kind of crummy for whatever reason, has, has been really comforting. 

 

As a manager, knowing when my engineers have have crummy stuff going on outside of work just helps me empathize and contextualize the occasional dip in performance or dip in pro productivity. Um, and these are just important things, uh, to kind of pay attention to as a people leader. 

 

Adam Sockel: I love that so much just because I, right. Not long after I started the, um, a big piece that anyone in the tech world is probably familiar with now, the space of developer productivity came out fabulous. And it was, I feel like that was like the first big piece I, I wrote about extensively here. And I love that you started off with overall wellbeing and happiness at work because there's just so much data that shows like if people are happy, they have a good sense of like self-worth, they feel like they're connected to the company and the projects that their team is working on, they're going to be more productive. 

 

Kristen Foster-Marks: Absolutely. Abs Yeah, you're absolutely right, Adam. And you know, like mid-level managers, like we have relatively little control over things that can ha mm-hmm. like can impact that happiness at work, like, like benefits packages or PTO policies and even salaries to some extent, right? Mm-hmm. But we do have control over things that can make our people's, uh, jobs enjoyable. Like whether they're occupying roles on the team that they wanna be occupying mm-hmm. whether they're being given time to learn and to upskill, which is something that I like, I'm so happy that we emphasize that app, plural, right? 

 

Mm-hmm. like it's part of what we do, a big part of what we do, right? Yeah. Um, and that's absolutely contributed to my happiness at work. You know, we can control whether our, our folks are overworked or, or even underworked cuz you know, it turns out they're really good engineers. Like they're not happy when they're sitting around twiddling their thumbs, right? Mm-hmm. So, um, so I think that, you know, managers need to be collecting and paying attention to data that provides insight into that dev satisfaction piece. And, and part of that data is qualitative, part of that data is quantitative, and I think people are getting really creative with, with data gathering methods mm-hmm. these days. And we're starting to see a lot of products kind of help in that kind of hope and flow is headed in that direction in ways mm-hmm. But yeah, I think that, I think that that's really important. 

 

Adam Sockel: This is a Pluralsight podcast that, you know, I'm sure people have grown accustomed now to the many episodes that they've probably listened to that we're gonna talk about flow a fair amount. This is the pro, we're very passionate about it, but we also really believe in like, the importance of what it can do, just like the different types of insights and the reporting that not only managers and executives and C-Suite people can see, but the individual contributors and, and the transparency that it helps deliver for everybody. 

 

Kristen Foster-Marks: So Yeah, absolutely. I mean, yeah, Adam, to that point, like, I'm a flow fan girl, You're wearing a, no one else will see this, but Kristen is wearing a flow sweatshirt right now, and I know that because I have the same sweatshirt. yes. Love this hoodie. Love it. Yeah. I mean, I, I practically baked to be hired here, so yeah, I hope it doesn't come off like, you know, just promoting, promoting the product I work on, like, there's a reason I work here. It's cuz um, I, our, our product is amazing. It provides a lot of value. 

 

Adam Sockel: I feel like people add by this point, having listened to a few episodes, they're probably able to hear like the passion in all of our voices. It's like, we're not just, you can't fake that. I always, I actually joked about it, um, talking about our ceo, the first time I heard him speak, I was like, you, you can't fake his excitement. Like it, no one's that good of an actor. Like he's, it's real What are some of your f uh, personal favorite reporting options in our tool flow? 

 

Kristen Foster-Marks: Yeah, good question. Yeah, we, we do have a lot of reporting options and I, and I do have, you know, a few go-tos. So this is definitely kind of a bias response, but I do love, love the reports that my team builds. So, you know, in that delivery module that, again, it's just really focused on helping teams figure out, you know, what parts of their process are working really well and what processes are not working really well so that they can deliver value, um, more efficiently and, and better to their customers. Um, so that's kind of what that module focuses on. We've got the ticket log and the retrospective as, as part of that. And the ticket log has really been one of my go-to reports as a leader. Um, I've gotten in the habit of looking at it first thing in the morning, uh, just to see the state of our work as we head into a new workday. Um, and, you know, as we progress further toward the end of our sprint, there are a ton of, uh, filtering capabilities and the ticket log. 

 

So, you know, I can limit the set of tickets by a assignee if I'm interested in saying like, okay, like what's Rob going, what's Rob got going on this week? Like, uh, I know that, uh, you know, that he was waiting for somebody else on this. Was he able to get unblocked? Um, I can toggle between a list of what's already been completed in a sprint and what hasn't even been started yet, which is really, um, good high level information to just kind of keep tabs on as a leader, right? Mm-hmm. and I can also easily see what tickets have had a lot of activity on them, like new commons, um, description changes and, you know, haven't forbid any backward movement in the pipeline. We really wanna avoid that kind of stuff. So with that data, I can just easily see which engineers I need to check in with and you know, who I need to give, um, a little bit of support or assistance to, or, you know, if there are blockers that I need to remove. So really like you Yeah. 

 

Adam Sockel: Um, I know, I know you've got some others that we wanna talk about, but, well, I just wanna point out one of the things I love that you mentioned there is, is seeing the, the comments back and forth on specific tickets and stuff, like, I wanna emphasize for people, like when, when leads see that, or even individual contributors, like that's not, like you said, it's not necessarily a bad thing. Like that's collaboration, that's especially being either remote or hybrid, you know, we're talking to each other from basically across the country, and, uh, like, like being able to see that those, that those comments back and forth, you can see like which teams are collaborating with each other, like which ones might be, uh, a great, uh, you know, cross team collaboration on a project or things like that. It's just like a, such a powerful little note to be able to see. 

 

Kristen Foster-Marks: Absolutely. Well, and I love that you said that because something that we've talked a lot, um, on our team about is just using those tickets. So our vendor system is, is Jira. So for the ticket log, you know, we're, we're pulling all of our data in from Jira, but mm-hmm. JIRA is a system through which we're like making comments and you know, changing the description, changing the title. And we've talked a lot about, um, how as engineers, we can help our engineering leaders, we can help our product team just kind of like understand the progress of our work mm-hmm. by adding comments to those tickets. So to your point, like if a ticket has a ton of comments unfolding on it, that's not necessarily a bad thing. Right? Sometimes that's a really good thing. 

 

It means we're communicating out, you know, what that does, it makes it so that as a product owner, I don't have to tap your shoulder and interrupt your workflow and ask you for an update. And as an engineering leader, I don't have to shoot you a Slack message and be like, Hey, like, what's the progress on this? Like, it's all there in the ticket and yeah, that shows up in, it shows up in the ticket log and so I can like filter by Okay, what tickets are getting the most activity right now. 

 

Adam Sockel: Yeah, absolutely. All right. I'll let you get to, to your, one of your next kind of reporting things that you enjoy. I just, oh my God, had I had to just point out that collaboration, it makes me so happy to see that, hear about it And I love that. 

 

Kristen Foster-Marks: And collaboration is so huge. Like, uh, um, well, I mean we'll probably get into it later in this podcast, but coding is a team sport it really Is. 

 

Adam Sockel: All right. What's your, what's the next report you wanna talk about? 

 

Kristen Foster-Marks: So, retrospective, I mean, retrospective is a really just like, um, you know, as it's name applies, it's, it's a report that we can use at the end of our sprint. So, or, or really any time period to look at aggregates of the metrics that show up in the ticket log at that individual ticket level. So, you know, with these aggregates we can dig into the data and start to formulate and test theories around what's working well in our process, um, what's propelling us toward delivering to customers. And then, you know, on the flip side, what's impeding our delivery, um, you know, what things we need to tighten up in our processor pipeline. So, um, I'll, I'll just tell a story here. 

 

One of my favorite team retrospectives was one during which our team's analysis of our q time aggregate. Um, so just to clarify, you know, we're tracking q time on tickets as, um, the amount of time that a ticket spends in a waiting state. So like waiting for code review, um, is a waiting state and it's gonna contribute to your q time waiting for qa, um, ready to deploy. These are all times during which the developer is not actively doing anything, we're just like waiting for something else to happen. Mm-hmm. and you don't want really big Q times cuz they usually point to a larger issue. Right? Right. Like, I worked on a team where I'd submit something for code review and a week later I would start to get comments like, not that can't happen. Right? Like, comments need to happen like at most, a few hours later. Yeah. So, so I'd love Q time. Um, and you know, with our, when our team was looking at this, um, several months ago, our q time aggregate kind of revealed that we hadn't established an agreed upon a clear definition of done for our team. Um, and it's really, really important to do that as software developers. You know, when you're shipping code and, and your, your goal is to deliver value to customers. Like everybody needs to be on the same page about like what done is. 

 

Yeah. Like what constitutes done. So some engineers on our team thought once their code was merged into our staging environment, it was out of their hands and they were done onto the next ticket. While others thought, no, no, you shouldn't move on to the next ticket until that work is promoted to production where the customer can actually use it. You know, if it hadn't been for analyzing that queue time aggregate on the retrospective, I think it would've taken us a little bit longer to kind of understand that we hadn't really talked about that yet. And it was a conversation, um, and an agreement that we needed to make with each other. 

 

Adam Sockel: Yeah. I I'm laughing. So for clarity, for everyone listening, and I am in marketing and the marketing equivalent of this, I had a director at a previous job that I loved. I'm not throwing him under the bus, but he was very famous for doing the, uh, version final 1.1 or version final 1.2 all caps final for real. And it's just like exactly what you said. I was just laughing cause like the definition of done is such a beautiful way of putting that. Like what do we mean by complete everybody? We need to know this before we can move on to the next thing Yeah, absolutely. 

 

Kristen Foster-Marks: Absolutely. Yep. That's a good story. Yeah, you're, and you're right, like probably every like job profile and and organization has like those certain kinds of projects where like if you haven't decided as a team what done is you can get yourself into trouble. 

 

Adam Sockel: Exactly. Yeah. I know you've got one more here. 

 

Kristen Foster-Marks: I Know. Yeah. Oh my gosh. I'm Work Log. I love talking about Work Log. I mean it's like, it's Flow's flagship, but it's another one of those reports that I'll take a look at most mornings just to get a sense of what progress we made toward our Sprint goals the day before. Um, and for me this has eliminated that need for, you know, like checking in with engineers individually to see, you know, how things are going. We don't do, uh, daily standups on on my team. 

 

We do not do a daily synchronous standup. And I think that that's been a huge win for our team. Um, you know, our engineers span every time zone in the continental US mm-hmm. and some of us like to work early and some of us like to work late and, and it can be hard to find that common time in a day that isn't gonna interrupt at least one person's focus time. And we are all about focus here, right? Like we can't have flow efficiency unless we have time to focus and work Log makes it so that like, uh, we don't really need to have a daily standup like mm-hmm. we can all see what got done the day before. Um, and engineers can then take the responsibility upon themselves to raise their hands around any blockers that they need to report. 

 

Adam Sockel: As a person with a manager in Melbourne, Australia, and I am in Cleveland, Ohio, I feel this to my core. We have grown accustomed to, one of us is usually seeing a sunrise or a sunset behind the other one just depending on when we can see each other. See a thing like work log is just so beneficial cuz exactly what you said. Like, she can see what I'm doing. I can, I can kind of point out anything if I need to, to raise my hand and just say like, Hey, cuz all of our, basically all of our communication is asynchronous. It's like, Hey, when you see this, let me know your thoughts on this stuff. 

 

Kristen Foster-Marks: Yeah, absolutely. Absolutely. Yeah. Well, and one more thing that I should probably say about Work Log is, you know, it's got, has great use, um, kind of like habitual use cases like I just mentioned, but it's also been really good for me for just kind of testing those one-off theories. Um, so like for, to give an example, um, my team was really heavily practicing lean development earlier last year, which, um, you know, for those who aren't familiar with Lean development, you're not having the daily standup. 

 

Like, you're not doing sprints, you're not doing sprint planning, or, you know, it's just like very lean on meetings essentially. Mm-hmm. And, uh, we started building the Sprint movement report, um, and we weren't doing sprints, so we weren't doing anything kind of organized in that way. And we thought, you know, we should probably try out this Scrum thing for the sake of the report. And we were all very, you know, very suspicious and I was really concerned at the beginning that these extra meetings during the week were gonna kill our productivity. Mm-hmm. So, you know, once we kind of got into, um, into the Scrum things, uh, I started looking at the work log on a regular basis and, and just doing some spot checking to gauge if our weekly productivity was dropping and if our productivity on those meeting heavy days in particular was dropping and it wasn't. Um, and, and now, you know, months and months into this adoption of those Scrum things, you know, we're all kind of super sold on, on this being an overall improvement to our workflow. And it was just nice to be able to, you know, kind of have a theory and say, okay, what can I look at in flow to, to test this theory and what, what data is there to confirm or just confirm it. 

 

Adam Sockel: Just for some background, when we were at an, in an onsite together with the whole Flow team, everyone I went up to, I was like, Hey, I wanna ask somebody about these new reports in Flow. And they said, talk to Kristen. Talk to Kristen, she's gonna around talk about this. So the floor is yours. Tell me about some of the new reports available in Flow. 

 

Kristen Foster-Marks: Yeah. Awesome. Awesome. Well, I love that people were directing you to me. Yes, they were big time, super excited about our stuff. Um, okay, so I just mentioned sprint movement. Mm-hmm. Um, so that is one of our upcoming reports that I'm super excited about. I mean, my team is building it. What Sprint movement is doing is it's visualizing, uh, the work that was, um, committed to before the sprint started. So, you know, your teacher team goes through sprint planning and everyone decides, okay, this is what we think we can get done mm-hmm. so like we have a record of that. Um, so we look at that and then we look at the work that was added to the sprint while the sprint was in progress mm-hmm. so that's not ideal, right? Mm-hmm. uh, like you really don't wanna be adding things to the sprint in the middle of the sprint and sometimes you can't avoid it. Mm-hmm. like, it's not always a horrible thing, but if it becomes a pattern, then you might wanna look at whether that is affecting your delivery. Mm-hmm. um, whether there are certain things we can pinpoint in our process to either eliminate it or aswa it or, you know, whatever. What, what the sprint movement re report does is it allows you to compare up to six sprints to see, you know, what did you actually get done of the stuff you committed, like how many points or tickets were added and how many of those actually got done. And you can kind of start to see and track those trends over time, kind of start to take a look at what your work capacity is. Again, those process issues are easier, easier to, to kind of identify. 

 

Adam Sockel: And I love, you know, mentioning sprint movement, like to kind of give some people ideas of like the way that my brain is working about how people can use this with some of the other reporting aspects of flow to kind of give them like a real life example. You know, we were talking about comments before and things like that. I feel like you can look at the sprint movement report when it's live and then look at, you know, kind of the comments and the back and forth in certain sprints and you can start to get a feel for like, okay, like you said, is that work that's being added in? Is that on our, is that on our team or is that something that an external team or a a, you know, maybe an executive is, is constantly asking for more stuff. So we need to kind of set those groundworks of saying like, here is, we need to maybe have a stronger process to clarify when edits can be needed. So I just feel like absolutely they really put together really well. 

 

Kristen Foster-Marks: Absolutely. And I mean, just to give another example, like if you have a problem with the production bugs coming up mm-hmm. but like, like sometimes teams do, right? Sometimes products do. Um, if you realize that you've got, you know, half of your sprint load, every sprint is unplanned work mm-hmm. and it's all production bugs. Well, as an Oregon as a team, we probably need to take a look at why that's happening, right? Yeah. Cause that's not ideal and that's stressful for engineers and Yeah. At the end of the day, we're just trying to keep our engineers in this work climate. Right? 

 

Adam Sockel: Yeah. Especially now more, even more than ever. Yeah. Keep them happy and, and fulfilled and not Yes. Hyper stressed out. Yes. Um, I know you've got one more new report you wanna talk about. 

 

Kristen Foster-Marks: Yeah, I, I really wanna talk about the check-in report. It's super cool. Um, you know, it's meant to be used during one-on-ones and it, it has a place where an engineer can set goals around things that the flow application currently has the data to, to track pro progress around. So for example, um, you know, making smaller and more frequent, uh, commits mm-hmm. is something that, uh, a lot of engineers find that they have to, to work on. Um, I think that most engineers have probably been in a place in their career where, you know, they hold onto their code and they commit once a day or they commit once every three days and they're only pushing it up to the remote, uh, the, the safe remote branch, you know, every few days mm-hmm. Um, that's not great process. 

 

Now with the check-in report. Uh, engineers can set goals around them with their leaders, you know, if that's something they need to work on. Um, folks can also set goals around things like reducing the amount of time it takes to move, pull requests through the review and deployment pipeline. Um, you know, our flow efficiency gets a lot better when we're moving those things through. So also has little widgets for an engineer can see their work distribution. So you can see, you know, like 50% of my commits were brand new work and 50 50% were legacy root factor. Mm-hmm. it doesn't always, um, point to a good thing or a bad thing for the engineer or process, but sometimes it does, right? Mm-hmm. so like I had, um, a case where I was looking at this with an engineer a few months ago and she just had a lot of legacy refactor. And as a, as a leader, you know, I need to kind of step back and be like, okay, are am I giving this person fun things to work on? Mm-hmm. like some people love to refactor and they can do it all day every day, but, but some people absolutely hate it. So that's just a starting point for a conversation, right? Mm-hmm. like, 

 

Hey, like has this been onerous for you? Like, maybe we should get you on, you know, a, a different project when that comes up where you can do some more greenfield development and Yeah. 

 

Adam Sockel: Absolutely. It gives, like you said, it gives kind of leaders a nice, not only reason to check in, but like it helps you get to know your team members better. And when you know them, you can kind of better understand, you know, maybe even things like moving it to the, all the way to like the mental health aspects of like, okay, I can, I know because of all these interactions and these check-ins that I've had, I can tell when someone's in like a certain type of a mood or maybe they're just quiet because it's night in the morning for them and they're on the East coast. Like there's just using this check-in report for a really, really powerful way to not only catch up on and like check in on people's work, but also just check in on them as, as a, as a people I think is a really awesome way. As a fellow technologist, data nerd, what are some data points that you think get overlooked in software development and DevOps? 

 

Kristen Foster-Marks: So, I mean, definitely the, the dev satisfaction metrics that I mentioned earlier mm-hmm. I think, you know, we talked through that so we won't spend any more time on that. But, um, I think metrics like cycle time, lead time, queue time, I mentioned earlier, um, really get overlooked a along with that sister metric, uh, deployment frequency mm-hmm. um, uh, I know Dora is, uh, very much on everyone's minds these days and I think for good reason mm-hmm. I think for really good reason. 

 

You know, I once worked on a team where every team member developed a feature totally independently of each other. So like, like I would be developing both the front end and the backend for a new report mm-hmm. all on my own, like no, like, no collaboration with my teammates and all of my teammates were doing the same thing with completely different reports. Um, and, and I think our product folks kind of figured that, hey, if we do it this way, we can ship four reports, you know, this half of the year because we have four developers working on them. But what ends up happening is it takes us six months for your users, for your customers to get any single report and, and therefore new value from your product. Right. And, and the lead times, we see that in the lead times. Um, so, you know, for any of those projects that lead time, that cycle time is gonna be atrocious. It's gonna be mm-hmm. six months that will show up in your deployments. 

 

Your team is gonna have fewer deployments as a result of that throughout the year. Um, and it also like that human piece, like it makes your engineers start to feel really isolated from each other. Yeah. Um, and sometimes not even part of the same team. Right. So yeah, there is a lot of potential issues with this, and I think that if teams and organizations, uh, paid more attention to metrics like lead time cycle time, q time deployment frequency, and probably all of the Dora metrics, um, they could find better ways to collaborate, learn from each other, help each other, and, and just keep that customer value, uh, floating efficiently through their pipeline. 

 

Adam Sockel: Yeah. I love that you mentioned that, um, that isolation feeling that, like being siloed, especially, I know I'm, I keep harping on it, but like, especially with us all being remote, like if you're not interacting with your coworkers, at least on Zoom or Slack or, you know, commenting like you said in whether it's in Jira or anywhere else, like if you're never interacting with other people and you're just working on the same thing over and over, it's almo it's, it's like the shining, like you're just sitting there it's like all work and no plate. Like that's literally what it is. You know, looking at these pieces that you were mentioning, it's like, it's so important for just the overall health and the organization, but of your employees and it all ties in together, so. 

 

Kristen Foster-Marks: Absolutely. Absolutely. And then your wins, like are not just individual wins mm-hmm. their team wins. Right. And, and then I think, you know, when we're all, when we're all collaborating on the same thing, um, we just have more opportunities to learn from each other and we waste less time on, um, doing code reviews for projects that we don't really know that much about. You know, like I think the overall quality of the work that we do goes up, but as a result, um, and we, and we waste less time. So Yeah. 

 

Adam Sockel: When do you think evaluations should be taking place for product cycles? And we can talk about a couple different things here. 

 

Kristen Foster-Marks: Yeah, totally. So, yeah, I think, you know, in terms of those like whole team evaluations, I really like a regular cadence for, for team retrospectives mm-hmm. Um, I think it's good teams can, um, you know, just kind of commit to saying, Hey, every two weeks, every three weeks, every six weeks, whatever works for them. Yeah. Like, we're gonna check in together and do a look back on, on the work that we've done. And I think it's, it's important for teams to share the responsibility o of leading bees rather than just like asking the scrum master to do it every time. Asking the team, like the engineering lead to do it every time kind of gives engineers a more of a sense of agency when they know that they will have to lead one in the future, or they have like one so they know what it's like to hear like crickets chirping, right? Mm-hmm. So, and I think it's also, it's important to kind of mix up the format and the activities, um, of those retros just to keep it from getting stale. Um, my team wasn't doing retros at the beginning of the year. Um, and then we thought, you know what, like rebuild the retro report Yeah. Like we, uh, we should probably be doing this on a regular cadence rather than just like one-offs. Um, so, um, we decided to do them every two weeks. Um, and we do share the responsibility of leading those. Um, and we've even clubbed, uh, a book together. Um, it's called Agile retrospectives, making Good Teams. 

 

Great. Um, and from that book, we've gotten some really fantastic ideas around just different activities that teams can use to elicit both the quantitative and the qualitative data just to celebrate, um, celebrate the wins, identify the improvements, um, and then of course like, like we're using flow for that quantitative data. But I think too that those projects, project specific retrospectives are really important mm-hmm. um, and I think that they get, they get overlooked. I've actually never been on a team that, um, really consistently does project retrospectives and I myself have not been great about scheduling those despite, I would say like midway through every project that I've led, thinking Okay, we're definitely having a project retrospective I never end up scheduling them. So, you know, it's something that we have to build a habit around. Um mm-hmm. and I, I think it makes sense, you know, by the end of a project, we're all ready to celebrate the win and, and forget the little failures along the way and, and move on to building the next new shiny thing. But there's so much value in looking back at, uh, you know, back at both the wins and the failures and, and using them to reflect and, and kind of create new agreements as a team about, you know, how we're gonna work moving forward to deliver, uh, better and, and worry efficiently, you know, for the next project. 

 

Adam Sockel: Do you think that there are, there should be a difference for like individual evaluations as well? Do you have thoughts on that part? 

 

Kristen Foster-Marks: Yeah, I do. Um, I, uh, yeah, I'm pretty big on individual evaluations as, and I'm a former teacher, so I think that, you know, there's probably some, some overlap there or some influence there. You know, when you're teaching, you know, pretty much everything is an evaluation. Yeah. I think that those evaluations, um, of your, your team members, your engineers really should be happening constantly in various forms. As a leader, I'm always evaluating how the folks on my team are, are kind of, you know, completing their work and, uh, and progressing toward their personal professional goals for the year. So, to give an example, um, I have a team member who suffers a lot of anxiety around speaking up extemporaneously in public. Mm-hmm. Um, even if it's just contributing ideas to a brainstorming session, this person still just gets a little anxious around that. When I observe this person speaking up in a substantive way during a meeting or even leading a meeting really well, I'll shoot that person a bit of feedback afterward around what they did well, um, and what they can improve on for the next one. 

 

That's just a quick, you know, evaluative feedback cycle that can have a huge impact on building that person's professional confidence. Um, and I hope it also emphasizes to folks that like, it's okay to be in development mm-hmm. in certain ways and, you know, in, in certain regards. Um, it's okay to not perform perfectly every day and, and, and, and all day every day Yeah. Um, yeah. And so, and that's, you know, another way in which, um, that, that check-in report can be super useful because I also think those weekly one-on-ones are a place where we shouldn't hesitate to provide coaching and, and feedback for what transpired in the prior week. So you can use that check-in report to say, okay, like over the last week, you know, you were committing seven times a day and you were, you know, at the top of the team in terms of productivity and like, let's celebrate that together. Um, yeah. And, you know, if pro if productivity was, was nil, well, like why did that happen? Like, there's probably a good reason for it, but let's talk about it and figure out if there's some coaching that I feel like I need a sticky note with, like Kristen says, it's okay not to kill it every day. 

 

Adam Sockel: Like, just like put it right in front of me. Cuz I, I, I do absolutely struggle with that personally, where I'm just like, if I have one of those days where I'm like, I didn't create even a, a piece of content today that'll look like five pieces of content. And it's like, okay, let's look back. Like were you in meetings all day? Was it just a hard mental health day? Like the Yeah, it was, I I love that. 

 

Kristen Foster-Marks: Oh my gosh. Well, and Adam, I've had to do so much work around that mm-hmm. I think particularly as a software engineer and then, you know, in this last year leading the team because I mean, as a software engineer, like you fail a thousand times a day. Uh, yeah. Like when you're writing code, like the computer's the only entity to that knows that you're failing but like you're getting a thousand error messages a day as you're working towards a viable solution. Right? Yeah. And, and then that's just like one example, but like, we really do, like, we fail every day mm-hmm. and that's okay. And we're not our best every day. And that's okay. Like, that's so human. Like who is their best every day. 

 

Adam Sockel: Yeah. And that's the thing is like, it's not even like it's failing. It's just, you know, constantly improving things. Like I wrote by the, uh, by the time this comes out, I think it'll be out. We have a, a massive 2021 lookback report of like looking at all of the data that Pluralsight, you know, all the Pluralsight customers had over the year and like basically trends that are going on. And like, I wrote the initial report and then it went to, as you can imagine, 15 different people to edit it. And like, there's just something about, I've told myself I am never going to the version control because I don't wanna see what it started with. And I, like I said, I'm a writer, like, so I know the process of this, but I'm just like, man, I don't even remember at this point, which was my words, which was like the initial copy editor's words and which was our CMOs words. It's just like, I don't wanna know how much in my mind I failed. Cause it's not, it's not failing, it's just iterations and all sorts of stuff. 

 

Kristen Foster-Marks: So, Absolutely. Adam, are you familiar with Natalie Goldberg, the writer? She's a writing teacher. 

 

Adam Sockel: Yes, I am. Yeah. 

 

Kristen Foster-Marks: Okay. I think it was Natalie Goldberg who said that writing is a communal activity. Mm-hmm. and of course she was talking about writing poetry and writing prose, but I think that it is the same way for code. Yeah. Like it is a communal activity. And I sometimes think that, you know, it's probably easier to kind of adapt to like the code code review process mm-hmm. for folks who have a, a strong writing background because Yeah. As a writer you're used to like submitting your work and having a torn apart in a really good way. Like for a really good purpose. Right. For making it better. And it's Kim Yeah. 

 

Adam Sockel: In a way that I like to think about it from a, from a code writing standpoint is I have, I, my previous job I was in the literary world and I interviewed authors all the time and I've, I have a lovely group of friends now who are like bestselling authors and stuff, and there's two of them. I love that. Yeah. There's, so there's two of them. Kimberly Jones and Gilley Sequel, they wrote a young adult bestselling book together called, I'm Not Dying With You Tonight, and I'll give them a plug. And they wrote it together and they literally, I remember interviewing 'em the first time and I asked them like, do you guys remember if you were to go through the book? Like, which lines or who's, and they both said, I have no idea what I wrote and what Galey wrote back and forth. And to me that's what code should be too. Like if you look at it, you should know like, okay, I know I was a part of this, but like, you don't need to be beholden to like, this was my section, this was my snippet. Like it all is working together. 

 

Kristen Foster-Marks: Yes, absolutely. Are you familiar with GI Blame? 

 

Adam Sockel: No. No. But I have a feeling like I know what you're about to tell, I think I'm following the, from the naming convention Yes. 

 

Kristen Foster-Marks: So like, okay, so like we use GitHub, right? Yeah. Um, uh, as our remote repository. And uh, there's, well actually this is just a Get thing. It's not even GitHub, but GitHub has a tool where you can, you can use GI Blame really easily. Um, and again, just allows you to see who the last person to touch that line of code was. And there have been, um, movements to change the name away from Get Blame cuz it has such a negative connotation. 

 

Adam Sockel: It's like Reddit, like, am I the asshole? It's like, am I the good? It's like, oh my goodness gracious. Ok. Alright. Tangent over. I'll get back to our actual questions now. Oh, that's so funny. Um, okay, so what is a, a skill that you think tech leaders should be focused on that maybe isn't currently given enough attention? 

 

Kristen Foster-Marks: That's a really good question, and I think everyone, I think every leader would probably answer this little differently depending on what, what, what their, what the composition of their team is. And actually, it's funny, my husband and I were talking about this the other day, um, and he really thinks that individual contributors need to get better at, uh, learning how to triage and prioritize work. 

 

Okay. So as, as individual contributors, we often find ourselves in the situation where, um, you know, we're heads down on something, we've been working on this thing for four days, let's say. Mm-hmm. like two bugs come in within three hours of each other. And so now you've got three things that you could potentially be working on. You know, somebody has to make a decision about what the highest priority is mm-hmm. Right. And I think that oftentimes we rely on our managers, on our leaders to just make that decision for us mm-hmm. which is fine, but as ics we can make that job a little bit easier on our managers by making an assessment mm-hmm. um, beforehand and then coming to them with some evidence for why you think this is number one priority, why this is number two, and why this is number three. And then just asking for confirmation. 

 

Right. I'd like, I like his thought on that, but, but mine is a little bit different mm-hmm. And, um, like you, I'm a writer. Uh, so I think that, you know, this is definitely informed by my background there, but, um, I do not think that engineering leaders put much focus on developing their people's communication skills, particularly written communication skills. And, and, you know, your, your freshman comp put instructors were not bullshitting you when they said that writing is really important no matter what job you do mm-hmm. like it actually is. Right. Um, and it's really, really important in the technical sphere. Um, and I just wanna clarify, like, I'm not talking about this quote unquote having good grammar. Um, uh, actually hate that phrase you know, if you only hire programmers who like perfectly execute the grammar of standard American English, you're ignoring a lot of linguistically brilliant people for whom English is, you know, a second or a third or a fourth language or people who did not have the opportunity of early and sustained exposure to that privileged standard dialect of English. Yeah. Right. Um, there's a really good set of arguments, um, and response articles, uh, written by Kyle Williams and John mc, where they kind of dig into that debate, mm-hmm. Um, so maybe we can link those to the podcast notes. 

 

Yeah. Um, I think it's really, really interesting. Um, but, you know, to kind of, to get back to that, like, like what I'm talking about, it's not like having good grammar, but like having a good grasp of those, um, what we call super potential components of a language. Hmm. So things like cohesion, um, coherence, and even like those pragmatic language features. So, you know, those things we do with language to make sure that our message is constructed in a way that makes our listener or reader receptive to our ideas mm-hmm. and, and actually able to understand them. Right. I once had a teammate who was a brilliant engineer, um, but a very serious ramer, uh, both in writing and face-to-face mm-hmm. um, nothing he said was concise and to the point. And his written communication was just kind of particularly poorly constructed. Uh, lots of overly complex and oftentimes un grammatical sentence structures. Um, lots of unclear reference. 

 

So, you know, he would often say like, oh, this and that and those, and you were like, okay, but what does this and that and those refer to, and it's just a good lot of time to untangle what he was actually trying to communicate. And when you're trying to understand technical problems and explanations and proposed solutions, especially when production is down and everyone's like scrambling to fix it, that TROs prose just does not help at all. Right. Yeah. So I think that this engineer really could have used some coaching around just rereading what he had written with a mind toward conciseness mm-hmm. um, and coherence and clarity, uh, before hitting, hitting the send button. And, and I've seen that in like product writeups and I've seen that in Jira tickets and like, I kind of get the sense sometimes that people aren't refactoring, but they wrote, you know, we refactored and revise our code and we have to do the same with our written pros. 

 

Adam Sockel: And, um, I don't know that I'm seeing a lot of that, By the way, for everyone listening, it will not surprise everyone to know the other background in linguistic Correctly. You have, uh, another, the other extreme as well that you wanna talk about? 

 

Kristen Foster-Marks: Yes. You know, I've worked with another engineer who, again, super brilliant and a really, really good person, but every comment she left on a poll request was so clinical and direct, um, and kind of devoid of any like human emotion that, that everyone read like a tiny injunction, like a tiny order to do what she wanted you to do. And it was really off-putting and it was a little ego bruising, um, at times, to be honest. Um, I think, you know, sentiment analysis is something that most people know about these days and mm-hmm. if you had read a corpus of her code review comments through a sentiment analysis machine, like the emergency sirens would be going on, it was not good And like, we do have to be direct and to the point when we communicate with each other in a professional setting. Like, we don't wanna waste people's time by forcing them to sif through pages and pages of polite preambles and hedging. But we also need to remember that there are real people with, with real insecurities and maybe a little imposter syndrome on the other end of that code comment. So becomes especially important when you're working with, uh, new engineers, junior developers, um, folks who, you know, may not, uh, kind of be used to the idea yet that feedback that you need to change something in Recode, it's not a bad thing. Like we, like most of us know that, but when you're new you don't know that. Like, it's, it's stinks to get that feedback. So if we could just soften it with some hedges and, you know, then uh, yeah, There's a real art to that. 

 

Adam Sockel: I, I used to be, I, like my team members would come to me and say like, I have a problem with someone because I'm a, I like to joke with everyone that I tell 'em I'm a very blunt person. And yeah. That used to be extremely true. Like, I would basically say my point Exactly and I'd be like, I'm not saying it to be offensive, I'm saying it to get to the point and get the job done. I have since come to realize like, okay, Adam doing that, that cold and like, confrontational feeling way is not the way way to do it. Especially like you said, like being so far away from each other and like, it's so you, you can't get context, so you can't read sarcasm in a tweet or in a comment. I mean, even speaking of tweets, even Twitter, like if you go to a, a comment that's getting a ton of interaction now they're literally, they put like a little note that's like, just a reminder. There's a human being behind that, that handle and it's like a little thing that they've done. I don't know how helpful it's being, but at least to start, the last question I like to ask all of my guests is for like, the best piece of advice that, that they can offer. But you were adamant about this when we were slacking back and forth. You said, I will give my best advice, but I also wanna offer what's the worst advice that I've ever been given. So you can start worst or best, whichever way you wanna start, Kristen. But what is the best and worst pieces of advice you've ever been given? 

 

Kristen Foster-Marks: I had so much fun reflecting on this is, so when you, you know, kind of you, when you told me I'm gonna ask this, um, I didn't really know what the best piece of advice, like I really had to reflect on that mm-hmm. but yeah. Like worst piece of advice, I was like, oh, I know exactly. Because it's just something that comes up over and over again in, uh, I think in a lot of people's careers. Worst advice, um, I've ever gotten several times in my life is, uh, this whole like, fake it till you make it mm-hmm. thing, right? Like, I, I just think as a piece of advice that that is bullshit. Excuse my language, and, and I'm talking purely in the professional sense here, right? Like as in like, like, hey, you don't have those skills or abilities or confidence yet, fake it till you make it sister. Um, I just don't understand how that works from a practical perspective. Yeah. and I really don't understand how that makes you a good employee and a good teammate. Um, if you don't have certain skills or abilities or confidence yet, you should be honest with yourself about that and, and you should be honest with your manager so that the two of you can work together to find ways for you to acquire those skills mm-hmm. And abilities. Mm-hmm. And then the confidence follows, right? Because not only do you now have those skills and abilities, but you've got the satisfaction in knowing that you work sincerely and honestly toward acquiring them. 

 

Adam Sockel: I love that so much. Just because like, like you said, I, when people say fake it to you, make it like it can be so harmful because even just in little things, like I said in marketing, like if I'm sitting there and I, you know, say I'm just outta graduate school and my director asks me for our cerp results, like from the CERP report for our s e o and I just say, yeah, totally. And I have no idea what he's saying. If I don't know, like, it, it's so much more harmful for me to say, yeah, I totally know what a ERP is, as opposed to being like, can you explain to me what a search engine result page Yes. What that actually means. Like, can you explain to me? And then he'll walk me through it as opposed to just being like, oh, I totally got it And it just creates more problems than solutions. 

 

Kristen Foster-Marks: So, Yeah. Absolutely. And it's, and it puts you like, you put yourself in a vulnerable position mm-hmm. by raising your hand and saying, Hey, I actually don't know what that means. Yeah. But n none of our managers, uh, nobody who hires us, um, believes or expects us to have all of the knowledge and all of the skills Yeah. To be totally effective at our jobs. Like they know that we have to, we have to learn and grow towards that. Right. Yeah. Um, I know that, um, and I don't know if this is maybe somewhat specific to being a, a female engineer. Um, we probably don't wanna go there, but but I've had, you know, quite a few, um, male engineers, uh, say to me, um, when I've raised my hand and said, um, I, I don't know that I can do that without, without a little bit of help. Mm-hmm. have people say to me, oh, you should be more confident, Kristen be more confident. And I'm just like, well, no, I'm just, you know, like I'm, I'm thinking about my team here. Like, if we need to get this done in two weeks, right. But I think I'm gonna need a week just to learn about it and then another two weeks to build it. It's really in everybody's best interest for me to be realistic and honest about, about where I think I'm at. Right. Yeah. That's not a lack of confidence. That's actually confidence and, and being able to raise my hand and say, yeah, I don't know that yet. Yeah, I will, but not yet. 

 

Adam Sockel: Yeah. The, the way that I've always done it, being in marketing and having to wear so many hats is like, if I needed to write a, uh, a script for a video and work with our videographer, what I always used to do, and, and I still do now, is like I'll have a planning meeting with them and tell 'em like, here's what I have in mind. And if they say, well, how do you want it to look? I will say, I trust you to come up with a look of the design, but talk me through why you want it to look that way. Yeah. Because then I am relying on the talented person who was brought in for their talents, and I'm letting them use those talents, but I'm also learning their perspective and getting a better understanding for it. So it's just like I'm, I've grown comfortable showing my vulnerability and saying, like, you, the person who spends so much time doing this, obviously you're going to know more than I do, but can you give me some of, can I kind of sponge some of that knowledge off of you so that I can learn throughout the process as well? All right. So let's, let's do the positive side. What's, what's the best advice you've ever been given? 

 

Kristen Foster-Marks: Best piece of advice. My parents are gonna love this because it comes from them. Um, you know, they are two of the most fiscally responsible people I know and I guess this was more of a, a mantra in our household than, than anything. Um, but I remember them emphasizing to my sister and I from a fairly young age, um, if you cannot afford to buy something with cash, then you cannot afford to buy that thing. So there are some qualifications here, right? So I think this obviously doesn't apply to things like a home mortgage, Um, and there are a lot of people in the world who by forces outside of their control, cannot afford to buy even the bare essentials with cash. Mm-hmm. right? So, so this doesn't apply to them. Like that's a whole nother thing. But, but there are a lot of people making really good salaries, um, putting non-essential luxury items on credit cards. Mm-hmm. like, like, you wanna remodel your kitchen, sorry. But if you're financing that, then, then you need to back up a moment. Like, you, you can't afford a new kitchen. Yeah. You're springing for the Tesla, but now you got a $600 a month, uh, payment because you couldn't cover the thing with cash. Well, um, I'm sorry. Like go get the rav4, like, it will give you, it'll get you to work. I promise. Uh, um, so, you know, having all joking aside, um, I, I think it's really important for young software engineers, uh mm-hmm. to hear this message because they're likely right outta college, um, Macon bank, right? Like mm-hmm. software engineers get, get paid pretty well. Um, and uh, I, I've got no doubt that like it's probably really cool to have a Tesla when you're 24 but it's also cool to pay off your student loans five years early. Yeah. Um, and you know, if you can't afford to, to buy that Tesla with cash without dipping into an emergency fund or, or skimming back on your retirement contributions, then like you can't afford the Tesla. Right. 

 

Adam Sockel: I, listen, I love this. I drive a 2012 Ford focus. Yes. It's Not Cause I can't get a new car, it's because I work from home and it sits in my garage. And if I need to drive to my, my sister who also works from home, she likes to joke that, like she says, she gets roughly two months to the gallon on her car cuz she never, like, that's how often you feel. And like when I started working from home, it became the same thing. Like, I think I've changed my oil once in the past like 18 months. I'm like, why would I get a new car and pay $500 a month for it to sit in my garage? It just makes no sense. 

 

Kristen Foster-Marks: Oh my gosh. Yes. And then your insurance goes up and then like your yearly registration goes up. Mm-hmm. it's like, and who is that car for? Like, who is that fancy car for? 

 

Adam Sockel: Really Listen, Not, I, like I said, 2012 Ford Focus, whole bunch of dents and scratches. It still gets to the grocery store, into the gym when I don't want to go run. It's perfect. 

 

Kristen Foster-Marks: Love it. I love it. Well Adam, when I see you, you know, driving on the street with that thing, I will wave at you from my, from my rav4 that I plan on driving into the ground Yeah, Exactly. 

 

Adam Sockel: We're we're so, alright, well this was so, so wonderful Kristen. Thank you for joining me today. 

 

Kristen Foster-Marks: Oh my gosh, thank you for having me. This was super fun. That's super, super fun. 

Adam Sockel: You've been listening to the Perspectives and Leadership of Pluralsight podcast. For more information on how Pluralsight can help you build tech skills to drive results for both teams and individuals, be sure to visit pluralsight.com. And don't forget to follow Pluralsight on all of your social media platforms so you never miss the latest updates from the company or from our podcast. If you enjoyed this or any other episodes of our show, be sure to subscribe to Perspectives and Leadership wherever you listen to podcasts and leave us a review to help other people find us a little bit more easily. Thanks for listening. See you next time.