Performance Management With Ted Neward

Posted on Tuesday, Jun 7, 2022
Managing a team’s performance is more than just firing those who don’t behave well and promoting those that do. It’s nurturing and growing your team to help them perform at their best. Ted Neward, co-founder of Solidify/US talks about his experiencing managing the performance of software teams.


Scott McAllister: Welcome to Page It to the Limit, a podcast where we explore what it takes to run software and production successfully. We cover leading practices used in the software industry to improve both system reliability and the lives of the people supporting those systems. I’m your host, Scott McAllister, @stmcallister on Twitter.

Welcome back everybody to Page It to the Limit. Today, we’re joined by Ted Neward, co-founder of Solidify/US. Ted, welcome to the show. I understand you’ve had an eventful day.

Ted Neward: Pink elephants man, they’re flying in formation. Dentists give you the good stuff, man.

Scott McAllister: You all right there, Ted?

Ted Neward: Little numb. I had to go into the dentist this morning to have them do some work on my teeth that required a little Novocain in the corner of the mouth here. And yeah. So occasionally… But we should be fine.

Scott McAllister: All right. Well, that’s a true professional to keep an appointment with me on a day that you had some Novocain pumped into your mouth.

Ted Neward: Oh, just wait, I have to go teach a class later tonight. So, right about then it should be starting to wear off and whatever pain is there, will start manifesting itself. So students are going to come up to me and say, “Hey, Ted, about this CSS…” “What? What do you want?” Should be fun. Should be tons of fun.

Scott McAllister: Those poor students.

Ted Neward: Yeah, exactly. Fortunately, my TA is a trooper. If you weren’t doing your Page It duty thing, you would be judging projects and you would meet her. But Grishma is, she’s been a wonderful grader and she’s been very good answering students' questions as well. So if nothing else, I’ll just fall back to her and let her take care of everything and just curl into a corner in the classroom and go to sleep or something, which should be entertaining all of itself.

Scott McAllister: Is there a camera in that classroom?

Ted Neward: I probably should have figured that out a long time ago. I don’t think so.

Scott McAllister: That would make for entertaining content, Ted.

Ted Neward: I mean, aside from what you bring, when you bring a laptop in, of course everybody’s got a cell phone.

Scott McAllister: That’s true. That’s true. You could be up on the internet this evening.

Ted Neward: Ooh. Ooh. Ooh. Could I go viral? I understand from you whipper snappers, that going viral is a good thing. So us gen Xers, we don’t quite know what that all means yet. Playing up my gen X roots, the audience can’t see it, the gray in my beard here and all that.

Scott McAllister: It’s a sign of wisdom, Ted. That’s what we say. The gray is a sign of wisdom.

Ted Neward: For most people maybe, but… Well, the old saying right? That good decisions come from wisdom, you know where wisdom comes from? Bad decisions. Yep.

Scott McAllister: Well, if that’s the case, I’ve got a bucket full of wisdom. That’s for sure.

Ted Neward: You and me both, my friend. Like scheduling a dental appointment the same day you’re doing a podcast interview.

Scott McAllister: As I mentioned before, I think this is the formula for classic content for a classic episode. So thank you for joining us today.

Ted Neward: You bet.

Scott McAllister: So tell us about Solidify, your role there, what you do. I mean, co-founder is a really broad term.

Ted Neward: Yeah. Solidify, they’re a DevOps consulting company out of Sweden. I should say Europe. They’ve got a branch in Denmark as well. But it’s a boutique consulting company. And about three months ago they reached out and said, “We’re interested in opening an office in the US. Are you interested?” And I said, “Yeah, let’s have that conversation.” And the more I’ve gotten to know them, the more it really has been very, very much a meeting of similar minds. The CEO Magnus, in some cases is finishing some of the sentences, I’ve said, “Hey, I want to,” and he’s like, “Yeah, I want to do that too.” Very committed to the idea of doing training, very committed to the idea of trying to grow juniors into seniors and so forth. The founder or co-founder title is really deliberate because at this stage, just getting started, there’s a lot of stuff that you need to be doing.

