Engineering Management Anti-Patterns

Like many people. My engineering management career started when someone left the company, I was working with boards and I was asked to take one on, so my reaction. Sure why not? I mean, you know, I've read some blog posts by my crew law.

four months later the engineer asked if we can chat for a moment. So we walked into a conference room.

We're giving them. I can still picture the conference room. I can still remember my head sinking into my hands because I knew I had screwed up

all too often. As new engineering managers, we are left to learn from our own mistakes. Well, no more today. You're going to learn from my mistakes. Okay. So who are? Hi, my name is rod. I am currently an engineering manager at Dropbox. I've been there for a little over a year and a half, but I've been managing engineering teams now for about eight years.

Dropbox. I primarily work on with engineers working on paper, which is our collaborative editing tool. I'm leading the growth teams. I'm going to give a quick plug for a Dropbox paper is the best way to get your ideas down quickly, to share them with others, to get feedback, to build consensus.

And if that doesn't convince you to try it, you should know that we treat. As a first-class citizen, even going so far as to having an emoji counter along with our word counter, I dunno why we were the only editor that has this but let's face it. Emoji is the most effective way to communicate in 2017.

And before Dropbox, most of my experience came as being one of the three founders at a startup that was called. And this is me with my two co-founders on the afternoon. We decided we were going to start working together on this. And actually with the three of us, I was the one engineer. So as we start it, I was writing all the code, but then over years, the company grew and we went from being a team of three to being a company of 55.

There were 16 engineers on the team that I had hired. I was managing the, I was responsible for, they came from a vastly different set of backgrounds and experiences, and I screwed up in all kinds of ways. My God did I screw up? So that's me. So let's switch gears to the topic of this talk. What I want to talk about are patterns and anti-patterns.

You may know, design patterns, design patterns came into the fore in the mid nineties, and this was a bit, it was Polish design patterns. It was general, general reasonable solutions to commonly occurring problems. And what happened was a group of S computer scientists got together and looked at things they realized were being implemented over and over, and they gave those things names.

This is a facade. This is a Singleton decorators factories. And an interesting thing happens when you give something a name, it means you can talk about it. You can discuss it. And everyone knows they're talking about the same thing. No. In addition to design patterns that you should be using their existing anti-pattern.

An anti-pattern the definition from wikipedia.org is a common response to a recurring problem that is usually ineffective and risks being highly counterproductive. Now, the fun thing about anti-patterns is they feel like the right thing to do at the time. They seem like a good idea. So what we're going to talk about.

Well, I'm going to talk about is mistakes I've made as a manager. You may already have made some of these mistakes yourself. Chances are you will go on and make these mistakes in the future, but hopefully by giving a name to some of these patterns, you'll be able to recognize them in yourself as they're happening and try and avoid them.

Okay. So the first make mistake I have made. As a manager is being the cloner. So you're a new manager and as a new manager, almost every bit of advice you can give someone on your team will be based purely on your experience. As a contributor, as a, as a team member, you will be tempted. To want to turn every one of your reports into a version of yourself.

You'll want to advise them that the way they should grow the way they should learn is the way that you grew, the way you learned. So for example, I personally hate classes and lectures and sitting in an auditorium while someone speaks like I would be out with my phone, just snow. But that's not, I can't just say to someone, oh, the best way to learn.

Oh. Is get stuck on something Google around for a while. Maybe find a book, figure it out for the right person. That's great advice. Just, you know, keep, keep searching, keep digging around is the right thing to do, but understanding the people on your team, understanding the ways they're different from you and then working out the ways to help them.

Work out how you should get invested in them learning and growing and becoming better engineers, you know something like pair programming. No, I personally like the idea of having to sit and explain what I'm thinking to someone and they type it like that to me is just like, I don't want that. I want to be left alone with headphones on and just decode, but it's a really effective way for people to learn.

And if people are really conducive. They love it. They never want to go back from it. And so you have to be ready to give people advice that again, may not be the way you would want to be treated and may not be the way you would want to grow. But it's important for you to figure that out and find that for people, especially if you are an overrepresented majority, the advice Jill gave an incredible talk before lunch, but.

