074 - Removing roadblocks for your dev team with Kim Burgaard, Rodney Cox and Axel Robinson

Jeremy Morgan chats with the Director of engineering at Fernish, Kim Burgaard; VP of engineering at Via, Rodney Cox; and Engineering Manager of business solution and implementations at T-Mobile, Axel Robinson. Together, they’ll dive in to help you better understand developer productivity.

If you enjoy this episode, please consider leaving a review on Apple Podcasts or wherever you listen.

Please send any questions or comments to podcast@pluralsight.com.

Jeremy Morgan:

Hello, and welcome to All Hands on Tech, conversations with top voices in tech. I'm Jeremy Morgan. Thanks for joining me again on All Hands on Tech. I recently led a panel with three top engineering managers, and that's what we're sharing today. The panelists were Kim Burgaard, Director of Engineering at Fernish, Axel Robinson, Engineering Manager of Business Solution and Implementations at T-Mobile, and Rodney Cox, VP of Engineering at Via. Together, we talked about how tech leaders can help developers be more productive. We talked about what productivity means and what kind of goals to shoot for. We talked about removing roadblocks for developers and helping them reach their full potential. So let's jump right in.

So today we're going to talk about developer productivity. Now the never-ending need to quickly ship code and update products can be daunting, and developers are always facing that drumbeat of deadlines. So there's something that you can do to combat this issue. Helping your team understand the roadblocks that are holding up their productivity and realizing their untapped potential is critical to sustainable success. So today, I'm going to be talking with Kim Burgaard, who's VP of Engineering at Via, Rodney Cox, who's Engineering Manager of and Business... or sorry, Engineering Manager of Business Solution and Implementations at T-Mobile, and Axel Robinson. And together, we're going to dive in and help you better understand developer productivity in these areas. So how's everyone doing today?

Axel Robinson:

Fantastic.

Rodney Cox:

[crosstalk 00:01:36].

Jeremy Morgan:

Awesome. So we can kind of start with intros. We'll start with Kim, if you want to just tell us a little bit about who you are and what you do.

Kim Burgaard:

Yeah, sure. Thanks. So yeah, I'm Director of Engineering at Fernish, which is a startup based in LA. We call it Furniture as a Service, where you can rent high quality furniture at a low monthly rate and with full flexibility. And I have, at this point, a pretty long career in software engineering, having done almost 30 years of it. I've been in big corporate defense kind of settings and tiny startups. When I started at Fernish almost three years ago, I was the sixth or the seventh employee in the office. And since then, we've grown to... I think we're about 50 now at the headquarters.

Jeremy Morgan:

Oh, wow. That's awesome. So next, Axel.

Axel Robinson:

Hey, guys. First and foremost, very happy to be here today. Been looking forward to this call for the last few weeks. So Axel Robinson here, Manager of Business Sales Support and Implementation at T-Mobile. In a nutshell, what we focus on is providing a world-class onboarding and implementation experience to our customer. My background is also in engineering, but more so on the business side of things as well. But also, I would like to mention that everything that I'll be discussing on this call today, it's not a reflection of my company but more of my own personal views and opinions.

Jeremy Morgan:

Okay, awesome. And Rodney.

Rodney Cox:

Hi, guys. I'm going to echo on what Axel said in saying that it's a pleasure to be here. A little bit about myself, I'm the VP of Engineering for a startup called Via. We do e-commerce marketing technology specifically for Shopify stores. We have a tool that generates a mobile app for your Shopify store in a drag and drop format, as well as very targeted SMS marketing. I actually started at Via about two months ago. My previous experience was in a company called RiskRecon. It was a startup. I was the third employee there, spent five years there as we went through our series A and series B until we were acquired by Mastercard in January of 2020. I kind of went through the integration process at Mastercard, and then I found an awesome opportunity here at Via, so.

Jeremy Morgan:

Awesome. So we'll start out with the first question. And we kind of go in a round-robin, but if anyone wants to jump in, the very first question is about productivity. And it can mean many things to many people, of course. So let's start with your definition of what productivity is as a developer. And Kim, we could start with you.

Kim Burgaard:

Sure so I've been through many iterations. So thinking about that is that, back in the very early days, there was a lot of talk about SLOCs or source lines of code. And then for a while, everybody was talking about points. But what we really kind of zeroed in on our team is talking about features. At the end of the day, the reason why we're here as software engineers is to produce, implement features for the company to meet the company's goals, right? And so the only thing that really matters is the number of features that we push through. So the metrics that we're collecting to look at the productivity is, how many features are we pushing through? And yes, some features are tiny, and some features are weeks long or even month-long, behemoths [inaudible 00:05:42].