In any sort of startup kind of scenario, the early players at the startup are all going to be doing lots of different things. So right now I’m working with another colleague that I’ve worked with before to get just some of the basic infrastructure in place. And then do a little bit of hiring, do a little bit of business development, do a little bit of HR. Founder seemed really like the best term to use. And the nice thing is, it is generic. And once we start growing the Solidify US office, it’ll become more apparent based on who I hire and what the needs are, what role I need to step into, or step out of as the case may be.

So if I find a really strong biz dev person, great, I’ll let them do a bunch of business development and I’ll focus on more doing some of the technical delivery management. If I find a bunch of really solid consultants, I’ll let them focus on the technical delivery and I’ll do more of the biz dev. It’s really going to be kind of based on opportunistic, what comes and take what the market gives and go from there. So, the vagueness of the title is deliberate.

Scott McAllister: Nice. I like what you said there about how you and the other founder have an understanding of growing people, of taking people from junior into senior, because that’s kind of the crux of the conversation that we’re having today. Is we’re trying to help people grow by measuring their performance or managing their performance. Talk about… What we tend to do on this show is we open the questioning with a question about myths that are real common on a certain topic. So think about myths or common misconceptions about performance management and what would you say that those are and how would you debunk them?

Ted Neward: Oh, myths of performance management. In a lot of respects, I think one of the common myths, and I’m going to leave this to scope it down to engineering management, if you’re in the sales division or marketing or so forth, there’s likely be some ven diagram overlap, but my experience is really with engineering management. One of those myths, particularly around performance management is that your job is to fire people when they don’t behave well. And your job is to promote people when they behave well. And while both of those, in some respects, that’s not a myth, you do have to do those things, so much more of the performance management is all the space in between. In many respects, the success of the people on your team is very much an equal reflection of the capability of the people on your team, as it is your ability to nurture and grow them.

I’ve certainly had both levels, prior to Solidify, I was working at Rocket Mortgage. We hired a guy for the dev rel team who just didn’t work out, was not a great fit, and we had to let him go. I had a conversation with the dev rel team leader to say, “Some of this is on us, you and me, either we hired poorly or we didn’t meet what that individual needed in order to be able to be successful at Rocket Mortgage.” Similarly, unfortunately, there’s a lot more of these examples, there’s one person I’m thinking of in particular, because she and I just talked the other day. She was a marketing intern, Alyssa Witsleben, you may have met her Scott. I can’t remember.

Scott McAllister: Name doesn’t ring a bell. Sorry.

Ted Neward: Anyway, Alyssa joined the dev rel team. She was a marketing intern at Rocket and she joined the dev rel team knowing very little in the way of technology. And she found that she absolutely enjoyed dev rel and absolutely excelled at it, did very well with it and is very excited and has seen a lot of growth in terms of becoming a developer advocate. And again, a lot of that credit goes to Alyssa, but a lot of it also goes to Woody, who was the dev rel team lead, for creating an environment in which she could thrive, in which she could ask questions and not feel stupid or shamed or anything for doing so, but also for feeling encouraged. And when I left Rocket, almost literally the moment she heard, she emailed me privately and said, “I want to keep our one-on-ones going.”

And there’s an interesting book if people are really curious as to this notion of, some of the things you do as a leader to help people grow. It’s a book called Superbosses. I can’t remember the author, but Superbosses. It’s one word, you know how in sports, particularly in the NBA and the NFL, Scott, you’d have to tell me if this happens in soccer, football as well. But we talk about coaching trees, where one coach has a number of assistant coaches that will go on to success within the professional leagues. And those are kind of what we’re talking about.

As a engineering manager, some of the best things you can do are grow people to the point where they leave your organization and go off and do great things in other places because you helped them become not just a great individual contributor, but also a great leader in their own right. And that I think is kind of the, it’s not so much the myth of, a lot of people think performance management, the team reflects credit back to you. Yes. But the much bigger issue is, how do people exit your team in some respects is almost as important or more important than how do they behave while they’re on your team. Does that make sense?

