031 - Building strong tech teams

Tech companies are continuously searching for and hiring top-tier talent, but what happens after they’re hired? How do you empower them to be the best in their craft?  It starts at the top.

 

Jeremy Morgan recently lead a panel discussion on this topic with world-class engineering leaders. Among other topics, they discuss:

• Fostering growth in uncomfortable conditions
• Aligning team members around common goals
• Creating a culture of learning and psychological safety

Watch the video version of this panel discussion

Download the ebook or audiobook version of Perspectives on Technology Skill Development for free

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.

00:00:06.3 Daniel Blaser

Hello and welcome to All Hands on Tech, where today's leaders talk tomorrow's technology. I'm Daniel Blaser. Tech companies are continuously searching for and hiring top tier talent. But what happens after they're hired? How do you empower them to be the best in their craft? It starts at the top. Jeremy Morgan recently led a panel discussion on this topic with world-class engineering leaders. Among other topics they discuss fostering growth in uncomfortable conditions, aligning team members around common goals, and creating a culture of learning and psychological safety.

00:00:40.7 Jeremy Morgan

Now managing tech teams is easy but leading them is difficult. In today's ultra-competitive environment, you need your tech teams to be on top of their game, both in output and in innovation. Tech talent is a differentiator in most industries but hiring talented people on the team is only part of the puzzle. Leaders need to foster growth with a psychologically safe environment and rally their teams around common goals. So, how does a leader create a space for their teams to thrive? Today we're talking with three veteran engineering leaders to break down their approach and help their teams grow. Dragana Hadzic is an agile coach, and a consultant, and a senior manager with Levi9. Dragana, would you like to go ahead and introduce yourself?

00:01:20.0 Dragana Hadzic

Yes. Sure. Hello everyone. Well, as Jerry mentioned, my name is Dragana Hadzic and I'm a consultant. Most of my career I've been actually helping teams and organizations to succeed in their goals. So, this is something that I'm really passionate about. I'm originally also coming from a software engineering background, but most of my career I was working in a role of agile coach, leader of management teams, project and delivery manager. And yes, I'm also a Pluralsight author.

00:01:51.7 Jeremy Morgan

And we have Michael Rasmussen, who's a VP of Engineering at Sling TV.

00:01:55.9 Michael Rasmussen

Great. Yeah. Thanks for having me on. So, I'm VP of Engineering at Sling. We have about 3 million subscribers to our live TV service. I run a team of about 200 Engineering, Scrum Masters, Product Owners, Product Managers, and we are currently going through a really difficult transformation from feature teams to empowered product teams. And, really having kind of full cross-functional ownership of the entire value stream. It's a lot of hard work, but I think we're making some good progress. My previous background is actually mostly in the game industry. I worked for companies like EA and Zynga and led transformations like this there and yeah, I'm happy to be here.

00:02:38.0 Jeremy Morgan

Spencer Gardner is a co-founder and VP of Engineering at Tava Health and would you like to introduce yourself, Spencer?

00:02:47.1 Spencer Gardner

Absolutely. Yeah. Thanks again for having me on. I wish I was a Pluralsight Author. That's one of my new goals Dragana, thanks for setting the standard. Yeah. Spencer Gardner. I started Tava Health about a year ago with a couple co-founders, and we're an online mental health network that we sell as a benefit to employers to provide to their employees. Super passionate about how mental health affects all of us in our daily lives. It's a rising crisis that's really affecting everyone in this world, I feel like, and there's lots of statistics to back that up. So, it's just been an awesome experience starting this company, building it from the ground up and kind of connecting technology with helping people with their mental health. Before that I was at Artemis Health, one of the early people there, leading the product engineering team and had a great experience taking that business quite a ways and it's doing pretty well. And then I had some brief stints at Microsoft and doing some user experience design at RAIN Agency and a competitive distance runner. And so, that's something that keeps me going during the day.

00:03:56.4 Jeremy Morgan

For our first question, and anyone can answer this, what does fostering growth mean to you?

00:04:01.8 Michael Rasmussen

Well, I'll take a stab at that. I think that fostering growth, to me, means really unlocking the potential of your team. In particular engineers. There's quite a lot of data to show that some of the best insights and innovations actually come from engineers. Those that are closest to the problems that we're trying to solve. And, all too often engineering teams are feature teams. The highest paid person comes up with a list of things that they want done, and then we have to somehow how figure out how to fit that into the capacity. And, that is fundamentally the wrong way to run things. And, I think the right way to run things and the right way to foster growth is to unleash the potential of the teams, of the folks that are closest to the problems.

00:04:48.0 Jeremy Morgan

How do you foster ownership mentality among everyone? So, to really get people engaged and involved?

00:04:54.7 Dragana Hadzic

I think that basically ownership mentality is there if people are motivated. If they have the goals that are clear to them. Did they buy the goals? And, did they also have some personal, let's say, interest in achieving those goals? And, not from the interest perspective, but did they have a wish that these goals are achieved? So, basically, depending on how much ownership is there, people are getting motivated. It's a very important factor in people motivation. So, I think once we have motivation in place, that basically everything is about transparency and making enough space for people to work. And, when they have this opportunity then they will basically be triggered by that and they will achieve the goals themselves. When we don't have this element in place, then we need to think more about how to establish authority but personally, in my opinion, I'm always more for the approach to basically develop the culture where we have ownership mentality rather than establishing some more traditional, let's say, authority.

00:06:04.6 Spencer Gardner

I'll just add on to that, as well, that especially with my background and spending lots of time in younger, more scrappy sort of situations with start-ups focusing on vision and mission first. What is the kernel of this business? What are we getting at? And, in my case right now, it's improving people's mental health. Which that's a kind of an easy thing, I feel like for people to relate with and to start taking ownership of in their day-to-day engineering or product development, it might not always be as altruistic. It might be improving some business software. It might be trying to streamline other parts of someone's workflow. But at the same time, I think that, again, coming back to the core foundational aspects of why the business was founded and what the mission really is, can really help people to find ownership in a way that makes sense to them. And, if they're not aligned with that, it's going to be hard to align them with really anything in the business.

