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.
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.
Americans being into hierarchy is a bizarre opinion. Are you confusing it with asian countries?
The only time I have ever been “ordered” to do something was for an American middle manager (not in my line) in an American company. “Haha get fucked” wasn’t the answer he was expecting, but my non American manager told him the same thing when he went to demand I’d get fired.
I mean, that'd probably get you fired even in a country that really does allow for a lot of informality with your bosses (e.g. Australia).
Where i’m from, if your manager literally states “you are ordered to do xyz” that manager will be fired. It’s not the fucking military.
Were your quotation marks meant to indicate that was the literal language used? I interpreted it in the opposite way (as scare quotes), but would agree extremely authoritarian orders will produce interesting and counterproductive reactions.
JFYI, scare quotes are also indicating the it is "the literal language used". The quotes are added to say that you are quoting literally what other people/the culture uses, but that you disagree with how that term/phrase is used.
I'm aware, but what I meant is the ironic usage - you can use scare quotes in an ironic way (i.e. you may be quoting someone or an expression or idiom but we do not know it is the boss being quoted verbatim).
I think Anglo-Saxon countries are all pretty much the same in that respect.
No fan of Suella Braverman, but she got fired not because of what she said, but because she publicly went against hierarchy, which seems to be a terrible offense. Which in the UK it probably is.
A lot of Americans, particularly the more traditional minded, really are into hierarchy.
They’re probably confusing hierarchy with our obsession with middle managers who fear it being discovered that they don’t actually do anything.
Same experience here. See my reply to the sibling comment.
It's not as bizarre as you might think. The United States is not a monoculture, different parts of the country are more hierarchical than others.
Being American and having worked in American companies we absolutely are. Not as much as Asian countries, but much more than European countries.
I don't work for Americans who seem to be much more into hierarchy in the workplace and not asking questions.
In my experience, this is not true at all. But, as you say you don't have direct experience to come to this conclusion, may I ask what makes you think this?
Not OP but I have that experience. Europeans have been much more open.
My personal theory is that it's connected to job security and how big personal problem it is to lose your job in a layoff. If you get laid off in Europe, your health insurance is paid from public budget now and you get several months salary from your employer. If you worked for a big name, it may be six months or more. If it was a small startup, you get at least two months.
Our US colleagues always made more money but also were more afraid of losing their jobs. All of that said from the IT perspective. I'm sure being a coal miner and getting laid off is much worse.
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.
This is a great point -- and I do, when I can. I guess it's the culture shock that I find most difficult. I'm only asking for clarification so I can fulfill the request more effectively -- but even this is seen as risky and pushy in many businesses.
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 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.
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.
> brief ask ... imprecise ask ... any ask ... receiving an ask ... clarify that ask
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.
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.
You can join me on my crusade changing 'utilize' to 'use'.
That is nothing compared to the cringe I experience whenever I see people type "lead" when it really called for "led"; "He lead them into battle" instead of "He led them into battle." - I see that a lot these days.
Oh and speaking of "a lot", it makes me sad every time I see people using "alot". And that non-word gets used increasingly often. It's not like it's a typo or autocorrection. A lot of people unironically type "alot". Ugh!
EDIT: Lol, I received a downvote. I found the "alot" user. Or the "lead instead of led" user! Or perhaps I scored a double strike ;)
An old but good resource on coping with "alots":https://hyperboleandahalf.blogspot.com/2010/04/alot-is-bette...
If you ever go led climbing at night while listening to Led Zeppelin, you will probably want to bring a lead light, but not one powered by led assed sells, as that would way alot, probably to much.
A lot is annoying to swipe type on a phone. I know alot is not in the dictionary, but it will always be one of the first words I purposefully add to my user dictionary, right after all the cuss words.
From an exhausted and humiliated veteran of the failed struggle against the verbification of "impact", you have my respect and sympathy.
I think that one is a direct result of people being pedants about the difference between effect and affect which made a lot of people try to avoid them completely.
My favorite is that affect and effect are also sometimes a noun and verb, respectively.
Knowing how to use all 4 (affect noun, affect verb, effect noun, effect verb) correctly feels like a superpower.
You're fighting the good fight.
I also find the usage annoying (probably because it’s corpspeak), but I made an executive decision to overrule my emotions on the matter because simplifying the common usage of the world’s lingua franca by having verbs do double duty is, in the long run, fine and good and useful. We already do it for “drive” and “run”. More gerunds is a good thing.
“request” is a word that can be a noun or a verb. Why can “request” be a noun, but “ask” should not?
Just remember that the noun "ask" begins with a T.
And that ancient and perfectly good noun has transmogrified into a modern, trendy and awkward corpspeak verb with nauseating echos of milspeak.
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."
Or the ever annoying "learning" instead of "lesson".
"Key learnings this quarter"...
In Australia I've only ever heard it used in the specific phrase "That's a big ask".
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.
And "action" has made the reverse transition...
"Could you action this ask from Bob in Finance?"
Same with "invite" used as a noun in place of "invitation".
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.
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.
When somebody asks for an order in writing, it's patently clear that the trust has already been broken, and irreversibly so. Nobody asks for that from a position of trust.
That lack of trust is reasonable though - what’s in your head and what’s in my head may be completely different, why ‘trust’ that we’re on the same page when we can literally ensure it by writing it down and looking at it.
You wouldn’t verbally describe a structure to a builder, and then accuse them of not trusting you when they ask to see a blueprint.
Asking someone to file a ticket does not seem to point to a lack of trust, in my opinion.
Unless it's multipart or otherwise complex, then the person asking just wants to make sure they didn't forget everything important. I've asked this on more than one occasion and I think it's clear that I'm asking so I don't forget anything (and have sometimes made this explicit).
No it's not. I made it clear to my last team that I'm just super forgetful and if you don't write down your request, I'll have to stop and write it down myself, implicitly making me an over-paid secretary.
There was resentment yes, but I did trust them!
I often ask people to write up requests and often write up my own verbal requests to provide documentation of the ask and allow for clarification. Over time I’ve learned that my verbal requests often leave out important details and then people make assumptions that aren’t always right.
I read it as a mysterious CYA move as well, mostly based on the phrasing.
A possibility is that asking for a written version of the task got the manager to start thinking about the fact that they were asking for something that would be hard to articulate exactly, which revealed some hidden complexity in the request. But I guess that would be asked in a fashion more along the lines of “let’s work out the details asynchronously.”
Depends on the level of effort required for the task in my opinion.
If it's a trivial thing like send an email or some small ask then I wouldn't necessarily expect it to be in writing.
For any non-trivial task I'd expect it to be in writing, even from my manager. Reason for me is that where I work I don't only report to my manager when it comes to how my time is used, but other workstreams and projects, etc.
If I'm busy working on a task for you that is undocumented, then all these other workstreams will wonder what the fuck I'm doing with my time, or may question whether its more important than other tasks. Obviously this is industry specific, since I don't actually work directly with my manager on any projects and probably never will.
From my perspective, my manager has failed or is lazy if they fail to put their non-trivial tasks in writing.
I've had managers give stupid orders
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.
Sometimes a manager will just throw something out there. "Can we get a dashboard for this (thing that has come up 0-1 times)".
Feeding into those whims is rarely good for anyone, except the manager's ego.
A lot of the time they don’t need education, they need reminding to think. The request to write it down achieves that.
(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.
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.
Sounds like they're completely right, then. "Don't bother Steve unless you really need something from him", which is exactly what he wants.
Then why is Steve in a job in the first place? Such an attitude would find more traction in the contingent consulting world. At a job, where you're paid to deliver for your co-workers, it's asking to be laid off or fired.
You'd have to ask Steve. But he's still there, so the organization may just feel his idiosyncrasies are worth it. Maybe he does really impressive, reliable work when you just let him do his thing.
It's less important (and implausible) that everybody act as the same game theoretic agent than that the team understands everybody's idiosyncratic shape and can compose those shapes into productive patterns.
You usually have to do very good work to be a Steve and hang onto your job, but very good work is rare and valuable, so if you do deliver on it, you can often be more assertive and draw some of the boundaries that more marginal team members can't get away with. It works because real-world teams are more like an organic ecosystem than a mechanical gear system.
It turns out that Steve, in this scenario, is functioning just like a manager. He has outsized influence, and you have to be careful what you ask of him. With Steve, there are no free looks, and he has the power to stop whatever line of effort you're pursuing. On the other hand, he can activate your efforts, give them the needed bit of polish, and get them in front of the right people.
But Steve is an informal manager, so he better be sure that he has the tacit approval of the actual manager for the team, or his actual manager's manager. Otherwise he's not doing his job, and this will eventually put him in conflict with exactly the people who have control over him.
And if Steve is your direct report, you better keep the situation under control, or Steve will eventually have to be let go and you will be made to look stupid for letting a talented contributor fall out of step with the team.
As someone who did his fair share of project work across departments, first as resource and later as a manager type, people like Steve arw everywhere. And they are a pain to work with, have no real influence whatsoever. All they are is not enough of a nusiance to be delt with, which ultimately they will if their attics block the wrong people's project.
That being said, if I have to deal with the "command line" people by tellong them each and every step of the work they are supposed to do, more often than not I'm faster doing it myself. There are places for those people, places they actually provide a ton of value because strictly following procedure is paramount, things progress faster when people can get an assignment and everyone else can count a) the assigment being completed on time or b) everyone getting a heads if not.
Those other roles are tge easiest to automate, and by no means do they justify the salaries some people are expecting to be paid.
But he's still there, so the organization may just feel his idiosyncrasies are worth it.
Alternately, he’s solely there because the HR requirements are onerous and take time, and he hasdramaticallymisunderstood his importance and value. Or he used to do good work and thinks he is now irreplaceable because of domain knowledge.
In any case, as a manager, Steve is a needless disruption/drag and there is nearly no situation in which his work outshines his stated personality. The org would be better off without him.
well said
Perhaps, but if you know how far to push it, it's not a bad strategy. If you're on a salary it's in your interest to do the minimum possible that won't get you fired, just like how it is in your employer's interest to pay you the minimum possible that will get you to do your job.
Trying to do that calculus is just asking to make yourself unhappy.
Ask a fair salary, do what you can, act in good faith.
Success often follows being the person remembered as being helpful or useful.
Steve's job is emphatically NOT to prioritize delivery of solutions for arbitrary or ill-formed requests from co-workers! Saying "yes" to one such request requires saying "no" to everything else, including strategic priorities and commitments. And it invites more of the same. An organization that ignores the need to respect each others' time is dysfunctional. An employee who insists on clarity, instead of allowing half-baked interrupts to derail the work they're already engaged in, may simply be defending their ability to do their job.
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.
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.
"Good faith" doesn't mean being dishonest. Instead, it's about showing a little empathy
Being pedantic when talking about empathy is about the least empathetic thing you can do.
Being empathetic doesn't mean you have to accept wrong definitions.
NOTE: The meaning of good faith, though always based on honesty, may vary depending on the specific context in which it is used.
Notes don't pass the command line it seems.
Empathy is the word of the times so it gets used where it's wholly inappropriate.
good faith just means you assume the person is earnest in trying to make the project you're on successful. Part of that is understanding that people say stupid shit, but the other part is trust.
One of the reasons my current employer is so sticky is that it's a billion dollar company and I've only met 2 people whom I won't accept in good faith, everyone else is earnest even when they disagree with you.
People don't cover their ass out of fun, they do it because getting blamed for something later is areal problemthat can actually hurt you.
Playing social games is non-optional.
I've watched direct reports operate as a "human command line", requiring precise syntax before they'll act.
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.
How about a $25 gift card to Chili's if you do well this quarter? Would that change the equation?
And believe, me this is a hypothetical, but what if you were offered some kind of stock option equity program. Would that do anything for you?
That comma placement is hurting me.
insubordinate clause
Whenever I've been offered stock, it has either been stock options for a private company, or RSUs for a FAANG.
In the first case, I value them at 0. The stock can't be sold unless there's an IPO or the company is sold, and me working harder is vanishingly unlikely to be the difference between there being or not being an IPO.
In the second case, the impact of my actions on the stock price is nil. I'l be happy to take the RSUs and sell them ASAP, becasue they are actually worth money, but I don't see their value linked to my performance.
I don't agree with the GP's position of zero responsibility, but stock is not a better incentive than cash in my experience. That's just internal marketing in my opinion.
Sounds like you're incurring lots of risk - risk that the company won't really want to keep you around.
Agree. I would fire such an employee on the first opportunity.
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 anddofeel 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 whodothrive by it)
Some people flail and fret without explicit, procedural direction…
Is this different from the “human command line” mode of operation that the grandparent mentioned?
Two different points. He's saying not to be one of those but as a leader, you will have to lead those. Some people are just not great at interpreting context and your job will be to spoon feed it.
Yup. As a team lead, I fretted that I wasn't giving me one of my new team members enough hands-on time / direction. I'd sort of give him stuff with as much context as I had, meaning to follow up in a few days to see how things were going, but never got around to it.
I later got feedback from my manager that my teammate really appreciated that I was giving him space to figure things out on his own rather than micro-managing him!
I think I do my best work when it's something no one asked for in the first place. I also do great work when I have a good back-and-forth to clarify requirements until I know exactly what we're going for. Where I get discouraged is when I get half-baked requirements, carefully consider the problem and provide a best effort solution, then get clarification that would have been great to know up front, now requiring a re-think.
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".
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.
That's right. It's all part of the back-and-forth of good faith.
It's also why senior's are so important and why the dichotomy between product people and technical people is so inane and stupid.
There are developers that just want to keep their head down and write code, you'll never get those people to ask the questions that are being suggested here.
Yeah honestly I know I’m capable of asking those kinds of questions, but I’ve been realizing lately that I just don’t want to. I want other people to figure their shit out first, then come to me when it’s ready to be built.
Few users / clients actually know tho'. They think in wants. They think in - because of past disappointments - what they can get. They think in what they think the boss wants. They rarely think in actual biz needs.
You can give them *exactly* what they ask for and still be wrong. The user / client isn't going to admit that. Nah. They'll just play the "Damn IT" card and it'll be back to the drawing board but now with a shit load of tension.
It's best to ask - sooner rather than later.
True. The problem is, eventually those devs will want to be promoted and yet haven't exhibited any business acumen or any skills outside their technology focus.
When new / jr devs ask me what they should learn, I say: business, marketing, etc, and improve your comms skills ( speaking, writing, and listening). That's not the answer they get typically.
"Can you tell me more about why you want X?"
They actually need Y.
Time saved.
The real fun begins when an executive skips down the chain to directly order you to provide X, accompanied with another order forbidding any further efforts on Y.
Then, six months later, said executive shows back up demanding to know why you haven't provisioned this great Y thingamajig that his golf buddy was raving about.
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?"
I treat my managers the same. :)
This could be interpreted like you've switched to giving them an implicit command
an intake of breath is risky because it could be poisonous and kill you. Yet you wouldn't suggest someone stop breathing.
There's lots of ways this could be interpreted, that shouldn't stop anyone from attempting to execute a teachable moment.
> 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.
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.
Poor planning on their part doesn’t constitute an emergency on your part
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.
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.
(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."
(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.
To reinforce (1), eveninterestin a topic from a leader, if clear operational structure isn't present, will result in additional work. Be careful what you care about!
Same thing happens all the in my relationship with my partner:
I text "oh hey if you haven't left yet could you bring my umbrella?"
She arrives 20 minutes late and $20 down, having received message after she left and taken a detour to buy me an umbrella.
Communicating stakes and priorities is hard! I think I've been explicit but she doesn't read messages as literally as me. I should have said "if you have already left then please don't worry as I have a coat on".
This negative framing is terribly disheartening. She went to the time and trouble to pick out an umbrella especially for you, and she did it because this is clearly not the first time so it makes sense for there to be a spare umbrella.
Maybe it’s also time foryouto step up and buyhera thoughtfully selected umbrella.
This negative framing is terribly disheartening. She went to the time and trouble to pick out an umbrella especially for you, and she did it because this is clearly not the first time so it makes sense for there to be a spare umbrella.
What a giant leap. Thinking like that is a sure fire way to have relationship problems.
Respecting your partner's executive choices and self-assigned preferences, and recognising that they follow motivations of their own, leads to relationship problems?
Only for those carrying the controlling/abusive danger flag.
Respecting your partner's executive choices and self-assigned preferences, and recognising that they follow motivations of their own, leads to relationship problems?
Not what I said, and quite unrelated.[1] Moreover, it is not whatyousaid, even if that's what you meant. You said:
She went to the time and trouble to pick out an umbrella especially for you, and she did it because this is clearly not the first time so it makes sense for there to be a spare umbrella.
These are significant assumptions to make. Jumping to conclusions like that will lead to relationship problems.
Of course, I could go on and talk about how the behavior could be problematic even if the assumptions are true, but it depends on the particulars of the two people involved. Certainly, if the assumption is true, the behavior is not necessarily a positive one. Intentions matter. As do outcomes. Don't ignore the latter.
[1] And yes, that could trivially lead to relationship problems, and could also trivially lead to relationship bliss, given how generic your comment is.
Jumping to conclusions like that will lead to relationship problems
Good grief. No, it will lead to a moment of amused bonding over the burgeoning umbrella collection you now share, and a perpetual anniversary in my calendar labelled "New umbrella day".
The point I'm making, and shall reiterate, is that maintenance of social relationships is utterly dissimilar to how we manage organisations.
she did it because this is clearly not the first time so it makes sense for there to be a spare umbrella.
Where are you getting this information from?
IMO there is nothing wrong with the comment you're replying to. They didn't say that they didn'tappreciatethe gesture. Just that it taught them that they needed to be more explicit about the priorities of requests.
Where are you getting this information from?
Thevery first clausein their remark gives that this is a typical and repeated scenario.
They didn't say that they didn't appreciate the gesture
The point here is that social relationships are not a valid analog for management.
Where are you getting this information from?
A different thread of conversation in this post is arguing over what good faith means.
The above poster is clearly not showing good faith because they're assuming negative behaviors. That's where they got the information from.
I would appreciate the thoughtful gesture, but I would rather have 20 more minutes with my signifiant other than an umbrella. And that's the point of the article. Disrupting a work pipeline to answer an executive question might be fitting here. Sure they would have liked the answer to their question (umbrella) but they didn't want to lose 20 person hours to that question.
Good communication is key.
And spend 20 mins less waiting in there rain for them
I think that's a uncharitable reading of a post that goes:
1. I took this action.
2. It had this impact on another person.
3. I should have taken a different action!
I've had similar experiences working with people and my big takeaway is that communication is fraught with such little challenges.
Best way I've found to avoid this is to leave as little to assumption as is reasonable to.
A part of me thinks that some of the pitfalls in communication comes from culture, where different groups of people have different expectations of how much to leave to assumption, etc. Hard to really put it clearly, but I would love to read some research around this.
The problem with leaving little to assumption is that this tends to be verbose and people tend not to like to listen to long speeches and will simply not read long text. So, as everything in engineering, it's a tradeoff.
I micromanager will work around that by splitting the requirements up in tiny jira tasks that cannot be ignore easily, and then follow up daily on every single task.
This completely kills initiative, tough, and may reduce the value added by each team member by 50% or more.
The only time to use such tactics is with someone who is acting in very bad faith and at risk of being fired. It can be done for a while to establish an example, while rewarding better behavior with more autonomy gradually.
If they still ignore the instructions, then that's proper grounds for firing them (even in Europe), and if they chose to leave because of it, well, that's ok too.
My spouse gets frustrated with me for being too verbose in my requests, and also frustrated with me for following instructions in "the wrong way" when those requests were under-specified in the first place. Knowing "the right level" to communicate requests can be challenging in any relationship, even one with 20 years of shared experience to fall back on.
Yup, pretty much this. Thank you!
I have the opposite takeaway. If I experience that people follow my input too literally, I try to figure out which of the following three applies:
1) I've been micromanaging them too much, and they stopped thinking for themselves. Possibly partly because they were lazy, or annoyed or because they thought it was ok.
2) They don't have the ability to see that my instructions did not make sense in the situation they're in. Maybe they didn't have the training, self confidence or initiative to realize that the instructions were assuming a situation that was different from the actual one.
3) There is real bad faith involved.
Most cases fall roughly under 1). In that case, the proper response is to reduce the level of micromanagement, and let the people figure more things out on their own. That means that even when I spot that they're making minor mistakes, I need to keep my mouth shut. People need to make mistakes sometime so they can learn from them. If they want to discuss those topics with me, I will try to treat them as peers not subordinates. While doing this I also try to make it clear that I expect independent thought.
Then there are the cases that fall under 2). In those cases, I try to give tasks or instructions that are either intrinsically easier, or if that is not possible, I may break the tasks down to more manageable units, while trying to actively provide training and mentoring.
The rarest case is 3) If this is the case, I will provide some push back. Luckily, as a tech lead, I don't have direct reports, so I can refer such cases to the line manager if it gets too bad.
Yeah but you can't be consistently fully mathematically correct with people around you, its often the parts you don't even realize have some room for mis-interpretation that tend to bite back hardest IMHO
The other pitfall of trying to clarify all assumptions is that your message then becomes too long. Then the reader actually will skim over the main points, which makes it worse.
So yeah, it takes a lot of works to communicate efficiency, no matter the length of the end results
Yeah but then you write out a spec that costs you a ton of time, that won't be read, or won't be followed to the letter, and you'll be known as someone who obsesses over specifying things. If you spend that much effort communicating what's needed, you might as well just do it yourself.
(I have no idea what your generalized statement is in relation to btw, so I could be talking out of my ass as well, lol)
Funny how you recognise in the last sentence that you actually made a communication mistake but are still trying to blame her.
How are they blaming her?
Imagine you're his partner reading this. How would you feel?
If I was their partner I would read this as, "Oh, they understand that we have two different ways of communication and they are changingtheir ownbehavior instead of asking me to change mine so that we both end up saving time/money. This is what it looks like to be a good partner? Pointing out that your partner thinks differently from you is not the same thing asblamingthem for something.
Could you explain, in your own words instead of putting the responsibility on me to interpret your meaning, how they are blaming their partner for the interaction?
Indifferent, probably. The thing missing from the post is the conversation where the miscommunication was identified and discussed, so I don't know how his partner would feel. In this hypothetical, I'm the partner, and I'm the kind of person who knows all relationships have communication errors. If we recovered gracefully, then saying "20 minutes late and $20 down" is hardly dirty laundry. Would probably even appreciate that he uses it as a reminder of how to reduce ambiguity communicating with me, as I have my own reminders of how to reduce ambiguity communicating with him.
Maybe it would help to explain how you would feel. I would get a good chuckle at recalling this particular memory.
Imagine you're his partner reading this.
No. Do not imagine it nor ponder it. Go right to her andask.
And in the long run, she needs to be coached to articulate without being asked every time (if that is the case with her).
Generally, when people start imagining how I feel about X, they are wrong over 50% of the time, which leads to an escalation of problems. Don't wonder how I feel. Ask me explicitly.
As for the wider discussion: The path to Hell is paved with good intentions. I struggled with this often until I read some negotiations books,allof which said "Don't give credit to someone who did something for you that was of no value to you, and signal to them that this is of no value so that they do not expect a concession from you as a result." For random one offs with random people, it's fine to appreciate their (totally wasteful) effort because you don't have to deal with it often. But in a long term relationship it becomes a currency and causes long term stress. Not only are these efforts creating problem for you (money wasted, time wasted, etc), in the long run the other partywillexpect credit for it, whichwillfeel like an added insult to injury.
if you haven't left yet
I don't think OP have made any communication mistakes.
That reaction will lead to a beautiful umbrella collection ;)
She didn't follow your directions, they seem to have been quite clear, why is that your fault?
Part of communication is also to give feedback about such things
GP expressed the need for an umbrella and she went above and beyond. He now knows that she's the type of person who will do so, so now knows to add a disclaimer to not go out of her way. Or he can just appreciate the fact that she will go out of her way and sincerely express that appreciation.
No fault here for either party. Just a learning experience. And as you say, he can give the feedback that she didn't need to go out of her way as well.
Exactly, I write a literal message with a literal if/then meaning. She reads it as "my partner is out in the rain and would like me to help".
Of course I think _my_ communication style is "better". But the best communication style is actually the one that communicates your thoughts to the other person, not the one that "makes the most sense".
And meanwhile there are still cases where it will be the other way around and I am going "well I said X, but surely you could have read between the lines..."
So yeah, the best response is to tell her about the miscommunication so she can know better next time, but it's stupid to try and say she was "wrong". It takes two!
To me the premise "if you haven't left yet" implies "don't go out of your way" and adding that would be redundant. But not everyone sees things the same way so you have to adapt communication individually based on experience.
There's possibly a buried lede there, of the GF feeling like she cannot ask questions for clarifications or cannot let the commenter down.
Or infinite reasons:
- Rain distribution isn't uniform, it poured where she was and thought it was necessary.
And/or
- Overestimating time/sunk cost fallacy ("it's just going to take 2 minutes")
And/or
- Giving less importance to ponctuality than others
And/or
- She didn't have one and thought it was a good idea, worth being late
And/or ...
It's not about 'fault' really, it's about achieving better outcomes by learning from previous experiences.
Sometimes, people's thoughts for you overpower your explicit directions - she obviously didn't want you without your umbrella.
I’ve had those kinds of things in a relationship too - both with a partner ‘taking initiative’ to do something for me that I didn’t actually ask them or want them to do - and vice versa, partner hurt that I didn’t take initiative to do something for them that they didn’t ask (but secretly wanted) me to do.
Either way is unnecessarily frustrating, and while I’m willing to be a little bit patient while I train people out of the practice, sometimes it’s just not tenable. If you pause, take a breath, try to think critically, and both pre-answer anticipated questions and ask questions for clarification - better communication and more reasonable expectations are absolutely achievable. You’ve just got to be willing to commit to working on it. Not everybody sees the value in that unfortunately.
I know my partner well enough, so I'm not worried about communication with her, but what's hard about communication is that some people take things literally, some people try to read into questions what isn't there, and some people ask ambiguous questions.
I've gotten feedback from some people that my communication is too terse and from other people that it is too longwinded. I can adapt to people I communicate regularly with (like my partner, people on my team, etc.), but it is not possible to do anything with that feedback in terms of first time communication or communication with infrequent collaborators.
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.
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.
No, Junior technical staff are terrible at scope estimation and will commit to ridiculous things on impossible timelines without realizing it.
I have an extreme instance where the ceo bypassed everyone to directly drive a group of sde1s. When pushed for same day deliveries and the sde1s pushed through, and everyone else were publicly humiliated for taking much longer to deliver. It resulted in weekend marathons and all nighters being a regular occurence for the group he directly took charge of, and the demands escalated to timelines needed in hours instead of days, and a mess of code. The already popular copy paste driven write once development pattern became the only means of survival to many. (code so bad that it's only written once, nobody had the confidence to modify. New, similar request? Copy paste, modify, and manually test.)
I am so glad to have escaped that, for many more reasons. Still working off that near burnout and putting off getting back to work since a few months. (burnout not due to overwork, I escaped that madness, but other dysfunctional things in the organisation.)
Almost by definition, junior engineers are incapable of distinguishing "this is the literal request from the stakeholder" and "this is what the stakeholder is actually trying to accomplish."
On the other hand, the game of telephone up and down the hierarchy frequently confuses important details.
In that case, CC the engineering boss while discussing with the IC; otherwise what's really going on is the nontechnical is trying to hide their impact on the IC's workload from their boss.
This leaves aside for the moment that I don't think nontechnical leadership belongs in a technology company.
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.
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.
Exactly this. Context is king - and as someone else stated below knowing how to get to the actual ask vs. how the ask is being phrased is something that comes with experience.
That said, it should also be the role of the more senior technical leadership to involve junior technical staff in the process so they have the opportunity to grow. For example, CEO asks CTO how long it would take to add X feature so CTO loops a junior engineer into the conversation and demonstrates how to get to what the CEO isactuallyasking (which may or may not be X) vs. just providing a time estimate for X feature. Hopefully the CEO learns something here too but ymmv.
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.
"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.
"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?
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.
Additionally, as long as documentation is made throughout, this can still be valuable.
* 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'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.
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.
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.
I wish I could give my status updates like this.
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.
“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.
I actually love when I'm given a time limit for a task. It enables me to engage my prioritization skills more effectively.
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).
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.
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 athttps://twitter.com/TechEmailsand 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.
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.
"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."
Offload the cognitive workload onto them.
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 itfeelslike 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.
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.
And “ask” as a noun is an abomination.
Let's table that for now and see if we can fast-follow with an iteration to our nouning paradigm.
Oh, and "table" as a verb can mean either postpone of start it now...
Like “drop” can mean “release” or “cancel”.
I've heard "drop" used as a noun meaning release far more often. Plus the phrasing is usually slightly different when used as a verb.
"Let's table this" I've heard used both ways, extremely ambiguous.
I have no asker, and I must scream.
I had to re-read it twice, only to start thinking that it is a typo and was intended to be "task", but even then it did not make too much sense to me. Do people really use "ask" as a noun?!
Imprecise asks from managers and leaders cause a disproportionate amount of turmoil and wheel-spinning.
This isn't just for managers, that applies to everyone. I'm currently working through a backlog of tasks, some of which are years overdue (or no longer relevant). The primary issue as I see it, is that the vast majority of these tasks are minor issue, not worth allocation someone to full time, they are also so poorly worded and lacking in description that nobody is going to be able to look through the backlog and pick something to work on for a few hours.
Tasks and bug reports linger when you don't provide enough context for someone to easily get a sense of what you're asking. You could spend weeks working on something only to find out that it's either not relevant or that you're going in the wrong direction.
Clarity is hard.
I have a rule. If something has been sitting in the ticketing system for more than six months, I close it out. People will bug you about things that are important and you can make a new ticket. And if you are in a position where the highest value thing you can do for a company is to look back and fix the things that were never high priority, do yourself a favor and look for a new team or a new company… It’s not good to work on low priority work.
That's a terrible and destructive practice. You can set the priority to 'low' if you want. You can filter low priority tickets out of your todo list. But don't close the ticket unless you are actually confirming that it is no longer an issue.
That's a terrible and destructive practice.
Harsh words :) Care to elaborate on why?
For what it's worth, I don't literally delete... I mark it as "backlogged" and then it goes into the vast pool of backlogged tickets that are searchable, but no one is going in there just to look around because there's so much in there. And I think that's healthy... if you are working at a successful company, priorities are likely to shift over time. Something might be top of mind today, but you look at it two years later and it turns out it was never important. Or there's a bug that came up once but wasn't a big deal and doesn't seem to be re-occuring.
Open-but-backlogged is OK!
I'm sorry for using such harsh words; I was flabbergasted and lost my calm. As for why, there's so many reasons that it's hard to find where to start, without launching into a thousand word essay.
- Usuallyclosedmeans eitherthis has been doneor elsewe've thought about this and decided it doesn't need doing; closing a ticket just because it's old adds noise to that signal, especially when you can already filter by date.
- Creating new tickets that are duplicates of closed tickets also adds noise, time and confusion when searching for those issues, and for people who were monitoring those tickets, and can make the status of the work unclear to people other than yourself.
- Tickets are valuable documentation; duplicating tickets is duplicating work.
- There are many possible reasons why someone isn't hounding you every six months about an old ticket, which aren't all "it doesn't matter anymore". Maybe it's not their personality to do so. Maybe it's because they thought they already did what was necessary: create the ticket and leave it in capable hands. Maybe it's because they got frustrated and switched to a different product.
- Priorities shift over time, but not always in a direction of older --> lower priority. Sometimes everything gets swept off the table to fight a fire, but once the fire is out, the old stuff becomes high priority again. Sometimes a blocking issue needs to get resolved first, and that can take time. Sometimes a ticket requires a lot of resources that only become available down the road.
Etc!
My language sensor is always tickling when I am seeing "ask" used as a noun. So I looked around and found this:
https://english.stackexchange.com/questions/4246/can-or-shou...
Just in case others are similarly affected.
Nice one, when I read it, I assumed a typo and thattaskwas meant.
That's a really good teach.
Thanks for the inform.
That was an interesting read, thanks!
I used to work in the government, and we actually didn’t have this problem. A senior might ask for something, but —
- We seldom got imprecise questions.
- When we did get imprecise questions, we would ask a series of follow-up and clarifying questions until the task was correctly scoped.
It was only after leaving the government for the private sector that anyone was treating their superiors like infallible god-emperors. No one seems to think they can question a directive, even when the purpose of that question is to better fulfill the directive. It’s as bewildering as it is sycophantic. And worse, I don’t seem to be able to explain how crazy this is to anyone who has been in the private sector for a long time.
Your comparison is interesting. I've only worked in government (US military, but also with many federal civilians), where we've all internalized the notion that we're incompetent in every way compared to the private sector. But I could see your observation being a function of:
1. More managers and senior leaders "coming up through the ranks." A lot of people in government have been in the same agency or office for decades, so there's a lot of institutional knowledge that I suspect doesn't (even can't) exist in private companies. At least in the US DoD, it seems very rare to bring in people "off the street" through lateral entry for management jobs. People need clearances and institutional knowledge that they can only get by spending time working their way up.
2. Many things are pretty well specified in laws, policies, doctrine, etc. There's a way to do them, and the people directing and doing them both know what it entails.
The downside of these things is the institutional inertia and bureaucracy for which we're famous.
where we've all internalized the notion that we're incompetent in every way compared to the private sector.
We might have worked for the same government. It was a pretty big shock to me when I transitioned to the private sector, and found that many and most things had been done better in the government.
That said, the government is a large place, and is not uniform. Same with private businesses, which are arguably even more varied.
I imagine part of it is that it's far easier to lose your job disagreeing with your superiors in the private sector ("Not a culture fit", "Not a team player"). It's better to just go along with stuff sometimes because most of the time systemic failure takes years to manifest.
I think you're right. Within the DoD, you see a dichotomy between uniformed military service members and federal civilians. The people in uniform (especially officers, especially between years 5 to 15 of their careers) exist in a brutal up-or-out promotion system. The civilians, on the other hand, are known to be impossible to fire and can remain in their positions for life (it's hyperbole, but there's some truth to it). In general, I think you can see it in the degree to which they "[treat] their superiors like infallible god-emperors."
I wish there was a version of Copilot that can do time-estimates for programming related questions.
Estimates for trivial programming tasks are trivial estimates.
In a real software engineering process not one task is trivial. The implementation depends on the architecture of the project and specifics around it. These things are out of LLM scope, even if it knows the language.
Even non-trivial feature estimations should be easy if the process is good.
It's the bugs that you can't estimate because they're unforeseen consequence by definition.
It's the bugs that you can't estimate because they're unforeseen consequence by definition.
Well, it doesn't need to be better than human estimates. Just less time-consuming.
I was thinking that would be a great witty to add “A.I.” to project management tools. I mean, there are so many developers that hate writing estimates that they wouldn’t complain if an LLM built into the bug tracker made something up.
Yes. And it would be great if it would adapt to the current state of the code base. So managers can see the effect of technical debt immediately in the time estimates.
Is this a callout for micro management?
Of course it is good to be clear on expectations, but the more specific leadership has to be in order to achieve their goals, the more likely they end up with a team that only does things when asked.
The hyper specificity usually comes from a place of not wanting to share the larger context; in my experience it's for office politics reasons.
not wanting to share the larger context
... or not being capable of articulating the larger context (edit: in which it would be the perfect case to do micro management)
I'm in a place where we need more specific details on what is expected. This comes due to a lack of clarity in each ask, a lack of clarity in vision, a surplus of ego from management, and a lack of autonomy given to employees. Every time I think I know enough to make a decision on my own (or even within my team) and move forward, 6 months later I'm told to re-do it, because that wasn't the plan. I was never told the plan, and when I ask, I'm ignored. I don't think they know what they're doing either, which is why there is no clarity. They just know that it should be their decision, not mine, so I'm always wrong by default. It wasn't always like this, new managers, new style, and a lot of political nonsense.
Just a month ago I was on a call with 6 VPs. I wasn't invited, but someone added me, because I wrote all the code for the thing they would be talking about. It took me a good 40 minutes to get some very simple questions answered. I had to ask over and over again, in many different ways. At the end, I thought I had clarity. I did exactly what they asked, and then when it was done, and I explained exactly what I did (because I thought it was stupid), I was told to change it. My saving grace, was I knew it was stupid, so I made it very easy on myself to flip the logic, so that only took about 2 minutes. Before I spoke up on the call, they were going to ask someone to manually do some extra work at the start/end of every automated run, instead of just asking me to update the automation. It was like they weren't aware the whole process was automated end-to-end and it could be modified to make it whatever we want.
Some organizations are so dysfunctional there is no way to win.
A leader says “we need to be modern, no excuses!” Not wanting to seem dumb, nobody asks what that means
disappointed when a critical project is not being shipped on time
So everybody is just fine with seeming dumb
The leader has a history of interpreting questions as excuses, and so the choice is to personally look dumb now by asking a question, or being only partially embarrassed later as part of a more diffused dumbness.
Lose/lose unless you do the extra work to effectively communicate with someone who has a history of shooting messengers.
Or you could just share a plan for that "modernization project that focused on a sweeping tech upgrade" you've prepared along, highlighting the implications for feature delays, and potentially waste only the time spend preparing said plan. Don't even need to ask a question/"excuse"
I seems unlikely that they meant a modern API syntax (as the OP mentioned)
One of the biggest time wasters is when the request doesn't come with the context. It's like they try to save time by keeping everything on a need to know basis but the "why" or the context is a really important aspect of providing a good solution because without that you don't know what they've thought of beforehand.
For example, "we need to block requests from X country". No problem, that's easy enough with most firewall services but why are we doing it? If it's to make contractual guarantees that no traffic will originate from that country then that's not going to work because anyone can easily bypass country code detection mechanisms in 2 minutes with a VPN.
Sounds like an XY Problem:
- user wants to do X but doesn't know how
- they think that Y will work, and asks for help on Y
- others are confused because Y seems strange
the vpn vs country thing is the canonical example of engineering vs management and present in most organizations.
lot's of ppl died on that hill already and it was implemented regardless, don't be another victim.
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.
Some places will just be bad, that's fine.
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.
Even though it sounds crazy, using a ticket system like asana or jira foreveryrequest is quite effective.
What's crazy about that? It's the best way of tracking requests and seeing where an employee's time is going
Think outside developer land. Imagine marketing using tickets for all requests amongst all people in the org. It will sound crazy to them. I think it's a great idea, but I don't think most people would.
Is there a point in time that we can locate when we stopped calling them "requests" and started calling them "asks" even though it's grammatically incorrect?
Propagating* incorrectness because someone with power did it first is surely a symptom of something negative. Is there a name for it?
> Propaganding incorrectness because someone with power did it first is surely a symptom of something negative. Is there a name for it?
Did you mean "propagating"? (Only asking because your comment was about incorrectness...)
Being passive aggressive with your snark doesn't make it civil, it makes it smarmy.
“I expect this to take about 2 weeks and not cause major deprioritization of other efforts. If that timeline doesn’t seem accurate after diving in, or if you end up having to prioritize against other things, reach out to me ASAP.”
Forget about it. This is impossible, unless you literally have nothing else to do. And that's really unlikely, or they wouldn't talk about prioritization in the first place.
If you really want to know if someone understood what you asked of them, ask them questions about it. If they can't answer correctly, you didn't explain enough yet.
Impossible because for most people something that literally takes "2 weeks" cannot be done without deprioritization of something else, or becauseanyadditional work cannot be done without deprioritization of something else?
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.”
For someone like me, this also adds a lot of stress (which over time turns into demoralization and inefficiency). I gotta watch the clock while I'm doing the thing, and maybe optimize my approach for time as I'm going. What if I'm a little distracted that day? Did I get so few results because I'm bad at this or because it was actually complicated? Do I turn it in half done or spend another ten minutes and not tell him?
You spend the extra 10 minutes, and not tell him, immediately you're a 1.5x engineer.
I had a "manager" (he was hired as a senior dev and became a dev manager because we really needed one) who would handle this by saying things like "look into X for me but don't spend more than Y time on it", with the Y usually being an hour.
When people tell me that I normally times their expectation by three.
Saves on the risk of them being disappointed by an hours output.
I’ve had this in interviews where people say, ‘don’t spend more than 5 hours in this prep task’ and then wonder why it isn’t a golden monument of best practices and tech
Ideally, people do only what's needed before it's needed without being asked.
Which management behavior evolves the organization in that direction?
That's an optimizing function with a range of five variables (delegator and delegate, subject matter and issue, and context) and a domain with multiple cost and quality scales.
There are times when the "imprecise ask" is right, but most situations call for adverse bias (i.e., considering it a management smell).
Jean-Louis Gassee famously tamed disputes between engineering heads by saying he's going to do the thing neither one wanted, so they had to get together to overcome him.
Intelligence and decision-making depend mostly on focus: knowing what to ignore. If you're the delegate, it's your job to manage all that is being ignored (and only hoist it in the degenerate case that it cannot be ignored).
But business context is the local valuation function: if you're in QA or doing medical software or your organization is highly politicized, then yes, adopt a defensive posture. But mostly if you have faith in yourself and others, you can get the temperature right.
Request
Every leveling guideline I’ve seen for any tech company both first hand and second hand has a criteria of “dealing with ambiguity”. As a senior, you should be use to getting vague asks and operate on the “flip side” where you take responsibility for disambiguating.
People in power often don't have the expertise to be competent in their role. They didn't rise on competence. So, don't expect more from them.
I like the problem statement in the essay, but it's generally more effective to give context instead of more precise instructions. The people you work with are smart and capable -- if you tell them what problem you're trying to solve, they will adjust accordingly. Plus, giving context fills in so many more gaps than just the time and effort expectations.
Here's a related post I wrote:https://pcounsel.blog/always-give-a-good-reason/
Related site on Slack/messaging etiquette:https://nohello.net/
your
Not wanting to seem dumb
is to me the root cause, not the imprecise asks
Be clear about how it should be prioritized: “I expect this to take about 2 weeks and not cause major deprioritization of other efforts.
Does "major deprioritization" have understood meaning in that org?
Is "2 weeks" in person-weeks or calendar-weeks?
Is the "expect" an assessment of the effort, a business requirement, a priority-based resource allocation, or an attempt at whip-cracking?
Any context that would help understand the priority?
"We have a high-priority request from Jane. We're trying to close a deal with FooMart, which might be enough to land our next funding round. Sales asked if we could have a demo-grade integration of the CatJet preview with FooMart's CRM within 2 weeks. What could we pull off reliably, and who else's help do you expect to need? ... We could pause almost anything in the Gantt chart except Sally's critical path for the MVP. ..."
No Hello:https://nohello.net/
The higher up somebody is, the more they prioritize speed over quality. Low level employees do not have the breadth of context that higher-ups do. The more that each level understands this about the other, the more aligned their expectations will be.
In my experience if you give a time estimate, people make that the new metric to optimize to. So they spend 4 hours creating something that looks like 20 mins.
Most articles like this focus on what is lost for employees at the whim of a careless manager, but I think they often miss a point: the team researching X random thing means they may learn other knowledge and their overall understanding of things goes up which - though inefficient - may have value later.
Moreover, work is broadly inefficient because human coordination is inefficient. People bring their own stories and narratives and goals. Hence the reason the 20min ask is now the 4 hours to make it look like 20 mins. Treating it like something that can be optimized misses the point of it.
The ideas in the article are solid and I agree with most of them. I would only counter by adding the following: those who get used to providing quick direct responses to owner/manager/executive inquiries become incredibly valuable and can get a seat at important tables they would otherwise not be privy to. This is part of the informal signaling that good managers use to identify talent and leadership to grow.
In addition, from being on both ends, asking for what the priority is for a new ask is incredibly important. It not only gives you cover for when other things slip due to the new ask but forces the manager to consider the slippage (always good to remind them as well) and be clear if this is a "drop everything" or "when you have time" task.
I've been lucky to work at some places that are very clear about their asks and also are very open to you coming back and saying "So I looked into this and to do it the way you want it will take 2 weeks or I can get it 90% of the way there in <1hr". Being open to that back-and-forth as well as surfacing the different time estimates are both important and can benefit everyone. It's sometimes hard to know, as an employee, when asked to do something if it's important that it be "pixel perfect"/"exactly to spec" or if it was just an idea someone had who would be happy to settle for an alternative that takes a fraction of the time to complete.
As a manager I've found how important time-boxing certain tasks are and asking people to circle back if it's taking longer or if they later realize the task is bigger than either of us thought. Sometimes we have to take the time and sometimes it's something that we need to think about a lot more before we dive in. The worst is when you get busy with something else then find out the next day that someone spent all day on a task you thought would take <1 hour. Sometimes it's a misunderstanding of what needs to be done, sometimes it's the person trying to match exactly what you asked for even if an alternative would be way faster and completely acceptable, and sometimes the task just is a bigger task than you anticipated.
Bottom line, always communicate (both up and down the chain) if you think a new ask is going to affect other timelines, communicate if something is going to take longer than anticipated, and communicate if you have a faster alternative. So really, just communicate. I totally understand there are companies where CYA or blame-culture makes the idea of being open/honest about things like this is dangerous for your career prospects (at least at that company). To that I just say: consider finding a place that doesn't have so much "office politics", they absolutely exist and they are so much nicer to work at.
A moment's verbal reflection can radically reduce the time wastage.
One time I told my producer that for each sentence in her email -- mostly questions -- each sentence translated to an HOUR of my time.
This is fine, I'm happy to work to answer her questions.
However, she was horrified :)
It's easy for people to talk or ask questions without considering the consequences!
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.
A corollary, your unfounded assumptions create a huge headache for everyone else.
We had a business person in a leadership role who made an unfounded assumption about some content. We were pretty sure she was wrong and asked her if she was sure at least 3x. Come to find out, her assumptions were wrong. Suddenly it was an emergency that had to be addressed within two weeks. Did she have to spend long hours and weekends addressing the situation? Of course not. Was there any fallout on her? Of course not.
For random asks, I prefer having full context. More information is better. Instead of "can we get a estimate for getting X done ASAP?" How about "Can we get an estimate for X because new customer Y really wants it and we're trying to close that deal week?"
An executive asks a quick question
Rule: When people interrupt with a "quick question",
\a\ theirinterruptionmay well be quick; but
\b\ they haven't considered that an adequateanswermay take time; so
\c\ they are almost always surprised and/or offended if you indicate (b)
The big problem I've seen is being asked to do prototypes that absolutely will not be used in production, and will require rewriting half of it, rather than spending an extra hour or less to do something resembling the production version.
So I spend two hours, because half that time was prototyping something that's already very well known to be A Thing people can do, with only one obvious best practice everyone does, not really much that needs to be prototyped or explored.
I'm talking about things like not bothering to get a JSON parser working if it's nontrivial in a certain language, but using string split nonsense and some simpler file, because managers like to see regular progress without large gaps.
I'vealsodone this kind of thing to myself plenty of times when in a hurry.
Imprecise asks from managers and leaders cause a disproportionate amount of turmoil and wheel-spinning. To combat this, leaders should be very precise with the amount of time investment they’re asking for when they ask for things.
The amount of time expected is one additional piece of information to add to an "imprecise ask," and it should be part of the conversation, but it really makes me wonder how information-starved your subordinates are if it serves as a valuable parity check for them.
How about this: never launch an ambiguously specified days-long task for a subordinate with an offhand comment? Always have a slightly more extensive conversation about it? It's really hard to maintain a major disconnect through the duration of a substantive three minute conversation. Try it. Try to write a realistic, two-way three minute conversation where a major misunderstanding between two people isn't uncovered. You're basically writing a comedy sketch.
Human speech is ambiguous, and it makes up for this by providing many different ways of describing a single situation, each conveying additional contextual information. If you say something in one way, the person you're talking to might understand it one of three different ways, but each time you say the same thing in slightly different words, the intersection of possible interpretations tightens down very quickly. Because of this, being strategically chatty is incredibly important for clear communication. Striving to be precise in your use of words is necessary and valuable in engineering, but it can never completely replace redundancy, except in formalized contexts. (Engineers can see strategic chattiness as a superpower, but for managers, it's an expected skill.)
It's great to explicitly mention time expectations, but even if you don't, your subordinates should sense something wrong and speak up if the amount of time you spend discussing something with them isn't proportionate to the ask. If a subordinate thinks you are asking for days of work in an offhand comment and doesn't speak up for clarification, then either they are scared to talk to you, or they are accustomed to being starved for time with you. Either way, it likely this stems from a pathological power distance.
Imprecise asks from managers and leaders cause a disproportionate amount of turmoil and wheel-spinning.
True. But the scope is far too limited. When you listen *very* carefully to comms you quickly realize how much fill-in-the-blanks and vagueness (is back filled with assumption) is typically involved. This happen with leaders, managers, colleagues, family, friends, etc.
"It's not what you say, it's what they hear."
Sure, off the clock it doesn't always lead to turmoil and wheel-spinning, but it can. Regardless, those habits get brought into the office.
All that said, leaders and managers of a culture where asking questions (for clarity) is discouraged need to rethink their culture, as well as the quality of their comms.
I think that this largely comes down to company culture and how comfortable people are pushing back at senior leaders (the onus being on senior leaders to make it comfortable for people under them to push back). The best leaders, in my experience, show humbleness and a willingness to listen.
That said, sometimes working on bullshit is just part of the gig. If there’s too much of it, by all means look for another job, but don’t be the guy who is always second guessing management.
It's everyones responsibility here. I think part of the problem here is words like "manager", "executive" and "leader". That creates weird ideas of hierarchy when a better mental image is just that people have different roles. Then it's much easier to ask good questions and avoid stuff like this.
This is a super complicated topic as the thread here demonstrates. It all comes down to the quality of communication that managers have cultivated with their direct reports. Great communication means that DRs a) understand many of your assumptions and don't require that everything be explicit, and b) that they feel comfortable asking you to clarify as required. A phone call as opposed to async writing is a great way to get to the ambiguities in your ask that matter to the people who will perform the task. Exhaustively writing out all assumptions to defend against all interpretations is simply a symptom of a pathological org or team.
80% of this is is solved when you, as the receiver of the request say, “great, let me dig in a little and I’ll circle back later today/tomorrow/end of the week with an update and any clarifying questions” 1. This lets you get a little smarter on the ask, and potential resource investment. 2. Quickly reporting back some rough estimates/responses + an estimate of what’s require to get the more complete answer usually ends the conversation there. 3. If not, you now have the opportunity to pin them down on expectations and resource investment etc.
Aren't those all examples of people attempting to go 'above and beyond' in hopes of their 'hard work' resulting in promotion outside of the normal channels?
If you don't want people to trip over themselves engaging in politics, have clear guidelines regarding what gets promotions, when and what the criteria is.
The trouble is - 'leadership'likesnot having clear guidelines because thentheyget to play politics, which is the only thing most of them are any good at.
As a non-manager, I try to get into a mode where I'm frequently saying:
I'm doing this unless somebody recommends otherwise
...in order to preempt being asked to do it. Even if it ends up being the same task that I'd have been asked to do.
Transparent Autonomy > Forgiveness > Permission
If it was my idea, and I'm also the one doing it, so much communication hassle goes away.
With a bit of patience you can shift the conversation from specific asks to more general conversations about priority alignment, which I think results in fewer detail related communication mishaps and lowers the risk of malicious compliance or other sorts of wasteful non-alignment.
The focus on "imprecise" in this article seems like a slippery slope towards micromanagement . Train your manager to trust you. Then train them to leave you alone. You're the expert here.
This frees up time for them to manage up on your behalf and to figure out how to get you a raise or open doors for your career growth, which is better for everybody.
One of my best professional attributes is my willingness to stop everything until I understand what's going on if I'm confused or something seems unclear to me.
“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.
Most CEOs at large organisations are aware of what their ask causes: A lot of them went through their own "schooling" spending weekends on these tasks that are then largely ignored. If they don't want a lot of time spend they will typically be very explicit.
This is incredibly boring to me. Create an environment where people feel safe and empowered to speak up and show them you value their judgment and are genuinely receptive to feedback, hire great people, manage out the bad fits, practice basic empathy as a matter of habit, and this will not be a major issue, just correct deviations from expectations with careful nudges. A healthy culture is the highest leverage tool in your toolbelt.
What the article describes isn’t wrong, but is duct tape over a poor work culture. Just fix the culture. Doesn’t that sound more fun?
(If you aren’t in a position to influence the culture and can’t afford to leave the job, then absolutely deploy the duct tape. My heart goes out to those in this category)
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.