As eng manager, you so frequently get request to drop what you are doing
twitter.com
twitter.com
The alternative is to have people decide for themselves when things are urgent. This leads to four scenarios;
- Really good - they don't interrupt you with a non-urgent thing.
- Good - they interrupt you with an urgent thing.
- Bad - they interrupt you with a non-urgent thing.
- Catastrophically Bad - they don't interrupt you when there's an urgent thing.
Accepting the bad interruptions in order to avoid the catastrophically bad non-interruptions is worth the pain. If you can't handle that then you shouldn't be an engineering manager.
Yes I agree! And it is funny because ironically throughout my years (thankfully to a lesser extent recently) the most inaccessible people have been managers. They always seemed to have calendars stuffed to the brim with "important" meetings
Some people think it means "a project/product manager (PM) for an Engineering team/org." PMs are all about meetings, because their job is to sit with the team, understand what they're doing, and then use that information to 1. glue the team together at the joints (i.e. act as an Enterprise Service Bus for the team's otherwise-flaky message-passing); 2. help the org understand where the team is with their work; and 3. balance the needs of the org with the needs of the team (mostly by pushing back against the org when people without the PM's understanding of the "inside view" of the team, request things that make no sense given that "inside view.")
Other people interpret the term "Engineering manager" as more akin to a tech lead — someone who does engineering, but whose responsibility is technically to marshal resources (other engineers on the team, usually more junior) to get things done. While these folks still do engineering, they only do it when things either "slip through the cracks" such that there are no people free to work on something (usually because the thing is urgent/unplanned, but everyone is busy with planned work); or when nobody on the team has the personal experience with the problem domain and also doesn't really need to have that experience (e.g. when an old legacy component is falling over and needs to be patched Right Now, despite a rewrite for that component being almost shipped.)
The problem comes when orgs try to conflate/confuse these two roles, and install one person (either with only one of the two skillsets, or with both) to serve both roles. Usually the person either becomes stretched far too thin; or just fails to do the half of the job they know less about.
I think that's entirely reasonable, with a few exceptions (i.e., production is on fire and needs fixed now).
Being interrupted a lot is less bad than creating a culture where people are afraid to bring bad things to you early.
Also these questions (I assume) are not rigid "bring a signed stakeholder form to me before we start", its an informal "Mr. X wants this worked on instead of (other thing)?" and they say "Yes". If later it turns out to be inaccurate then the requestor is now the boy who cried wolf and gets vetted much more strictly for future requests. Possibly with a signed stakeholder form before you start.
But the questions are really simple: What's the impact? Is the scope of work agreed asked for by product?
The third question is really their question to their team, what's the effort needed for us to fulfill this ask?
That seems like common sense to me, but maybe I'm missing something. These questions should be answered before even the original asker starts their work.
1. Power of the purse. They fund our teams and ultimately determine priorities
2. Organizational mandate. Blanket authority to dictate standards and penalties for non-compliance (which may include unilaterally shutting your service down).
The best you can hope for in these cases is to surface the costs to those people and hope they are making rational decisions.
It's great if there's actually stuff you can turn down, but more often than not there really are business objectives that won't be met if you don't do the work. It's about choosing which of those business priorities gets harmed and that's generally not a call that's down to engineering.
Make it about resource planning. Two stories:
One of my old managers was really good at getting himself in meetings where new business was being discussed. Even if he wasn't invited because people didn't think our team would need to be involved in a project. He could either convince them that we didn't have resources, we needed additional resources, or we could make due (maybe shuffle a bit) with what we had. Our team was almost never blindsided.
I was running a small software team doing multiple embedded projects. We had more projects than people, but I made a chart breaking software for each project into common high level components (some were N/A of course, some were largely reusable) and showing percent complete on each one. In one meeting I simply showed that one of the smaller projects had zero percent completes across most components, and said it was going to stay that way for the foreseeable future due to all the other partial completes on higher priority products. That one got cancelled within days.
I've come to appreciate an important part of management is to prevent these interruptions from reaching the people doing actual work, or to... you know "manage" the workload on behalf of the team.
Or, you can suck it up, learn that humans are a critical (THE critical) component of the system. You have to learn how they work too.
In some organisations there is so much fear of making poor decisions, that leading never really happens. And instead of thriving in a competitive environment, the company slowly dies.
A good middle manager is supposed to be able to mediate the strategic needs of the organisation as dictated by senior leadership, and the feelings of their team in a way that makes everybody happy. This is a very difficult skill.
In a world where we are doing fast feedback iterations, that’s two to three orders of magnitude off from the rest of the organization.
Yes, because YOU are the scarce resource that the org needs to allocate. Critical for orgs to figure out smooth ways to identify these conflicts and resolve them with good decisions. Not easy though!
P1 - Entire network is hard down, I can straight up power cycle all your gear at will. Oh I can't? Not a P1...
And so on.
Obviously as Engineering manager things aren't as solid but having defined rules about "urgent" and so on really do help.
Our sales team used to have to fill out a form before they got their VP to start pulling chains. Way too often they'd get their VP calling everyone up demanding action and ... nobody would even have a point of contact with the customer. Like how urgent can it be if the customer doesn't want to work on it?
Solution was they filled out the form. VP "signed it" (digitally) and sent it to support. If I called that phone number for the customer contact and they didn't answer ... it was no longer urgent.
Sales VPs actually liked that process too.
The good thing was if it was urgent I had good contacts and data in front of me to ACT quickly.
Slowly, the field has progressed to 100% deliverables 100% of the time. The interrupts are constant because the business hasn't staffed enough engineers. The reason is always the same: despite all the planning and sizing meetings we have, somebody promised someone a feature by X date before asking engineering thinks (or you have yes-people answering for engineering that doesn't represent the actual engineers).
At first I though this meant make everything clear for your team and shield them from random crap (this twitter thread is a great example of this). But I eventually realized that this advice works both ways: done send ambiguous signals to other stakeholders either.
The end result: your staff will love you for it, the other managers will hate you for it -- and stuff gets done! And that is what counts.
- Documenting your API or product for internal stakeholders (i.e. how the thing works) - Training support
Often enough, there's 0 of any of that. So what you see is the support superstars do it after hours. Then they get hired by engineering, and the cycle repeats itself, you've just created an attrition pipeline for talented engineers, and customers pay the cost in pain. Then the engineering managers grumble that support is incompetent and annoying.
I have seen this literally at every software company I've worked at.
Arguably he tried to change too much too fast, but anyway, there's a reason I only lasted 4 weeks.
"Two of my MDs have talked to your leadership and this is your priority now."
"This is a dependency we just discovered while trying to close this audit MRA."
"OK, we understand how important your roadmap is to you. We'll have Eng Mgr X rescue this strategic project instead."
In B2B, telling your largest customer their problem with the service isn't urgent, then attempting to educate them is going to be a mess.
How you communicate where a customer’s urgent request falls on the roadmap may change, but it’s never a smart move to upend the roadmap just because the customer thinks something is urgent.
The hardest part about this is that the problem does not get significantly better as you scale. There is always a biggest customer and they always matter a lot. Even AWS and Azure have to deal with this phenomenon.
2. Have a meeting and ask sanitized versions of the questions in the tweet thread.
3. Put it on the road map and tell the client "your business is very important to us and we've made this task a high priority."
4. Profit
Of course that $10MM contact may be huge to you but tiny to your customer. I mean big enough that your customer really cares.
You don't have fire fighters who also work as bank tellers. When there's a fire you want immediate response. Same with servicing key customers - make them pay for the high quality of support.
If it's the product team coming to me, well, that's their job. I just explain what they'd be giving up by changing priorities. Of course, a PM that can clearly articulate a single #1 priority is a rarity, so sometimes this discussion gets a bit heated, but that's part of the job.
And if some other team or product manager went directly to one of my engineers, I'll politely tell them that's not how things work.
- Either the eng team is a tragedy of the commons, a place to graze whatever sheep you care to send their way, and sure why not let your friends and neighbors also come graze here too? After all, it's not like YOU own it, it belongs to the EM, right? And it's the EM's job to figure out to sustain 100 sheep on a 10 sq ft plot of grass, right? After all, that sounds like some cool engineering whiz shit (to invent hyper-efficient grazing), doesn't it?
- OR, the eng team is YOUR resource, and you don't want others to graze on your land for free...
IMHO, I don't even know that I'd call it a "high quality" vs low quality thing; I think of it like, making a choice about what you want your product <-> eng relationship to be like - do you want your eng team to be thoughtful and do "deep work", or do you want them to optimize for context-switching and multi-tasking? I know it sounds like "deep work" is always the right answer, but it might not be, in all contexts (... okay it probably is right, in 90% of contexts).
These kinds of divisions were tried in the middle of the twentieth century when all big companies had dedicated research divisions: think Bell Labs. While the technology outcomes were often spectacular, very little money, if any, were made from these divisions.
On the other hand, if all you do is context switching and busy work, then the organisation will never grow and move forward, forever bound by the whims of the market.
Agile is great in theory, expects perfectly functional rational organisations without an internal political tug of war. Which us why agile almost never works well in practice in BigCos.
In none of them it's a "never" bucket, mostly because it's the only bucket you have.
Anyway, both of those explicitly don't have the possibility of stopping whatever you are doing right now. The agile methodologies (always remember that Agile says you shouldn't put too much stake in methodologies) have plenty of flaws, but this isn't one of them.
I started just not responding to messages I don't think are important :P
Yikes. This is a sure fire way to build a toxic company culture.
But seriously, I would if I could. I just don't have time
"In order for my team to look good by making/exceeding deadlines, I need X from you, so it is high priority" ... but that's career advancement not business need.
here is a more pernicious one:
"I have limited resources/budget/time (especially budget), I'll get team X to do Y, therefore I get more done and look good" ... again, career advancement and not business need.
The worst for the second case is that sometimes you do that for the team. Then watch that when you need them to come through it's "sorry no time/budget" ... yeah FUUUUCK YOU. You'll never get orgwide credit for "donating" resources unless you have it explicitly spelled out to the stakeholders what you're doing.
In large orgs, #2 can be done a sufficient number of times that the sociopath will get promoted, and then can play the same game with a different tier of managers or move to another company with a better title.
Middle Management Machiavellianism at its best.
Is there any "Machiavelli for Middle Manager" books for realz among ALLLLLLL those management books printed?
If I was a manager (I'm not and never was, just watched what some of my manager friends went through), I'd have a very prominent "Middle Management by Machiavelli" joke book on my desk or shelves.
And the wage was really good, I had no motivation to cheat them, like I did when I was getting paid way under the Chilean minimum wage under Lamar Editores (Niccolo Martelli) in Santiago and was losing money from working there. Something had to give, that was an expensive job, it would have been better for my account book to stay home but I was being coerced to work by the people around me.
So what I did was have three avenues I could advance in the projects with which I was tasked. There was a machine shop and there were tools, I had prior experience with basics, but there were moments I knew I needed to ask how to proceed. Either because the results depended on how I went about it, or because the avenue I took would simplify the work, or because I knew I didn't know. And I did some more work, took more measurements, to understand the roadblock well, figure out how to ask the right question about it.
I noted that roadblock, then I would start on a different line of work, until I came up with another roadblock. I noted that too, and switched to a different task. And when I came to the third and final roadblock, I would then take all three roadblocks to my eng manager--and for sure I interrupted him in the middle of something else, but giving him some time to change focus to the interruptions--and I asked the three right questions I had stored up for all three roadblocks in that single interruption. And we took like 14-30 minutes to review all the roadblocks, walking around the work site, see the constructions, discuss questions in full, at the beginning I learned faster and then later I even came up with ideas as questions double-checking if they were OK, but after the questions were addressed I was ready to work for 2/3 hours before interrupting him again.
Few interruptions, batch mode, and like 3 minutes idle (waiting for him to be available when interrupting him) every few hours, and as I gained experience the hours I could work alone got longer and longer.
> The way I always approached these requests was to educate the person coming with them
This is a very pompous attitude.
What people who make requests like that want is their emotional state managed for them. They feel anxiety and often they have created the situation they are anxious about.