How To Provide Effective Feedback to Engineers with Lara Hogan of Etsy, Kickstarter, and Wherewithall

Ledge: Hi, Lara, great to have you on!

Lara: Thank you. It’s super to be here.

Ledge: Could you give a two-, three-minute background story of yourself and your work so the audience can get to know you a little bit?

Lara: Definitely! Before the current job I have now, I was the VP of Engineering at Kickstarter; and before that, I was an engineering director at Etsy. Along the road to get there back when I was a baby manager all the way up to the big VPE role, I realized how much I loved building teams and supporting emerging leaders.

So when I decided to go on my own, which is what I’m doing now, I really wanted to focus on the parts of those jobs that I loved the most which are coaching; mentoring; and finding opportunities for people to grow and learn management and leadership skills not just of engineering but for tons of disciplines: product, design, anything in our industry.

Since the beginning of 2018, I have been at Wherewithall which is a coaching and training company geared to help support managers and leaders be better humans to support their teams.

Ledge: Dive into that a little bit. How do you coach that? I presume that the first thing that matters is a desire to be a better leader and manager, right?

And this is not certainly limited to engineering. Are you feeling that there’s a catch up to do in the engineering space?

Lara: For me and for many others, there’s no training. When people hand you your manager hat, it’s not like someone says, “Here’s also everything that you need to know” or “Here’s what it looks like to do it well” or “Here’s how to know if you’re doing a good job at the end of the day.”

There’s often very little support that companies give managers. So the way I think about it is that it’s really that breakdown between those two skillsets, the mentoring skillset and the coaching skillset.

Mentoring is much more about advice giving, perspective sharing, and sharing what you’ve seen worked and have not worked. It’s all about what you can provide to help this person see what they should do or not do.

But in coaching mode, it’s actually very different. When you’re mentoring, you’re thinking about problem and solution; in coaching, you’re really focused on this person who is in front of you to help them understand kind of the shape of what they’re dealing with before we even hop into problem-and-solution mode.

I’ll ask lots of questions ─ hopefully, open questions ─ that will help them introspect and understand the shape of whatever it is that’s going on for them before we move into the advice-giving mode.

I go back and forth between those two hats not just in coaching sessions but in workshops. Everybody needs something a little bit different.

Ledge: I’m familiar with the coaching paradigm and I know it has a lot to do with facilitating them to get to their answer, the place where they feel comfortable. There’s a lot of balance going on.

I would suspect that you talk a lot about areas that have absolutely nothing to do with engineering management because we’re all pretend compartmentalizers. We bring stuff with us.

“I yelled at my Scrum team today because my dog is sick” or “My kids were late for school this morning and I’m stressed out and I’m late for a meeting.”

Do you find that the empathy for this kind of thing has grown?

That’s a hot topic across all work. We’re just kind of not kind to ourselves.

Lara: We bring our whole selves to work. We can’t just pretend that we’re only bringing the business side or the technology side. We’re fully formed humans when we show up to work as much as we wish we weren’t, sometimes.

Ledge: Absolutely! You’re talking to a lot of engineers right now. Some think they want to be leaders and some are like, “No, I don’t want to be a leader.”

Let’s talk about some best practices that have worked and some success stories.

Lara: Awesome! There’s no judgment from my point of view if someone doesn’t want to be a leader or a manager. We can talk all day about the blogpost but instead of doing that, let’s just talk about how it’s cool to not want to be that.

If you’ve got that clarity, amazing! Don’t try it just because you want more power or more authority. Often, those roles will give you access to more information but there are lots of downsides. Those things might not work.

I also think it’s really important to not talk about moving into management or moving into a leadership role as a promotion necessarily. I hear a lot of “I got promoted to engineering manager.”

Let’s reframe that for a second because it’s actually a whole new discipline for you. You’ve probably got no training which means it’s not a promotion; it’s like a sidestep, at best.

Or you move into this new role and you’re kind of a junior again. Because you’re a junior manager, you might have incredible technical series of skills but the stuff you’re going to use today as a manager is totally different.

Ledge: So I land in that seat because I’m in one of those organizations that believe in the Peter Principle and I have to rise to my first level of incompetence.

Great, I’m an engineering manager now. Maybe I aspired for this; maybe I didn’t. But, sometimes, you just have to.

So what’s that skillset where you make that transition because it’s going to happen to your senior engineers a whole lot?

Lara: If you find yourself in this position and you’re like, “Oh, God, what do I need? What skillsets do I need to build?” the first thing I’m going to talk about actually is the difference between mentoring and coaching skillset because so many of us default to mentoring especially in senior tech positions. We’ll pair. We’ll give code reviews. We’ll try to help unblock people. That’s mentoring mode.