But on average, we have a pretty good sense that rolling average over a couple of months, we tend to be able to see, are we doing good? Does productivity appear to be dropping? Or are we, for whatever reason, doing everything right, and it's increasing? And to me, for this company, for where we are right now, that feels like the right measure because up until then, we were using points, but [inaudible 00:06:12] an increasing awareness that points can be very arbitrary, right? You can have two [inaudible 00:06:19] or [inaudible 00:06:20] in the same company, and yet they have very different philosophy metrics in terms of points, right? So we've found that measuring features for completion and measuring how long it takes for those features from when you start working on them to then in production, that's the best metric that we have. And really, that's the one thing we should focus on.

Jeremy Morgan:

Yeah, absolutely. So Axel, what is your definition of productivity?

Axel Robinson:

Yes. That's a very intriguing question. So I'm going to start by saying what is not productivity. Right? So I think we often mistake or confuse business for being productive, right? So at the very core, productivity is one's ability to maximize time. So how can you maximize your time within a given task? So at the very core, that's the way that I look at productivity, one's ability to maximize his or her time.

Jeremy Morgan:

Awesome. Yeah, that sounds great. And Rodney.

Rodney Cox:

Yeah, I like both those answers. And when I think about productivity, I think in engineering, it's very easy to get caught up on commits, how much codes pushed out or features. But I really think it's important to tie engineering culture and goals to the business' goals. And so as I look at productivity, I think it's very important to say, of the code that was pushed this last week, what impact has it had on the bottom line of the business? What extra deals were able to be signed? What customers were retained? And so it is a little harder to measure in terms of at a per developer level, how much value they added. However, I think there are ways to correlate it back through how quickly features are completed, and you can tie dollar value to the features that were done and you know what developers worked on that feature.

Jeremy Morgan:

Yeah, absolutely. And so all three of you have kind of touched on releasing features as a part of that. And so part of that is a reduced cycle time, right? So we used to develop software months at a time and have big cakes and great six months has passed, and now we're doing the new big version. And we've kind of moved away from that. So what are some ways to improve cycle time and therefore improve productivity? So what are some kind of key ways to reduce that cycle time from idea to feature that's on the customer screen?

Rodney Cox:

I can take that one. In my opinion, it all starts at defining what a cycle is. You go back 20 years when something was developed, everything was waterfall in terms of project management. You have to build everything out completely before you could ever release it. And so I think being able to set a standard with your engineering team of iterative, agile development, in terms of identifying what little things can be added and quickly released, that really He says what the cycle is and kind of helps you, I'd say, have more insight and control into how quickly those cycles are executed.

Jeremy Morgan:

Yeah, definitely. Oh, go ahead. Axel?

Axel Robinson:

Yeah, I can definitely echo a bit on what Rodney said, but also adding the importance of identifying predictable issues and challenges along the way, meaning that anytime your team is going through a cycle, there's lessons learned from past experiences, but there's also predictable issues that an engineer or a manager is aware of prior to starting the project. So it's quickly identifying what those things are and creating a bulletproof, I guess, process, not only to ensure that the cycle is completed within a timeframe, and also to increase productivity because the last thing anyone wants to do is rework. No one likes that. Of course, we also want to minimize the numbers of defect. So understanding what those predictable issues and challenges can be can improve the productivity and reduce the cycle time.

Kim Burgaard:

I agree with all of that. I think, and I'm probably going to repeat myself a little bit throughout this conversation, but I think to achieve that, you need tooling, right? In order to have the best productivity, you need a efficient CI/CD pipeline so you can push code up, right? So it's also incredibly important. But you also need process, right, so that people understand what are the right things to do, one, and then you need culture that fosters communication and all the soft stuff on top of that. And so when you have all three of those, then you're in a good place in terms of productivity. If one of those is lacking, it doesn't matter that you have the best CI/CD pipeline in the world if you don't have process and communication or vice versa.

Rodney Cox:

Yeah, and I like to add on to both of the statements. Axel, you brought up a great point about challenges and obstacles that come up during a cycle. And as we go back to the question on what are foundational things we can do, I think a lot about culture, like Kim is saying, so identifying what players on your team are the type of people that can work autonomously and problem solve and work through issues without needing top-level coordination. There's only so much time in a day and so many man hours that can be done, so it's identifying those key players that can solve the problems that can overcome the challenges. I think it's super important to any team.

Jeremy Morgan:

Yeah, absolutely. And so agile was mentioned a couple of times, and Axel, you brought it up. And then Kim, you also brought up the point system. So I have a question. So when we're doing process, and we're talking about frameworks, should teams adhere as strictly as possible to a framework, say, a scrum framework or something like that when you have something, like you mentioned, points. And if we're going to go with the agile framework, and we're going to stick to it, then we have to use points. And I'm sure that all four of us probably have the exact same opinion on points. So is it better to try to follow a framework dogmatically and try to follow as much as possible? Or is it better to just kind of piecemeal pick out the things that you like from each one for your process as you go? And it's a question for any of you.

Axel Robinson:

Yeah, I can start with this one. I think there's not a one-size-fits-all type scenario. I would say is, in order to identify which framework is most feasible for your team, it's first identifying what is your end target goal. What exactly are we trying to accomplish? Because there's more than one way to get to the final destination. What is the optimal way to get there? And just knowing that can help you eliminate the unnecessary framework that could prevent your team from finishing something in a timely manner. So I would say, definitely, identifying what the end target goal is and making sure that that is clear enough so that within the framework that you guys are using, people are able to adapt along the way because adaptability within every framework is key because there are things that come along the way, especially if you're building a software or you're pushing out a product. There are so many variables that can move things, any kind of way. So being able to adapt and understand what the envision should look like, I believe that's the key.

Jeremy Morgan:

Go ahead, Kim.

Kim Burgaard:

So I think there's a time and place for many things, right, and it's really hard to talk about these things in abstract. So I like to think about it as, you really have to understand the why before you choose the dogmatic approach to something because that's the how, right? And so I think for a lot of these things, I like the guiding line, which says that, be dogmatic about your principles, but be pragmatic about execution, right, because that means that no matter what the situation is, for every different team and company, there's different things that work, right? Let's say, you have a very mixed and very inexperienced team. You might have to do a more dogmatic approach to really kind of reinforce with people, "This is why we have to do it," until they kind of get it that, it makes sense, the why, it makes sense to them, right? Whereas if you have an experienced team, and they're all [inaudible 00:16:33] and collaborators, then a very soft touch approach to it, "Whatever works for you, guys," is kind of come up with a good result.

Rodney Cox:

Yeah, and I would say one of the things that really should impact how you structure your processes is the company size and maturity. During my time at RiskRecon, starting on a very small dev team, we had to understand that processes and shipping code, product features, are both... sorry, they both have a function of man hours. So if I've got 100 hours of manpower to develop, how much time do I want spent on processes? And so with those processes, the heavier and more rigid they are, the more time they're going to take and the slower you're going to push product and add value to the business. And so as our company grew over the five years, I saw that at the very start, we were using Post-it notes on the wall for our sprints. And as we matured, we added CI/CD pipelines, and we had sprints, and we started following the more dogmatic approach. And when I eventually wound up at Mastercard, I saw that the business needs that Mastercard and the company [00:17:53], they needed to ensure that things were always working. And so they were very strict processes, and that's what helped the business continue functioning like it should.

Jeremy Morgan:

Yeah, nice. So that kind of brings me to another question of outcomes versus outputs. So how do you make the right goals to get the results you need? Because developers are always going to want to do things their own certain way, and then the business will be like, "No, you're on the wrong path. We don't care about any of that." How do you kind of align those two so that you can align to get the right outcomes versus just output?

Kim Burgaard:

I think that's the hardest part of actually what we do day-to-day as managers. At Fernish, we're very proud of our cross-functional collaboration that we do between engineers and product and product design and operations and all the other stakeholders in the business, right? And for all of that to really work, to be a successful collaborator and to succeed on goals, right, not just produce lines of codes, on one hand, we want to empower the software engineers to really have freedom to make a lot of decisions. But they also have to respect and understand the stakeholders that are there, right?

So when somebody comes in and they start working on a feature, we don't necessarily want them to start doing product thinking all over because that's not valuing and not appreciating what product brings to the table or product design. So I think, to maximize the value of what we do is really maximizing everybody's context and understanding of, what is it that we're trying to build, and how does that lead up into the company goals? And that's a challenge. I don't have a universal answer to that, but it's part of why I like going to work everyday. It's working on trying to figure out all of these things because we're all different, and they're all unique situations where you have to adapt to and try to give the developers the tools to understand and appreciate what are the pieces that are brought by everybody and how does that fit into the solution.

Rodney Cox:

Yeah, and I totally agree with that. I would also say that team structure plays a very important role on getting the right outcomes. I've heard the analogy before of cowboy coders versus ivory tower coders. And so your cowboy coders are your guys who just want to crank code out, maybe they don't like writing tests, they just want to push product. And then you've got your purists, so they want to write beautiful code and have 100% test coverage. And I think as you structure a team, it's good to have people from both sides of that, [inaudible 00:20:58] you can find a happy medium. You don't want a cowboy coder pushing code that's going to break and cause bugs to your end user. But you also want product to eventually get released. As we built the team at RiskRecon, and as I'm building this team, I think it's very important to make sure you have a lot of diversity in mindsets in the team you built.