00:07:03.6 Michael Rasmussen

I think the ownership piece is so important. I think that having everybody on the team have a very clear focus, and a focus is not priority. Priority is a list of things. A focus is, like, there are two to three things that we are focused on and these are the outcomes that we really want to drive. That is where you can unlock ownership. I don't think you get ownership when you say, "Here's our list of 80 things. They're stacked rings so you know the priority". That doesn't drive ownership. Ownership is around outcomes, not output. And so, I think it is actually on the leaders. I think it's easy to say, "Hey, we need our teams to have ownership". But if there's an ownership problem, it's a management and a leadership problem. It's usually not the problem of the folks on the team. Most of them want ownership and it's actually; we have to put the structure in place and the alignment around the outcomes in place to have ownership. Otherwise, it won't happen. It can't happen.

00:08:00.9 Dragana Hadzic

I fully agree that all people want to have ownership. All people want to have purpose of their work. They want to get engaged. So yes, we just need to enable them to do that.

00:08:12.8 Jeremy Morgan

And, are there different approaches at different sizes of organizations? So, if you're trying to get your group to focus on the... Like I said, focus on the outcomes, is that a different approach, say, if you're a large company, big, large organization between small start-up?

00:08:31.8 Spencer Gardner

Yeah, it's really interesting you asked that question. So, my career started at Microsoft and then it transitioned really quickly into the very beginning stages of a start-up. And, that was a really interesting transition that I will say did come with some implications in terms of understanding what the mission of the company was, understanding what the goals really were. And, actually, one of the reasons that I felt, personally, it was difficult for me in the current team I was in at Microsoft was because I didn't feel like I had a clear path towards achieving some real objective that I felt I could really change. And, I don't think that's necessarily true for Microsoft as a whole, or big companies as a whole, but in my particular situation that was the case. But then transitioning right into Artemis Health, it was they gave me a laptop and said, "Hey, this is what we're trying to solve. Here's a laptop. Let's go do it" and that was immediately clear, and I almost had immediate ownership. If I didn't perform then the company wouldn't exist, pretty much. And, I think fostering that sort of idea amongst employees, even in a medium-sized business or large business, I think is really effective.

00:09:48.5 Michael Rasmussen

I think conceptually it's the same. I think in practice it's a lot more difficult, the larger organization you have, to scale that because what you're really trying to capture is that "Two-Pizza Team" feel of a start-up. And, I've been at a start-up and its really, really easy to have that alignment because you're all sitting right next to each other and you're saying "Hey, this is our goal" and it's on the wall and, ultimately, that's exactly what you're trying to recreate at a larger organization. It's that alignment and that ownership and the scale of the teams. Where they're the right size that they can move quickly. So, there's a lot of approaches on how to do that at a larger organization but, ultimately, you're trying to recreate that same feeling that you have at a start-up.

00:10:37.9 Dragana Hadzic

Yes. Basically, I think in a start-up it comes naturally so everyone is aware of what we want to achieve. We are all part of this, we are just doing it together and in a large organization you just need to put some mechanism or to introduce some effort into basically aligning everyone's individual contribution to the bigger picture. But there are some very successful mechanisms for that. So, I don't think there are obstacles it's just about different ways to organize things.

00:11:08.7 Jeremy Morgan

What do you define as uncomfortable conditions for engineers in your organization?

00:11:13.9 Michael Rasmussen

We're going through a lot of change right now and I think uncomfortable conditions happen when you're not taking advantage of your engineering talent. I think the way that things are and when I got here, for example, was that JIRA basically ran our business. An engineer would come in on a given day and he'd go and see what tickets were assigned to him it was a very mercenary attitude. Engineers don't like working like that. Engineers like being missionaries. They like understanding the vision. They like understanding where they're going. So, I think anytime you're working in a feature factory, or a mercenary type organization, you have to put in a whole bunch of other things to manage people, and get them excited, and get them motivated. You can unlock their intrinsic motivations by making it a missionary organization and by aligning them with the outcomes rather than output.

00:12:09.4 Jeremy Morgan

Basically, being like a firefighter that's always solving problems, things like that. That kind of stress can lead up to making things uncomfortable if I'm understanding correctly. But if you get them building features and doing things that are improving the business and trying to improve that mix, does that help make the...

00:12:30.1 Michael Rasmussen

Let me kind of just further thoughts there. You know, I think we have, for example, we have a lot of production burden. So, we have three million subscribers. We have to keep the lights on. There's a lot of work involved in keeping the systems up and running. They're very complex. They're a distributed system. It's a non-trivial problem. And so, there's just sort of that baseline level thing that has to happen. In addition to that, we have to find a way to prioritize new features and innovation and that just is a constant ongoing battle. And, I think we have to be in a position where we invest in the infrastructure, and we invest in the technology that allows us to move more quickly. And, going through that transition, it's hard. It's really hard on an engineering team.

00:13:17.1 Jeremy Morgan

When you have disruptive changes on the horizon, how do you guys prepare your teams for those changes? So, I know a lot of times, like the digital transformation, seems like it's happening everywhere. There's digital transformation and then there's culture transformations that happened at the same time, as organizations are moving from on-prem to the cloud, or they're moving to a mobile app instead of a traditional desktop app, or things like that. So, how do you prepare your team to address those drastic changes?

00:13:46.3 Spencer Gardner