The advice you give based on your experience is probably colored by the privileges you have. If someone is saying to you you know, if if a female engineer says you know, the advice you want to give is you should speak up more in meetings. You, you, you, I see you sit there and you're quiet and you're not giving the, you know, give input imprinted discussions.

That's the way you grow is you should be more forceful with your. That can be terrible advice for a couple of reasons, especially if you're not aware of things like microaggressions and the fact that women are often, you know, they'll give ideas and meetings and they're not taken seriously until guys are repeating them.

And then suddenly it's that guy's idea. Not only are you maybe giving advice that is counterproductive, that should give more, to being more involved in meetings could be more vocal. But in fact, you mentioned exposing your bias that you're missing the fact that they are speaking, you're just oblivious to it because of your.

So really understand these things. Think about the person you're talking to think about the advice they're hearing and think about the way they can grow. Don't just try and create another you. Another mistake I've made for you is being the decider. Now, again, this is incredibly tempting at first, especially if you're the manager who's going to be working on a team, you know, the system, you know, You know how things work.

I know you're managing the team. You've been sitting there and looking at this team and going to this, all this inefficiency, all these discussions and back and forth and meetings and all these things have to happen to get anything done. I'll save the team. Their time by me making all the decisions for them.

It doesn't sound great. Cause you know, at first it seems to work. You inject yourself into the conversations. You you know, you, you you're being useful. Like you're, you're valuable. That's do value as a manager is you are helping this team get things done and make Coles, except it doesn't scale by being the person who's a.

Suddenly people need you in all the meetings and you only have so many hours in the day. So decisions don't get made because you're not around to me. Awesome. And even worse. Now that time that you probably saw as wasted of people trying to get on the same page and come to an agreement that time is no spent people trying to convince you, you and get you on board.

You're disempowering your team. So going back to what Laura was talking about this morning, break things up, let go, and make individuals responsible. And when someone, when you do this and you give someone some work, I want you to go and design this feature. I want you to design this system when they come back and it's not the way you've, you would have done it.

Stop and think I've been in that role. Well, so I built the first version of the site. I was the architect. And so I, you know, to begin with, I would start by saying, Hey, as you go and build this thing, and here's the design and here's how you should build it. And okay. That was bad. The people just implementing what I told them to build.

They weren't, you know, they weren't using their intellect to solve problems. They were just turning specs into code. Okay. So then I got better. I improved. Hey, go and do this. I'm not telling you how to do it, go and build it. And then they would come up with a design and I would look at it and go, oh no, I wouldn't do that.

No. Where are you from there? And he was thinking that the database load, when you run that you're going to have all these queries and that's bad. So that was also bad. The way I learned to handle that was I built an internal flow chart for myself. Someone's taken on a task and they've not done it the way I would do it.

Okay. First question. Do I have a good reason for why I wouldn't have done it that way? Or is it just not the way I would have done it? Okay. If that's the case then sure. Build it that way. You know, I don't have a good reason. It's just different. Okay. But then, okay. Maybe I do have a good reason. You know, the next question is, is it an important enough reason to stop this person from the path there?

Because sometimes that is yes. Yeah. If someone's coming in and they're saying the way we're going to solve this problem is I know we already run all our stuff on my Mexico and Mongo, but we went to add post-grads because that'll help us solve this pickup problem. At that point, you can go, no, that's crazy.

Here's all the stuff you don't thinking about wolves. But even if it's like, you know, again, my example of, Hey, this is our design for it. And I'm looking at going shit. That's gonna, that's going to loop in as me on this database load. And I think that's gonna.

That's probably not a good reason, a good enough reason to stop them. Maybe raise it as a concern. I like, I kind of built up a catchphrase for myself, which was, well, well, I need to be worried about is by himself. I give him that bit of context and then let them go because here's the fun part. Sometimes. I was wrong.