Jeremy Morgan:

Absolutely. And Axel, did you have anything to add to that?

Axel Robinson:

No, those are all very good points. The one thing that stood out to me, as Rodney was speaking, is the importance of having a middle ground, right? From some of the developers that I've worked with is, when things are concretely defined, then you guys can meet in the middle, right, to understand the overall intent and impact of their work and how every single version of the code, or everything that's pushed out, what role does it play in the overall output of the group. So being very clear and concrete on every single step, I've learned that has significant and positive impact on the overall output of the project.

Jeremy Morgan:

Yeah, absolutely. So what kind of measurements do you all do for measuring how your team is doing? So what are some kind of high-level measurements that we're doing well or not so well?

Axel Robinson:

Yeah, yeah, I can start with this one because at least for me, anything that I look at are things that are impacting the customer, right, because we focus a lot on customer experience, and the customer voice has a huge role in how we run our business. So to your question, what do we measure and how do we measure it, at least for me, whether it's through surveys, right, through survey monthly or customer feedback not only from the happy customers, right, but also from those customers who are angry because those are the feedback that really empower us and empower me to make sure that we streamline the process, right? So if you're sending a beta version to your family, the feedback you get from them will be a lot different than if you send it to a stranger and what type of feedback they're giving you. So for us, it's really about the customer voice and the level of satisfaction they feel whenever they interact with one of our product or with any of our services.

Jeremy Morgan:

Yeah, absolutely. And so does anyone else have-

Rodney Cox:

Yeah.

Jeremy Morgan:

... [inaudible 00:24:27]?

Rodney Cox:

Yeah, I do. And it's kind of funny because just a minute ago, we were talking about points and how everyone's got a mixed opinion about points because measuring output for a development team is so hard. That's why points are so different from every single team. And so I might sound like a broken record when I talk about company size and company needs, but as I look at my team, I think there's two things that really matter. One is, how are we impacting the other business units? How quickly are we getting features out that our sales team and potential customers are requesting? And then the second is more at a micro level with team dynamics, and it's one-on-ones with team members and clear communication to understand it and view how individual tasks are going and what approaches developers are taking and kind of identifying how they're maturing and understanding our processes as they evolve because a year from now, we're going to be measuring outputs a lot different than we are today. And two years ago, I'll say the same thing.

Kim Burgaard:

I agree with Rodney. I think we're in a pretty similar place in terms of small startup that is on a continuous growth path, which means that, every quarter, situations change a little bit, which means that you also have to adapt your tactics to what you're doing. We do have some low-level metrics that are mentioned before. We keep track of how many releases do we do. We can do multiple releases each day if we want to, but there has to be features to release, right? So we also don't want to create busy work. We track the number of features, and we track how long it takes on rolling average for feature completion. But they're more kind of a back-of-the-mind kind of background awareness. It's not something that's put up in front and center at the company at weekly business review, for example.

At that point, to Rodney's point, we track all of the things that are important for the business. And as to Axel, he mentioned, a big part of that is customer happiness. Are we actually making our customers happy? Because if we're making our customers happy, then the likelihood that we're doing something right is a lot higher than if we get a lot of negative feedback on what we do. I do think there's a challenge for us as engineering leaders, I think for all of us, is that we kind of serve these organizations for then the company that serve all the other business units to meet their goals, which means that often, our goals are sort of indirect, related to what the company is doing. And unless we're building direct product features like apps, and in my case, we're building the software that's driving the business, right, but what we sell is not the software we write. What we sell is the service that has to do with furniture, right, which means that a lot of the things that really, really matters, I have to translate from, okay, we care a lot about growth in sales, we care a lot about customer satisfaction, and how does that help drive what I need to do in order for the software engineering team, right, to help the rest of the business succeed?

Jeremy Morgan:

Yeah, absolutely. And Axel started with mentioning feedback. And that's kind of where this thread has gone. How important is customer feedback these days? Because I feel like years ago in software, it was kind of, we were almost in a tower, building things, and we'll tell you what you want as far as customers goes. We'll publish these things out, and you'll take these features that we've decided what is great. And it seems like these days, customer feedback is a lot more important. So that would be my question for you all. How important is customer feedback now compared to even five, 10 years ago?

Axel Robinson:

Yeah, I think, yeah, I can definitely start this one. I would say very much. It's only because the landscape has expanded. As technology improves, more people have access to it. And I'm not sure what the exact data is, but I think every single hour, there's at least one startup that's coming up, right, so which means that there's more options for the customer, which is great. But at the end of the day, I think, whether it's Kim or Rodney, we've all worked in an environment where we get sucked into the technology. But one thing that I've learned, the customer don't care about the technology. They don't care how many lines of code you've written. They don't care what your API can do and so forth. At the end of the day, the customer wants to know, what can it do for me? What value is it adding to my everyday life? So you can have the coolest technology, you can have the most impactful code, but it's not adding value to the customer, then it's pointless. So the customer voice is very, very important to what we do in the sense that we want to build things that people use. We want to build software that simplify people life. And we want to push out products that make their life even better. If we're not doing that, then it's pointless.

Rodney Cox:

Yeah, and I think customer voice is so important. One of our VCs at my last gig gave us some great advice. And the reason why is because, as Axl was saying, every day, there's a new startup. And a new startup isn't typically a new business that's operating in an existing vertical, like, if I'm starting a dental practice, it's a very known space of, this is how you do dentistry, this is what teeth cleanings are, this is how you get to cavities. It's all very well defined. When RiskRecon started, we were entering into a space called third party risk, which was in its earliest maturity. Our salespeople were having to sell customers on the idea that they needed this product, not that this product was better than competitors. And so the VC, what he said is that you need to identify three to four customers who are thought leaders in this space and kind of let them drive where your product goes because you're solving a need. You're solving a problem for stakeholders that, in a way, where they don't currently have a product. So let those stakeholders, those people that are trying to have their problem solved, define what your product does. And so it was instrumental at RiskRecon, and it's very important to me now.

Kim Burgaard:

Yeah, I think that, I mean, that's crucial to all businesses, right, is to find market fit. And if you're trying to establish yourself in a well-understood field, I mean, you can either choose to go and do what everybody else is doing or try to redefine it, right? And as the startup we're in right now, I hope all businesses are looking at... We use NPS religiously, net positive subtraction scores, right? So we watch that every week in a weekly review. We have a business review, where we look at that. We look at, how many customers did we add, how many customers did return? I mean, I hope there was a business 101 key metrics, right, because the feedback you get from your customers is, someone then will answer surveys. But for those who don't, they will definitely tell you through their [inaudible 00:32:38], right, how your product or your service, I mean, and how you're doing, right? And so it can be frustrating at times because there might not be a lot of information in that, but it still tells you how you're actually doing as a business.

Jeremy Morgan:

So that kind of thing is relatively established how you measure your output, kind of the way that you all have explained that. So I have a trickier question. How do you measure collaboration between developers or between teams?

Axel Robinson:

That's a very good question. I think one way to measure that is ensuring that the strategic and tactic aligns with the overall vision, meaning that most of the time, when people collaborate, the first thing they wonder is, what is in it for me? What do I get out of it? So if the strategic and tactic, how to reach that end point, does not align, the collaboration suffers. So most of the time, whether you're writing in one language and then the other developer wants to write in a different language, or whether or not there's more than one way to get to the end goal, so it often becomes on, how can you bring your best to the table? Or how can we align what we both do best in a respectful manner and ensuring that we're all moving towards the same direction? So for me, for collaboration to be effective, both individual or teams need to align on the strategic end tactic to ensure a respective result in output.

Rodney Cox:

Yeah, I think that measuring collaboration is Very challenging because it's so abstract, and I think the difficulty increases as the teams grow. And not to plug Pluralsight here, but the tool GitPrime, I don't personally use it, and we haven't bought it yet, but just the idea that seems awesome the way... I remember in my last job watching pull requests that developers would push up, and there's certain people that would comment more, give more advice. And it's really easy to identify on a small team, okay, who are the people that are leaders that really understand the code that want to shape this product in the right direction? It's easy to do that when the team is small. As it grows, it's more difficult. You have to rely on mid-level managers to communicate impact in collaboration up the chain, and you're going to lose insights. And so having a tool like GitPrime would be awesome just because at a very high level, I can identify key players and key contributors with an actual quantitative approach that doesn't have bias.

Kim Burgaard:

Yeah, I think quantitative is the key word for me there because collaboration is such a wide concept, right? What does it mean to collaborate? Is collaboration a conversation? Is it actually being in the same code at the same time? Is it sharing ideas? I think it can be all of that, right, plus many, many more things. And so to me, it's a soft skill. And I think if you want to measure it, to me, I think that the right tool for where we are right now is simply just the weekly one-on-ones that we have with the engineers, right, to see how are things going because I can definitely see traps where you fall into. Well, who speaks the most? Well, that's not necessarily collaboration, right? Or who commits the most codes? That's also not productivity and collaboration.