I think that a really practical thing that I've done in the past is having hack days. That's getting really, really specific really quick. But I think that it's on the mind of most of the engineers in an organization. I know it's on my mind every day. I'm thinking about what's coming up next, what the new challenges are, what the new tech is. And, you read about it on your Twitter feed, or wherever you are, on your Y Combinator feed, whatever, and you see these technologies coming through and everyone's kind of talking about them but maybe doesn't have any experience using them. And, so one of the really practical mechanisms that I've used is just having a hack day or a couple days where engineers can take a business-oriented problem and then try to match it with some new, disruptive technology or some new approach to solving that issue. Just to kind of build the confidence and to get a little bit of that experience with that new concept. That's more on a practical level. There's also larger disruptive things that are happening that you wouldn't necessarily have a hack day for but that's just one idea. I think, without having to invest a ton and without having to commit to something long-term, you can just spend a couple days looking at it.

00:14:55.0 Jeremy Morgan

From my experience in tech leadership, there's always certain types of people on the team and there's usually one person that's very resistant to change and technology. And, generally that's the person that's been around the longest and knows the most about the system. So, you can't discount their opinion in there. Like, "Well, why are we chasing this new fad? And why are we chasing the new thing?". And so, I found the hack days or just let's sit down with Angular for today and build something together type of thing, helps a lot to break down those barriers and help people see this is why we're changing to this new thing. Because you usually have one person on the team that wants to do all the latest and greatest things, and then one person on the team that's like, "Why are we changing what we're doing now?".

00:15:39.4 Michael Rasmussen

And, if you're at the point where you've decided we need to make the change, there's quite a few frameworks out there for managing change but they're all some variant of starting with awareness. Starting with the why. This is why we're going to do this. Then moving to knowledge or this is how we're going to do this. And, then moving to the ability of... This is what we're going to do. We recently did a big DevOps transformation and, at the same time, we're transitioning an old monolithic system to microservices. And, there's no way we could have done this in one single hit. We had to have this constant heartbeat of starting with the awareness, this is why we're doing it and then and then moving to the knowledge. Okay, we want to enable everybody and help them get the skills necessary and develop those skills. And, then we can map out how we actually do this. And, in some instances, that it takes a little bit more time, in particular with a large organization, to go through that kind of change.

00:16:41.0 Jeremy Morgan

How much runway do you give your team to shape the approach taken with the disruptive technology as it comes in? Like, for a DevOps transformation for instance.

00:16:51.3 Michael Rasmussen

Yeah, so I can speak to DevOps. The unfortunate reality is that in some of these transformation it takes years. With larger organizations it can take years, but I think that there's some quick things you can do right away. So, if you've got a system that's legacy, like ours, and you're trying to completely automate the CI/CD pipeline, that's a lot of work. It's going to take a long time. But what you can do is, you can start changing the mentality and the culture right away, and shifting left on things like QA and Ops, and starting to integrate those teams, and say, "Hey, we have to solve these problems together. We don't get to throw this over the wall anymore. We're breaking down silos and this is our goal. This is where we ultimately want to go". So, it goes back to that same thing: we have to articulate this goal. This is where we want to go. This is how we're going to measure it and then we're going to start to give you the knowledge and the ability and the training and everything necessary to actually drive in that direction.

00:17:59.9 Dragana Hadzic

Yeah. I think it really depends on what the uncomfortable situation is and what is the current state of your teams. But maybe it sounds too simple, but I think in general we should give no more or no less time than is actually needed to make things right. So, for example, I work with a lot of agile teams and, in normal circumstances, what I'm looking at as one of the metrics is focus factor. And, I think when everything is normal, where people are productive, then I'm looking that they need approximately 80% of the time to work on their current tasks and then 20% for meetings, emails, or whatever is needed. So, this is something that is standard when everything is okay. But with any small change it can simply... People can lose focus with the additional 20% or something and if we are talking about big change, it's completely different. So, I think however time is needed, no more or no less than we actually need to make things work.

00:19:10.9 Jeremy Morgan

How do you keep your team motivated and hungry for new things?

00:19:17.1 Spencer Gardner

Maybe just a couple of specific examples I think we could talk broadly to, but I think in general it's really important to focus on small wins. It's very important that you don't celebrate only at the very end of the big project or big initiative. If you do that, then chances are that people will be burnt out by the end of it or you may not even get there. So, what one popular idea that sales teams have is that sales gong that they'll use sometimes when they make a big sale. So, I had a small gong that I got and on small releases or small updates, when we shipped the update, we would hit the gong. But that was just... The principle of it was celebrating that next step towards success and it was something that was kind of wonky, kind of funny, but also did help the team to rally around something and celebrate a little bit. Another thing at Tava, that we do, is, as important milestones in our business come up, with patient volume and with people and patients seeing therapists at a certain volume, then I've actually written some code that will actually notify us in Slack when good things happen on our system. Super small, but again during the day when you get that Slack notification that notifies you of a win for the business, that really helps keep people going.

00:20:44.6 Dragana Hadzic

That sounds fun. I think in general; these small wins are really important. I think there are two dimensions. We need to keep an eye on small things. So, this is what is our everyday work and from the other side, we need always to have this big "Why". Why we are doing it? What is the big goal? As Michael mentioned earlier. So, this "Why", or long-term goal, is very important also for teams.

00:21:13.9 Jeremy Morgan

What's the difference between communicating company goals and objectives versus having them focus on the on the "Why"?

00:21:22.3 Michael Rasmussen

So, I think if you do it right there is no difference. So, we're actually rolling out OKRs which I actually don't think OKRs are a great methodology for aligning, unless you actually have empowered product teams and the OKRs aren't going through managers but they're going through product, and you have very active managers. Otherwise, I think it's actually kind of distracting. But I think if you do a really good job of company goals than that is the "Why". And, it all ties up to... So, for us, we have a product which... We have a mission for the company, we have a product vision which gets one additional level of granularity down, that very clearly states "This is where we want our product to be five years from now" and we have OKRs which are "Here's what we're going to focus on in the next one to two years" that are very, very wide focus. Like, we want to have better engagement with our watchers for X-reason. And why? Because it leads to this. So, they're very focused on the "Why". And, then every team has their OKRs that ladder up to those OKRs. So, I think that's really, really hard to do. But I think if you do that then the "Why" and the goals are the same.

