My least favorite version of this is when non-technical leadership skips a level or two and talks to junior technical staff rather than the senior or leadership technical staff who have enough experience to know to ask clarifying questions, establish a timeline, expected outputs, etc. It's something I've seen often at various campaign and political tech organizations.
I frequently see these attempts to bypass hierarchy like this, and it never works well. The junior technical staff understand the chain of command, so when higherups break that (either intentionally or unintentionally) it creates confusion and chaos.
No one is saying it, but a part of the reason is that a long power distance makes it difficult for a junior to object or negotiate a request. It’s usually a plain “yes, I’ll do it”, no matter the consequences.
Or it's a relief because the request will get watered down and / or expanded upon the more management layers it goes through. Are those layers of management even needed? I've read some anecdotes from people working at google and co where it seems a massive management party and nothing of value is done.
I’m not leadership, but if I was, I feel like I would probably be guilty of this. The junior engineers are often the ones doing the actual, physical work and are best suited to answering certain types of questions that those with a higher-level view would not be able to answer as well. Why play a game of telephone when you don’t have to?
Junior engineers might be doing some of the actual work, but by the nature of being junior tend to lack any context around how their work fits into or impacts the overall system. Mix that with being too green to feel confident pushing back at all, and you get someone who will say yes to nearly any question you ask them.
“Hey junior front end engineer, how long will it take you to change that passcode from 4 digits to 6?”
The junior responds with “There’s nothing to it. A day tops.”
But the junior doesn’t realize that the devices that are integrated with the system are statically allocating memory to hold that passcode and can’t change the length without shipping new firmware.
Of course that kind of thing can happen when asking a more senior person as well but it’s much, much less likely.
Because there’s always additional context that the junior and higher ups need that they aren’t aware of, the most obvious being time/capacity.
I used to manage an engineer who was responsible for a critical part of our system and he would frequently get hounded by higher ups who went around me and it ate up all of his time to the point where my manager thought this engineer was just unproductive. I wasn’t able to stop those requests entirely but I was able to establish a paper trail and show my boss that this engineer was actually being overworked.
I think this is a good argument but also an example why it should probably be technical people defining the product and requirements rather than this made up role we've created of product owners.
If you feel the need to drill down, skipping levels to ask what the people in the weeds are doing, you are probably micro-managing and should start working at a higher level.
"It's something I've seen often at various campaign and political tech organizations." If you're already in hell, what's a few more degrees here and there going to matter to you?
"experience to know to ask clarifying questions" I have seen this happening in sales also: An inexperienced vendor "project coordinator", plus a vendor technical person who is used to the coordinator doing the job, plus a client who is new to the circus and you have a potential mess on your hands.
> you’ll definitely look dumb if you do the totally wrong thing because you didn’t ask a question.
> Do not, DO NOT, assume they are too busy to answer clarifying questions as you work on the [t]ask.
Any tips for this when you're working remotely and online chat isn't an option?
In-person, it feels easier to ask lots of small, quick, imprecise, and half-baked questions because you get a quick reply then can follow-up. Over email though, I end up spending more time articulating what I'm confused about and trying to pre-empt possible replies because it feels more formal and interruptive. Video calls can take time to arrange and have a lot of overhead.
One trick I use for client projects is to have a Google Doc that I append small questions to as they crop up, I ping the client occasionally to check the doc (or they subscribe to edit notifications from the doc), the client writes the answers directly into the doc, and this repeats as the task goes on.
Pros: the client doesn't have to answer everything in one go, client gets less notifications, feels like less formal writing is fine on both ends, feels more collaborative, it's easy to add follow-up questions next to the relevant snippet, you can add comments to the doc for quick discussions and to assign/track small tasks, easy for others to read and contribute to.
(Edit: I'm thinking contract work here with non-techy people where you don't know them or their business well, and you'll have lots of little questions)
> Over email though, I end up spending more time articulating what I'm confused about and trying to pre-empt possible replies because it feels more formal and interruptive
I would try to fix this first. You're putting constraints/feelings onto email that other people don't. Just fire off an email with your question(s). Unless you're emailing the CEO or something, just type your questions stream-of-consciousness and hit send. Don't be afraid of immediately sending a second email "oh I forgot this question too, thanks! $QUESTION"
Take a look at https://twitter.com/TechEmails and the emails from high-level executives. Most of them are super informal. Some of the older ones between Bill Gates and MS execs are barely more coherent than text messages between a couple HS freshmen. I'm not saying to start including emojis in your emails to your boss's boss's boss's boss, but an informal quick email won't be a career ender by any stretch.
> I would try to fix this first. You're putting constraints/feelings onto email that other people don't. Just fire off an email with your question(s). Unless you're emailing the CEO or something, just type your questions stream-of-consciousness and hit send.
Hard, HARD disagree from me. The point is not at all about formality or appearing bad towards your boss, it's about avoiding misunderstandings, confusion, and endless followups that multiply the latency and further increase misunderstanding and confusion.
A phone (or a video) call has no more overhead and is no more of a bother than walking over to someone's cube for a chat. I understand that it feels like more to a lot of people but I don't think it is, objectively, more of a bother for either party. If you need the back and forth interactivity to clarify your question then do it.
Your trick with a shared doc is also a great idea and has two additional benefits. 1. The act of writing is an extra step to help you clarify your question. 2. The question and answer are now documented for the future. Both big wins versus a quick chat that then needs to be written down.
"Hey Boss, I'm having a little trouble understanding this request, can you please elaborate a bit on what exactly you're looking for? I'd especially like clarification on X, Y, and Z. Thank you."
Even with access to online chat or even in person, I prefer to batch my questions together. It's better to interrupt someone once than several times throughout the day.
Whenever I get a new issue to work on, I go through it, plan what I'm going to do, dig in my head for potential issues/conflicts, create a sometimes giant list of questions, break it apart into who will most likely be able to answer what question, then start the online chat conversations.
This seems like more of an issue with working with an external client than with working remotely. Within a company you can generally just ping someone on slack (or whatever messaging your company uses) for a quick 5-minute video call. For colleagues I work closely with, I will also just call them unannounced.
The latter could potentially work with external clients (perhaps using their actual phone number rather than a video call) if it was arranged in advance. i.e. you have a kick-off meeting where you discuss how much contact the client wants and what kinds of questions should lead to immediate communication vs. slower async communication.
I think time is a terrible proxy for effort or substance or scope.
Take the example from the article:
> Please look into this for me. Do not, DO NOT, spend more than 20 minutes on this. Please come back with whatever you have after 20 minutes.
Each person looking at this is going to achieve a slightly different amount in 20 mins. Even if we ignore that, there's no guarantee that the manager making the request is going to get what they need from 20 minutes of your effort.
In 'agile' working environments, I regularly see discovery/research tasks labelled as a 'spike' and given a 'time-box'. I often question: "What happens if we don't discover what we want to in that amount of time?", and there's generally no good answer. What actually tends to happen is the 'time-box' is expanded until we found out what we needed to. So time is a terrible proxy for effort, substance, or scope. The same is true here, the manager has some idea of what they want to find out, and you better hope you can do that amount of research in their sized time-box.
I think the later examples on this article are better:
> Are you expecting something super thorough, [...] or a quick write up?
This is much more valuable because we're talking in terms of the scope of work, not how long it will take. When anyone measures in time, there's no guarantee that you'll get what you want in that amount of time, and then what? Well, we add more time!
I think I have to disagree on what you have say on time-box.
> "What happens if we don't discover what we wna to in that amount of time"
Then we know that the answer could not be discovered in that amount of time we had estimated and we adjust our expectation on the effort to do the research on this task.
As a manager, thats one of the key information that I would want to know.
It’s also absolutely vital as a manager to put in place a system of psychological safety before making these kinds of asks. If someone feels like they will be held accountable for not accomplishing the task in the allotted time, then everyone is hurt by the exercise, and morale and trust can plummet - to say nothing of the exploration itself being compromised by a panicked context. But done in the right environment, this can be an amazing technique for exploring a design space.
I'm not a consistent machine though. I may be having an off day. If I don't pull it off in 20 minutes I'm not sure if it's just me, or me that day, etc.
That person couldn't discover it. Maybe another engineer could have discovered it in 5 minutes because it's what they were already working on (and the one researching wasn't aware, or maybe it was down a rabbit hole that looked unrelated).
I guess it depends on how high priority it is. But everything is high priority to management.
> there's no guarantee that you'll get what you want in that amount of time, and then what?
I am absolutely _shocked_ you've never received an answer to this.
There's no guarantee you'll get what you want in _any_ amount of time. You absolutely need to timebox, everything & anything, to make sure projects aren't going off the rails and ending up in the trash. This applies even to personal/solo work too. You can keep working on anything forever, it's much better to force a stopping point, get feedback (or ship it) and decide if it's worth continuing or not.
The mechanism at work here is forcing people to prioritize. If you're very good at prioritizing then a timebox maybe doesn't make sense, but even then, it may be hard to resist continuing to work on something to a higher degree of quality than is needed without a timebox.
> What happens if we don't discover what we want to in that amount of time?
We reevaluate with more information than we have right now.
This pattern of task is helpful for things where the unknowns are substantially greater than the knowns. The idea is to incrementally shift the balance until the knowns are _enough_ to actually make an informed guess instead of just a wild guess.
There's a bug in the legacy codebase. The replacement is nearly finished and slated for launch in two months. How do we handle that bug?
We could ignore it, we could just tell someone "go fix it, whatever it takes". Neither is a great option.
So: "Go investigate this bug, don't spend more than an hour, and let me know how far you get."
By the time you're done, we'll have a _better_ idea what the shape of the problem is.
Maybe you come back and say "yeah I found the problem's in this area, I need to sit down with someone that understands the business logic better to untangle this and then we can tweak and fix it"--great, we'll get you the appropriate resources and try and follow through with a fix. We'll figure on something like an afternoon of interruption for you.
Maybe you just come back saying "it's in this part of the code and it's pretty organized, just couldn't quite track it down yet" and we can greenlight more time based on some level of confidence that it won't be an enormous task. (Or maybe not, depending on the actual scope and severity of the bug.) We'll figure on a day or two of interruption to get it over the line.
Maybe you come back saying "it's somewhere in this eldritch spaghetti, and when I stared into it the abyss starting back at me sent chills up my spine and the pictures on my walls wept blood, please don't send me back there" and it's clear it's not worth pursuing any further and we drop it.
> Maybe you come back saying "it's somewhere in this eldritch spaghetti, and when I stared into it the abyss starting back at me sent chills up my spine and the pictures on my walls wept blood, please don't send me back there" and it's clear it's not worth pursuing any further and we drop it.
“Quick” means “done in a short time”; the sentence you call out is still using time to describe work.
> When anyone measures in time, there's no guarantee that you'll get what you want in that amount of time, and then what? Well, we add more time!
I believe you that this has been your experience, but it’s not universal. The problem is treating “what you want” as the end in itself, which is why the article also mentions “tell people what you need it for”: “our biggest client needs to know before they renew their contract” is worth more money, and thus more employee-hours, than “I was just curious”. At the leadership level, you are expected to realize that you can’t chase every benefit, and strategically focus on those with the best cost ratio.
"Each person looking at this is going to achieve a slightly different amount in 20 mins. Even if we ignore that, there's no guarantee that the manager making the request is going to get what they need from 20 minutes of your effort."
It is a managers job to delegate tasks appropriately. That isn't just assigning bodies to jobs. But assigning the right job to the right people with the right skills.
Time boxing is just a method to do cost/benefit. So sure, time is a bad proxy for many things, but it's not a bad proxy for cost in a world where folks are compensated for their time (generally speaking).
The manager was very clear and specific that what they needed was 20 minutes spent on the issue. Don’t second guess them. If they wanted something else, they’d ask for that instead.
This has happened to me. The CEO of a startup I was working for asked me for something. I recall that he did not provide many words to the ask. Maybe one or two sentences. This lead to a 14 page report I put together. I spent several hours doing it, and did most of it on my own time. I sent the CEO the report. Never heard back from him after that. Nothing came of it.
I created a new rule for myself after this. The cost of the ask, should be proportionate to the cost of delivering that ask. Now if I get an ask that is very costly, I will wait and delay and request escalations and such. The person asking should show that it is worth the cost by doing their due diligence and getting approval from people higher up the food chain. If the ask is a bunch of BS, then I will never hear about it again. If it is worthy, I will do it and also I get the added bonus of the effort not being done in secret without the appropriate visibility.
Having been at different levels in engineering (from junior up through C) there are a few things I've learned along the way.
(1) Everyone needs to operate in good faith. I've observed leaders ask their direct reports for something off-hand, without giving it more than 5 seconds of thought. I've watched direct reports operate as a "human command line", requiring precise syntax before they'll act. Don't be either of these type of people.
(2) If you're a manager/leader, there are no "one-off" requests. Any ask carries an implicit priority over everything else. You have to work within the overall system and environment, otherwise you are forcing your team to make choices about those things. Don't be this kind of manager/leader.
(3) If you're the one receiving an ask, help your requestor understand what's involved. Eliminate implicit assumptions; that's where the dragons lie. Communicate, inform, educate. Nail down what the requestor wants and be sure you both agree.
We do these things in the name of efficiency, of not wanting to waste time if it's not necessary. I've found if we all try to help each other in these requestor-requestee situations, it generally makes life much more tolerable.
> (1) Everyone needs to operate in good faith. I've observed leaders ask their direct reports for something off-hand, without giving it more than 5 seconds of thought. I've watched direct reports operate as a "human command line", requiring precise syntax before they'll act. Don't be either of these type of people.
Operating in good faith is so important.
Leaders who operate by pushing the limits of what they can get away with are a stark contrast from leaders who operate to form good faith relationships with their team. Managers who make thoughtless demands all the time will steadily lose their best employees. In my experience, after a long enough time these leaders are reduced to having only juniors reporting to them because everyone with experience avoids the team.
Your description of “human command line” team members is a great example of bad faith operation, too. I’ve worked with people who thought they were so clever by demanding that even the smallest request be delivered through a form they created or a document they need people to fill out before they can get started, which they might try to debate, critique, or circulate for a couple days before they’ll even think about working on your small task. They think they’ve insulated themselves from small asks because nobody wants to go through all the trouble of asking the question just right to get them to acknowledge it, but over time they build a reputation as difficult to work with.
Another variant is the person who tries to exploit ambiguities in every request; These people have a good idea of what’s being asked of them, but they think they’re “teaching a lesson” by exploiting ambiguities in the request to deliver something that technically matches the letter of the request, but that everyone knows isn’t really what was needed or wanted.
Not coincidentally, most of the people I knew who tried these game found themselves laid off in the past year. I think people can tolerate a bad faith coworker who at least does some work for a while, but when it’s time to downsize they’re at the top of everyone’s list to remove.
I’ll add that poor managers inadvertently create a third variant of these employees by expecting them to “take the initiative“ but then “raking them over the coals” when it doesn’t go smoothly. It can devolve into a very unproductive environment where nothing gets done because the CYA requirements are extremely expensive, but nobody dares to move unless they’ve got their incredibly exact instructions in-hand.
>They think they’ve insulated themselves from small asks because nobody wants to go through all the trouble of asking the question just right to get them to acknowledge it, but over time they build a reputation as difficult to work with.
Sounds like they're completely right, then. "Don't bother Steve unless you really need something from him", which is exactly what he wants.
Big +1 to "there are no off-hand requests"; this was a failure that I realized I was making as a leader a month ago. I was (ostensibly) trying to give my team ownership, blasting them with the multiple things that needed doing, but in practice I was pushing the stress of "what should they be working on in any given moment" to them.
It's a sneaky trap, because you think "I'm making them so empowered!" but you're actually stressing them out and reducing their focus.
> It's a sneaky trap, because you think "I'm making them so empowered!" but you're actually stressing them out and reducing their focus.
As a head's up, the even sneakier trap is that different team members thrive best with different approaches. Some people flail and fret without explicit, procedural direction and others are completely discouraged by it and do feel disempowered.
Rather than taking your lesson as the New Universal Rule, make sure to just add it to your toolbox while trying to learn how to discern who needs what. It's good that you're learning to work better with the people who need more explicit direction, but you're going to burn out managing a team where all of them need that all the time (and if you only practice one approach, you'll eventually get there: filtering down to only have those team members who do thrive by it)
When you give someone the power to decide what to do, they also have to be empowered to know the deadlines and costs of not doing each. They have to be trusted to make the right decisions - which often includes deciding not to do something - if you are not willing to back their decision when things are not done then you shouldn't have given them the authority in the first place.
Good that you realized it. Far too many managers have the impulse control of a puppy that just had a double espresso. Every hour a new task that "has priority".
At one point, I was fastidiously replacing the word "ask" with "request" in every Google Doc I had edit access too.
I've since given up, it's just too overwhelming. For every "ask" I squash, there's 5 more being thrown at me in Slack and emails and Google Docs and Slides.
Agree, it's a little grating on the ears, but, language change is part of life! There are examples out there of modern nouns that used to be something else, but because the change happened so long ago, we're no longer pained to hear it changing.
For example, "Flirt" used to be a verb that meant to make a brisk, jerky motion. Now it is either a verb, to playfully act attracted to someone one, or a noun, a person who flirts.
I feel it's used mostly as corporate jargon. "the ask is moving forward we will need to increase impact by taking initiative, driving solutions, and delivering value to our customers."
One time I laid down two options of what we could do. I did not mention that one would take much longer than the other, because I didn't want that to influence their decision. I thought we should do what was best for the business and end users, not what was easiest for me. Well, they chose the longer and harder one. Later on I learned that they really wanted to go with the other one, but thought it would be harder for me to do. Doh!
Of course, this also happens in real life. I was building new kitchen cabinets and when we got to the doors I gave my wife two options of top rails. Again, one was harder than the other, but I didn't mention that because I wanted her to pick the one she liked better. Of course, she chose the harder one because she thought it would be the easier one even though it turned out that she preferred the other one.
So... always give the other person all the information.
Point #2 is correct, but there’s no good reason it _has_ to be correct. Why can’t we tell management that a question they asked is non-sensical? The answer of course is that you don’t buck the hierarchy. But this adherence to hierarchy doesn’t actually help the business. It seems like this is a value which needs to be more easily discarded.
> Why can’t we tell management that a question they asked is non-sensical?
You should absolutely do that (I tell my team to inform me if what I'm asking doesn't make sense.) If I'm coming to someone with a request, it's because I think they're the right person to address it. Just tell me if I'm off-base.
FWIW, I encourage everyone to not care about the hierarchy, so that may not work in every place.
I do this all the time and have done with every boss I've had over the past 25 years. None have ever objected. The phrase I use with my current CEO is "I'm not sure what you're asking for, can you clarify?" With my line manager this is shortened to "huh?" But then again I don't work for Americans who seem to be much more into hierarchy in the workplace and not asking questions.
The whole point of a hierarchy is division of labor - managers are supposed to be looking at the big picture and monitoring resources so that they can direct their subordinates more efficiently than the subordinates could self organize. Of course there needs to be two way communication, the people down in the trenches are inevitably going to have a much better grasp on the details than the general 100 miles away. But assuming you have told management all the information they need from you, setting priorities correctly is managements entire reason for existence. It is not and should not be the responsibility of every employee to monitor all information and identify whether an ask should or should not be given its current level of priority. You should be confident that when your boss tells you to do something that it is for good reason even if you don't quite see what that reason is. If, on the other hand, you have to do your boss' job for them, then it's better for both the company and you to just cut out the middle man.
I think it’s important to make those requests as minimal as possible. If we have a well oiled system of Jira tickets, estimates, and expectations for each sprint, these one off requests fly under the radar and impede engineer performance and expectations
You could have a percent of each sprint dedicated to one-offs, but then are they really one-offs in the colloquial sense?
The smaller the team and org, the easier it is to handle the one-offs (imo), because we can more directly connect the request to tangible impact more often. At the very least, in a small co your manager (or C suite executive) would easily back you up as the engineer if other executives were questioning output or something etc etc
In larger orgs the extra communication burden makes the one off requests more expensive
The OP responded so seems to understand the link between what you've written and their point #2, but I don't see how it addresses point #2. Point #2 to me seems to be about prioritization of work tasks, and the need for a manager to appropriately prioritize anything they ask for within the context of everything else the worker is doing.
> I've watched direct reports operate as a "human command line", requiring precise syntax before they'll act. Don't be either of these type of people.
I've had managers give stupid orders, and seen them immediately backpedal when asked "would you write that down for me, please?"
So yeah, I'll definitely act in good faith but unfortunately I can't assume good faith on the other side, I occasionally need to be a human command line.
I'd suggest that "good faith" means turning those stupid orders into sane orders. In a case like this, help your manager -- educate them.
If your relationship is tenuous, I get this can be hard. Show your good faith and explain to your manager in clear detail why something is stupid. Manage up, as they say.
The only time I've ever had a report ask me to confirm something in writing it was clear they were operating in CYA mode, but weren't willing to talk to me about why.
It's the sort of thing that immediately escalates a situation, and in reality when the card is played it either breaks the trust, or the trust has already been broken.
> Nail down what the requestor wants and be sure you both agree.
I don't want to nitpick but the change of a single word is going to make significant difference in the outcome, time spent, satisfaction, next steps, etc.
Nail down what the requestor *needs* and be sure you both agree...
I wish I had $20 for everytime the initial "I want..." followed by a couple of questions - or even the famous The 5 Whys - evolved into the true (business) need.
> Everyone needs to operate in good faith. I've observed leaders ask their direct reports for something off-hand, without giving it more than 5 seconds of thought. I've watched direct reports operate as a "human command line", requiring precise syntax before they'll act. Don't be either of these type of people.
Do you think people in either of those situation would agree they acted in bad faith? The leader could say they were trying to avoid bikeshedding on what was clearly a quick and simple task. The direct reports may bring up multiple past interactions where imprecise requests led to a waste of their time and negative feedback. Telling everyone to just "don't be these type of people" is not very likely to be helpful.
"Good faith" doesn't mean being dishonest. Instead, it's about showing a little empathy between two people.
This situation sounds more like people trying to cover their ass so they aren't blamed for something later. Work to get things accomplished, not to avoid some kind of criticism.
So, rather than being these types of people -- be a person who helps get something accomplished and maybe improves this situation along the way.
Quite a few comments imply that asking for something in writing is mark of distrust. I ask for things in writing because I often forget. Run into manager in kitchen and he or she asks a question. It's not like I had nothing to do, I was probably taking a break from another task I needed to finish. By the time I am done with task I was working on the corridor conversation is now blurred. So I need it in writing as a reminder. I could also meet two managers on my walk to get coffee and get to vague requests. I am that employee, if you want something from me put it in writing.
>> I've watched direct reports operate as a "human command line", requiring precise syntax before they'll act. Don't be either of these type of people.
That's giving me PTSD. Run if you ever find yourself in such a team. Operating in good faith should be the base line of working together in and with a team but for some it's not. Then it just turns into politics and ego games.
> (1) Everyone needs to operate in good faith. I've observed leaders ask their direct reports for something off-hand, without giving it more than 5 seconds of thought. I've watched direct reports operate as a "human command line", requiring precise syntax before they'll act. Don't be either of these type of people.
Yeah... until the 4th round of guessing what they mean, resulting in months of tossed out work for lack of the exec elaborating on what they want. think "i need a sales report". You'd think there would be a better brief after the first time.
(2) is what agile sprints are supposed to protect workers from. The worker would simply respond "We'll triage it for our next sprint. If it can't wait please talk to our manager to decide which existing tickets need to be swapped out."
I see point (2) very often combined with a higer-up also bypassing hierachy. I even get the feeling that the higher-ups feel like they are helping because they are so hands-on.
What happens in every case is that the priority of that task for the assignee is the highest. Sometimes this is a help, because often people have to multitask a lot of tasks with the same priority.
But in even more cases it might be a huge distraction.
> I've watched direct reports operate as a "human command line"
I've recently started teaching my daughters how to play chess. When they hang the queen, I ask them "do you really want to do that move?". If they ask why not, I tell them. If they insist on doing it anyway, I capture the queen.
They've learned to listen when I ask "do you really want to do that?"
To reinforce (1), even interest in a topic from a leader, if clear operational structure isn't present, will result in additional work. Be careful what you care about!
> “Are you expecting something super thorough, like multiple hours of effort, or a quick write up?”
Hahahaha yeah.
Ok here's what happens - if an engineer is honest with a non-engineer about how long something will take, the non-engineer will be shocked and say no.
>Clarify the expected time investment: “Please look into this for me. Do not, DO NOT, spend more than 20 minutes on this. Please come back with whatever you have after 20 minutes.”
Are you insane? Nothing takes 20 minutes! You may as well say "don't look at this, go for a coffee and then ball park it for me". We're doing complex work, we need time to consider. If you don't want us to spend time considering it, just... don't ask!
This is part of the problem - you don't want to tell your boss to fuck off, and you don't want to tell them you spent 6 hours on something they think takes 20 minutes. So instead.... everything else slips. Which is why good engineering management is keeping the engineers as far away as possible from the people who are going to unwittingly nerd snipe them.
The classic sign of weak management is asking for reports or assigning tasks they do not understand the full implications of.
The classic sign of weak engineering is saying yes to the former.
When asked by weak management to do a task that is outside the scope of what can be trivially done, it is the responsibility of the worker to do one of three things (depending on technical and social context):
A) Ask, "how should that be done?"
This works if the manager is also technical, and is using vague tasking as a way to compensate for their own technical incompetence, push that shit right back to them. Asking this question forces them to come to grips with the realities of the scope and mechanisms of what they are asking.
B) Inform them, "That will take X resources, what are your expectations?" (Where X is an immense amount of man-hours, money, old-school RuneScape GP, whatever). This is for non-technical managers and serves a similar role as (a), making them come to grips with the fact what they are asking is a major request that needs to go through the normal procedural mechanisms for such a thing, not something they can authorize off the cuff.
C) Say "No". This is not possible in every organization or every social context, but organizations that want to be high-performing will make this possible. In high-performance engineering contexts, engineering will has a strong veto power over dumb bullshit that can only be overridden high up in the C-suite. Understanding how and when to exercise this veto is an important skill for engineering to develop.
The reality for me in what I guess you would call "weak organizations" has been that half of the tasks are expected to be trivial, non of them really are, all of them delay previously assigned tasks without this being acknowledged by the boss, and the boss makes it clear by their tone that they have no real interest in a follow up discussion which means everything you say to them about it may be pushing you towards the door.
They may survive as orgs, especially if its just one weak limb in a larger basically competent organization, or if they serve a sufficiently non-competitive niche where being efficient isn't a particularly important goal.
NASA is an organization where the outside incentives prioritize a particularly high level of safety in engineering, the US Naval Nuclear program has outside incentives that force both high efficiency/readiness and high safety, my local coffee shop closes sometimes because they run out of cups.
Organizations are shaped by the incentives that support them. If there's no particular reason (or, indeed, if there is any room at all to survive) for an organization to be efficient or timely, it won't be.
Readit News
“Hey junior front end engineer, how long will it take you to change that passcode from 4 digits to 6?”
The junior responds with “There’s nothing to it. A day tops.”
But the junior doesn’t realize that the devices that are integrated with the system are statically allocating memory to hold that passcode and can’t change the length without shipping new firmware.
Of course that kind of thing can happen when asking a more senior person as well but it’s much, much less likely.
I used to manage an engineer who was responsible for a critical part of our system and he would frequently get hounded by higher ups who went around me and it ate up all of his time to the point where my manager thought this engineer was just unproductive. I wasn’t able to stop those requests entirely but I was able to establish a paper trail and show my boss that this engineer was actually being overworked.
Deleted Comment
> Do not, DO NOT, assume they are too busy to answer clarifying questions as you work on the [t]ask.
Any tips for this when you're working remotely and online chat isn't an option?
In-person, it feels easier to ask lots of small, quick, imprecise, and half-baked questions because you get a quick reply then can follow-up. Over email though, I end up spending more time articulating what I'm confused about and trying to pre-empt possible replies because it feels more formal and interruptive. Video calls can take time to arrange and have a lot of overhead.
One trick I use for client projects is to have a Google Doc that I append small questions to as they crop up, I ping the client occasionally to check the doc (or they subscribe to edit notifications from the doc), the client writes the answers directly into the doc, and this repeats as the task goes on.
Pros: the client doesn't have to answer everything in one go, client gets less notifications, feels like less formal writing is fine on both ends, feels more collaborative, it's easy to add follow-up questions next to the relevant snippet, you can add comments to the doc for quick discussions and to assign/track small tasks, easy for others to read and contribute to.
(Edit: I'm thinking contract work here with non-techy people where you don't know them or their business well, and you'll have lots of little questions)
I would try to fix this first. You're putting constraints/feelings onto email that other people don't. Just fire off an email with your question(s). Unless you're emailing the CEO or something, just type your questions stream-of-consciousness and hit send. Don't be afraid of immediately sending a second email "oh I forgot this question too, thanks! $QUESTION"
Take a look at https://twitter.com/TechEmails and the emails from high-level executives. Most of them are super informal. Some of the older ones between Bill Gates and MS execs are barely more coherent than text messages between a couple HS freshmen. I'm not saying to start including emojis in your emails to your boss's boss's boss's boss, but an informal quick email won't be a career ender by any stretch.
Hard, HARD disagree from me. The point is not at all about formality or appearing bad towards your boss, it's about avoiding misunderstandings, confusion, and endless followups that multiply the latency and further increase misunderstanding and confusion.
Your trick with a shared doc is also a great idea and has two additional benefits. 1. The act of writing is an extra step to help you clarify your question. 2. The question and answer are now documented for the future. Both big wins versus a quick chat that then needs to be written down.
Offload the cognitive workload onto them.
Whenever I get a new issue to work on, I go through it, plan what I'm going to do, dig in my head for potential issues/conflicts, create a sometimes giant list of questions, break it apart into who will most likely be able to answer what question, then start the online chat conversations.
The latter could potentially work with external clients (perhaps using their actual phone number rather than a video call) if it was arranged in advance. i.e. you have a kick-off meeting where you discuss how much contact the client wants and what kinds of questions should lead to immediate communication vs. slower async communication.
Take the example from the article:
> Please look into this for me. Do not, DO NOT, spend more than 20 minutes on this. Please come back with whatever you have after 20 minutes.
Each person looking at this is going to achieve a slightly different amount in 20 mins. Even if we ignore that, there's no guarantee that the manager making the request is going to get what they need from 20 minutes of your effort.
In 'agile' working environments, I regularly see discovery/research tasks labelled as a 'spike' and given a 'time-box'. I often question: "What happens if we don't discover what we want to in that amount of time?", and there's generally no good answer. What actually tends to happen is the 'time-box' is expanded until we found out what we needed to. So time is a terrible proxy for effort, substance, or scope. The same is true here, the manager has some idea of what they want to find out, and you better hope you can do that amount of research in their sized time-box.
I think the later examples on this article are better:
> Are you expecting something super thorough, [...] or a quick write up?
This is much more valuable because we're talking in terms of the scope of work, not how long it will take. When anyone measures in time, there's no guarantee that you'll get what you want in that amount of time, and then what? Well, we add more time!
> "What happens if we don't discover what we wna to in that amount of time"
Then we know that the answer could not be discovered in that amount of time we had estimated and we adjust our expectation on the effort to do the research on this task. As a manager, thats one of the key information that I would want to know.
* Someone else can continue research, where they left off.
* The research they did, can be discussed amongst the team, possibly by a more senior teammate.
* It may reveal that further research isn’t necessary, and this effort should be shelved until a later date.
I guess it depends on how high priority it is. But everything is high priority to management.
I am absolutely _shocked_ you've never received an answer to this.
There's no guarantee you'll get what you want in _any_ amount of time. You absolutely need to timebox, everything & anything, to make sure projects aren't going off the rails and ending up in the trash. This applies even to personal/solo work too. You can keep working on anything forever, it's much better to force a stopping point, get feedback (or ship it) and decide if it's worth continuing or not.
The mechanism at work here is forcing people to prioritize. If you're very good at prioritizing then a timebox maybe doesn't make sense, but even then, it may be hard to resist continuing to work on something to a higher degree of quality than is needed without a timebox.
We reevaluate with more information than we have right now.
This pattern of task is helpful for things where the unknowns are substantially greater than the knowns. The idea is to incrementally shift the balance until the knowns are _enough_ to actually make an informed guess instead of just a wild guess.
There's a bug in the legacy codebase. The replacement is nearly finished and slated for launch in two months. How do we handle that bug?
We could ignore it, we could just tell someone "go fix it, whatever it takes". Neither is a great option.
So: "Go investigate this bug, don't spend more than an hour, and let me know how far you get."
By the time you're done, we'll have a _better_ idea what the shape of the problem is.
Maybe you come back and say "yeah I found the problem's in this area, I need to sit down with someone that understands the business logic better to untangle this and then we can tweak and fix it"--great, we'll get you the appropriate resources and try and follow through with a fix. We'll figure on something like an afternoon of interruption for you.
Maybe you just come back saying "it's in this part of the code and it's pretty organized, just couldn't quite track it down yet" and we can greenlight more time based on some level of confidence that it won't be an enormous task. (Or maybe not, depending on the actual scope and severity of the bug.) We'll figure on a day or two of interruption to get it over the line.
Maybe you come back saying "it's somewhere in this eldritch spaghetti, and when I stared into it the abyss starting back at me sent chills up my spine and the pictures on my walls wept blood, please don't send me back there" and it's clear it's not worth pursuing any further and we drop it.
I wish I could give my status updates like this.
> When anyone measures in time, there's no guarantee that you'll get what you want in that amount of time, and then what? Well, we add more time!
I believe you that this has been your experience, but it’s not universal. The problem is treating “what you want” as the end in itself, which is why the article also mentions “tell people what you need it for”: “our biggest client needs to know before they renew their contract” is worth more money, and thus more employee-hours, than “I was just curious”. At the leadership level, you are expected to realize that you can’t chase every benefit, and strategically focus on those with the best cost ratio.
It is a managers job to delegate tasks appropriately. That isn't just assigning bodies to jobs. But assigning the right job to the right people with the right skills.
Deleted Comment
I created a new rule for myself after this. The cost of the ask, should be proportionate to the cost of delivering that ask. Now if I get an ask that is very costly, I will wait and delay and request escalations and such. The person asking should show that it is worth the cost by doing their due diligence and getting approval from people higher up the food chain. If the ask is a bunch of BS, then I will never hear about it again. If it is worthy, I will do it and also I get the added bonus of the effort not being done in secret without the appropriate visibility.
1. Never do anything on the first ask. If it's important, they will ask again and I'll think about it.
2. If I have to stay late, you have to stay late. You don't want to stay late? Guess it wasn't important then.
(1) Everyone needs to operate in good faith. I've observed leaders ask their direct reports for something off-hand, without giving it more than 5 seconds of thought. I've watched direct reports operate as a "human command line", requiring precise syntax before they'll act. Don't be either of these type of people.
(2) If you're a manager/leader, there are no "one-off" requests. Any ask carries an implicit priority over everything else. You have to work within the overall system and environment, otherwise you are forcing your team to make choices about those things. Don't be this kind of manager/leader.
(3) If you're the one receiving an ask, help your requestor understand what's involved. Eliminate implicit assumptions; that's where the dragons lie. Communicate, inform, educate. Nail down what the requestor wants and be sure you both agree.
We do these things in the name of efficiency, of not wanting to waste time if it's not necessary. I've found if we all try to help each other in these requestor-requestee situations, it generally makes life much more tolerable.
Operating in good faith is so important.
Leaders who operate by pushing the limits of what they can get away with are a stark contrast from leaders who operate to form good faith relationships with their team. Managers who make thoughtless demands all the time will steadily lose their best employees. In my experience, after a long enough time these leaders are reduced to having only juniors reporting to them because everyone with experience avoids the team.
Your description of “human command line” team members is a great example of bad faith operation, too. I’ve worked with people who thought they were so clever by demanding that even the smallest request be delivered through a form they created or a document they need people to fill out before they can get started, which they might try to debate, critique, or circulate for a couple days before they’ll even think about working on your small task. They think they’ve insulated themselves from small asks because nobody wants to go through all the trouble of asking the question just right to get them to acknowledge it, but over time they build a reputation as difficult to work with.
Another variant is the person who tries to exploit ambiguities in every request; These people have a good idea of what’s being asked of them, but they think they’re “teaching a lesson” by exploiting ambiguities in the request to deliver something that technically matches the letter of the request, but that everyone knows isn’t really what was needed or wanted.
Not coincidentally, most of the people I knew who tried these game found themselves laid off in the past year. I think people can tolerate a bad faith coworker who at least does some work for a while, but when it’s time to downsize they’re at the top of everyone’s list to remove.
Sounds like they're completely right, then. "Don't bother Steve unless you really need something from him", which is exactly what he wants.
It's a sneaky trap, because you think "I'm making them so empowered!" but you're actually stressing them out and reducing their focus.
As a head's up, the even sneakier trap is that different team members thrive best with different approaches. Some people flail and fret without explicit, procedural direction and others are completely discouraged by it and do feel disempowered.
Rather than taking your lesson as the New Universal Rule, make sure to just add it to your toolbox while trying to learn how to discern who needs what. It's good that you're learning to work better with the people who need more explicit direction, but you're going to burn out managing a team where all of them need that all the time (and if you only practice one approach, you'll eventually get there: filtering down to only have those team members who do thrive by it)
It's curious how "ask" has transformed from an ancient verb into a modern, trendy and awkward noun.
According to the OED, nounification began with colloquial usage in Australia.
https://www.oed.com/search/dictionary/?q=ask
We all know that language is a constantly changing biosocial cognitive artifact, so there really are no rules.
But this usage grates like chewing sand, especially when we have perfectly good synonyms just sitting there, unused.
I've since given up, it's just too overwhelming. For every "ask" I squash, there's 5 more being thrown at me in Slack and emails and Google Docs and Slides.
For example, "Flirt" used to be a verb that meant to make a brisk, jerky motion. Now it is either a verb, to playfully act attracted to someone one, or a noun, a person who flirts.
https://www.etymonline.com/word/flirt
"Could you action this ask from Bob in Finance?"
"Key learnings this quarter"...
Of course, this also happens in real life. I was building new kitchen cabinets and when we got to the doors I gave my wife two options of top rails. Again, one was harder than the other, but I didn't mention that because I wanted her to pick the one she liked better. Of course, she chose the harder one because she thought it would be the easier one even though it turned out that she preferred the other one.
So... always give the other person all the information.
You should absolutely do that (I tell my team to inform me if what I'm asking doesn't make sense.) If I'm coming to someone with a request, it's because I think they're the right person to address it. Just tell me if I'm off-base.
FWIW, I encourage everyone to not care about the hierarchy, so that may not work in every place.
You could have a percent of each sprint dedicated to one-offs, but then are they really one-offs in the colloquial sense?
The smaller the team and org, the easier it is to handle the one-offs (imo), because we can more directly connect the request to tangible impact more often. At the very least, in a small co your manager (or C suite executive) would easily back you up as the engineer if other executives were questioning output or something etc etc
In larger orgs the extra communication burden makes the one off requests more expensive
I've had managers give stupid orders, and seen them immediately backpedal when asked "would you write that down for me, please?"
So yeah, I'll definitely act in good faith but unfortunately I can't assume good faith on the other side, I occasionally need to be a human command line.
I'd suggest that "good faith" means turning those stupid orders into sane orders. In a case like this, help your manager -- educate them.
If your relationship is tenuous, I get this can be hard. Show your good faith and explain to your manager in clear detail why something is stupid. Manage up, as they say.
It's the sort of thing that immediately escalates a situation, and in reality when the card is played it either breaks the trust, or the trust has already been broken.
I don't want to nitpick but the change of a single word is going to make significant difference in the outcome, time spent, satisfaction, next steps, etc.
Nail down what the requestor *needs* and be sure you both agree...
I wish I had $20 for everytime the initial "I want..." followed by a couple of questions - or even the famous The 5 Whys - evolved into the true (business) need.
They actually need Y.
Time saved.
Do you think people in either of those situation would agree they acted in bad faith? The leader could say they were trying to avoid bikeshedding on what was clearly a quick and simple task. The direct reports may bring up multiple past interactions where imprecise requests led to a waste of their time and negative feedback. Telling everyone to just "don't be these type of people" is not very likely to be helpful.
This situation sounds more like people trying to cover their ass so they aren't blamed for something later. Work to get things accomplished, not to avoid some kind of criticism.
So, rather than being these types of people -- be a person who helps get something accomplished and maybe improves this situation along the way.
That's giving me PTSD. Run if you ever find yourself in such a team. Operating in good faith should be the base line of working together in and with a team but for some it's not. Then it just turns into politics and ego games.
Yeah... until the 4th round of guessing what they mean, resulting in months of tossed out work for lack of the exec elaborating on what they want. think "i need a sales report". You'd think there would be a better brief after the first time.
What happens in every case is that the priority of that task for the assignee is the highest. Sometimes this is a help, because often people have to multitask a lot of tasks with the same priority.
But in even more cases it might be a huge distraction.
I've recently started teaching my daughters how to play chess. When they hang the queen, I ask them "do you really want to do that move?". If they ask why not, I tell them. If they insist on doing it anyway, I capture the queen.
They've learned to listen when I ask "do you really want to do that?"
I treat my managers the same. :)
Nope, I absolutely want to be this type of person. I don’t want any level of responsibility whatsoever.
You get to hang yourself if you can’t give good orders.
I am an employee. I don’t win if the company wins so I refuse to incur any risk.
Hahahaha yeah.
Ok here's what happens - if an engineer is honest with a non-engineer about how long something will take, the non-engineer will be shocked and say no.
>Clarify the expected time investment: “Please look into this for me. Do not, DO NOT, spend more than 20 minutes on this. Please come back with whatever you have after 20 minutes.”
Are you insane? Nothing takes 20 minutes! You may as well say "don't look at this, go for a coffee and then ball park it for me". We're doing complex work, we need time to consider. If you don't want us to spend time considering it, just... don't ask!
This is part of the problem - you don't want to tell your boss to fuck off, and you don't want to tell them you spent 6 hours on something they think takes 20 minutes. So instead.... everything else slips. Which is why good engineering management is keeping the engineers as far away as possible from the people who are going to unwittingly nerd snipe them.
The classic sign of weak engineering is saying yes to the former.
When asked by weak management to do a task that is outside the scope of what can be trivially done, it is the responsibility of the worker to do one of three things (depending on technical and social context):
A) Ask, "how should that be done?" This works if the manager is also technical, and is using vague tasking as a way to compensate for their own technical incompetence, push that shit right back to them. Asking this question forces them to come to grips with the realities of the scope and mechanisms of what they are asking.
B) Inform them, "That will take X resources, what are your expectations?" (Where X is an immense amount of man-hours, money, old-school RuneScape GP, whatever). This is for non-technical managers and serves a similar role as (a), making them come to grips with the fact what they are asking is a major request that needs to go through the normal procedural mechanisms for such a thing, not something they can authorize off the cuff.
C) Say "No". This is not possible in every organization or every social context, but organizations that want to be high-performing will make this possible. In high-performance engineering contexts, engineering will has a strong veto power over dumb bullshit that can only be overridden high up in the C-suite. Understanding how and when to exercise this veto is an important skill for engineering to develop.
They may survive as orgs, especially if its just one weak limb in a larger basically competent organization, or if they serve a sufficiently non-competitive niche where being efficient isn't a particularly important goal.
NASA is an organization where the outside incentives prioritize a particularly high level of safety in engineering, the US Naval Nuclear program has outside incentives that force both high efficiency/readiness and high safety, my local coffee shop closes sometimes because they run out of cups.
Organizations are shaped by the incentives that support them. If there's no particular reason (or, indeed, if there is any room at all to survive) for an organization to be efficient or timely, it won't be.
https://english.stackexchange.com/questions/4246/can-or-shou...
Just in case others are similarly affected.