Scott McAllister: That does. And to answer your question. Yeah, absolutely. The coaching tree philosophy or way of progression absolutely happens in soccer. The name that came to mind is the manager at Manchester City right now, his name’s Pep Guardiola, and he’s legendary. He’s been in multiple European leagues, but his assistant coaches have also gone on to be great coaches at other teams. And so that absolutely happens. As you were explaining the successes and there was one person at Rocket that you had to let go. Do you think that it boils down to something like well defined expectations or what else?

Ted Neward: That helps. As it turns out, I’m in the middle of working on a course for the folks over at Educative,, if video online training is not your boat, you might want to check out the Educative folks because they do prose training, so it’s more written articles, books, et cetera. And I’m working on right now for them around performance management. And one of the things that the editor there was really kind of stressing is look, a lot of times engineering management, they want to focus around metrics because we have so many metrics in engineering, we have code churn, we have mean time between failures, we have cycle time, and all these other metrics. And there’s a couple of things to be clear, expectations are not the same thing as metrics. Metrics can help you judge the level of an expectation, but you can’t just focus on the metric because then you fall victim to Goodhart’s law, which is to say, as soon as you start holding people to a particular metric, people will optimize to that metric, not the actual thing that you’re concerned about.

And we see this all the time. 20 years ago, was it, whenever the second Bush was in office and they instituted the No Student Left Behind law, which was really focusing on test scores. What ended up happening is all these schools started putting all this time towards focusing on those test scores and the overall education experience suffered because the emphasis was around test scores. That is an example of optimizing to a metric even to the detriment of the desired expectation. So yes, expectations definitely play a strong role in this. And those expectations can often be expressed via metric. But part of it is also consistency, as a manager, if you’re on my team and we meet in January and I say, “Okay, Scott, here’s your expectations.” You go, and then we don’t talk about it again until next January, that in of itself is going to be a fail point.

Because just as with agile, the reason we do all these iterations, the reason why we do these standups and weekly releases to the customer and so forth, is to get customer feedback. Feedback is every bit as critical to the whole performance management cycle as anything else. And so, one of the things that I will frequently tell people is, look, you’ve got to be doing weekly one-on-ones with your directs. You’ve got to be meeting with them about their performance. If you’re doing annual reviews, you should probably be checking in with them specifically around performance once a quarter, but even so all along the way, you should be giving your directs feedback to say, “Hey, love what you did there. Not so fond of what happened here. Let me help you do more of what I want. Let me give you coaching to avoid the things I don’t.”

And really in many respects, I think one of the myths, particularly, because if you look at some of the books like Radical Candor and whatnot, where they say, “Hey, let me just tell you what I think,” actually the Harvard business review, couple of authors did a follow up article where they actually studied some of the Radical Candor and what they found is yeah, radical candor doesn’t work quite as well as we thought and doesn’t work quite the way we thought. Yes, honest feedback is good, but in many respects that feedback, you can’t just say this was terrible. And you can’t just say, what you need to do is X, because there’s a certain amount of assumptions that you make when you do some of this, it’s far better for you to come in and say, “I really liked what you did here. Let’s encourage more of that. And this other area where it didn’t go so well. Yeah. We’ll try again. Let’s do something different next time.”

But you really want to accentuate the positive more than you point out the negative. And I think a lot of, particularly those coming from an engineering background where we’re so accustomed to find the bug and squash it by pointing out the negatives and how to fix that. So it’s this constant wheel of improvement rather than the annual, Hey, you did great. You get a raise. Hey, you did terrible. We’re putting you on a performance improvement plan. If all you’re doing is having that performance conversation once a year, I don’t care how good the coaching, I don’t care how good the expectations, you’re failing your team.

