How to manage Engineering managers

Oh, here we are.

Thank you so much.

I think it's very loud, but maybe it's just my impression.

Thank you so much.

I wanna talk about something that is a little bit.

More practical than the previous talk which I've really enjoyed though.

Anyway.

So from the strong philosophy into practicality obviously I was already introduced.

I'm currently one of the directors of engineer at Rokt uh, formerly, VP engineering SiteMinder.

This is how you get in touch with me but...

Thank you for the kind introduction anyway, let's jump through it.

One of the biggest problem that I found when I became a manager of managers is the lack of information, how to do it.

In general, you have a lot of information on the internet blogs, podcast about leadership.

Everybody seems to like leadership more than management, but there's a very little information about, okay, when you are a manager of managers, what, how does that your role change?

And specifically, I've found none in the field of software engineering, which I find really intriguing because everybody's hiring engineering engineers.

They teams are getting bigger.

It's, becoming a relatively-VP of engineer.

It's becoming a relatively common job.

Now I wanna cover just a few things.

Trust me I'm, not big on very long presentations, so don't worry.

There's six things to cover, but I hope I'll go through them relatively quickly.

But this is something, some of the learnings that I gathered through my own career as well as through talking to people.

I do some sort of informal mentoring within my organization and outside outside Rokt as well in a couple of Slack communities.

And without further ado, Let's jump into the first one-structure.

Who has heard of Conway's Law?

Everybody's heard of Conway's Law.

Now has it stated this be complicated to understand, but the bottom line here of this law is, basically that the way you structure your teams basically determines your architecture.

I think that is a different version of the same.

It says that if you have a, four group working groups that work on a compiler, you get a four step compiler.

I always liked that.

But the concept is depending on how you set your org structure, so is your architecture gonna come.

The problem with this approach is that it's just wrong.

It's something that I've seen in many, organizations.

You need to start first with a product, then that dictates the architecture that dictates your org chart.

A lot of companies start the other way around and and you, when you join as a VP of engineering always has this, di have this dilemma where the organization is set up for you.

But it is so, important to start with a product, to be able to have a right architecture.

What I also like to say is you cannot be really a manager of managers without diving deep enough.

Who knows who Joel Spolsky is?

Quite a few of you.

Joel Spolsky is the founder of Stack Overflow.

I had the chance to meet him in person a few years ago.

Really nice guy, really down to earth.

. He was a product manager at Microsoft for a long time, actually who would've said that a product manager can start a technology company.

And the reason why-isn't it's crazy, isn't it?

But he has a nice blog where he talks about a lot of things.

But there's one blog post that I I really change my perception of how to, to be a leader.

It talks about a meeting that he needed to have with Bill Gates for a new release when Bill Gates was still in, in charge of Microsoft.

It was about a new release of Microsoft Excel.

Now, you may not know, I'm not that old either, but Excel was modeled after Lotus 1-2-3.

Lotus 1-23- was the, main product, in early 1980s.

The problem with Lotus 1-2-3 is that it had a lot of bugs, and these bugs were never rectified because they became entrenched.

So people knew about the bugs and, they worked around them.

And so when Microsoft wanted to challenge the incumbent, what they did is they actually replicated the bugs.

And some of the bugs were in the date.

So some dates actually cannot be represented in Excel up until recently, really they just, they the, bug is still there.

But, so when there was a new release of so Joel Spolsky was working as a product manager in creating a new release of Excel.

So the way that would work is they would have to write a nice summary with details.

And what he did, he sent it to Bill Gates the night before the meeting less than 24 hours to see, for Bill Gates to review it.

Now, the first thing that he mentioned in his blog post is that Bill Gates came to a meeting prepared.

He actually had read the whole thing, and he had questions all across that.

What it's, also funny you will see there, there's funny elements to it because bill Gates when he was a bit younger, he was a little bit more controversial in the way he approached things.

He was very hard person to work with.

It would swear a lot and people would take note how many times he swore during a meeting.

So if you know a few F words, this was a good meeting.

But the point was what he was trying to do, he was trying to test Joel in telling and see what was the depth of his knowledge around the product.

Because Bill Gates knew a lot about Excel even though people when I was growing up you had this kind of negative I don't even know-connotation to him that what, was really important?

What, what made the difference for him is that he really dig deep and he was expecting everybody to do the same.