Sometimes I would be like, I wonder if they still basically they build it. And actually that wasn't a problem at all. And if I had stopped to them, we wouldn't have learned that. Or even if they built that in there as a database load problem. Okay. But they've never learned that for themselves. It's not that it's not some abstract thing that they don't understand.

And they were told to stop. They've got to built it and then realize, okay, I built this, I did it wrong. I've never learned a lesson. And that's really valuable too. That's that's being the decider. Now, one of the hardest mistakes I've made for you was being the buddy. Now, again, we're not talking here.

We're about being friendly with your team, you know, as Jill was talking about, it's really important to build that trust that those bonds. But being the buddy is, especially if you're managing a team that formerly were your peers, you have a set of expectations to them. You have a relationship with them and really you want to avoid hurting their feelings.

You don't want to give them the hard feedback. You don't want to tell them that. The news about the project is going to change the way they're thinking about things we all want to be liked. And especially by our friends and our buddies. So you kind of swallow that and you can have hope, well, maybe I don't give them the feedback.

They'll figure it out for themselves. And this is really bad. It's not good for them because without feedback, you're stunting their growth. You know, we, you know, Joe's char before, you know, like people don't feel, they don't get as much feedback as you. And really it's important to give people the feedback and let them know here's my expectation.

Here's why you've not met it. Here's what we're going to do next. It's also not good for you to be that person swallowing the feedback, because if there is ways they can be improving, if there is room for them to grow and you're not giving them that advice, at some point, they will find that out and they won't trust.

If you can't trust your manager to give you the feedback to help you grow it, and you hear about it through other channels, that's, you know, incredible breach of trust. Another part of being the buddy is, as I say, when you have the social relationship with peers and the way you perceive the way they perceive you, and it goes back to that story, I was telling at the start, when I.

Had my first reports give his notice because the reason I knew I'd screwed up was I made a rookie mistake. I still thought of this person as my friend. So when he brought something up to me, I gave him the advice I would give to a friend. He mentioned that he'd had a recruiter reach out from another.

And I would give the advice I give to any of my friends, any of my, anyone I know who doesn't directly report into me, which is going and doing job interviews is a good thing to do. Go and sit in and do those interviews from time to time, even if you're not planning to taking another job, because being on the side of the table, being asked those questions, seeing how different companies work.

That's good information. Again, great advice to give a friend locally advice, to give to someone who works at your company, who you want to keep working for you. So he taken my advice, he just funded through the recruiter. He got to interview, he got an offer. He was off to work at a big company. So again, knowing that, knowing the difference between like your responsibilities as a manager and your responsibility as a buddy is very important.

Now the opposite of being the buddy, being the asshole. This is how I overreacted in the case where I hadn't been giving someone the critical feedback and making excuses for them. Oh, that's him, you know? Yeah. You can't give him a vague spec. You know, you have to be really precise with him. Yeah, that's just, that's just how he is.

Well, I eventually had to give them the feedback of, Hey, you take things too. Literally you only go as far as the specs as, and you don't think any further. I did that in our six monthly reviews. This is feedback out of nowhere, this was felt really harsh to him and it became worse because then I was like, okay, now I have to know that I realized this.

I have to keep pushing this. I have to keep forcing this issue. I have to make sure this change is happening. I have to like tough love. And you know, for that negative review happened, the question he had for me was why didn't you tell me sooner? So it's about finding that balance. You know, don't do the shit sandwich.

No one ever goes well, I got some really tough feedback, but at listing coach that was two bits of positive things around it. I say more often, I've seen, well, I completely missed the feedback in the middle. Cause I enjoy, I enjoy being, having my ego fluff on either side of it. But you have to find that balance.

Hey, in that meeting, that thing you did there, that was really great. Oh, but when you said this. Finding that I'm making sure, as I say, it's never out of left field. It's never a surprise, never a shock, trying to tie closely to the time when events happen. Again, it doesn't have to be immediate. If you're angry about something it's probably best not to go and speak to someone immediately.

We have to talk, but, and finding that time closely, you have weekly one-on-ones with all your reports. Yes. Yes. Good. Excellent. And making sure that you talk about it in the night.

