I think the thread is actually quite accurate, but with crucial detail missing - the person who gets to decide whether or not the 'urgent' work is really more or less urgent than what the team is working on is the engineering manager. You can't complain that people interrupt you with things when it's your job to decide whether or not they should have interrupted you.
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.
> You can't complain that people interrupt you with things when it's your job to decide whether or not they should have interrupted you
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
"Engineering manager" can refer to different things to different people.
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 simply tell them, on the record, that I think my topic is more important than their X meeting and why I think that. If they disagree or don't respond, then it's on them.
I don't think the author is saying they shouldn't be interrupted, just that they're not going to change the focus of the _team_ without the criteria they laid out being true.
I think that's entirely reasonable, with a few exceptions (i.e., production is on fire and needs fixed now).
The point is that every barrier you put up ("Have you answered my 3 special questions!?") means people are less likely to interrupt you, which is great on the face of it, except for that one time you really want to hear about something as soon as possible and they decide not to bother you because they haven't written a spec for "Make sure the website is actually up."
Being interrupted a lot is less bad than creating a culture where people are afraid to bring bad things to you early.
I dont understand why it goes from "person comes in (implicitly) demanding work" to "person doesnt even talk to me at all" in that scenario. I think if you have had an empathetic "training session" previously such that they are aware of how you are going to evaluate requests, they will come with questions/conversation rather than requests/demands.
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.
I'm not sure that's true. I don't think there's any malice in their three questions, and they seem reasonable. Of course, they could be an asshole and demand way too much detail in those answers.
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.
Right, the third one is non-negotiable. In no scenario would it be ok for a requestor to come in dictating how long it would take, and any language about that would always be reason for having a conversation to set that expectation.
I think thats true when a lateral team is asking for work, but he also lumps in requests from higher-up. The assumption would always be that this person knows the priorities better so is in better position to say if work is urgent. The disconnect with these parties is usually that they forgot you are in the middle of "other thing that is more urgent" or that there will be unwanted downstream impact, and so they can be convinced that actually the new thing is not as urgent.
That is a bad assumption. Superiors can make the call on urgency, but don't know the tradeoff involved. They will always ask for more and need to be presented the costs.
Superiors usually don't make any better calls on urgency, and the more superior the more completely out of touch they usually are, and the more they need a conversation like this.
I consider it a failure of the manager if their superiors don't have the tradeoff information for a decision they are making. It's an expectation that managers also manage up
It depends on the organization. In my org, the people most often interrupting us either have
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.
Isn’t this classic Type 1 vs Type 2 errors? Minimize the catastrophic error, which in this case is no interrupt and urgent thing, because tolerance for that happening needs to be as low as possible, so accept the other kind of error: non urgent, interrupt.
It's confusing because he wrote "you" which reads as "the manager" in the first sentence, when he clearly meant "the team", as shown in the following sentences.
In my experience it is very difficult as the engineering manager to be the person with the final say. I've constantly been in situations where the leadership ladder gets involved - someone on the business side comes to you and says "Hey I need X" you go "Great, I'll stick it in the backlog and we'll look at it on the next planning review", but that's not good enough, so now his boss is talking to me, before you know it the CEO is talking to the CTO and I'm twiddling my thumbs thinking "what the fuck is the point of any of our processes". In reality what is happening is that I've got multiple stakeholders on the business side and a fight between their priorities is being run through my planning process.
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.
>> 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.
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.
Engineers never want to admit that it amounts to politics. No amount of process will shield you from politics. It has to play out; priorities have to be decided. You can try to alienate yourself from it and watch it play out like the weather -- leaving yourself to prepare for the seasons.
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 addition to this, GP is wrestling with an open feedback cycle. As long as the executives are allowed to behave this way with no consequences, they become habituated to doing it. They need back pressure, in order to train themselves to look a little farther down the road (a month is not too much to ask) instead of constantly sabotaging the team every time a new thing they just thought of enters their heads.
Executives typically do face consequences for making poor decisions. But the nature of their work means the outcome horizons are often way off in the future. C-suite leaders who perform poorly are eventually removed by the board and shareholders.
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.
You could try only accepting work from product managers. If someone wants something they need to convince a PM that it’s more important than whatever the PM currently has in development. Product is the “what” and engineering is the “how”
In reality that's what happens - the advice in this twitter thread is about the PM role, not engineering manager. It's still ridiculous though, because you still end up having phone calls with the CTO and CEO to explain why some arsehole is complaining directly to them about their pet project not getting prioritized, including having to explain to them that there is a process, which they designed, for us to make these decisions and that phoning me up isn't a part of that process.
> In reality what is happening is that I've got multiple stakeholders on the business side and a fight between their priorities is being run through my planning process.
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!
When I worked technical support for some big routers and switches we had very defined rules for various ticket priorities:
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.
This is a lot harder with feature work. My team might be working on a new API that enables team A to build feature A. Now someone interested in feature B needs "just a small API change" to enable their feature B which "was promised to important customers to be available this month". It gets pretty fuzzy. Your idea of having some standard questions pre-answered is always helpful though. In this case that might be stuff like expected revenue. Of course in my example the person interested in feature B also needs a talking to for committing both fixed scope and fixed time externally (already bad) while not talking to all impacted parties ahead of time.
In the good old days as a system administrator, roughly 15% of your time was spent on deliverables, maybe 35% spent on troubleshooting/outages, and the rest of the time doing whatever you wanted. We had time to investigate weird things, work on performance improvements, build new tools to automate things, you name it. There was excess capacity built into the system because there needed to be, every once in a while you needed many people at once to handle a rush of problems.
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).
All good considerations, but note that these four points only define failure conditions and there are no success conditions. I've worked with groups that set up these hurdles, watch you clear them, and then just say "ehhh, no".
I've found that the best managers are the ones who are able to deflect those requests coming in using the techniques described. As a new manager on a new team, that's hard though since you still want to make good impressions and not get a reputation of a Debbie Downer. But if you hold to your guns, it's worth it for your teams' sake.
Great advice I got 30 years ago was “the job of the manger is to eliminate ambiguity”. This single sentence has really helped me figure out how to do my job.
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.
Being an engineering manager is to run interference for your team of engineers. Protecting your team like a mama bear from the various requests / demands from outsiders. Of course, to do that you need the attitude of a mamma bear.
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.
While it is a great perspective, my experience has been that engineering managers feel like non-important things are:
- 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.
At a startup I worked at briefly (~4 weeks), engineers were constantly being asked to do ad-hoc pieces of work from people all over the business. A product manager who started around the same time as me tried to introduce a lightweight triage system for his team by which inbound requests would go via him. He was immediately taken to task by the CTO who told him to stop rocking the boat and not to introduce any other changes until the new VP of product joined in a few months.
Arguably he tried to change too much too fast, but anyway, there's a reason I only lasted 4 weeks.
As a corollary to this, Eng Managers also need to be able to explain why the asks they themselves are making of other teams are important enough that the other teams should care about and act on the asks.
Yeah, but running around with your hair on fire from half-finished “urgent request” to half-finished “urgent request” is still a recipe for complete failure all the same.
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.
It's possible but difficult. Mainly, it requires setting expectations well, communicating what you're actually working on and why. Your field teams (sales, account management, customer success, sometimes even product marketing) are key for this. It's important to have good relationships with them such that they're highly informed partners.
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.
Ironically the more money the contract is worth often implies the less thrashing you’ll be subject to, just because the project is so important to the customer.
Of course that $10MM contact may be huge to you but tiny to your customer. I mean big enough that your customer really cares.
Ideally the service/support team should be just that and not also doing development.
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.
I had the same thought. When some other team comes to me with a non-trivial request, one of the first things I do is check with the product team. Is it part of somebody's roadmap (it's not part of mine, or I'd know about it already)? If so, is it a current thing or a future thing? And do they agree that my team needs to drop our current work?
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.
I get the sense that the author is referring to the combined product/engineering unit, as I usually see PMs fulfilling much of this type of filtering/pushback role. But I had a similar reaction – high quality PMs actually view it as their job to stand in the way of a lot of these requests because preserving engineering (and often design) focus is one of their top priorities.
Speaking as an EM, from product partners, there is basically this switch that sometimes flips (depending on the PM, depending on their experience/career maturity, depending on the team/business context):
- 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).
With most human endeavours people need to be able to do both. Having no context switching, and only deep work is going to lead to outcomes that are divorced from the reality of the business.
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.
Yeah these seem like product-level things. Seems like a bit of a mess if engineers are coming to their managers about working on things that weren't specced out. Shouldn't they be busy with things that were already specced out and estimated?
This is what agile is for. You have a backlog of work in priority order and it can change whenever you need it to. If you get an unplanned request, instead of saying "yes" or "no" go review the backlog and see where it fits. It's a true existential threat to the business, it can go straight to the top. If it's just a thing they want, it can go in with the things everyone else wants. If the ask is incomplete, you work on completing the ask before asking a developer to look at it.
backlog sounds like "not today" bucket but in reality backlog is "never" bucket
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 scrum "backlog" is "look at it once a month and decide what you will work on". In kanban, "backlog" is "the list of potential next actions".
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 find it's built exactly for office politics. Because the backlog can be shared with stakeholders everyone can see what work is in the queue and in what order. The only thing a team lead needs to stand firm on is capacity.
That's good. A lot of people will come to you with ultimately low business value asks. It's just how it is. People have ideas, they want to briefly discuss it, I direct it to the backlog. If the EM and the Product Owner both consider it low-value, the requestor has to accept that fate or create a more compelling argument for why the assessment was incorrect. But most requestors won't put in the work to justifying the requests. There is no problem with backlogs becoming graveyards. We might revisit the item later if business priorities change yet again, and now we have a paper trail of the decisions.
If the backlog keeps growing either the tickets aren't important or you need to grow your capacity through additional headcount or vendors. As a manager it's your job to communicate the implications of both.
I think this provides some insight into why the biggest and most resourceful heavy orgs on the planet fail to innovate, often having to resort to aquire small and nimble competitors. So much bureaucracy is put into place because these orgs need stability and predictability above else.
This is not a size issue. This is human nature as well as the nature of development interacting with non-development. I've dealt with the same exact issues/conversations in every company I've been a part of, except a startup.
Engineers are super valuable/powerful at software companies. Everyone wants a piece of your time. 90% of the time, if what they're asking you feels like any engineer could figure out themselves, just ignore them
I started just not responding to messages I don't think are important :P
If you are a new manager in a large org, these requests are a symptom of common anti-patterns:
"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.
So what I did working for Peter Thiel (and later Elon Musk) funded company was I knew my interruptions had a price. But I had a work ethic: I had to be working all the time I was paid to work, and wait when it made sense. I was also paid to wait, but it too had a price. There was a balance.
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.
I find the attitude "You have to work on this problem right now!!!!" to be a pompous, especially if you are unable to even define what the work you want done is and it turns out it actually isn't urgent at all.
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.
I agree on that particular line, but the rest of the thread is pretty reasonable I think. Although that said it's explained like "this is a new amazing magic formula" when really it's just qualifying the work your team takes on. Most of these questions should be asked of work that's less rushed.
For what it's worth as someone senior who is sometimes the source of the urgent request, I actually want to be educated by the team I'm bringing it to. Blind adherence to urgent asks is actually an anti-pattern (even if it's frustrating to have someone push back hard in the moment).
I think secondcoming is interpreting "to educate" to mean "to be schooled / to be instructed" whereas others are interpreting "to educate" to mean "to provide information / to persuade with information". Both are viable meanings per Merriam Webster. The tone of the twitter thread led me to believe that the author was trying to convey the latter meaning which does not come across as pompous. However, if someone was to parse the earlier meaning from the thread I can see how it could be viewed as pompous.
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.