But, as a manger, it’s way more important to help grow your people; and growing your people actually means coaching mode because mentoring short circuits it. It doesn’t help people necessarily connect the dots for themselves. And that’s what coaching does.

That’s the first skill ─ the difference between mentoring and coaching and starting to get better at coaching.

The second skill I like to highlight is dealing with surprising human emotions in others. We all wish that we could be rational and logical and just be computers or robots. The tough part is that you’re surrounded by humans.

There’s a lot out there in figuring out how to respond and how to help people work through our surprising emotions. That’s number two.

Number three is feedback. This is the other biggest thing that’s required in order to help grow your people and support them in making sure you’re giving and actionable feedback to them. It’s really hard and scary.

And the fourth thing I’d like to touch on is how to set good expectations for your team. Lay that groundwork so that people understand what’s expected of them, understand how they should be collaborating, and understand what’s expected of you like how you’re going to be supporting them.

These are probably the four common skills that I focus on in my workshops and in coaching.

Ledge: And what happens when you get to sort of a leadership- or management-type position like “Hey, I want to still reserve some of my time to code. I love coding. I’m a code poet and to give that up really hurts my soul?”

I imagine that comes up a lot.

“Gosh, I don’t get to commit any code anymore.”

What are people supposed to do? What is an organization supposed to do?

Lara: What’s really interesting about that is a ton of organizations approach this differently. Some organizations will say, “You’re no longer allowed to ship. You should be one hundred percent focused on the management stuff.” Other organizations expect you to split 50/50 or some other combination. They’re actually explicit about “You should still be contributing in this way.”

Another subset of organizations don’t give you any guidance whatsoever and they just hope that you figure it out; or it doesn’t even occur to them that that’s something that might stress you out.

So depending upon the organization that you’re in, you might react to this differently.

If you’ve got clarity, that’s amazing and a gift. If you don’t have any clarity, I would say, “Figure out how much you need to be context switching day to day and measure your energy levels at the end of the day.”

That’s usually my biggest guideline for people who are still trying to contribute in that same way that felt so good. Especially if you’re new to management, it’s going to be hard to feel like you did a good job at the end of the day if you’re doing one hundred percent management stuff.

You’ve developed that internal parameter of success by shipping code. You know what “productive” looks like as an engineer. So lots of new managers cling to that to still feel productive.

But context switching is where it starts to kind of fall apart. If you spend an hour coding or viewing PRs and then four hours in 101 and another hour in a strategy meeting or whatever or if it’s like really spiced up throughout the day and you’re constantly context switching, that’s going to be a problem mostly for your energy levels and your ability to focus and get stuff done.

In those situations we’re you’re actually able to still contribute code-wide, I would say try to block out some focus time whenever possible. Don’t try to squeeze it in between meetings. Again, it’s not always possible but trying to context switch as little as possible is probably the best way to make that successful.

And then, if you’re not allowed to ship any code at all, I get it. I’m sorry. Some people love it. By the way, they love having the clarity that they’re not allowed to ship anymore like it’s a gift of “Okay, I can actually focus on developing this whole other set of skills.” For other people, it’s the worst thing that’s ever happened to them.

So figure out what coding gives to you. Does it give you a sense of productivity? Does it give you some creative outlet? Does it give you the ability to feel closer to the product?

Whatever it is that it gives you, see if you can find that thing in a new way because for anything that it can give you, there might be another way to feel productive or feel like you’re closer to the product ─ whatever it is. And I’m optimistic that you’ll be able to find something.

And if you don’t, totally cool! Transition back. I’ve seen so many people successfully transition back and forth from those two disciplines. Again, it’s organization dependent. Not every organization is going to support it.

But if it’s not right for you, please, you have my permission to switch back.

Ledge: How about your organizational support? I can imagine you coaching these things and your coachees are going, “Yes, my leadership team doesn’t get it.” And so, you’re dealing with sort of a rare receptive audience that totally wants to do all that. But they don’t come from an engineering-based organization.

And so, how do they train up the people on top of them because, a lot of times, this comes out of “Well, we’re Startup X or whatever. Our engineering team finally got big enough that we realize we need some vertical leveling; not everybody can report to the CEO or the president. Okay, let’s add in some management”?

But, ultimately, at the end of the day, you’re reporting to marketing and sales. And how do you train them because they don’t come from this?

Lara: No, of course not! In the coaching and workshops, we try to focus on things that the individuals can do themselves but, obviously, as you’ve said, they might have the tools.