00:22:50.7 Dragana Hadzic

I think it's a bit, also, about wording and communicating is also fine. This is perfect. But for me, when I say just communicate it initially sounds as one-way street. So, you inform people or communicate this to them. And, when I think about alignment then I think about bringing everyone into agreement. And, even if these are bigger goals, long-term goals, I think that people can still develop the sense of ownership. If they can, for example, if you have an objective and then a person has an idea about initiative, how they can contribute to the objective; they're already building the ownership. And, then when we build this together, I think it's really alignment. This is the real thing but, as I mentioned, it's also about wording, communicating is also fine.

00:23:41.1 Jeremy Morgan

And so, who should create the OKRs? Should that be the engineers? Leadership? Or, kind of a combination of the two?

00:23:50.9 Michael Rasmussen

So, there's some very clear best practices around OKRs and I've unfortunately been companies where they have OKRs and they're actually pretty unhealthy. I think adding OKRs should be done with engineering and product together and they should be aligned around product teams, not managers. So, for example, I've been to places where my boss has an OKR, and then I have an OKR, but some people on my team are on product teams and then it's like, "Which OKR are you actually on?" and I think that's a mess. I think the way to do it is have, for your overall business, have OKRs and then each product team, which is focused on some sort of vertical experience, they have OKRs. And, those teams may be composed of people from different departments, but it can very quickly mushroom into something that's confusing and actually detrimental. So, I think you have to have a lot of discipline to do it right.

00:24:49.3 Dragana Hadzic

Yeah, sure. You should keep it simple, I think, with OKRs. I think they're fine. But basically, they are just a way to achieve the alignment and to bring everyone together to the same goal. So, it's one technique. Sometimes with it I use a very simple technique that is impact mapping. So, it has some similar elements to OKR, so I find that sometimes it works. But as I mentioned I think those are only, let's say, techniques. It's important what we want to achieve, we want to bring everyone together, heading in the same direction with the feeling of ownership.

00:25:25.7 Jeremy Morgan

How do you align separate departments and divisions? Like you're talking about, with product and engineering. How do you align those together if they're fairly siloed in nature? How do you get them aligned and moving towards the same set of goals?

00:25:43.9 Dragana Hadzic

Well, I think there is a structure and the culture there. So, looking at the structure, for example, in the environment where I work, so we have departments, but we also work as agile cross-functional teams where different people from different departments are in agile teams. So, in that way they all have a common goal and they have a collective accountability to deliver something. So, it's basically one mechanism of alignment between different departments. And then, when talking about company culture, it's about growing the values of openness, transparency, about simple things. As Spencer mentioned; hackathons, knowledge sharing groups, presentations, everything that brings people together around some common goals and to encourage that kind of behavior.

00:26:35.0 Spencer Gardner

Yeah. Yeah. Exactly. I think I'd also add just finding some way to foster empathy amongst departments. And, that sounds a little bit weird because a department having empathy for another department is kind of an interesting, abstract concept. But, oftentimes, I find that it's just for a manager of a department to imagine another department, that empathy sometimes isn't there. That communication isn't there and I think it's a very common misstep. It's just to not communicate, not understand what the issues of that other department's dealing with. And then, yeah, just a second when Dragana said, I think once you understand those issues and you have the empathy for the other department or there's interdepartmental empathy that's built, then you can start looking at "Oh, what projects can we do together? How can we help each other even in a small capacity to start with?". And, it starts a flywheel, I think, of productivity and communication within the business and, I don't know about the rest of you, I just really dislike the culture of one department sometimes having a competition with the other. That tends to happen sometimes. Sometimes engineers will complain that salespeople are selling ahead of the engineers or the product people. And, sometimes the salespeople complain that the engineers aren't quite fast enough, and I think it’s just really toxic to a culture and I've seen that in lots of different places. And I think that, again, coming back to empathy, understanding the issues, and then working together instead of trying to work orthogonally, then things go a lot better.

00:28:10.0 Michael Rasmussen

Yeah, at my last gig I was actually VP of Product, not VP of Engineering. So, I think that product and engineering, it's absolutely critical that they work together, and I think the best way to do that is with cross-functional teams that are fully cross-functional. That actually do own the entire value chain. So, that includes product design, engineering, QA, Ops, and includes all of the departments. And then, really, the departments are just the HR management of those teams, but that's where their actual work happens, is on those cross-functional teams. And, if they truly are empowered and they're truly aligned, with OKRS or impact mapping or whatever you use to align on the objectives, then I think that's when the magic happens because I think then they move really, really quickly. And, there's a lot of things that have to be in place as well. You have to have a platform that can support that from a technology standpoint, and you have to have the right processes in place. It's really four things. There's processes and procedures. It's culture. It's the org structure and it's technology. And, you have to have all four of them for it to work.

00:29:20.0 Jeremy Morgan

And, what kind of changes have you folks seen over the years in things like that? Like, procedures and org structures and things like that? I know personally, I've seen a pretty drastic difference, even in the last 10 years, of how organizations that I've been with are setup. What are some big changes that you folks have seen?

00:29:43.8 Michael Rasmussen

So, I started my career a long time ago, before Agile. So, when I was a software engineer, we would do completely comprehensive design documentation. So, the design process actually happened in this huge chunk before we wrote any software and then we would go in a very Waterfall manner and then write the software. And so, I think the lead time from an idea to when it actually hit customers was years. So, I think ultimately, it's all been about shrinking that lead time. And, then I've seen people that implement Agile but it's more Agilefall. They're still just doing Waterfall, and they have Scrum, and they have stand-ups, and they're not actually doing quick iterations on that whole design, build, release, measure cycle. They're actually just doing what they used to do, but they're calling it something different. And, I think the real transformation is when you truly do move into Agile teams. Truly cross-functional teams that truly do own the entire value chain. They go from releasing a couple times a year to releasing multiple times a day. And, I think that transformation, which you can call DevOps, which you can call Agile, is I think the biggest transformation that I've seen.