Now I've also, when I first discussed this these patterns with some people, one person says, actually I went the opposite way. I was asshole. At first I became the buddy. So again, work out for yourselves where you are on the buddy asshole scale and to compensate. Now, one of the worst mistakes I've made for you was being the joke.

I am a naturally sarcastic person. One time someone said to me, rod, I don't think you can say anything without being sarcastic. Am I supposed to say, yeah, right.

I've always kind of viewed my contribution to team culture, to be I'm the person that kind of fire spit balls of the people in charge. But an interesting thing happens when you become a manager. Management and Virta comments. You have the word manager in your title. Suddenly people assume that person has information.

I don't have, even when it's not true. This is a natural assumption. You knew more about what's going on in this world than I do. So if you make jokes about what's screen on in leadership, Oh, Hey, as soon as this VP said that they're Volvo people, as soon as true, Hey, this must be a thing that this is how these kinds of things can spiral up.

There's an imbalance of power that happens when you're a manager. And you have to understand that, especially as I say, if you're looking at person who jokes about things, oh, that's the elation up the team mood. Yeah. It can have a really deep impact. The example of this, that I, I most remember a few years ago there was an engineer on my team and he came into the office and I brought his wife in, introduced her to the team and I was in the middle of something.

I was, I, I don't know why, but I was at my keyboard tapping away and he's like, Hey rod, this is my wife. And I was like, oh, nice to meet you. She said, oh yeah, it's a nice to be here. And hope Ted is doing well. And my response was, well, we haven't fired them yet on WebEx. I know, I know. No I, but I, that moment in my head, this is clearly a joke.

He's doing an awesome job. We love what they have. So glad he's here. This is. But they went on, well, my nine has competition, but you've got to be fired. I don't know. I don't, again, it was in retrospect. I absolutely can see that, but at the time, because in my head, no, it's clearly a joke. Understand that it's the things that can be clearly a joke.

Just talking about a meeting that people weren't at and something that happened, it can really have an impact on your team.

So another mistake I've made. Has been being the boy who cried Wolf again, feels like the right thing to do at the time. Like, you know, as say we're, we're, we're all good managers. We all do our one-on-ones every week with our reports and you're talking to someone and they're telling you why they're unhappy and you listen to this and you go, okay, this is a problem.

Something should be done and I'm the person to do it. And so you raise the issue, Hey, there's this problem. We should do something about this. This is big, this is important, but maybe it's not big and important. Maybe that person was having a bad day. Maybe there's a little thing that was just on their mind.

And they happened. You asked them that moment, this question. And that's what they told you.

An example of this was when I once had a one-on-one with an engineer and you're talking about how progress is going. And they said, yeah, the problem is that, you know, the design team, the product team is just, the specs are never ready. You know, we, we have these products that we have these deadlines, but then the specs are never ready.

And so it makes engineering look like we're failing because we're late when everything is. And I heard, it sounds like yes, maybe a profile I've seen that. That makes sense. I, okay. So I went and talked to my cool phone rang and said, Hey, this is a problem. Why is the product organization not getting specs done in time?

That's it? My co-founder went and sat down with that engineer a day or two later and said, Hey, here's a problem of over this and engineers like, oh, it's not that big a problem. Oh, no, it was just this project I was working on with. But because I got to race is the big deal. Suddenly the CEO was talking to the head of product and this is, this is being spiraling up.

So it's really important because when that happens, you lose face as a manager to your peers, to your people above you. If you become the person who cries Wolf. So when you hear something like that, this is, you know, someone tells you, this is why they're unhappy. This is why they're frustrated. Take a beat, take a pause.

Look through your, your own recollection of things and say, does this seem like a problem that I've heard a lot about? Or is this something that's new to me? And if it is new to you, maybe don't do anything to share Saint's version. Thanks. I'll look into that. Right then in your notebook, you investigate product specs.

Are they ready or not? And then for something like that, maybe over the course of the week, I should do your other one-on-one. Talk to people, ask them again. You don't have to be, Hey, I hear from Tony, that's a, the spectrum already asked people things like, Hey, what's blocking you, getting your work done and see if these themes come up.