So when that happens, I usually start to talk about the discipline of changed management, the idea that there’s a whole series of skillsets out there that’s related to management but not necessarily management as to how to change the environment that you’re working in when you don’t have complete power or authority to change that environment.

There’s a whole subset of research that “I am not an expert but I love talking about it.”

My number one recommendation for people who find themselves in this position where they want to enact some change that’s a huge sweeping change, organizational change, where we need to push back on some leadership is to read the book Switch by Chip and Dan Heath.

That’s where I learned most of the things that I know today about this. I refer almost every single one of my coaching clients to this because, again, we need to change something and that change in the organization is a topic that comes up all the time.

Ledge: Let me up the ante now. So I am both becoming a manager of engineers and we’re fully remote. I’m a remote contributor which is a totally different gem because, now, I need to figure out that my whole world is about communication and measuring the productivity of people I can’t see.

And another thing is “Is my organization prepared to scale in that way and not just leave people behind?” I don’t know what everybody is doing at their desk. I mean, there’s so much unpacked there; and yet we know that the skill of managing remote is just a hyper-focused magnifying glass and the fact that you don’t know how to lead and manage; and, now, it’s just really becoming super clear because it just shines the spotlight on that.

Talk about that because I think “remote” is just huge now and it’s becoming absolutely dominant. And if you can’t manage your remote workforce, you’re in trouble.

Lara: I completely agree. Again, just like before, so much of this is organization specific. Some organizations are really equipped for remote management. All communication happens anyway; everything is documented. There are no hallway track conversations.

But that’s not every organization. That’s just a slim few.

So if you’re in an organization that’s not equipped yet, again, I’m going to come back to changed management. You might need to help the organization become better holistically. I’m thinking about remote management.

My number one recommendation here is to find what’s often referred to as a “first team.” That’s the team of your peers whom you can rely on. See how they’re approaching this problem. See what they found works and doesn’t work within this organization because, again, so much of this is kind of context specific.

What are they worried about? What have they tried and failed at?

Start to build up that network of support. I often also talk about this first team principle not just this first team but as this concept of a manager Voltron which can also be outside of your organization.

Can you tell me what a Voltron is?

Ledge: I can absolutely tell you what a Voltron is. Would you prefer the cartoon version?

I’m of the Voltron generation. I also remember Gobots and Transformers. But Voltron was a collection of robot lions and they would transform into the giant big robot that would fight anybody in the next generation. I remember the Power Rangers, a very poor facsimile of Voltron. Voltron was totally cooler.

Lara: They all come together to form this super ─ everything, it’s like levelled up everything. And this is what I like to think about when people are finding that network of support for themselves.

Don’t just rely on your one manager to help you figure out what you’re supposed to do. Don’t just rely on one coach.

Actually, form what I’m going to call a “manager Voltron” for yourself. Find a network of people you can rely on with their different kinds of experiences from different industries and different companies; people who are your peers; people who are more senior or more junior than you. Find that network of support and lean on them as you grow.

I need to plug this. Again, having a coach is really helpful. It’s one part of your Voltron. But, definitely, if you find yourself especially in a remote environment, start to build out that network for yourself.

Ledge: I’m in an organization and I want to coach. Of course, I want to coach. Who doesn’t want to coach? Any self-actualized person is kind of aware of this.

How do I get my organization to fund me having a coach? I want that but there are budgets and stuff. Where do you usually live on the budget-line-item spectrum?

Lara: What’s really funny is that I’m finding that engineering organizations usually have the professional development budget to throw at this stuff whereas other parts of organizations don’t.

In an engineering organization, I find that engineers and engineering managers have a little bit of an easier time using their professional development budget, their conference budget for stuff like coaching.

That’s not always true.

In those cases, I usually recommend that people try to figure out who controls the budget and what is it that they care about the most. What’s the thing that they are bringing their voice to all the time? Is it a company initiative? Is it holding people more accountable? Is it scaling the company? What is it that they talk about all the time?

Try to see if you can basically transform your pitch for coaching into the thing that they care about. They’re not going to care that you care about it. So how can you translate the thing that you want ─ which is hopefully, in this case, a coach ─ into the thing that they care about?

“Hey, I can help hit this business goal way faster if I have this extra level of support” or “Hey, can I please hire someone who can help me learn how to hire other people?”

Whatever it is, take something that you know that they’re going to care about and, hopefully, that will help your pitch because they already care about that thing.

Ledge: Let me get kind of philosophical. We’re software people. Our organization is just like Agile to the core; we’ve got to be Agile. And as I start to look at the evolution of some of those things, there’s a lot of pressure on that particularly remote because, let’s face it, we’re sitting in Slack and we’re doing all kinds of stuff; and remote demands a lot of documentation ─ you even said the word before ─ and reporting and processes and tools.

