Communicating Feedback to Your Team, With Miles Sterrett
Miles was a Partner at Fretless now at Bend Health, a custom software development shop that helps software companies level-up their software chops. Miles’ team specializes in coming into high-growth teams and acting as an interim software leader. He has worked with startup and scale-ups to help them overcome technical debt and build the engineering team that can help them hit their future product goals.
In this episode, we talk about ways he reduces stress, reasons to hire out of a coding bootcamp, and how to give effective feedback to your team.
Key Subjects We Covered:
- Advice for coaching junior developers, straight out of coding bootcamps
- The importance of giving negative feedback to junior engineers
- The role that organizations should play in the professional development of their teams.
You can listen to the full episode here:
Miles Sterrett thanks so much for joining us today on scaling software teams.
Yeah. Thanks for having me, Wes. I’m stoked to be here. Ready to rock.
What brought you into the engineering leadership?
I have, for about as long as I can remember – as our mutual friend Tyler Moore would put it – been a person who starts things. The more recent example would be just getting into Indy RB and taking over leadership roles there and starting Indy Hackers and that sort of thing. But it really dates back to high school. Once I realized that’s a thing that I like to do, I took over management when my then-manager left nFrame in 2010. That went okay… [laughs]
But really, you know, fast forward a bit – I freelanced for a few years after that and ended up starting Fretless with my former manager at nFrame Davey Spruce and that’s where I started deep diving on engineering management as a craft.
So Davey left, you became the manager, and then you followed Davey to Fretless. Is that the right?
Yeah something like that. So I’d been freelancing for a couple of years and when [Davey] left nFrame he was “Enterprise I.T. Manager” at Indiana University. And so when I realized that… and this goes along with being a person who starts these little communities… when I realized that freelancing means you’re a lone wolf, and I actually don’t enjoy being a lone wolf, I texted Davey and said, “Hey what if we started a thing? Like where you as far as Enterprise I.T. Manager goes at IU?”
And he was like, “Yeah. Can we start tomorrow? I’m ready.” So then as part of Fretless, I’ve been kind of able to further hone that craft, and I will probably never feel like I’m super great at it, perhaps, but being able to be interim director at places like Springbuk and Peerview Data now Olio… it’s been it’s been fun.
I’d love to zoom back – you said things went “okay” when you got thrust into that engineering management… what are some of the “okay-er parts” of that? What did you learn that you wish past Miles would have known about engineering management?
So I would say that I took a decidedly project manager-style tactic, I guess? And so it went okay. It was just me and one other person. So the good and bad there is that only one person had to suffer at the hands of possibly poor engineering management, but he seems to still like me and works for Fretless now so it’s okay.
It’s a pretty good sign. So you’re jumping around – Springbuk is a series B startup and you’ve got Peerview… Olio… you’re kind of being an Interim V.P. of Engineering. I don’t know if that’s the title that’s kind of that’s my perception. What is not so awesome about that?
I don’t want to sound like a complainer because there’s lots of aspects that I love about this and about jumping all over the place. But being a manager or a director of engineering, or what have you, at a client as well as [doing that same] thing for Fretless at the same time to the best of my abilities can be really stressful.
You know we have a belief at Fretless that we need to be at least on par if not better than your best employee in whatever role we’re fulfilling or else what’s the point of having Fretless there?
That’s pressure.
Yeah it is! And I’m lucky enough to have a partner at Fretless in Davey Spruce or otherwise I would probably have a complete meltdown. But it’s good pressure, it makes you grow and that sort of thing. So there’s positives and negatives but that’s probably the most difficult part.
So you have to be the best version and the best engineering manager. That’s the kind of pressure you put on yourself. How do you deal with that stress? It sounds like having a partner that you can talk to helps. What are some of the other techniques you’ve used to be more resilient?
I guess I [would] say letting myself play.
So you had some previous guests on the podcast talk about things – not putting yourself under the pressure of also reading engineering management articles all night, [for example]. You’ve had folks talk about getting enough sleep. I won’t claim to be great at the sleep thing. I have the tendency to go the other direction and decide that this fantasy fiction book – which tends to be my pleasure (guilty pleasure depending on your perception of that sort of thing) let’s just read this until midnight and then get up at 6 or 6:30 or whatever.
Which obviously is not sustainable for a long time but it also helps me evade some of that burnout that I think you can get by keeping yourself under that constant pressure to get better and be the best at engineering management- or whatever your craft is.
You’ve had some interesting roles mentoring a group of code school graduates. Could you kind of set the stage of what that was like?
Yeah absolutely. So I have done that in a few different ways.
So at a company called Moby – now part of Tango – I ran a three month apprenticeship program, or I co-ran this program with one of their employees. We had five people – all new development from various backgrounds but two of them fresh from a code school called The Iron Yard.
And then you know there’s been various I guess code school grads that I’ve worked with either as being a senior developer or as being the director of engineering at various places including my current client Olio and including Fretless, actually, so we’ve had a couple good school grads.
You’ve done this several times now where you’ve mentored a group of junior engineers. What have you learned about how to do that successfully?
I think what I’ve learned the most is that when you graduate from a code school – especially some of these immersive… you know… “quit your job and do this full time for three plus months” sort of code schools, you come out of that accustomed to drinking from the fire hose, as impossible as that might sound.
And that can be awesome for your manager because you were constantly thirsting for knowledge and so they can just feed you as much knowledge as possible, and you’ll still… be able to take on more. [But that] can also be somewhat intimidating as as the person trying to feed them knowledge because you never have enough – they’re always seeking more… but it’s great!
When you graduate from a code school, you come out of that accustomed to drinking from the fire hose.
— Miles Sterrett
So I feel like coming from a code school you’re so accustomed to learning so fast that you come on the job and pick things up super quick.
And of course there’s always going to be gaps in knowledge. You’re a brand new developer and if you’re employer is bringing you in right out of a code school, hopefully they’re prepared to help you fill in some of those gaps that maybe someone from some other background would already have filled.
When you’re at a startup and you have product to ship… there’s a roadmap, there’s customers, there’s cash drop dead dates. How do you balance those knowledge gaps with the need to ship?
Some of it is just making sure you’re putting those people in a position to succeed.
Whether that’s a task that you’re confident they can quickly figure out on their own or whether it’s pairing with them with someone else, or that sort of thing. I think in a lot of cases, you don’t hire a code school grad in order to further push your pedal towards the metal. You hire a code school grad as fuel for 100 miles down the road when you’re going to need it, if that makes any sense…
So we’re talking about a tradeoff between the short term and maybe medium term, effectively – it helps you go farther in the medium turn.
Yeah. A lot of times what you’re getting from a code school grad is someone who had a previous career and so they have experience they can bring to bear that someone fresh out of college doesn’t have. And a lot of times and I think a huge advantage of looking at code school grads is they could have experience in an area that required a lot of practice communicating with other people.
That is not always a thing that a lot of technical people get: is that practice communicating with other people. And I think nearly everyone that you’ve had on this podcast – nearly everyone that you would probably ask about what’s important when you’re hiring someone for an engineering role – would say, “Oh communication is super important.” And I think that’s a big advantage of a good school graduate.
When given that that tradeoff between the “go far” and “push the pedal to the metal” [stages] – and you’ve been at several different stages of companies when they’ve made this decision to hire a good coach school grad… When is the right time to hire a group of code school grads?
Yeah, I think that is a super, super difficult question, and that’s perhaps going to be different answer for everyone.
For me I think you should at least consider in your hiring process bringing on a code school grad or a very “early career developer”… when you have at least a couple senior level engineers that are willing and able to mentor.
Now, I’ve mostly hired for smaller teams and mostly hired for, we’ll say, single teams that are on the cusp of splitting into two to three teams – that sort of thing. But I like to put out job posts that are pretty general and that don’t necessarily say “I need a senior” or “I need a mid-level” or I need an “early career” developer. Talk more about your company, and what your company does, and what the business domain is and what it’s like for an engineer at that company… and then see what you get.
And sometimes you get a candidate that is so great in all the areas except for this technical area that we measure by, you know, early career, mid, and senior… and it could be worth taking a chance. You have to ask yourself at that point, “Do I have the capacity? Do I have the senior level leadership to support this person and grow them into the amazing engineer that I think they’re going to become in a couple of years?”
So I need to have at least a couple of senior engineers who are ready and willing and then they need to decide if I’m going to make that investment to grow that person into what they can become.
Let’s say I was hiring you to coach a group of early career developers. What’s something that you would do different now… versus maybe what you did when you did it for the first time?
I would tell past Miles to practice giving negative feedback. You want to give more positive than negative – you don’t want to do them at exactly the same time the classic like “sandwich” thing. It’s terrible, don’t do that.
But I tell people this in my like, “Hi I’m going to be your engineering manager here’s how I do things” speech. I am constantly trying to get better at giving negative feedback. I don’t like doing it, it feels bad. I’m the guy who likes to just give everybody a high five every day and say how great everything is all the time. That makes me feel good and makes other people feel good which makes me feel good.
But people will struggle to get better, and to correct their mistakes if they’re not being told what they’re not doing great or what their mistakes are. And so I would tell past Miles, practice that; practice giving negative feedback. Give negative feedback as close to the moment that the negative thing happened as possible. And do that regularly. I think regularly for me would still probably not be often enough because of my hang-ups about that thing, but I would help a lot of people get a lot better in that way, I think.
People will struggle to get better, and to correct their mistakes if they’re not being told what they’re not doing great or what their mistakes are.
— Miles Sterrett
So an important thing is timeliness – giving the feedback near to when the thing that could have been improved happened. What else makes negative feedback more effective?
There’s a manager tools podcast that talks about this – and I’m probably going to mess it up – but make it very concise… which as your listeners will find I am not [concise].
Yeah it’s really hard to make short letters written this long podcast.
[Laughs] Exactly. Yeah. So you know you you say, essentially, first you gotta to ask – it’s important to ask and make sure they’re open to feedback at that moment. If you just walk up and tap somebody on the shoulder… they were in the zone, they turn around and they’re angry at you… and then you give them negative feedback (which I’ve totally had that happen and it’s like “feels bad on top of feels bad”).
And then maybe that person just wants to go home for the day. You have to ask – make sure they’re open to feedback at that moment… and hopefully you’ve talked to them previously about how you want to give feedback and they understand that if they’re just not ready for that they can say, “No.” No hard feelings. And then you let them know like, “Hey when you do X it has Y negative effect, so let’s try to correct that behavior” or whatever sort of very brief corrective suggestion you might have.
And then let it go. Then you’re done. Walk away, unless they seem to not understand, or have questions, or that sort of thing. But keep it short. And then move on.
It’s so hard though, Wes. It’s so hard.
It is… You want to caveat, you want to say, “But you’re doing so great at other things.” And… it deletes the feedback.
Oh man. Yep. And I mean that helps everyone, but the early career developer out of code school developer needs that maybe more than anyone, and is probably going to be more receptive to it than anyone.
They’re in a new career and they wouldn’t have spent the money and time to go to code school if they didn’t want to be as good as possible at this thing. I mean that is a commitment that they have made to themselves. And so you’re helping them if you give them that negative feedback.
Would you be up for a role playing some negative feedback with me? I read Max Yoder’s “Do Better” workbook and I’m super jazzed on the idea of [trying] some conversations as a way to learn and get more concrete. Would you be up for that?
Yeah! Let’s try it.
Okay. So I’m a junior developer. What’s a common mistake you see early on that I might have made? Maybe I break the build, push code without getting review, etc.
Yeah… actually know what a really good one is that I think everybody can get this feedback – and needs to get this feedback early – is the scenario where you’ve started to feel a little bit confident about one area of the code and you jump in on a code review and drop a, “this is a terrible idea” or something along those lines in a text.
And maybe the person to whom you responded, if you said that to them in person in your jovial manner they’d [laugh] and everybody moves on with their lives. But that is one of the toughest ones and as I was racking my brain, I have confronted that before and failed to give the negative feedback.
Let’s try it sort of quickly. I’m head down, I’m coding, and I read a pull request earlier today from one of my colleagues. I was feeling pretty confident and I write, “This is a terrible idea. You should redo this.”
“Do you have a moment for me to give you a little bit of feedback?”
“Yeah sure sounds great.”
“So I was I was looking at your review of Tyler’s pull request and when, in a pull request you come with a lot of negativity and say “this is a terrible idea” it immediately puts the other person on the defensive and makes it difficult to have a constructive discussion about the code and about why it might not be the best idea.
“So if next time if you can just try to find a way to phrase it as constructively as possible, that would really help us have good conversations about the code. Does that make sense?”
“Constructively? It’s kind of a terrible idea… he was repeating whole sections of code. How do I make that constructive?”
“Yeah. So maybe you can say, ‘Hey, it looks like we’ve got some repetition in here. Maybe we can extract out some methods or something to reduce the repetition and make this code easier to understand and change in the future.’ That might be an example of how you could say it in a way where Tyler’s not gonna gonna feel hurt.”
That was awesome. I like role playing so we might do it again if nobody hates it.
Yeah. Hopefully that worked out all right.
What is something regarding software engineering leadership that you’ve changed your mind on?
That a good team doesn’t need hands on management.
I think I was in pretty good company regarding this belief – I think a lot of folks still believe it. But you’re starting to see some organizations that kind of seem to lean on this belief, have a very flat structure, start to create more of a leadership hierarchy.
And I totally get [the drawbacks]. With more leadership hierarchy comes more meetings, and meetings seem to be universally despised – that’s a whole other conversation that we could really dig into.
What changed your mind? What made you come to this realization that maybe hands on engineering leadership was beneficial to the team?
Certainly a lot of different things. But there’s one inflection point… that really cemented it for me a few years ago at Fretless. We had five developers, we were humming along, it was awesome. We felt awesome and within the span of about six months we lost two of them.
Which is 40 percent, so it felt pretty significant to us. We’re still friends with those folks, love them, great folks, but they left for somewhat similar reasons. And I just cannot help but wonder, if I had been having regular one-on-ones, and having conversations with them to better understand very early on kind of where their heads were at on, for instance, consulting lifestyle versus product engineering team lifestyle… or any number of other problems that could occur with an engineering team… if we were talking about those six months before they left would they have left at that time?
Would we have had them longer, would they still be here today? If nothing else, if I had known earlier, maybe we could’ve made the transition smoother for everyone involved, right?
So even things like that. Like listen, it’s software engineering, people are going to leave jobs probably around every 18 months at this point. You jump in and do your tour of duty, essentially, and then you move on to the next thing. But that doesn’t mean that thing can’t be done better; that whole transition, that whole sort of professional development and then transition elsewhere.
Yeah and losing team members is tough – like the best managers can help people become professionally fulfilled.
Thinking about being professionally fulfilled, what responsibility do you think companies have towards professional development for their team members?
I think at least some if not quite a bit. I mean, listen, I get it, but the benefit of professional balance to employees is obvious.
So we just talk about the risks for the employer, which I think is what most people worry about: “If I put a bunch of time into this employee they’re going to leave in 18 months” right? And, yeah, maybe they will. They’re gonna go and take their big full brain elsewhere, and then that big full brain is going to go be super productive somewhere else.
And if you do things right, they’re going to say how awesome it was that your company helped them get to their brain big and full. Other people are going to notice how big and full their brain is and be impressed, you know?
Or they might not leave and they might use their big full brain to make your company’s work more awesome, thereby making you more awesome and then everybody wins.
So I I feel like there is a lot of hand-wringing like, if we make them awesome they’re going to leave, or it’s not our responsibility to make you awesome. But I think in reality, if you make other people awesome you’re going to stumble into being awesome.
Just make other people awesome.
In reality, if you make other people awesome you’re going to stumble into being awesome.
— Miles Sterrett
The awesome osmosis property. I know [an Indianapolis company] that went to a conference and one of their team members used that conference to apply to other jobs. And so then they came away with a policy to not sponsor conferences in the future because they didn’t want that to happen again.
Oh wow.
So let’s say you’re the engineering manager there, and let’s say your boss is pushing back and saying, “Why would I send my team to conference when I might just lose them?” How do you advocate for that professional development?
Yeah, I think that’s the exception and… well for the other company their story is they hired this awesome person at that conference, right? [Laughs]
That’s right. That’s assuming there’s a certain symmetry to that.
But in my experience with conferences… you send your people, they are stoked at the opportunity to get to go to that conference without spending a copious amount of their own dime and going on vacation. They learn a ton. If you send multiple members of your team they get to bond and discuss and further grow one another through going to those conference talks and that sort of thing.
There is a possibility that someone’s going to go talk to other people and apply elsewhere. But if they were going to go there and apply elsewhere, and it happened to be there they were going to apply elsewhere, anyway, right?
Yeah, it was going to happen either way. So why try to hold it down?
There’s a similar story for a company that I used to work for, where they got lots of certifications for people – not software engineering but network operations and that sort of thing. And to a great extent, they required those certifications – like every year you needed to add to the list of acronyms at the end of your name if you were going to work in this department.
And there were a couple people who over the course of six months got three different certifications paid for by the company and then used their new certification to jump to a higher paying job elsewhere. And so they made the policy that if you left within like six months of getting a certification you had to pay back the cost of that certification.
But I just… I don’t get it. I mean, that’s a good way to kind of double punish yourself if you weren’t willing to give that person a promotion for the new certifications, which is probably the reason they were looking elsewhere.
And then in the future you’re going to charge people if they try to gain that promotion through the job jump? That’s gonna get out there; people are going to hear about that and then that’s gonna make your whole recruiting and hiring process more difficult. Not to mention that maybe you’re going to make people think twice about trying to make their brains bigger and fuller while still working for you.
So I’m glad you mentioned recruiting and hiring. What’s a hiring or mentoring mistake that you’ve made in the past?
Mentoring wise I think the easiest mistake to make is giving the mentee maybe even more credit for knowledge that they have than they would maybe say they want.
So as a better, more illustrative example, I feel like I’ve worked with a lot of really smart people from code schools. And they’re so smart that sometimes I forget that there is one whole piece of software engineering that they have had zero exposure to.
And so I might say, “If you could just go and write a couple of unit tests for that, that’d be great. You know probably these three public methods need some unit tests, and then yeah I think this story is ready to go.”
And because you acted like that should be a thing they already know how to do, and they could just go and kind of whip that up, they might just kind of look you and [say], “Okay. Yeah I’ll uh… I’ll do that then.
I’ll just write you a test… like that word, “just”.
Yeah. The anchor words. Actually, when I was at… Tango… They would, when you were talking about code in a code review or if you were reviewing stories for the next sprint or that sort of thing, if you used something like “just” or if you said “that should be easy”… if you used any sort of sort of anchor word when talking about the thing, they would write that anchor word on the board and write your name next to it.
And it’s essentially an “in-meeting shame” in order to try to break people of the tendency to use those terms. I always kind of appreciated that.
What are some other anchor words?
There’s one that has cropped up for me recently… it’s become our go-to joke phrase because it’s an attempt to avoid anchor words and just turn them into a longer phrase: “that should be relatively straightforward, right?”
Yes, go build a startup and raise venture capital. That should be relatively straightforward.
Yeah. I mean many people have done it, right?
Yeah it’s all relatively straightforward. [Laughs]
What role do soft skills like communication and collaboration have in your interview process.
A very large role. I would say often those are the main focus of the hiring and interviewing process for me.
And how do you get a read on those that?
That is a longer answer, actually.
Should be straightforward.
Yeah it’s relatively straightforward. [Laughs]
No, the opposite is actually the case. Arguably, I suppose, but it’s relatively straightforward, perhaps, to figure out technical ability, because at least technical ability you know, it’s technical in nature. I mean, it’s at least somewhat quantifiable.
Communication skills and collaborative skills, teamwork, all of those things…
… can be fuzzier.
Very fuzzy. All of the fuzzy. So first of, all you have to establish some sort of rubric. It’s not easy. But as you’ve said in a previous episode… an imperfect rubric is better than no rubric at all. So I have a pretty imperfect rubric for these things, or I guess a way to fashion that thing.
I’ve had a lot of help getting to my process today, including from you fine Woven folks – lots of advice and all that sort of stuff which I really appreciate. And devolves all the time, right? Like I tried to start with a list of outcomes that I would expect in the first 30, 60, and 90 days from a successful hire. So just kind of assume that you made the right hire and then they did these things.
What’s an outcome that would kind of fall under communication and collaboration mean?
Yeah that’s a great question. I’m gonna refrain from quickly digging into my Google drive for all of the documents that I have on that sort of thing.
So actually one that I really like is… something along the lines of, “Disagreed with me kind of publicly in a meeting.”
And I would understand if people would think that sounds funny but I want people to push back, and I want people to speak up in meetings and tell me when they think something is a terrible idea. As we talked about earlier, preferably in a more constructive way. Although… that’s alright because I have lots of terrible ideas all the time and we can’t make the best of whatever it is that we’re making if everybody just rolls with my terrible ideas because I have role power, right?
And so I need people to push back.
Disagree with Miles in a meeting. So that’s your objective – how do you get at that, so that they’re likely to achieve that objective?
So looking at that and some of the other outcomes we might come up to try to create competency – kind of a word or phrase that embodies whatever that attitude is…
Then from there you can take that and start to gather however it is that you might gather behavioral interview style questions that you believe will lead to sort of a positive or negative answer about those competencies.
So it’s a behavioral style question.
Honestly on this one it might be, “Hey tell me about a time that you disagreed with one of your leaders about a product direction suggestion?”
I told him in a pull request that his idea was terrible.
[Laughs] Right! And so at that point actually what you find out is maybe they they have the competency to disagree – but maybe they lack the competency to give constructive feedback, or something like that right. And so then you can kind of craft a rubric and cite supporting evidence from your interview with competency, and… behavioral interview stories or answers that kind of point to those things, that confirm or refute those competencies.
I love that lens of gathering evidence – we’ve got an objective, which is “disagrees with Miles in a meeting in the first 30 days” we’ve got a competency which we couldn’t define… maybe there’s “willingness to disagree” and “ability to do so constructively.” Maybe those are two competencies. And then we have a behavioral interview question to tell me about a time where someone exhibited those competencies, and that helps us predict whether they’re going to meet that objective. Yeah it’s simple but it’s powerful. It’s not technical, it’s not fancy. It’s questions in Google Docs… I presume that’s what we use.
Yes. And you can get you know you can dive deep on that and start doing things like, “Well these competencies are tier 1 competencies, so they’re most important.” And you kind of try to poke at… like… where is the line of, “hire [versus] don’t hire” which I think is super difficult.
It is a difficult line. There’s a line we’re all trying to figure out. That’s that’s my journey.
Right!
My guest today has been Miles Sterrett. Miles, thank you so much for being on Scaling Software Teams.
Thanks Wes. Was a good time.