00:31:08.8 Dragana Hadzic

Yes. I recognize what you're saying, Michael. So, I was also working as a software engineer in more a traditional setting. I was also working as a project manager in a more traditional setting and then moved to Agile etc. And, the main difference that I see is that way back then it was more focused on processes and now it's more focused on the value, which is really great on the outcomes. So, I think it's a big step forward.

00:31:35.9 Michael Rasmussen

If implemented. I think a lot of companies say that but don't actually do it.

00:31:41.8 Dragana Hadzic

I see more and more, really, that people are really focusing on value and outcomes. I think it's just what is coming. So, everything is becoming more complex, faster, technology is advanced etc. So, it's just I think is necessity. So, I really see that in more and more environments, really people are focused on value.

00:32:03.0 Michael Rasmussen

I agree.

00:32:05.0 Jeremy Morgan

And, I think showing value is probably the easiest way to get adoption. I was a software engineer when Agile first started really becoming popular in groups and people were very slow to adapt to it. I was also in the Waterfall type groups where we'd deploy every six months. And, as soon as the results started showing up from changing certain processes, that's when the resistors were like, "OK, there may be something here".

00:32:34.1 Michael Rasmussen

And, I would say there's actually ongoing transformation that needs to happen. I think Agile, in some ways, has actually made some problems worse. There are teams that are really good at churning out a whole bunch of features. Have they actually aligned those features with customers? Are they actually doing customer discovery? Or, are they just executing on a list of whatever the highest person told them to do?

00:32:57.4 Dragana Hadzic

Yes. So, I think this is also the next thing. So, what they see is that most companies are now really good at Agile processes, delivery processes. So, teams are working in an Agile manner etc. But now, where focus is shifting more to product side. So, also to make the planning Agile, also to validate assumptions, to basically update to the goals and to adjust the goals according to what is going on in the world. So, I think that focus is shifting there, definitely, and it's a really good thing.

00:33:29.7 Spencer Gardner

From a management perspective, I think more is required. Well, maybe not more but a different set of skills is required of managers now than was, maybe, 10 years ago or 15 years ago. It needs to be a little bit more dynamic, needs to be a little less "I'm a cog in a big machine and I will just do my thing, and churn through the Waterfall of tasks". It really does require thinking differently as a manager. There's no silver bullet, of course. There's lots of things online. I'm sure Dragana knows all sort about this. Lots of discussion online about "Is Agile a silver bullet?" and there's conversation about "What's the silver bullet?". And, of course, there is none, right? It's merely an approach but it is one that seems to be popularized among the community right now. And, we're learning a lot, as an industry, about how it is helping us. But of course, the cherry on top as a manager is, you need to understand the core principles of business, and of what you're doing, and why you're doing it first, and then apply the Agile methodology, for example, to be productive.

00:34:43.7 Jeremy Morgan

So, when building teams and putting together teams, what are some specific traits that you're looking for in your team members?

00:34:55.5 Spencer Gardner

I'll just jump in first. Obviously, pretty big topic, right? We could talk probably for a couple of days or weeks about it. But one of my favorite, favorite things that I saw recently, well it's about a year ago, but it was a Tweet and it said, "Culture add is greater than culture fit". And, you could agree or disagree with it, but I saw it and I really loved it because for so many years that's been part of the conversation with hiring. Okay. Do they fit our culture? Do they fit our culture? And, I think it's not an either/or sort of thing, of course, but I really liked switching by hiring decisions and thinking about how to build a team and who to bring on in terms of "How do they add to my culture? What do they bring to the table that's going to change things up in a way that's really great?". And, if you don't have a specific reason for adding that person, if it's just to add to your head count, to fill a quota that the business from a top-down level has allocated to you then, maybe, you should think twice about what's happening. But if you can find a reason, a culture add reason, for hiring that person then I think it's a good hire.

00:36:11.3 Michael Rasmussen

I look at several things and I think culture is a huge one. I look at general cognitive ability, how smart are they? Are they going be able to solve difficult problems? Their ability to do the actual job in question, which is I think secondary to most of the others. Leadership ability, which I think is a huge one, because we're putting people in really difficult situations where they have to lead their teams through it. And, then, just like Spencer said, the culture. Are they going to be missionaries? Are they going to go after this, taking this hill and drive themselves and those around them to actually do that? I think often that passion is more important. In fact, I'll take people that have that passion even if they're a little bit lacking in their ability to do the job because I trust that they'll be able to figure that piece out.

00:37:09.5 Dragana Hadzic

Yeah. So, cultural aspects for me is also the most important. Cultural add or cultural fit? So, both but I think this part is really what makes the difference. Of course, we need to have some skills in place etc. But, for me, it's more important that person has awareness about their ability to learn and that they want to learn.

00:37:36.5 Jeremy Morgan

A mission fit over a cultural fit is basically what you guys are saying. That's one of the things that we follow here at Pluralsight also, is the passion and the mission and where people are directed is more important than anything else. How do you guys balance and prioritize things like learning time for your teams? Obviously, in technical positions, there's a ton of technical things that need to be learned and mastered yesterday. So, how do you balance that out with time actually working? Dragana even mentioned that 80% work and 20% meetings. What part of that percentage should be learning time for learning new skills?

00:38:20.2 Dragana Hadzic

What I think is learning is in those 80%. So, the only thing, for me, this works is if I treat learning time as any other working tasks on the planning horizon. So, basically, as you mentioned, if I'm deciding today whether somebody is going to learn something or deliver something concrete, some feature that is needed for the deadline, always the second thing will win. So, basically, I think it's much more easier to plan to negotiate and to prioritize learning activities if we do it from the long term perspective. So, do it in time, get the buy-in of people who are deciding about prioritization, get those priorities listed, and then to treat it as any other working tasks. Because, if we don't do so then of course we are creating other kind of problem.