These are all the things that are on the right side of the Agile Manifesto absolutely required.

I find some contention there, philosophically. I wonder if we’re evolving.

Lara: I’m not sure what you mean.

Ledge: Agile Manifesto right? Individuals and interactions over processes and tools comprehensive documentation. All those things are absolutely necessary things that, in fact, we as remote engineering organizations really need to use.

Do you know what I’m saying?

Lara: Totally!

Ledge: So I find some contention there because you can’t be successful remotely without an excessive amount of documentation and processes. It just doesn’t work.

Lara: I’m hopeful that people are able to find a thing ─ it’s the right tool for the job. It’s not like being dogmatic about a particular process, a particular piece of software, a particular tool. I’m hopeful that this generation of folks who are becoming more distributed are able to find the right tool for the job; and, hopefully, it will equip the others within their organization to also find the right tool for their jobs.

Ledge: We will hope that, right?

Lara: Fingers are crossed.

Ledge: What are some of the challenges you face? You have a great playbook and I know it works for people.

Step back right into your business. You’re doing some things where you have to deal with different kinds of people all the time. What are the challenges of coaching that are hard to overcome for you?

Lara: Absolutely! I got lucky in that a lot of people that I work with know me from speaking, from books, or from whatever. So I haven’t had this stereotypical contractor difficulty of cold calling.

But one of the really interesting things I’ve started to see is that while engineering organizations have the budget for hiring a coach or for bringing me in to give a workshop, usually, HR doesn’t.

And what’s happening more and more is that I’m seeing that the engineering organizations get impatient with how slow their HR teams are moving to implement manager training or to implement some kind of level of support.

So they’ll call me which is like “What a weird place to be!” because I don’t want to steamroll HR. They’re probably doing really important things. It’s not that they don’t care about building up their own management processes. They’re probably implementing the first ever performance review process or developing actual job description for people. They’re doing other important things.

So one of the things I’ve had to figure out and hone is how to have these conversations with a CTO or a VPE where it’s clear that they’re bringing me in because they’re getting impatient and they have the budget to do so.

I’m having these conversations with the CTO and the VPE and they’re clearly getting impatient and I don’t want to steamroll HR. And so, I’m getting better at being “Hey, it sounds like you’ve got an HR team that cares. Can I talk to them first?”

Ledge: I’m one who have spent the last five or six years in the business development function. So you’re understanding who can say “no” and who your influencers are in the organization. And that’s a huge thing.

You know what else nobody learns in engineering is how to sell stuff.

Lara: Right!

Ledge: It’s an important thing.

Lara: It’s actually really interesting because in these organizations, engineering, usually, because they have their own budget and HR can’t say “no” to bringing me in which creates a really strange power dynamic especially in an engineering organization.

And so, I want to help these CTOs. I want to help these VPEs understand that there’s a healthier way to partner with your HR team and not just steamroll them with your enormous budget.

Ledge: To be fair, sitting on an HR seat, the unfortunate nature of the coaching industry is the lack of rigor. Anybody can hang out the coach sign just like anybody can hang out the consulting sign; and there are a lot of people who can be hired who maybe aren’t good at what they do.

And so, there’s that credibility gap where they don’t know you because they aren’t watching engineering keynotes and things like that.

Lara: Right! And I’m going to apologize to all the VPEs and CTOs who are listening but engineering management are not special folks. We like to believe that only an engineer could possibly come in and give this engineering management-specific training.

The HR knows better. It’s all the same stuff. It’s all how to deal with humans.

And so, what’s really interesting is watching HR hear the CTO speak or hear the VPE speak and say, “We need Lara Hogan because she used to be one of us.”

And HR is like, “Come on!”

It’s fascinating to be able to watch. “Sorry, folks, I’m here to give a good solid manager workshop and I agree with your HR team on this one.”

Ledge: I’ve been where you’ve been. However, that’s not the necessary component because these are like sort of eternal truths; and if you sent all your managers through this plan, it would look the same.

Lara: Exactly! It’s actually been a fun dynamic for me to kind of learn and grow and have these conversations and, hopefully, to help these CTOs understand that these are some really core fundamental skills that will equip their managers and other managers, too.

Ledge: I love what you’re doing. I think it’s a super important work. If any of the many engineers who are listening want to learn more, what do they do?

Lara: Go to wherewithall.com.

Ledge: Lara, thank you so much for joining us.

Lara: Thank you so much for having me.