Scott McAllister: Delivery makes all the difference. It reminds me of some advice I once received about how when you offer feedback on something, you give it as a feedback sandwich. Where you do the positive and then give them the corrective and then end up with positive. So they remember that there’s two positives in there, but then also a negative, that helps them grow to help them know that they can get a little bit better.

Ted Neward: Yeah. The drawback to the feedback sandwich is it tends to look like one of those Dagwood sandwiches. When I say that, people may not know the comic strip Blondie, Dagwood is the husband. And he would build those sandwiches that stack like 10 feet high kind of thing, where it’s bread, meat, lettuce, meat, meat, lettuce, meat, lettuce, cheese, cheese, meat, lettuce, meat, lettuce, bread. And so you get a little bit of a positive, little bit of a positive and mountain of negative. Again, all that’s really going to do is accentuate all the things that people are doing wrong. They go through a certain amount of statistical analysis that they did as part of the study for this article. In general, though, you get better results by saying, “These are the positive things. And we want to do more of that.”

And yeah, if somebody really blows it, I mean, if they come to work one day not wearing any pants. Yeah. You have to have a conversation and say, “Yeah, can’t do that. Just can’t do that.” But you get better results by showing them the things that they’ve done well and saying do more of that because it’s much more concrete. It’s much more focused. And if they don’t do something well, in some cases, just leave it be and see if it corrects on its own. Or if they’re focusing on more of the positive stuff, they’ll pick that up. This is somewhere where the art is more prevalent than the science. It’s hard to say definitively, you should always, because people not surprisingly are non-deterministic creatures and even what works well for one person one year may not work well for that same person in a different year or on a different day.

That’s one of the hardest parts about performance management in some respects is, I have to look at what just happened and I have to do a certain amount of gut check because the easy thing would be to say, “Oh yeah, Scott’s just screwing up again.” No, there may be other things going on here. Scott didn’t quite understand what I wanted. Scott didn’t have all the tools, Scott was afraid to ask for help. Scott may be having some difficulties with his family. Maybe he didn’t put as much time into this project as I would’ve liked because it turns out that Scott’s already overwhelmed and doesn’t want to say, “I’ve got too much on my plate.” There’s a lot of different reasons for that. And so you have to be a little bit of a detective to kind of probe around the edges and figure it out.

Or you hopefully build a relationship with your employee to the point where they can come to you and say, “Dude, I don’t understand what you want. I just got too much…” Whatever it is, you know what I mean? So really the accentuate the positive helps create that better relationship, creates that psychological safety. But in many cases it will also, people will gravitate towards the things they know they’re doing well. And in that sense, you’ll usually get better success out of it.

Scott McAllister: The hard part, Ted, is how you say that, it all depends basically, was essentially the crux of what you were saying there. But you can even see this in software, how we as humans, we want frameworks, we want some channeled or organized or defined way to do something and just tell us how to do it. So that sounds like performance management, it’s not a cut and dry sort of science, is what you’re saying.

Ted Neward: It’s really not. But the fun thing about your analogy, Scott, is we as humans want frameworks. Yes. But then what’s the first thing that happens. The framework made in the decision, now we talk about opinionated frameworks and how do I make a different decision than what the framework made? I mean, there are a lot of parallels between software and management and the concept of a framework is certainly one of them. Because there are a number of frameworks out there in the business world. There are some tools that are out there to try to help you with some of this stuff, OKR, objectives and key results, KPIs, key performance indicators. There are some other things from previous… There was one concept that was really popular in the nineties at a more strategic level called the balance scorecard where four questions coming from different directions to help get a more well rounded perspective.

360 reviews were popular for a while. Microsoft didn’t invent stack ranking. That was a popular thing for a while. And the thing of it is that many of these, if you don’t understand that they’re just tools, as with any software platform or framework, at a certain point, you need to know how to drill below the level of the framework. You need to know how to drill below the level of the language to understand what’s going on below there in order to be able to use it most effectively. There are times when the right thing to do is just poke at the dom as opposed to letting angular take care of stuff for you. Or write a native function in Java, or you just can’t get around it or you could, but it would cause so much more churn and you’d be creating so much more work than you absolutely need to.