And so as part of this story what is funny is that he obviously Joel has done his homework and he's able to answer about some specific bugs that they were replicating from Lotus 1-2-3.

And that was enough.

So the point that Joel makes is that you need to be very technical to manage technical people.

And it still doesn't change no matter how senior you get think about it, Bill Gates was actually the CEO, yet still he liked to give that the technical and that deep.

Same thing actually happens and used to happen in Apple.

Steve Jobs was not a super technical guy, but he really was intrigued and interested by very, low level details whenever he could.

I like this quote about a company of experts, leading experts, and that's what you want to try and, establish.

And the main reason is because you need to know your product specifically so that it can enforce a good architecture, so you can have a good org chart not the other way.

Expectations aka what good looks like.

Most people when you are an engineering manager, it's relatively easy to set the expectation for your individual contributors.

And the reason is it's, relatively obvious individual contributor, you know, good coding skills speed, quality, it's not too complicated really to, think about it there.

And, it's relatively obvious and you don't really need to set them up too much, although I am very big on doing that in creating coding guidelines, et cetera, even for the intro, individual contributor.

But what I found is when you go, it comes to management , and you are the VP of engineering and you have engineering managers or tech lead reporting to you.

It rarely happens that the VP of engineering sets the expectation for their managers.

So it turns out like sometimes it's a feeling, you get the feeling that the managers are like they need to work out what to do by themselves, and if things are working, you're doing great.

If there's a problem, there's a problem.

What I usually like to suggest if if you are a manager of managers and you have no idea where to start with a framework, with very simple three things.

Again, being very, practical after the stoicism, now I'm going really practical.

Please let me know if I'm running too fast.

But the point is you wanna make sure that 'delivery' works.

You wanna make sure that the systems are up and running.

I.E., you wanna have an absence of problems and you wanna also have an element of retention and recruitment because there's a people management side of it.

On this point, I worked and I have mentored quite a few people, very senior, and they still when I ask them, what is the delivery process that you guys are using within your company?

They just don't have an answer.

They say, ahh we're doing kaban.

Kaban is fine.

Okay, fine, but how, does that work?

And as you start digging a little bit deeper, you get these answers like, well, we just create tickets in Jira and they go through the process.

If you have tickets in Jira that have been sticking around for six months and they get delivered, whatever, if they go across if, things aren't tidy, you don't really have a process.

You're just using Jira, which is a great tool, but you still don't have a process if you can't predict the outcome, if it's if you have zero observability of what people are really working on.

So this is an element where I'm always big on.

And so the process becomes even more important when you are a manager or managers for the next reason.

You wanna have indicators.

Now who's heard of Andy Groove, Grove, Groove.

Yeah, not that many, okay.

So I'm starting to go into the niche area here.

Now it's very famous 'cause in 1983 he wrote a book called High Perform...

High output management.

Is the single most quoted books in the Silicon Valley.

So if you actually wanna read any books on management engineering management, they always quote something out of this book.

He's a legendary CEO of Intel.

He grew the company from nothing to, to what it is now.

I think recently passed away, but, A lot of people quote the book, and the book has got a lot of interesting information, but I really think that the key message that he, that the book sends is, the one that is quoted or mentioned the least.

In the first chapter, it describes how when you are a CEO of a company, every team looks like a black box.

Now, he was a CEO of a, not of a an engineering company and they were doing hardware, not a software company, but it still applies.

And so he says, from the to outside everything looks like you got some inputs, which will be obviously time and the number of engineers assigned, and you got some outputs, right?

But it still looks like a black box because you have no idea how things are working.

And if you've ever been a manager or manager that happens, pretty much all the time you got that team.

For example, my background is not SRE and you got an SRE team.

I like, what the heck?

What are they working on?

And it's hard to answer the question-is, is what they're working on really important?

So what he suggests is that you're gonna open a little bit of a few windows into this black box.

And the way you do is that you actually have to have some indicators , right?

Basically the concept is if you don't know how a team is operating, if you have no indicators, you have no idea how they're doing, how can you make sure that everything is working fine or you can't?

So going back okay.

One thing that he suggests about it is that you want two type of indicators.

You want quantitative and qualitative, and usually that boils down to output versus quality.