But I think to really help the team be efficient and drive towards that collaboration is... Again, I keep reaching for the understanding, the why, which also mirrors what Axel was talking about, the strategy and tactics, right? If everybody understands why we're here, then all the other stuff would follow, the what and the how, right? So getting alignment on why is, to me, the premise that needs to be there for efficient collaboration. And then you have to use your skills as a people manager to ask the right questions and to gauge the temperature of the team. Are they collaborating efficiently? Do I need to coach and mentor people on ways to express themselves or ways to receive feedback and all the things that you need to work on a day-to-day basis to keep that team collaborating happily and efficiently?

Jeremy Morgan:

Yeah, and with the overall theme here being communication, so developers generally like to do deep work, right? So they're heads down, headphones on, just cranking out code. And they say that every interruption costs 25 minutes of time for a software developer. So how do you balance communication so that it's not annoying them and interrupting them and breaking up their flow, but still getting information across? What are some good tactics for deciding what the form of communication is like? Kim mentioned daily one-on-ones being part of that. But how do you kind of balance that, interrupting them too much versus not communicating enough?

Rodney Cox:

I recently read a book by the founder of Twilio called How to Talk to Your Developer, and he pulled out some very interesting insights about developers. A survey was done about what these developers do in their spare time. And to an everyday person, developers are these people who like to sit at their computers and write code, and they're really good at math, and they smell funny. They have all these stereotypes tied to them. So he did this survey, and it talked about how so many of these developers were guitarists or athletes and had all these diverse hobbies. And one of these is the creativity. So I think at an individual level, it's more about understanding who your team is and what works best for them. There are some individuals who, really, they want to know everything about maybe a request that's coming through. And the more they understand it, the quicker and more easily they'll be able to implement it, as opposed to having a very structured communication channel where you get 30 minutes a day to try to explain everything about a task or a feature that needs to be done, and then you end up missing things.

There's some cons to a very rigid structure in terms of communication. So I think it comes down to knowing your team and understanding what works best for them. And I, myself, I couldn't agree more about that metric you said of, every interruption is 25 minutes, because I find myself during the day getting pinged by people, helping solve problems. And I still like to write code, and I always will. And so I typically end up having to write my code after-hours because I need uninterrupted time where I can just be heads down. But I don't necessarily think all developers are that way. Some developers like that collaboration component that helps them flesh out requirements and specs and really understand the business problem.

Jeremy Morgan:

Yeah, absolutely.

Kim Burgaard:

I agree with that. I mean, it's something that I think every business grapples with increasingly. So now we have Slack and Microsoft Teams and all these instant messaging apps that unless you understand how to manage it, can take you out of your flow second-by-second as your day progresses, right? We used to worry about e-mails, but Slack is even worse to me. And so one thing that we're definitely finding is that everybody has different things that work for them, right? But the key is really to help everybody find that thing that allows them to understand, what do I actually need to do so I can focus, right? Because I recognize, for example, in my previous job, I started when we were 25, and I was able to keep up with every pull request that was put up for review. Just out of curiosity, I've read all of them, even though I was not the one who was really responsible for reviewing them.

And then at some point, I found out that my productivity had just plummeted because all I was doing was trying to catch up with what everybody else was doing [inaudible 00:42:13]. That's not my job, right? Okay, stop looking at all those pull requests and just only focus on the stuff that actually matters to me, right? And another thing that I found personal for me that works is blocking out blocks of time, where I'm like, both for myself but also for everybody else, I'm sitting like, "Hey, Kim sits down on this stuff." And another tactic that the engineers really like was having meeting-free days. So Wednesday right now is our meeting-free day where nobody's allowed to book meetings with engineers. And they really like that, and we might even expand that.

Axel Robinson:

Yeah. Those are all very good feedback and advice. I think we started the conversation, I believe the first question was productivity, right, and what does that mean to you? And one of my feedback was that, let's start by saying what is not, right, and being busy is not being productive, right? So just to tie that back to what we're discussing now is really about the ability to zoom in and being able to focus on one task at a time. We live in a society now where, for somehow, some way, there's a misconception that multitasking is a great thing. I spend hours to debunk that. It's one's ability to really zoom in and not multitask. It's a great way not only to be productive, but to improve communication, right?

And being able to block time, I think it was Kim that talked about blocking your time. So one of the advice that I often give to folks on my team is, you have to own your time. You have to own it. It's your time. You have to own it. If you need to block out two hours in the morning to do X, Y, and Z, make sure people know ahead of time those two hours are blocked for this. Block your calendar on your time. And in doing so, it allows other to know when to communicate with you and when not to communicate with you. And when it comes to developers, engineers in general, one thing that I've learned when communicating with them is really defining in simplest form what the intent of your communication is and what is the impact. I've learned that when people clearly understand the intent of your message and the impact that it has, now, as Kim said, you have empowered them to be able to make the right decision within a time frame that they have.