00:39:23.8 Michael Rasmussen

You know, what's interesting is that nobody on my team has hit the boundary yet. I want them to push for more. I've never turned down any requests for learning, or for training, or for expanding horizons. I actually think, that at least on my team, I'm not seeing enough of it. I think people should ask for more. For example, we did test-driven development training and several engineers came and said, "We want to do a hackathon to figure out how we can transition to test-driven development". I was all for it and said, "Hey, all the rest of the teams, let's all do this". And, anybody that came to me and asked, I was more than happy to do that. I want teams to be passionate about learning and improving.

00:40:12.0 Dragana Hadzic

So, I think everyone wants that. And, I think that the people we have, the industry that we are working in, basically we are very lucky because people are very curious. They want to learn. At least this is my experience. In my whole career, most of people I work with they wanted to learn new things. They wanted to implement new things. They are sometimes motivated just by technology. So, in my experience I've never felt this is lacking. So, basically then it's about just fitting it in with some regular delivery stuff.

00:40:48.8 Jeremy Morgan

How do you create a psychologically safe workplace? This is something that I know has been brought up a lot over the last few years and it's kind of part of the DevOps thing, if you will. But how do you create a psychologically safe workplace where people feel safe to be honest with each other?

00:41:10.7 Michael Rasmussen

I think it ultimately comes down to vulnerability. So, I think we need to model that behavior and we need to own, you know... For example, we're going through this transformation and there's been a couple times when I stood up in front of the team and said, "You know what? We got this wrong. I got this wrong. I thought that this was going to turn out like this, and it didn't and I'm going to own that". But we're iterating to success together and that's okay. It's okay that I got it wrong because this is what we learn, and everybody needs to know that we're going to fail. It's just the nature of it. But if we learn from that failure and move forward then that's how we get to our best place. And the converse of that, where you're trying to find blame, absolutely kills psychological safety and then nobody wants to take any sort of risk. So, yeah, I think vulnerability is the key.

00:42:08.0 Dragana Hadzic

I would describe it as shifting the focus from the execution to learning. So, we of course do the execution but if we fail, this is fine as long as we learn from failure. So, I think this is the key. And, I think it's also important that we as leaders also show all our own mistakes, to openly share this because it just encourages everyone else to do the same. And, it's also about just simple conversation. Ask people, talk to people, actively listen. So, when people feel this kind of atmosphere then they will also feel the safety.

00:42:47.4 Spencer Gardner

I seriously just love what's been shared. Brené Brown, I don't know if you've heard of that author but maybe Michael has, talks all about vulnerability and it's just something me and my wife talk about this all the time. In a business context, in a personal context. Really great principles. Just to add onto that, our company, Tava, literally we sell a mental health benefit to employers to give to their employees. For people that are struggling. And, it has totally freed the employees, right? And, it's just becoming more and more clear, the longer I spend in this company, that just everybody has something going on. And, this is a little bit more of a personal approach but, as a manager, whether it's managing several teams or just managing a small team whatever, I think it's important to understand those facts. And, understand that, statistically, someone on your team, including yourself, is probably dealing with something. Whether it be family, or work stress, or anything like that, that they should probably get some help for. 

And, I think a specific example of what I've tried to do with my teams is with our one-on-ones. I'm a huge believer, and maybe Michael and Dragana have different opinions, but I'm a big believer in focusing on people instead of projects during one-on-ones. My least favorite one-on-ones ever, when I was kind of on the receiving end of them, was when they just talked about the business the whole time. What projects are you working on? How's it going? Are you going to deliver it? Yes or no. So, when I had the opportunity to start managing teams, I flipped it and I really just focus on the individual and I communicated specifically that I'm here to talk about how you're doing at work and love to hear about it. We don't have to talk about projects at all. And, it's fine if it came up, but that led to some really, really beneficial conversations, I think, for both parties and started to help build real friendships, honestly, at work. And, I think that's what people need. If you're spending most of your waking hours in a professional environment, you should probably have some personal connections with people that are meaningful. So, I think that can really help on the psychological safety front.

00:45:03.4 Jeremy Morgan

I'll go ahead and open this up for questions from our group here. 

When the Scrum team has contributors from different managers, how do you increase or drive the motivation of team members specific to one department that's a bottleneck of the team? For example, if Dev isn't producing when QA and BA are ahead and waiting.

00:45:21.1 Michael Rasmussen

Yeah. I think the best way to do this is what we've been talking about with ownership. If these are Scrum teams in name only, you're shooting yourself in the foot to begin with and, frankly, it's not going to be successful. But if they're actual Scrum teams where the engineers, the QA... And they're all aligned around one common goal, and that's their focus, and that's their job then it actually becomes pretty clear, pretty quickly; "Hey, we got a bottleneck with engineering" or "We have a bottleneck with QA". And, then I think you need to work those out together. If it's a resource issue, then you need to have that conversation with "Hey, we just really need more Engineers". If it's a performance issue, then you have to have those hard conversations. And, that's the flip side of vulnerability. You have to own your part but then you also have to own what everybody else is doing and ensuring that they understand what the expectations are. So, talking behind their back or smack-talking engineering like "Oh man, they never deliver a product, never gives us the requirements". That's not going to solve it.

00:46:33.3 Dragana Hadzic

I think that really the beauty of Scrum teams is this collective ownership. So, what I would do in this situation, so this is definitely something that is not a particular issue of these persons from a bottleneck department, but this is something to be discussed within the team. And, this is something to be brought to the retrospective and luckily those people who are in the team already know the solution. You just need to let them emerge the solution. So, when the team comes with some collective findings about what is the best way to deal with this problem, then I think this should be definitely propagated to the appropriate manager of a department or whatever in case the solution is related to that department. Maybe the solution is completely different. Maybe it's just the process needs to be adjusted a bit. It can be a lot of different things. But if it needs to be communicated also within the department and the person who is responsible for this, then this is also a way to go.