You also want these indicators to be a little bit on a tag of war at each other, like you want them to, be some tension, between them, because otherwise what happened is if you just have one type of indicators this is a interesting human property we, tend to over over optimize towards one area, but to giving up all other areas.

So you, want to keep that kind of usually output versus quality.

And if we go back to the expectation that I was suggesting before, the idea is once you set the expectations, that the delivery works, the uptime is there, and retention and recruitment are there, you wanna have some indicators.

Now, as I was talking before, if you have no idea how, if you don't do any estimation on your delivery, for example, really hard to tell how your delivering is going.

Is it going better this quarter than the previous?

I don't know.

Are they working on something a little bit more complicated?

You can work on output.

There's, many there's many other frameworks-you don't like agile don't, get me get me wrong.

It's, you can, I think there's another one from the creators of Ruby on Rails and I think it's called Scale Up.

You can do whatever delivery process you want, as long as you have a process that you can measure.

Obviously you can measure the up time, right?

If you have no production issues, you know that the system is working fine, but also there's are more subtle kind of indicators we wrote platform version two last year, and now this year we need version three.

I'm like, okay, so you know, you're rewriting again in a span of two years-is that a good sign?

Usually it's isn't.

And last but not the least, in the people management space, now you wanna know how many people you're retaining.

I think it's I think it's called 'regretful attrition', it's got this fancy name.

How many of people are you hiring?

But you also wanna know, how you're doing, how your managers are doing.

Now one of the sponsors here is Culture Amp.

They do a great product , that actually specializes in, this 360 feedback among others.

It's not expensive, yet basically 90% of the people I talk to are senior engineering position, they just don't do 360s.

They're like, ah, no, we do it all informally.

If done properly, they are a source of incredibly valuable information.

It lets you know how teams are operating.

It lets you see when leaders under you are struggling.

It lets you pick be very proactive in terms of handling people's situations.

Alright, so what we've covered so far, you need to know the product.

So the product will inform the architecture, which will inform the structure.

Alright?

So there's no way to get away from understanding the product.

Being a manager and knows nothing about what the VP of engineering knows nothing about, the product doesn't work.

You need to set the right expectations, and if you have no idea how to do it, again, use a very simple framework output quality as well and, RnR.

And you have to have indicators to tell you how a team is going.

And you can even, end up having a dashboard if you are that analytical.

I think depending on the number of teams you have, you may not need to do that.

Now I wanna cover a few other areas that I think I found really, useful.

The thinking process.

Now a lot of the time when you're a manager of managers this may sound like I'm contradicting myself a little bit, but teams come to you with ideas, suggestions, or problems.

And what happens is it's actually a little bit outside of your area of expertise.

As I was saying, in the example before, if I'm I don't come from the SRE space.

I can understand the cloud.

I understand but I don't know the low level implications of installing Istio as a cloud mesh versus other alternatives.

I just never delved into it.

So what happened is you get to a point where teams come to you with ideas or problems, and you need to help them out.

And, that's normal, right?

It's, part of a job.

Now.

You can use your experience if you have it.

But if you don't have another example I always make is in terms of compliance, legal aspects, we are storing PII, how are we gonna risk security?

You might not be an expert on all of those, right?

At some point though, you have to make decisions around these areas even if you're not an expert.

And so what I find that really works when you're not the expert is to test the thinking process.

What does it mean really?

Basically there is a correlation between how good the thinking process has been in coming up with a solution and the outcome.

Now, it's not a one-to-one correlation.

If you know what works and what doesn't, it's much easier and faster.

But if you don't have, actually have a hundred percent of the knowledge how you're gonna do this?

Again, some ideas over there, but I wanna quote an example.

It happened to me.

I this was when I, when actually when I joined Rokt, I was put in charge of one team.

I had been working around on a migration to from ??? To Kafka.

And if you've ever done this kind of work there is a lot of knowledge about which pipelines and what data they were storing and how they were working and sorts of elements of eventual consistency.

Not all their knowledge was available to me, but the problem was that the team had been working on this for a year and they actually hadn't delivered anything.

And so one of the first you know, question that was put to me is, okay, when are you guys going live?

And the point was, obviously some of the areas that I did prod was, okay, what kind of POCs have we done?

What is our level of confidence?

By the way, just going around and asking one to 10, let's go around the table and ask what's your confidence if we go live tomorrow?