Frameworks can help. But at the end of the day, these are human beings. And the more you ingest that, the more you’ll be able to discard a framework in terms of something that works better, or recognize when the framework isn’t working.

Scott McAllister: All right. Honestly, as you were describing that, described I think every software engineer’s experience with a framework, it’s amazing for doing exactly what the framework was built for, but the moment you’re stepping out of what it was intended to do, that’s 80% of your time right there, is trying to figure out how to get that to work.

Ted Neward: Yeah. Yeah. This is where from a performance management perspective, it’s helpful to, I mean, having those written expectations creates kind of a common playing field, but subject to privacy concerns, because you always have to have that, there’s nothing wrong with going to other peer managers and saying, “What do you think?” Frequently, the teams that I was leading at Rocket were interacting with other teams across the rest of the company. And it was not uncommon come review time for me to go to those managers and say, “Hey, would you mind, give me some written feedback on this individual or the team as a whole, what do you think?” Because that perspective can be helpful. And in some cases, they may see things that you are not because they have different experience or they’re seeing a different version of the person that you’re seeing.

Because like it or not, we do behave a little differently around people that have authority over us. That’s part of the reason why managers are frequently exhorted to not venture their opinion. If they are the highest ranking person in the room. It’s fascinating because I can usually now when I walk into a room full of strangers, I can usually spot who is the highest ranking person in the room because they’re the last person to speak on any particular issue. And that’s the ideal, is for them to be the last one. But if somebody says something and they’re the big boss, either what everybody else says will agree with the big boss or the big boss will say something and everyone will say, “Okay, cool, well we’re done here.” They have the authority. That’s what we’re going to do.

You are far likelier to laugh at your boss’s jokes than you would if they weren’t your boss. Getting a perspective from people who are managers, who are not the direct manager, they’re not you so they will see a different view, different perspective of the people on your team. So yeah, go talk to them and say, “Hey, I’ve got an issue here. Can you help me? Can you give me some insight, give me some thoughts.”

The other group that can actually be kind of helpful, and this is going to sound really strange, the HR team. Believe it or not, the HR folks are not the, they’re not the bad boys that are always hauling you up when you do something wrong. HR is its own science every bit as much as software is. And in many cases they will have some ideas. They’ll know certainly company policies better than you will. And they may have some suggestions. They may have some options. They’ll have a lot of different things that can help in scenarios with both performance correction and with performance reward. “Oh yeah. We’ve got some options. You could do this, that, the company sponsors these things.” “Really? I didn’t know we did that.” “Yeah. That’s exactly the kind of thing.” Getting other people involved to help you with some of this stuff can be really, really useful.

Scott McAllister: Sound advice, sound advice there, Ted. So there’s a few recurring questions that we like to always ask folks. What is one thing you wish you would’ve known sooner when it comes to performance management?

Ted Neward: The answer that first comes to mind is how to better recognize some of the signs of certain things. People that are asking for help in ways that aren’t necessarily words, certainly some of the stuff around the radical candor, how to give feedback such that you’re encouraging people to do the things you want rather than discouraging them to do the things you don’t. Those come to mind. I think one of the things that didn’t really crystallize for me until really recently is that when you get to be the boss, you often want to be, you want to be the good boss, you want to be the one that everybody enjoys working for and would work for again.

And part of that means holding people accountable. In some cases that means saying the uncomfortable thing, saying the thing that says, hey, I thought we were going to be done with this by now. What’s going on? Why is this taking so long? Let’s drill in deeper. Is it a case that we just estimated poorly? Was it a case that we had unforeseen obstacles appear? Do you not have skills that you, or not have enough skills around this particular area? What is really going on? This was the expectation. And you’re not meeting that expectation. We need to fix that. This is not, you’re now on path to be fired.