Rodney Cox:

Yeah, both of those comments were great, and they actually brought up great points. I love the idea of blocking out calendars. One thing we have here is little lights next to your desk that you can flip on, and it means wired in. So if you're wired, you don't get distracted. No one's supposed to come and talk to you and ask you anything. In my previous statement, I think I was thinking more theoretical high-level approaches, but there are low-level tactical things that can be done. Another one that we've done ties into what Axel was saying about what is the intent of what you're needing to talk to a developer. And so what we've done is we've created these human shields. So we've had specific people that are barriers for someone from our customer success team to talk to a developer. If you need something, you go to this person. This person decides whether it's a high enough of a priority to escalate to a developer. But if you have these human shields, they act as a funnel to take all of these potential distractions away from the development team and only feed them that impactful information that really matters if it's going to disrupt work.

Jeremy Morgan:

Yeah, that sounds great. So two of the biggest takeaways, I think, there are the meeting-free Wednesdays and the human shields. Those were some pretty good things, I think, to implement. So what are some foundational rules of creating the right environment for high performing-teams? So to kind of tie into that, the next question, are there some set rules that you have when you're creating an environment for developers?

Kim Burgaard:

So I think I can come full circle on that, right, because I started out talking about the three key things for me to have a highly productive software team, is you need to have the right tools, right, and you need to have the right processes to help guide the work that we're doing, and then you need to have the right culture that fosters that cross-functional collaboration that allows us to do more without having to explain everything up-front and kind of work our way through as a startup, what are the things that we want to do more on the fly?

Jeremy Morgan:

Yeah, does anyone else have some good foundation on rules?

Rodney Cox:

We just have a saying, move fast and don't break things. So I think it's easier said than done, but a lot of it comes down to culture. Culture is hard to [inaudible 00:48:11]know. So yeah, that's really all I have, I guess, on that one.

Axel Robinson:

Yeah. At least for me, it's really about three things, early, often, and effective, and truly understanding who your audience is, right, because based on your audience, you're able to know what kind of message to communicate. If you're talking to a SVP or the CEO of the company, he doesn't need to know all the granular detail. Keep it high-level and being able to communicate that early, often, and effectively. So those are the three things that I usually try to emphasize in addition to understanding who your target audience is whenever you're conveying a message, and do it early, often, and effectively.

Jeremy Morgan:

Yeah, that's great advice. So how is your communication styles changed since... Each of you have gotten into leadership. So gone from individual contributor, you communicate a certain way. Has it changed a lot, and if so, how, going from individual to leader?

Rodney Cox:

Yeah, I think what you communicate to a team, it really has to evolve as you grow. Specifically, like on teams I've been on, it's very often to find engineers who make enemies of the sales team or of the business because their whole thing is to write good code, and anything that's going to prevent them from doing that is a bad thing. So I would say, engineers perform so much better when you have just general positivity in your communication. Let's say, some policy change comes down from up top, where it might not be a positive change for developers, it's a matter of, how do I frame that in a positive light to kind of shield the business side from taking heat from how the developers feel? A happy developer is a great developer. So along with that, I think that constant recognition and praise are super important for a development team to keep people positive and really bought into the overall mission, which is essentially helping the business succeed.

Axel Robinson:

Yeah, and Rodney, if I can add on to what you said, you said there was shielding, right? So shielding for me, when you said that, the first thing that I thought about is being able to filter certain informations prior to that reaching your team. So if you have someone who's spending hours and hours trying to debug or trying to fix a line of code, the last thing they need is additional stress, right. So as Rodney said, you being the shield and alleviating the level of, not only information, but what could potentially stress them from performing in their job. So that's one of the way in which my style of communication has changed. It's more about knowing the time and when to convey certain information to a developer or to an implementation specialist, or to an engineer in general, because their mindsets are wired differently, and you want to minimize the level of mistakes.

Kim Burgaard:

I think that the biggest change for me, on a more personal level, is making the switch or the transition from being 100% contributor and being confident in what I do. I was happy to share my thoughts and opinions about everything, right, and gradually realized that you need to talk less, right, and listen a lot more to what the rest of the team is telling you and really be open to what is the kind of ideas and suggestions that are being put out there. And I feel that's a big part of my transition into to a much, much more people management than individual contributorship. Just like Rodney, I still like to code, but it's really, really hard for me to find those moments where I can justify my biggest value is to sit and code this right now opposed to all the other things that are on my plate, right?