But one of the thing that I found really useful is what I call a pre-mortem . A lot of a lot of the time people haven't heard of it.

A pre-mortem is actually just a simple meeting where we assume that the project has failed.

Okay, so first thing you do is, okay, imagine that the project has failed.

We went live and it was a cluster.

So what happened?

What went wrong?

Now, the moment you start putting that as a as a given, you will see that people are way more forthcoming in telling you what their worries are because nobody wants to think about the bad outcome and everybody wants to think that it's gonna work.

They don't want, don't wanna get there.

But once you, you take that off the table and you say it's a given, people will give you a lot of information.

Interestingly, we went live.

It...before...we did the pre-mortem something came up during the pre-mortem that was actually very very small thing, but it turns out that it was really important.

So one of our revenue metrics was actually would've been impacted during the switchover and it would've created a big glitch in our revenue.

That, I, we didn't think anybody was, would be, was looking at that metric in Datadog, but it turns out that they were in another office.

And so we were able to prevent that because one of the engineers just said worst case, the worst case scenario, screw up that metric.

And then it turns out that metric was actually very important because it was connected to alarms, et cetera.

So that's, some of the ideas or approaches that I take when I don't actually have the full knowledge.

Communication.

I love this one.

I, repeat myself on this.

I was actually I was talking at a meetup the other day on this specific topic.

Now it happens over time.

When you are leading, you are the VP of engineering or engineering director, whatever, and you have all your engineer managers under you.

You just wanted to say 'A'.

Now what does that mean?

You wanna communicate on a message?

The company's gonna do X, Y, and Z, or we move this migration to the next quarter, or the priorities have changed.

I've seen very, senior leaders do this.

Just gonna go through an, example and I find it really interesting how it-a lot of people don't quite get it.

Basically what happened is you are a VP of engineering.

You have your one-on-one with the engineering manager on the left.

I felt particularly I don't know how to say, I don't know if I wanted to name these engineering managers, but Okay.

I'll give no names.

So I could have called them Alice and Bob.

Sorry.

I've been very, I don't know, anonymous in my slide today.

But the point is, you have the one-on-one with the engineering manager on the left, and you say, okay, 'A is gonna happen' and then the engineering manager goes and has his own one on ones.

Okay with the various people reporting to him.

And guess what happens?

Basically there is this funny thing thing that happens that when people repeat a message, they try to add onto the message and it changes.

As it spreads around, things change completely.

So I've being a technical guy myself, so from A, we go to A1, and then you have these weird things where, because these two ICs on left actually on the right or the left they are friends.

They agree on a version of reality, whereas the guy on the left is more by himself.

Now what happened is you do another one-on-one the next day, right?

Who does all the one-on-ones is the same day.

It's painful, right?

But I do it, especially for this reason.

But most of the time you have them scattered throughout the week or throughout the two weeks period.

Guess what?

By the time you get to talk to a second engineering manager, the message has changed slightly.

And the problem repeats itself again.

So your problem was that you wanted to say 'A', but look what you've got.

The understanding from the full set of people is varied.

Okay?

The message isn't clear.

And the, and what happens afterwards is that these guys from two different teams have lunched.

and they say I heard this, but actually no, it's A2.1, it's a bit different.

And then the perplexity spreads and then you always get the guy that doesn't care 'cause he's been there for a long time and he just doesn't care-whatever.

Yeah.

All right.

I've been here.

We say one thing and then it's the opposite and.

But all of this is noise.

And this noise drowns your message.

So if you wanna be like an electronic engineer, you need to increase the signal to noise ratio.

And the reason is, and I'm very, convinced that it's not a quote from I came up with, but Tony Robbins says, in business, you're only as successful as the quality of our communication.

He says in business and in life.

But let's focus on business here.

So let's see how we can actually do something.

Crazy as it sounds.

You just get everybody in a room and you just give an update.

You just do a whole hands.

Now a lot of companies have whole hands from the CEO, but very, few company have whole hands from the engineering team.

Doesn't have to happen all the time.

Once every two weeks, 30 minutes, you do a 15 minutes presentation, say, this is what's gonna happening, this is where the business is going, this is what you know, and then you open up the mic for questions.

What happens is you've got happy people, but again, you don't get all the people because the guy on the right hand side actually was on leave or Buildkite deployment was stuck and he was on his left laptop, wasn't listening.