But the sooner you actually hold people to some of those expectations, the sooner you’ll actually either reclassify the expectation or identify an issue before it becomes an issue. That’s probably the biggest thing that I’m still learning to this day is where exactly to put that dial. And I think I’ve been too lenient in the past and I need to dial it up a little bit more to be, “Hey, this is what we need to do. And this is where I expected us to be and go from there.”

Scott McAllister: Yeah. Hindsight’s always 20/20.

Ted Neward: Yeah. Yeah.

Scott McAllister: So is there anything about performance management you’re glad I did not ask you about?

Ted Neward: So many things. So, so, so many things, the perf management space, I mean, the one question is really, how do I fire somebody? That’s often a question that comes up. And the short answer is not easily. Personally, I believe that if you ever grow too comfortable with firing people, you’ve lost a certain sense of humanity. You’ve lost a certain sense of compassion. And I do believe as the boss, you need to have that compassion. You need to recognize that these are people, et cetera, but it’s never easy. It’s never an easy thing to do.

And there is no mental trick. There is no phrase. There is no anything that makes it easy. My usual response is, you fire somebody by picking up the phone, calling your HR partners and saying, “I have a problem.” And hopefully you’ve done this long before you’ve had the problem because they will immediately want you to start doing the things to help avoid any sort of legal liability if you do it the wrong way. But that’s probably the one thing that I think a lot of performance management stuff tries to avoid talking about these days, because I think that’s the question that frequently gets asked is, “How do you fire somebody? How do you do it?” Badly. Every time, badly.

Scott McAllister: Yeah. I’m not sure. I’ve not been in the situation where I’ve had to fire anyone. And so, I can’t imagine what that would be like.

Ted Neward: It sucks. It hurts. And even in situations where, I mean, the person you’re firing saw it coming, knows it’s coming, doesn’t have a big deal with it, et cetera. I mean, it’s failure, for all intents and purposes, it’s failure. And I take that failure personally, because like I said, I feel that I am partly responsible for every individual that I have to fire because I was responsible for their performance. Either I didn’t enforce it or I didn’t give them the tools or something. It’s not completely my fault, but it’s partly my fault.

Scott McAllister: Yeah. It’s a heavy responsibility being in management, being in leadership.

Ted Neward: That’s why they give you the big bucks.

Scott McAllister: That’s right. That’s right. Well, Ted, we appreciate you coming on the show today, especially weathering the after effects of your dental surgery. So thank you for joining and sharing your wisdom with us.

Ted Neward: Thanks for having me and tolerating my drug induced haze.

Scott McAllister: No, I think there was plenty of good nuggets and wisdom in there. And thank you all for listening to this episode today of Page It to the Limit. And I’m Scott McAllister, and I’m wishing you an uneventful day.

That does it for another installment of Page It to the Limit. We’d like to thank our sponsor PagerDuty for making this podcast possible. Remember to subscribe to this podcast if you like what you’ve heard, you can find our show notes on and you can reach us on Twitter @pageit2thelimit, using the number two, let us know what you think of the show. Thank you so much for joining us. And remember, uneventful days are beautiful days.


Ted Neward

Ted Neward (he/him)

Ted Neward is an industry professional of twenty years' experience. He speaks at conferences all over the world and writes regularly for a variety of publications across the Java, .NET, and other ecosystems. He currently resides in the Pacific Northwest with his wife, two sons, three cats, twelve laptops, seven tablets, nine phones, and a rather large utility bill.


Scott McAllister

Scott McAllister

Scott McAllister is a Developer Advocate for PagerDuty. He has been building web applications in several industries for over a decade. Now he’s helping others learn about a wide range of software-related technologies. When he’s not coding, writing or speaking he enjoys long walks with his wife, skipping rocks with his kids, and is happy whenever Real Salt Lake, Seattle Sounders FC, Manchester City, St. Louis Cardinals, Seattle Mariners, Chicago Bulls, Seattle Storm, Seattle Seahawks, OL Reign FC, St. Louis Blues, Seattle Kraken, Barcelona, Fiorentina, Juventus, Borussia Dortmund or Mainz 05 can manage a win.