We give out every employee who joins the company Andrew Grove's book about leverage and about thinking about, what does it mean to be a senior person, right? And a lot of that is thinking about what is your impact, a word that has also been used a lot by Axel in this call, right, which is understanding, of all the things that I can choose to do, what is the ones that are going to create the most value? And I think that ties into also how you communicate with the team because my biggest value is not being the one who talks all the time and tells the team what to do and what to think, but increasingly more, to listen and then help everybody else figure out how to come to agreement on the things when other people have the room and have the space to share their opinions.

Jeremy Morgan:

Yeah, that is awesome. And so we're going to take a few questions here as they come in. I do have a question here from Ryan. It says, what was the book you mentioned, Kim? That's [inaudible 00:54:17].

Kim Burgaard:

Yeah, it's written by former CEO of Intel, Andrew Grove, and it's called High Output Management.

Jeremy Morgan:

Awesome. And then was another book that Rodney mentioned earlier.

Rodney Cox:

Yeah, it's How to Talk to Your Developer or How to Talk to... either Your or... Sorry, How to Talk to Developers, something like that, sorry. But it just came out this year, and I highly recommend it. It's not just about talking to developers, it's about the technological revolution that's happened over the past 20 years and how small companies can leverage things like AWS to build a product out of their dorm room or large companies can evolve and integrate new technologies to really set themselves apart from their competitors. So it covers a myriad of topics.

Jeremy Morgan:

Awesome. And Axel, do you have a book recommendation? Sorry to put you on the spot like that, but a favorite book you've read recently? (silence) I don't know if he's able to hear. So looks like we're getting pretty close to time. Does everyone want to give just kind of a final thought on building teams and building-

Axel Robinson:

Oh, I realized I was on mute there.

Jeremy Morgan:

Sorry.

Axel Robinson:

There is a great book called, for me, it's called Redefining Operational Excellence by Andrew Miller. So that's a book I read about maybe two months ago on operational excellence, which really helped me to understand how to be the culture that can, in many ways, provide great output but also become a high-performing team, like you mentioned earlier.

Jeremy Morgan:

Awesome.

Rodney Cox:

So Redefining Operational Excellencer by Andrew Miller.

Jeremy Morgan:

Perfect. Yeah, and I think this has been a really productive discussion. And I'm really glad that everybody has touched on culture a lot because I think that, earlier, and so we've all kind of been in this game for a long time. And for the longest time, it was technology-focused, right? We need Kubernetes. We need Serverless. We need all of these different things to make our teams run well, and I really appreciate the fact that everybody here has talked about culture and how important culture is versus having all of the latest technology solutions for everything. So that's a really great takeaway, I think, for everybody watching. Does anyone have some final thoughts-

Rodney Cox:

Yeah.

Jeremy Morgan:

... that they want say about productivity and team building?

Rodney Cox:

Yeah. With team building, it's interesting because depending on the business you're in, you maybe get to build your team, or you inherit one. But one characteristic that I think is really important when building a team, and it's something I look for, is finding T-shaped individuals. And for those that don't know what T-shaped means, it means someone who knows one area of expertise just extremely well, whether it's data security or database design, but then they also have a breadth of knowledge across the other areas, whether it's networking or application design or UI/UX. And I think if you comprise a team with a bunch of people who have skill sets that are T-shaped, and you make sure that those T-shapeds overlap, with a very small team, you can have experts in every domain of your product while also having broad coverage across all of them as well.

Jeremy Morgan:

Yeah, absolutely. So Axel, Kim, any final thoughts?

Axel Robinson:

Yeah, I'll let Kim go, and then I'll take the last one.

Kim Burgaard:

Sure. I'll be quick. So I think a lot of what I do is guided by the very simple understanding why and thinking about what that means for the what and the how. And I think we can apply that to a lot of things, culture around collaboration, but also, what are we doing as a business? And what is the software engineering team doing in collaboration with all the other business units side? I think that kind of thinking helps at least inform what I prioritize and what I think about and what I talk about with and collaborate with the rest of the team.

Axel Robinson:

Yeah, and those are both very good feedback. I think for me, my final note is really aligning productivity with operational excellence and not forgetting the human side of things and how is the people that impact the change. So when thinking about productivity, two things stand out to me, operational excellence and time, and being able to maximize both in order to have a high output.

Jeremy Morgan:

Yeah, absolutely. That's great. Well, thank you all for joining me for this. This has been really helpful and really awesome.

Axel Robinson:

Thank you very much for your time.

Rodney Cox:

It has been a pleasure.

Jeremy Morgan:

Thank you.

That was a great conversation, and I learned a lot. I hope you did, too. You can see the video version of this panel on our YouTube channel at youtube.com/Pluralsight. Thank you for listening to All Hands on Tech. If you like it, please rate us. You can see episode transcripts and more info at Pluralsight.com/podcast.