Your small imprecise ask is a big waste of their time
staysaasy.com
staysaasy.com
This leaves aside for the moment that I don't think nontechnical leadership belongs in a technology company.
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.)
“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.
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 is actually asking (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.
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.
> Do not, DO NOT, assume they are too busy to answer clarifying questions as you work on the [t]ask.
Any tips for this when you're working remotely and online chat isn't an option?
In-person, it feels easier to ask lots of small, quick, imprecise, and half-baked questions because you get a quick reply then can follow-up. Over email though, I end up spending more time articulating what I'm confused about and trying to pre-empt possible replies because it feels more formal and interruptive. Video calls can take time to arrange and have a lot of overhead.
One trick I use for client projects is to have a Google Doc that I append small questions to as they crop up, I ping the client occasionally to check the doc (or they subscribe to edit notifications from the doc), the client writes the answers directly into the doc, and this repeats as the task goes on.
Pros: the client doesn't have to answer everything in one go, client gets less notifications, feels like less formal writing is fine on both ends, feels more collaborative, it's easy to add follow-up questions next to the relevant snippet, you can add comments to the doc for quick discussions and to assign/track small tasks, easy for others to read and contribute to.
(Edit: I'm thinking contract work here with non-techy people where you don't know them or their business well, and you'll have lots of little questions)
I would try to fix this first. You're putting constraints/feelings onto email that other people don't. Just fire off an email with your question(s). Unless you're emailing the CEO or something, just type your questions stream-of-consciousness and hit send. Don't be afraid of immediately sending a second email "oh I forgot this question too, thanks! $QUESTION"
Take a look at https://twitter.com/TechEmails and the emails from high-level executives. Most of them are super informal. Some of the older ones between Bill Gates and MS execs are barely more coherent than text messages between a couple HS freshmen. I'm not saying to start including emojis in your emails to your boss's boss's boss's boss, but an informal quick email won't be a career ender by any stretch.
Hard, HARD disagree from me. The point is not at all about formality or appearing bad towards your boss, it's about avoiding misunderstandings, confusion, and endless followups that multiply the latency and further increase misunderstanding and confusion.
Your trick with a shared doc is also a great idea and has two additional benefits. 1. The act of writing is an extra step to help you clarify your question. 2. The question and answer are now documented for the future. Both big wins versus a quick chat that then needs to be written down.
Offload the cognitive workload onto them.
Whenever I get a new issue to work on, I go through it, plan what I'm going to do, dig in my head for potential issues/conflicts, create a sometimes giant list of questions, break it apart into who will most likely be able to answer what question, then start the online chat conversations.
The latter could potentially work with external clients (perhaps using their actual phone number rather than a video call) if it was arranged in advance. i.e. you have a kick-off meeting where you discuss how much contact the client wants and what kinds of questions should lead to immediate communication vs. slower async communication.
Take the example from the article:
> Please look into this for me. Do not, DO NOT, spend more than 20 minutes on this. Please come back with whatever you have after 20 minutes.
Each person looking at this is going to achieve a slightly different amount in 20 mins. Even if we ignore that, there's no guarantee that the manager making the request is going to get what they need from 20 minutes of your effort.
In 'agile' working environments, I regularly see discovery/research tasks labelled as a 'spike' and given a 'time-box'. I often question: "What happens if we don't discover what we want to in that amount of time?", and there's generally no good answer. What actually tends to happen is the 'time-box' is expanded until we found out what we needed to. So time is a terrible proxy for effort, substance, or scope. The same is true here, the manager has some idea of what they want to find out, and you better hope you can do that amount of research in their sized time-box.
I think the later examples on this article are better:
> Are you expecting something super thorough, [...] or a quick write up?
This is much more valuable because we're talking in terms of the scope of work, not how long it will take. When anyone measures in time, there's no guarantee that you'll get what you want in that amount of time, and then what? Well, we add more time!
> "What happens if we don't discover what we wna to in that amount of time"
Then we know that the answer could not be discovered in that amount of time we had estimated and we adjust our expectation on the effort to do the research on this task. As a manager, thats one of the key information that I would want to know.
* Someone else can continue research, where they left off.
* The research they did, can be discussed amongst the team, possibly by a more senior teammate.
* It may reveal that further research isn’t necessary, and this effort should be shelved until a later date.
I guess it depends on how high priority it is. But everything is high priority to management.
I am absolutely _shocked_ you've never received an answer to this.
There's no guarantee you'll get what you want in _any_ amount of time. You absolutely need to timebox, everything & anything, to make sure projects aren't going off the rails and ending up in the trash. This applies even to personal/solo work too. You can keep working on anything forever, it's much better to force a stopping point, get feedback (or ship it) and decide if it's worth continuing or not.
The mechanism at work here is forcing people to prioritize. If you're very good at prioritizing then a timebox maybe doesn't make sense, but even then, it may be hard to resist continuing to work on something to a higher degree of quality than is needed without a timebox.
We reevaluate with more information than we have right now.
This pattern of task is helpful for things where the unknowns are substantially greater than the knowns. The idea is to incrementally shift the balance until the knowns are _enough_ to actually make an informed guess instead of just a wild guess.
There's a bug in the legacy codebase. The replacement is nearly finished and slated for launch in two months. How do we handle that bug?
We could ignore it, we could just tell someone "go fix it, whatever it takes". Neither is a great option.
So: "Go investigate this bug, don't spend more than an hour, and let me know how far you get."
By the time you're done, we'll have a _better_ idea what the shape of the problem is.
Maybe you come back and say "yeah I found the problem's in this area, I need to sit down with someone that understands the business logic better to untangle this and then we can tweak and fix it"--great, we'll get you the appropriate resources and try and follow through with a fix. We'll figure on something like an afternoon of interruption for you.
Maybe you just come back saying "it's in this part of the code and it's pretty organized, just couldn't quite track it down yet" and we can greenlight more time based on some level of confidence that it won't be an enormous task. (Or maybe not, depending on the actual scope and severity of the bug.) We'll figure on a day or two of interruption to get it over the line.
Maybe you come back saying "it's somewhere in this eldritch spaghetti, and when I stared into it the abyss starting back at me sent chills up my spine and the pictures on my walls wept blood, please don't send me back there" and it's clear it's not worth pursuing any further and we drop it.
I wish I could give my status updates like this.
> When anyone measures in time, there's no guarantee that you'll get what you want in that amount of time, and then what? Well, we add more time!
I believe you that this has been your experience, but it’s not universal. The problem is treating “what you want” as the end in itself, which is why the article also mentions “tell people what you need it for”: “our biggest client needs to know before they renew their contract” is worth more money, and thus more employee-hours, than “I was just curious”. At the leadership level, you are expected to realize that you can’t chase every benefit, and strategically focus on those with the best cost ratio.
It is a managers job to delegate tasks appropriately. That isn't just assigning bodies to jobs. But assigning the right job to the right people with the right skills.
I created a new rule for myself after this. The cost of the ask, should be proportionate to the cost of delivering that ask. Now if I get an ask that is very costly, I will wait and delay and request escalations and such. The person asking should show that it is worth the cost by doing their due diligence and getting approval from people higher up the food chain. If the ask is a bunch of BS, then I will never hear about it again. If it is worthy, I will do it and also I get the added bonus of the effort not being done in secret without the appropriate visibility.
1. Never do anything on the first ask. If it's important, they will ask again and I'll think about it.
2. If I have to stay late, you have to stay late. You don't want to stay late? Guess it wasn't important then.
(1) Everyone needs to operate in good faith. I've observed leaders ask their direct reports for something off-hand, without giving it more than 5 seconds of thought. I've watched direct reports operate as a "human command line", requiring precise syntax before they'll act. Don't be either of these type of people.
(2) If you're a manager/leader, there are no "one-off" requests. Any ask carries an implicit priority over everything else. You have to work within the overall system and environment, otherwise you are forcing your team to make choices about those things. Don't be this kind of manager/leader.
(3) If you're the one receiving an ask, help your requestor understand what's involved. Eliminate implicit assumptions; that's where the dragons lie. Communicate, inform, educate. Nail down what the requestor wants and be sure you both agree.
We do these things in the name of efficiency, of not wanting to waste time if it's not necessary. I've found if we all try to help each other in these requestor-requestee situations, it generally makes life much more tolerable.
Operating in good faith is so important.
Leaders who operate by pushing the limits of what they can get away with are a stark contrast from leaders who operate to form good faith relationships with their team. Managers who make thoughtless demands all the time will steadily lose their best employees. In my experience, after a long enough time these leaders are reduced to having only juniors reporting to them because everyone with experience avoids the team.
Your description of “human command line” team members is a great example of bad faith operation, too. I’ve worked with people who thought they were so clever by demanding that even the smallest request be delivered through a form they created or a document they need people to fill out before they can get started, which they might try to debate, critique, or circulate for a couple days before they’ll even think about working on your small task. They think they’ve insulated themselves from small asks because nobody wants to go through all the trouble of asking the question just right to get them to acknowledge it, but over time they build a reputation as difficult to work with.
Another variant is the person who tries to exploit ambiguities in every request; These people have a good idea of what’s being asked of them, but they think they’re “teaching a lesson” by exploiting ambiguities in the request to deliver something that technically matches the letter of the request, but that everyone knows isn’t really what was needed or wanted.
Not coincidentally, most of the people I knew who tried these game found themselves laid off in the past year. I think people can tolerate a bad faith coworker who at least does some work for a while, but when it’s time to downsize they’re at the top of everyone’s list to remove.
Sounds like they're completely right, then. "Don't bother Steve unless you really need something from him", which is exactly what he wants.
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.
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.
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.
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.
Alternately, he’s solely there because the HR requirements are onerous and take time, and he has dramatically misunderstood 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.
Ask a fair salary, do what you can, act in good faith.
Success often follows being the person remembered as being helpful or useful.
It's a sneaky trap, because you think "I'm making them so empowered!" but you're actually stressing them out and reducing their focus.
As a head's up, the even sneakier trap is that different team members thrive best with different approaches. Some people flail and fret without explicit, procedural direction and others are completely discouraged by it and do feel disempowered.
Rather than taking your lesson as the New Universal Rule, make sure to just add it to your toolbox while trying to learn how to discern who needs what. It's good that you're learning to work better with the people who need more explicit direction, but you're going to burn out managing a team where all of them need that all the time (and if you only practice one approach, you'll eventually get there: filtering down to only have those team members who do thrive by it)
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!
Is this different from the “human command line” mode of operation that the grandparent mentioned?
It's curious how "ask" has transformed from an ancient verb into a modern, trendy and awkward noun.
According to the OED, nounification began with colloquial usage in Australia.
https://www.oed.com/search/dictionary/?q=ask
We all know that language is a constantly changing biosocial cognitive artifact, so there really are no rules.
But this usage grates like chewing sand, especially when we have perfectly good synonyms just sitting there, unused.
I've since given up, it's just too overwhelming. For every "ask" I squash, there's 5 more being thrown at me in Slack and emails and Google Docs and Slides.
Knowing how to use all 4 (affect noun, affect verb, effect noun, effect verb) correctly feels like a superpower.
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 ;)
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.
"Could you action this ask from Bob in Finance?"
"Key learnings this quarter"...
Of course, this also happens in real life. I was building new kitchen cabinets and when we got to the doors I gave my wife two options of top rails. Again, one was harder than the other, but I didn't mention that because I wanted her to pick the one she liked better. Of course, she chose the harder one because she thought it would be the easier one even though it turned out that she preferred the other one.
So... always give the other person all the information.
You should absolutely do that (I tell my team to inform me if what I'm asking doesn't make sense.) If I'm coming to someone with a request, it's because I think they're the right person to address it. Just tell me if I'm off-base.
FWIW, I encourage everyone to not care about the hierarchy, so that may not work in every place.
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?
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.
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.
You could have a percent of each sprint dedicated to one-offs, but then are they really one-offs in the colloquial sense?
The smaller the team and org, the easier it is to handle the one-offs (imo), because we can more directly connect the request to tangible impact more often. At the very least, in a small co your manager (or C suite executive) would easily back you up as the engineer if other executives were questioning output or something etc etc
In larger orgs the extra communication burden makes the one off requests more expensive
I've had managers give stupid orders, and seen them immediately backpedal when asked "would you write that down for me, please?"
So yeah, I'll definitely act in good faith but unfortunately I can't assume good faith on the other side, I occasionally need to be a human command line.
I'd suggest that "good faith" means turning those stupid orders into sane orders. In a case like this, help your manager -- educate them.
If your relationship is tenuous, I get this can be hard. Show your good faith and explain to your manager in clear detail why something is stupid. Manage up, as they say.
Feeding into those whims is rarely good for anyone, except the manager's ego.
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.
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.
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.”
There was resentment yes, but I did trust them!
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.
I don't want to nitpick but the change of a single word is going to make significant difference in the outcome, time spent, satisfaction, next steps, etc.
Nail down what the requestor *needs* and be sure you both agree...
I wish I had $20 for everytime the initial "I want..." followed by a couple of questions - or even the famous The 5 Whys - evolved into the true (business) need.
They actually need Y.
Time saved.
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.
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.
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.
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.
Most people have a vague idea of the outcome they want, and the reason for it. They also quickly know what they don't want _once they see it_
And that's why agile and iterative development is actually great for GUI based user interactive app development.
One of the advantages of being helpless is not taking responsibility.
Do you think people in either of those situation would agree they acted in bad faith? The leader could say they were trying to avoid bikeshedding on what was clearly a quick and simple task. The direct reports may bring up multiple past interactions where imprecise requests led to a waste of their time and negative feedback. Telling everyone to just "don't be these type of people" is not very likely to be helpful.
This situation sounds more like people trying to cover their ass so they aren't blamed for something later. Work to get things accomplished, not to avoid some kind of criticism.
So, rather than being these types of people -- be a person who helps get something accomplished and maybe improves this situation along the way.
Playing social games is non-optional.
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.
That's giving me PTSD. Run if you ever find yourself in such a team. Operating in good faith should be the base line of working together in and with a team but for some it's not. Then it just turns into politics and ego games.
Yeah... until the 4th round of guessing what they mean, resulting in months of tossed out work for lack of the exec elaborating on what they want. think "i need a sales report". You'd think there would be a better brief after the first time.
What happens in every case is that the priority of that task for the assignee is the highest. Sometimes this is a help, because often people have to multitask a lot of tasks with the same priority.
But in even more cases it might be a huge distraction.
I've recently started teaching my daughters how to play chess. When they hang the queen, I ask them "do you really want to do that move?". If they ask why not, I tell them. If they insist on doing it anyway, I capture the queen.
They've learned to listen when I ask "do you really want to do that?"
I treat my managers the same. :)
There's lots of ways this could be interpreted, that shouldn't stop anyone from attempting to execute a teachable moment.
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.
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.
Hahahaha yeah.
Ok here's what happens - if an engineer is honest with a non-engineer about how long something will take, the non-engineer will be shocked and say no.
>Clarify the expected time investment: “Please look into this for me. Do not, DO NOT, spend more than 20 minutes on this. Please come back with whatever you have after 20 minutes.”
Are you insane? Nothing takes 20 minutes! You may as well say "don't look at this, go for a coffee and then ball park it for me". We're doing complex work, we need time to consider. If you don't want us to spend time considering it, just... don't ask!
This is part of the problem - you don't want to tell your boss to fuck off, and you don't want to tell them you spent 6 hours on something they think takes 20 minutes. So instead.... everything else slips. Which is why good engineering management is keeping the engineers as far away as possible from the people who are going to unwittingly nerd snipe them.
The classic sign of weak engineering is saying yes to the former.
When asked by weak management to do a task that is outside the scope of what can be trivially done, it is the responsibility of the worker to do one of three things (depending on technical and social context):
A) Ask, "how should that be done?" This works if the manager is also technical, and is using vague tasking as a way to compensate for their own technical incompetence, push that shit right back to them. Asking this question forces them to come to grips with the realities of the scope and mechanisms of what they are asking.
B) Inform them, "That will take X resources, what are your expectations?" (Where X is an immense amount of man-hours, money, old-school RuneScape GP, whatever). This is for non-technical managers and serves a similar role as (a), making them come to grips with the fact what they are asking is a major request that needs to go through the normal procedural mechanisms for such a thing, not something they can authorize off the cuff.
C) Say "No". This is not possible in every organization or every social context, but organizations that want to be high-performing will make this possible. In high-performance engineering contexts, engineering will has a strong veto power over dumb bullshit that can only be overridden high up in the C-suite. Understanding how and when to exercise this veto is an important skill for engineering to develop.
They may survive as orgs, especially if its just one weak limb in a larger basically competent organization, or if they serve a sufficiently non-competitive niche where being efficient isn't a particularly important goal.
NASA is an organization where the outside incentives prioritize a particularly high level of safety in engineering, the US Naval Nuclear program has outside incentives that force both high efficiency/readiness and high safety, my local coffee shop closes sometimes because they run out of cups.
Organizations are shaped by the incentives that support them. If there's no particular reason (or, indeed, if there is any room at all to survive) for an organization to be efficient or timely, it won't be.
https://english.stackexchange.com/questions/4246/can-or-shou...
Just in case others are similarly affected.
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.
- 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
lot's of ppl died on that hill already and it was implemented regardless, don't be another victim.
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.
- 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.
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.
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.
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.
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.
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.
- Usually closed means either this has been done or else we'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!
> 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.
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.
"Let's table this" I've heard used both ways, extremely ambiguous.
Propagating* 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...)
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)
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.
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?
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.
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.
... or not being capable of articulating the larger context (edit: in which it would be the perfect case to do micro management)
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.
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.
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. ..."
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've also done this kind of thing to myself plenty of times when in a hurry.
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
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.
Here's a related post I wrote: https://pcounsel.blog/always-give-a-good-reason/
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' likes not having clear guidelines because then they get to play politics, which is the only thing most of them are any good at.
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.
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!
Rule: When people interrupt with a "quick question",
\a\ their interruption may well be quick; but
\b\ they haven't considered that an adequate answer may take time; so
\c\ they are almost always surprised and/or offended if you indicate (b)
> disappointed when a critical project is not being shipped on time
So everybody is just fine with seeming dumb
Lose/lose unless you do the extra work to effectively communicate with someone who has a history of shooting messengers.
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.
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.
Well, it doesn't need to be better than human estimates. Just less time-consuming.
What can be estimated by humans and computers alike is how much time does it take an average programmer to implement something if it's generic enough. An expert system consisting of LLM+more would spit out the stack overflow copy/paste answer and the 'more' part would give you the average effort needed to copy/paste that code in the project and adapt the variables,etc.
If you have "bugs" that you can resolve by simple stack exchange googling you need to up your project tooling and programming guidelines.
What's left is real bugs where you operate in the dark and no computer will able to estimate the size of that room because the light switch is off. Once you run head into it and light turns on, you're able to clearly see the size of the room and do the calculation yourself.
> Not wanting to seem dumb
is to me the root cause, not the imprecise asks
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".
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.
(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)
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.
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.
So yeah, it takes a lot of works to communicate efficiency, no matter the length of the end results
Part of communication is also to give feedback about such things
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.
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!
- 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 ...
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'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.
Maybe it’s also time for you to step up and buy her a thoughtfully selected 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't appreciate the gesture. Just that it taught them that they needed to be more explicit about the priorities of requests.
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.
The very first clause in 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.
Good communication is key.
What a giant leap. Thinking like that is a sure fire way to have relationship problems.
Only for those carrying the controlling/abusive danger flag.
Not what I said, and quite unrelated.[1] Moreover, it is not what you said, 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.
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.
1. I took this action.
2. It had this impact on another person.
3. I should have taken a different action!
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?
No. Do not imagine it nor ponder it. Go right to her and ask.
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, all of 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 party will expect credit for it, which will feel like an added insult to injury.
I don't think OP have made any communication mistakes.