Alternatively, maybe it's a issue. You come back to that engineer in a week's time and say, Hey, remember, last week you mentioned the product specs were a problem. No, this is good. Not only because you're getting into this problem, but also you're showing them that you've listened to the meeting and you've listened something to it in a one-on-one and you've remembered a week later that gives you Brony points to some other managers they may have had in the past.

So you do this, you do this digging and you find out is this a problem? And then the last piece of advice I have here is who should fix this? Because sometimes the answer to something like that is, Hey, you have this problem with product specs, not being ready. Why don't you work with the product and design teams and maybe collaborate more in producing the specs.

This is something you can fix are maybe something for you as a manager to fix, oh, this is a problem. Let me work with the product manager and design manager and we'll understand what the problem is and what the flow is here. And we will work together and try to. Or is this a problem that has to be raised?

This is something that's like as in endemic, across an organization and let's make sure my boss, my boss's boss, they're looking into this, but if you figure that out, if you can do that at diving, rather than say, just like raising an alarm, something must be done. If you can then go to your boss and say, you look to your manager and say, Hey, this engineer had this problem I dug in.

It is a problem that's affecting all of the team. And what we're doing about it is they're picking up and they're talking to this person, I'm doing this about. I've got this. That's great for you and great for your relationship with your manager.

So the final mistake I've made for you is being the shit umbrella. I'll be honest. The emoji in this deck, I'm mostly because I had a vision for this slide and everything else has just built around it.

Being the shift umbrella. What do I mean by that? I do not just mean you're a bad umbrella. It again. It's just, I have to clarify that if you don't know the expression

how's that going, being a shit umbrella where this phrase comes from his idea is that there's a lot of uncertainty swirling around your team. There's, you know, senior management or they're making changes, making decisions. There's the consumers, your users, the feedback coming from them, the noise on Twitter, about your product maybe other teams have, they have goals and they have plans.

And you know, you don't know if your team's going to still be together in a months time, or we're going to split apart into other parts of the organization and your instinct. What feels like the right thing to do is to shield your team from all of that. I'll keep them safe from all of those distractions.

I will be Willy Wonka and create a magical Wonderland where everything is perfect. So my team can just write code because that's what engineers are here to do. No, what's really important is to work out what is the right noise to let. Be more like a shock absorber. There's all this noise and uncertainty.

You're going to buffer it and let through to your team. The things that they should know about that will help them make smart decisions because the job of your engineer is not writing code that they're told to write. The job of an engineer is solve a problem through. So don't pretend that everything is known.

Everything is a hundred percent certain. The future is perfect and we're just heading this way. And as long as we get there, everything will be great. When there are gaps, when there is uncertainty in the plan, let your team know that. Now again, there are going to be things you can't. Sometimes there is the information that you, as a manager know, oh, we're doing this.

But then this team that their manager is leaving. And so we're going to maybe move people around. And, oh, I was an acquisition happened like the movie things you can't say, but understand what are the things that your team have the ability to absorb, to influence, to give feedback on, to drive through because they will surprise you.

They will often fill in the gaps with better ideas than you would have come up with on your own. And again, this isn't to say, you just said, Hey, it's a wild west right there. There's no point doing funny more than two weeks in the future because who the hell knows know what you have to do is find a way to give your team some direction and some consistency.

Hey, this is our goal for the next quarter, then it might change. That's okay. You don't want to shake people up too much. People do want some consistency, some like pro the plans and the product, things like that. But giving your team agency to have influence on the uncertainty and the disease where they can helps them.

And it helps you. So there you go. Hopefully you can all appreciate the hard work I've done over the years, making these mistakes on your behalf. I think we can all agree. I was uniquely qualified to do that. Also, hopefully by giving some names to these things, you'll be able to spot them, maybe not before, but suddenly as you're fishing your fruit into the bear trap and even better, you can spot them in others.

Next time you're having to fill out a 360 feedback from, for your mouth. Maybe cause there are particular to little emoji in there. Thank you all so much. .

‍