Alright.

Alright.

And so that guy didn't quite catch it and then you obviously got the guy on the left that has been there, seen, doesn't care.

No matter what you say, the message is not gonna come through.

So how do you solve that?

Guess what?

Two weeks later, you just say the same thing.

Alrighty, now you do it again.

Guess what?

Now you get that.

Most people got it.

And you always have a grumpy guy on the left that didn't quite catch it.

But you can't change that, and that's okay.

It's part of life, right?

As long as your message goes to most people that you can get it's, good enough.

Two things here.

You have to talk directly to people.

So many leaders like to be very in, in indirect, like you have engineering structures with a few layers and the big boss never talks, never gives a presentation.

He just does one-on-ones every now and then skip level every three months, and you never get an idea where he stands.

Silly things.

This is something happened.

A lot of companies multi-cloud, are we gonna go multi-cloud?

Seriously?

How much we've invested in AWS, how much is it gonna cost?

Why are we doing it?

And it's, very easy.

You just do a presentation, a slide that says, yes, we do it.

No, we don't.

But a lot of senior leaders feels really scared by doing that.

I'm not sure why.

By the way, I used to have a very early in my career, I used to have a CTO, he would take us all the engineering manager in the room every week, and he would give us updates.

That was I, found it really very interesting because it would give us updates from, he was a board member wasn't a huge company, he was giving us all the information.

What, may made me laugh is that one week he would say we are gonna build this in-house.

This feature.

And then the next two weeks later, he would say no, we are not gonna do it.

But the funny thing was he was giving us really good reasons, either way.

But I still appreciated the fact that he was transparent with us and said the board hasn't actually made up their mind about what to do, because there's a lot of things that are happening.

The we all work in companies that sell stuff to customers, change their mind, priorities do change.

So being direct, even when things aren't a hundred percent clear, it's great.

The other element is repeat, repeat, repeat You have to repeat the same message multiple times before it comes across.

Managing by exception.

Almost done.

I've seen this as well quite a bit for two main reasons.

One is this one.

So it's really I, have to confess first time I was a VP of engineering I pretty good about it, right?

There's nothing wrong to that.

I was like, I'm the boss.

Okay, I'm the boss.

No, it feels good, right?

Sorry.

I have to say, if it's all there is to it, then it's, you're a poor boss, and I can't explain it.

But the, there's sometimes you have these people that get promoted into areas of responsibilities and because they feel good about themselves or because they have a imposter syndrome.

Which you can have sometimes both.

A little bit of both.

What they do is that they try, and what I say is, 'manage by exception'.

So what they do is that they sit or they just they walk around the office smiling, shaking hands or, and what they do is, just saying they don't do much proactive stuff.

It just reactively help when things go south.

And believe me, when you have a engineering team, let's say 50 people, there's always something going south.

There's always someone resigning.

There's always someone having problems.

Throughout covid.

Amount of mental health issues through the roof.

Through the roof, something that people don't talk about it.

Depression through the roof.

And even now we're still paying for that.

Sorry, I shouldn't have mentioned Covid, John.

But through, the pandemic, let's say.

And the thing is it's like the, metaphor of firefighting because when you're a firefighter, what happens is, first of all, you're always needed.

Number two, most of the time when you have, there's a fire most fire alarms are false alarms.

But you still take a lot of your time.

Alright, so you always jump in between things and, people maybe for the law triviality, they ask you about silly things as well.

And the other thing is it feels more thrilling than installing smoke detectors.

So basically the point is it's addictive, but it's addictive in the wrong way.

You feel like you are being very useful and helpful, but you're not actually being, you're being reactive.

You're not proactive.

Real leadership is proactive.

If you go back and I think we'll go back now actually to what we just discussed, is make sure your structure is ready.

Set the expectations, have the right indicators use the right thinking process, have the right communication.

Everything.

Everything I covered today is about being proactive and not reactive.

Obviously people think it's obvious, right?

Yeah, it is obvious, but it's not that obvious because a lot of this stuff is actually quite boring to do it all the time.

Like you do two years of checking the indicators for each team of setting the expectation and, communicating and having all hands after a while, there is a little bit of a element of fatigue, but you still, it still need it.

It's still the boring.

Makes a difference.

Thank you so much.

I hope this has added value to you as much as it's been fun for me to put together.

Thank you.