00:47:33.4 Michael Rasmussen

And, I think that retrospective idea that is key. It's not about finding blame. It's not about "Oh, the engineers suck" or whatever else. It's: "Ok, what is the problem? We're not trying to point fingers. We're just trying to identify the problem and learn from it". And, any team that does that over and over again will fix the problems.

00:47:52.7 Jeremy Morgan

One thing that I've seen in the past that's worked well is having liaisons on teams. So, you would have somebody from another team come to your stand up, say once a week. So, we have five stand-ups a week and one day a week we'd have someone from database engineering. One day we'd have someone from graphic design. One day we'd have someone from product. And, each of those people would sit in our stand up and just listen. It's kind of the pigs and chickens thing, where they would just be an observer, they wouldn't take part in any of the ceremonies, but just take it in. And, then I would go to another team and take it in, and after a while that ownership starts to inherently develop to where people are like, "No, I hung out with those product teams and they're struggling with this, and this, and this, maybe here's a way we can help". Is that something that you folks have seen also?

00:48:43.9 Dragana Hadzic

Yes. Yes. I've seen this a lot. I've seen something like this. Also, because somehow Scrum Masters are always mostly oriented towards the making things work and there was a process etc. What we also sometimes do is that my colleagues are shifting, also coming to the stand-ups of different teams etc. Just somebody who is completely from different context comes and sometimes instantly can see something that team is struggling with, or something like that. But also, in some scaling environments we go even a step further. For example, in LeSS environment you have a concept of "Travelers" where you borrow a team member from another team for one iteration or two iterations or something like that. And, then basically you can have their feedback. You can learn some additional things that maybe you do not have enough competence in your team to do that. But then you gain that knowledge etc. So, there are some nice mechanisms around it.

00:49:46.8 Michael Rasmussen

I think there is also a reason why the most successful teams are small, two pizza teams and they're co-located. Just because of the way human beings are. If we know the person, it's very... If we don't know the person it's easy to revert to us versus them and, ultimately, most team issues are people issues. And, just the very act of being co-located, and actually knowing the person, and actually caring about that person as a person, I think that's 70% of the battle to make a team successful. And, it's really easy if they're in a different location and you don't actually know them, and you've never met them. It's easy to think that they suck in some way that or that they're not giving you what you need, when it's usually actually not the case at all.

00:50:44.5 Dragana Hadzic

But what I do when I work with distributed teams, so I almost always from time to time bring people together. So, people just travel to the same location and then spend maybe one iteration, or let's say quarterly they meet for the release planning or something. And, then you have this bond develop that it's much smoother later to work online.

00:51:09.1 Jeremy Morgan

What's your opinion of the impact of the human aspects of machine learning and automation becoming more important? How does an organization deal with this from a cultural perspective?

00:51:21.3 Michael Rasmussen

Well, I can speak to automation actually, and machine learning. We're doing quite a lot there. I view automation and machine learning as freeing up the humans to do the interesting work. So, I've got a large QA team. I want them to do qualitative testing. I want them to really understand the customer. I don't want them to find something that a machine can find. At the same time, I want to use machine learning to create a better curated experience for our customers in a way that the humans can't. But it's ultimately about curating, and concentrating, and focusing the best value which comes from the humans. So, that's what I view machine learning and automation as. It's about focusing that effort so that you're getting the most out of your most valuable assets, which are the folks that work on your team.

00:52:20.7 Dragana Hadzic

I think that impact is positive, in my opinion, because people do the work that is more interesting etc. If you look, for example, at the QA teams. They shift from some boring, repetitive work to making more abstract things, to creating some frameworks to do automation and I think people love it. So, people in technology just love to learn and love to experiment, so I think it's a good thing.

00:52:50.6 Spencer Gardner

I'm torn in two directions. One direction is to think about the Sci-Fi and articles that I've read, about autonomy, automation, and machine learning, and AI. It's something that, in the cultural zeitgeist, is extremely popular and is on everyone's minds. But then the other direction was, well, how does it affect my business? And, how does it affect the day-to-day of my people? And, I think the answers that have been given already are great. Maybe I would add, within the context of a business it seems like it... Maybe the question was geared around, "Oh, what happens when automation upends the work of people in the business? What happens then?". I think that's a pretty common sentiment and question that we're wrestling with as a society, honestly. So, I won't make any statements or any predictions there but I think that in a business context, you automate what you can and if you can hire engineers that can automate all those things, then you won't have to hire anymore. So, it doesn't seem likely that, unless you're in a very large business, that it will super affect it but I could be wrong.

00:54:08.3 Dragana Hadzic

Yeah. I think it's also creating a range of new positions and new rules etc. If we look at the Industrial Revolution, people were breaking machines because they thought they will lose their jobs and look where we are. So, things just become more interesting. And yeah, there is a lot of new things to do. So, it's fine.

00:54:31.2 Jeremy Morgan

So, if it is a performance issue, who brings it up to who to have those tough conversations?

00:54:40.3 Dragana Hadzic

Well, I think if you have performance issue in the team, for example, and if this is not naturally brought up to the surface during the regular teamwork, something is wrong with this team and you have more issues than just this concrete performance issue. So, I think it's about making teams really, how can I put it? Transparent, open and people are smart, they know if they have performance issues. But if you're really in a situation that you have a performance issue, everybody is just silent about it etc, then definitely bring it up.

00:55:23.7 Michael Rasmussen

Yeah. I think that goes back to psychological safety, honestly. I think if there's a performance issue the sooner you bring it up, the better. And, psychological safety doesn't mean you don't have hard conversations and it doesn't mean that you're not correct. It doesn't mean that you don't say things that need to be said that might be difficult. In fact, I think it means the opposite. I think it means that you're giving direct feedback frequently. I think it's a failure of management if a performance issue's brought up that's been happening for a long time and it's a surprise. This person should know and they should be receiving coaching, and training, and whatever to either address the attitude problem or the aptitude problem, so that they can perform.

00:56:07.7 Spencer Gardner

Oh, yeah. I think early and often is really the key. I think developing emotional intelligence as a manager is something that is just so important in the workplace today. And, honestly, when we're talking about careers, and successful careers, and things like that, I think that's a great differentiator as a manager or someone who you know, you're trying to level up in your career. People love that and they can notice that in you. So, that's one piece of advice I would give is, as you learn that and as you honestly market that emotional intelligence that you are able to talk to people about hard things in a psychologically safe way. What better way to differentiate yourself?

00:56:49.2 Jeremy Morgan

The person who is most resistant is often the one who's been around the longest. Can you discuss other options you've used to overcome this? Especially when that person is great at what they currently do.

00:57:05.1 Michael Rasmussen

Yeah. I think when you're driving change, it's really important to highlight folks that are doing it right, and to find champions and evangelists. So, I think some ways that I've seen this work is take some of those folks that may be naysayers. In fact, on my team, I did exactly this. There was this gentleman that's been here on the team for a long time. We're moving to cross-functional teams and he was very vocal about: "Oh, this is just going to increase silos". I spent time talking to him, understanding his concerns, trying to understand what he thought the risks were. We looked at some data, I had him read some things. He's now our biggest proponent. He's now the one that's driving it. So, I think if they're true leaders and they really want to move in that direction and achieve that vision, I think you can co-opt them and use them to drive the vision.

00:57:58.7 Dragana Hadzic

Oh, I agree with Michael and I also want to point out something. So, I think it's very important if you have somebody who is resisting a change or giving any kind of resistance that is not desirable, that it's very important to understand why. So, we should really build empathic relationships with our employees. So, sometimes you can also get surprised, because if you speak to somebody and if you really speak about that "Why" maybe you will discover that you have some blind spots. Maybe this person sees something that other people do not see. Or, reasons are completely personal, and they just want to resist the change. But when you have this answer to "Why" it's very important. It's a starting point for moving on and, as Michael mentioned, later this person can be actually somebody who is leading the change in the end, if you come down to the same ground.

00:58:54.7 Spencer Gardner

Yeah. They also maybe, in some cases, may feel threatened by someone who is potentially younger, faster, newer, knows all the latest, greatest, hottest tech or whatever. I think that can definitely happen too, where it's a little bit of defensiveness just because they don't... They feel a little bit intimidated, maybe, by somebody on the team or the makeup of the team. In which case I think again, going back to Dragana, I think it's just understanding why they feel that way. And, if you do then I think it's fine to focus , say "Listen, you might not know the next minor version, what's included in the next minor version of a software package and how we can use it or something. But you do have this experience that we can leverage. And, how can we balance your skills with other people's skills?" and really make it a win for them, instead of a comparison and it's a win or lose.

00:59:51.5 Jeremy Morgan

Yeah. It's oftentimes they're the most passionate also. They may be resistors but at the same time they're often the most passionate so, yeah, that makes a lot of sense. Trying to challenge them and channel them into being an advocate. 

My company has some challenges with implementing OKRs. The team understands the value, but it's become a burden or an afterthought. I would like to understand more about how to use impact mapping.

01:00:21.6 Dragana Hadzic

I can explain in short terms. So, impact mapping is about understanding business goals, understanding who are the main actors to achieve the business goals, and what are the deliverables that are related to that? And then, what are the assumptions behind it? Once you have this map in place, then you validate assumptions and you update it regularly. But actually, how this is related to OKRs? So, in the same way that OKRs have connections to each individual goal with company objectives and goals, also with impact mapping you have the goal of the product. You have the deliverables that will help to achieve these goals, and then you have individual assignments of teams. So, here we are more talking about collective assignment, team assignment rather than individual assignment, but in the organization, you can easily relate this to people, personal plans etc. So, it's more simple and you can Google it. It's a simple technique that I think is very nice.

01:01:31.0 Michael Rasmussen

One good thing about impact mapping is that it maps directly down, ultimately, to feature ideas. Because, you're like "If I can get this actor to have this behavior, I know it will impact this goal". So, I think it helps you focus your hypotheses around features.

01:01:49.0 Dragana Hadzic

And, it's dynamic. So, you continuously validate assumptions behind. So, impact mapping just accepts that our approach to achieving the goals is something that can be changed. Goals, of course, also. And, then if you want to connect it with teamwork, it also very nicely fits with user story mapping, which is another technique for Agile teams to basically create their backlog. But it fits nicely together because impact mapping is more on high-level. It gets you to the level of deliverables that are pretty much still abstract. And, then you can combine this with user story mapping which brings it down, really, to product backlog items of teams.

01:02:42.9 Jeremy Morgan

Very interesting, I'll have look at that some more. So, do you folks have any final thoughts you want to share with our audience before we wrap it up?

01:02:52.8 Michael Rasmussen

I think that there's a lot of changes happening in the industry. I think everybody's trying to move towards outcomes. I think there are ways you can figure out if the company that you're interested in, or if your company, is really approaching this appropriately. I think there's ways to be change agents to drive some of these changes. I think it's critical that we move to customer-validated outcomes over outputs.

01:03:28.8 Dragana Hadzic

If I can give one final thought. That after all that we discussed, I think that in general we've also touched upon some techniques and approaches and things like that, but it's all about people. So, whatever you want to achieve, just speak to people. So, it's about transparency and openness. And, after all years that I spent in my career, this is something that is always true. So, it's always about people and their happiness and, basically, being open to your team.

01:04:09.2 Daniel Blaser

Thank you for listening to All Hands on Tech. You can find show notes and more info at pluralsight.com/podcast. If you're interested in watching a video version of today's discussion, we'll include a link to that in the show notes. If you're interested in reading or listening to our recently released book, "Perspectives on Technology Skill Development", we've included links in the show notes to access the book for free. Thank you and have a great rest of your day.