12 ms·

Your small imprecise ask is a big waste of their time

501 points by zdw 3y ago

colpabar 3y ago
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.
- simmerup 3y ago
  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
2C64 3y ago
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.
- wildrhythms 3y ago
  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.
  - Cthulhu_ 3y ago
    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.
    - kortilla 3y ago
      No, Junior technical staff are terrible at scope estimation and will commit to ridiculous things on impossible timelines without realizing it.
      - MajimasEyepatch 3y ago
        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."
      - phanimahesh 3y ago
        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.)
  - closeparen 3y ago
    On the other hand, the game of telephone up and down the hierarchy frequently confuses important details.
    - s1gnp0st 3y ago
      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.
  - clnq 3y ago
    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.
- Xcelerate 3y ago
  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?
  - sarchertech 3y ago
    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.
    - 2C64 3y ago
      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 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.
  - mdgrech23 3y ago
    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.
- Exoristos 3y ago
  "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?
  - 2C64 3y ago
    The stories I could tell if it wouldn't out me!
- creer 3y ago
  "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.
- deleted 3y ago
  [deleted]
boxed 3y ago
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.
mrweasel 3y ago
> 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.
- chadash 3y ago
  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.
  - mitthrowaway2 3y ago
    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.
    - chadash 3y ago
      > 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.
bjackman 3y ago
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".
- zeusk 3y ago
  Sometimes, people's thoughts for you overpower your explicit directions - she obviously didn't want you without your umbrella.
- wsgeorge 3y ago
  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.
  - informalo 3y ago
    https://news.ycombinator.com/item?id=37176703 https://news.ycombinator.com/item?id=37176703
    - wsgeorge 3y ago
      Yup, pretty much this. Thank you!
  - saiya-jin 3y ago
    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
oregondan 3y ago
Related site on Slack/messaging etiquette: https://nohello.net/ https://nohello.net/
nickelpro 3y ago
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.
- ilaksh 3y ago
  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.
  - nickelpro 3y ago
    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.
chadash 3y ago
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.
zknill 3y ago
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!
- naru_s 3y ago
  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.
  - btown 3y ago
    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.
deleted 3y ago
[deleted]
RandomLensman 3y ago
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.
nickjj 3y ago
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.
- john-tells-all 3y ago
  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 https://xyproblem.info/ https://xyproblem.info/
- geraldhh 3y ago
  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.
eviks 3y ago
> 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
- ape4 3y ago
  I seems unlikely that they meant a modern API syntax (as the OP mentioned)
- datadrivenangel 3y ago
  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.
  - eviks 3y ago
    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"
wccrawford 3y ago
> “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.
- SoftTalker 3y ago
  Impossible because for most people something that literally takes "2 weeks" cannot be done without deprioritization of something else, or because any additional work cannot be done without deprioritization of something else?
j-a-a-p 3y ago
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.
- wildrhythms 3y ago
  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.
  - j-a-a-p 3y ago
    > 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)
- al_borland 3y ago
  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.
heresie-dabord 3y ago
> An executive asks a quick question 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)
jmartrican 3y ago
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.
- anitil 3y ago
  I have two rules to increase the cost on the requester - 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.
say_it_as_it_is 3y ago
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.
jroseattle 3y ago
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.
- chiefalchemist 3y ago
  > 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.
  - jroseattle 3y ago
    That's right. It's all part of the back-and-forth of good faith.
    - PH95VuimJjqBqy 3y ago
      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.
chiefalchemist 3y ago
> 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.
amelius 3y ago
I wish there was a version of Copilot that can do time-estimates for programming related questions.
- PaulHoule 3y ago
  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.
  - amelius 3y ago
    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.
- zare_st 3y ago
  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.
  - amelius 3y ago
    > 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.
    - zare_st 3y ago
      My point is that some things cannot be precisely estimated in any case. 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.
everdrive 3y ago
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.
- HalcyonicStorm 3y ago
  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.
  - warner25 3y ago
    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."
- warner25 3y ago
  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.
legendofbrando 3y ago
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.
joshstrange 3y ago
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.
layer8 3y ago
And “ask” as a noun is an abomination.
- electrondood 3y ago
  Let's table that for now and see if we can fast-follow with an iteration to our nouning paradigm.
  - Vicinity9635 3y ago
    [dead]
  - oblio 3y ago
    Oh, and "table" as a verb can mean either postpone of start it now...
    - layer8 3y ago
      Like “drop” can mean “release” or “cancel”.
      - oblio 3y ago
        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.
- johnisgood 3y ago
  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?!
generic92034 3y ago
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-should-ask-ever-be-used-as-a-noun https://english.stackexchange.com/questions/4246/can-or-shou... Just in case others are similarly affected.
- electrondood 3y ago
  That's a really good teach.
- doodpants 3y ago
  Thanks for the inform.
- Hackbraten 3y ago
  That was an interesting read, thanks!
- j-a-a-p 3y ago
  Nice one, when I read it, I assumed a typo and that task was meant.
jwsteigerwalt 3y ago
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.
onehair 3y ago
your > Not wanting to seem dumb is to me the root cause, not the imprecise asks
balderdash 3y ago
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.
dkarl 3y ago
> 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.
lukas099 3y ago
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.
danielmarkbruce 3y ago
Even though it sounds crazy, using a ticket system like asana or jira for every request is quite effective.
- Minor49er 3y ago
  What's crazy about that? It's the best way of tracking requests and seeing where an employee's time is going
  - danielmarkbruce 3y ago
    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.
    - Minor49er 3y ago
      Don't marketers often do something like this though? They usually track "deals" or "projects" which get logged in a system of some kind
CoffeeOnWrite 3y ago
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)
ram417 3y ago
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/ https://pcounsel.blog/always-give-a-good-reason/
icedchai 3y ago
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?"
seanwilson 3y ago
> 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)
- pc86 3y ago
  > Over email though, I end up spending more time articulating what I'm confused about and trying to pre-empt possible replies because it feels more formal and interruptive I would try to fix this first. You're putting constraints/feelings onto email that other people don't. Just fire off an email with your question(s). Unless you're emailing the CEO or something, just type your questions stream-of-consciousness and hit send. Don't be afraid of immediately sending a second email "oh I forgot this question too, thanks! $QUESTION" Take a look at https://twitter.com/TechEmails 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.
  - 3y ago
john-tells-all 3y ago
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!
scarface_74 3y ago
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.
__MatrixMan__ 3y ago
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.
neilv 3y ago
> 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. ..."
tonymet 3y ago
Request
alexashka 3y ago
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' likes not having clear guidelines because then they get to play politics, which is the only thing most of them are any good at.
irrational 3y ago
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.
WendyTheWillow 3y ago
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.
Vicinity9635 3y ago
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?
- sib 3y ago
  >> 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...)
  - Vicinity9635 3y ago
    [dead]
w10-1 3y ago
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.
blueyes 3y ago
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.
moandcompany 3y ago
No Hello: https://nohello.net/ https://nohello.net/
orblivion 3y ago
> 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?
- SilverBirch 3y ago
  You spend the extra 10 minutes, and not tell him, immediately you're a 1.5x engineer.
SilverBirch 3y ago
> “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.
eternityforest 3y ago
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've also done this kind of thing to myself plenty of times when in a hurry.

501 points by zdw 3y ago

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.

simmerup 3y ago
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

2C64 3y ago

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.

wildrhythms 3y ago
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.
- Cthulhu_ 3y ago
  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.
  - kortilla 3y ago
    No, Junior technical staff are terrible at scope estimation and will commit to ridiculous things on impossible timelines without realizing it.
    - MajimasEyepatch 3y ago
      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."
    - phanimahesh 3y ago
      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.)
- closeparen 3y ago
  On the other hand, the game of telephone up and down the hierarchy frequently confuses important details.
  - s1gnp0st 3y ago
    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.
- clnq 3y ago
  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.
Xcelerate 3y ago
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?
- sarchertech 3y ago
  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.
  - 2C64 3y ago
    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 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.
- mdgrech23 3y ago
  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.
Exoristos 3y ago
"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?
- 2C64 3y ago
  The stories I could tell if it wouldn't out me!
creer 3y ago
"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.
deleted 3y ago
[deleted]

boxed 3y ago

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.

mrweasel 3y ago

> 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.

chadash 3y ago
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.
- mitthrowaway2 3y ago
  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.
  - chadash 3y ago
    > 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.

bjackman 3y ago

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".

zeusk 3y ago
Sometimes, people's thoughts for you overpower your explicit directions - she obviously didn't want you without your umbrella.
wsgeorge 3y ago
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.
- informalo 3y ago
  https://news.ycombinator.com/item?id=37176703 https://news.ycombinator.com/item?id=37176703
  - wsgeorge 3y ago
    Yup, pretty much this. Thank you!
- saiya-jin 3y ago
  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

oregondan 3y ago

Related site on Slack/messaging etiquette: https://nohello.net/ https://nohello.net/

nickelpro 3y ago

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.

ilaksh 3y ago
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.
- nickelpro 3y ago
  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.

chadash 3y ago

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.

zknill 3y ago

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!

naru_s 3y ago
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.
- btown 3y ago
  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.

deleted 3y ago

[deleted]

RandomLensman 3y ago

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.

nickjj 3y ago

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.

john-tells-all 3y ago
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 https://xyproblem.info/ https://xyproblem.info/
geraldhh 3y ago
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.

eviks 3y ago

> 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

ape4 3y ago
I seems unlikely that they meant a modern API syntax (as the OP mentioned)
datadrivenangel 3y ago
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.
- eviks 3y ago
  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"

wccrawford 3y ago

> “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.

SoftTalker 3y ago
Impossible because for most people something that literally takes "2 weeks" cannot be done without deprioritization of something else, or because any additional work cannot be done without deprioritization of something else?

j-a-a-p 3y ago

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.

wildrhythms 3y ago
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.
- j-a-a-p 3y ago
  > 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)
al_borland 3y ago
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.

heresie-dabord 3y ago

> An executive asks a quick question 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)

jmartrican 3y ago

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.

anitil 3y ago
I have two rules to increase the cost on the requester - 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.

say_it_as_it_is 3y ago

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.

jroseattle 3y ago

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.

chiefalchemist 3y ago
> 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.
- jroseattle 3y ago
  That's right. It's all part of the back-and-forth of good faith.
  - PH95VuimJjqBqy 3y ago
    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.

chiefalchemist 3y ago

> 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.

amelius 3y ago

I wish there was a version of Copilot that can do time-estimates for programming related questions.

PaulHoule 3y ago
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.
- amelius 3y ago
  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.
zare_st 3y ago
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.
- amelius 3y ago
  > 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.
  - zare_st 3y ago
    My point is that some things cannot be precisely estimated in any case. 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.

everdrive 3y ago

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.

HalcyonicStorm 3y ago
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.
- warner25 3y ago
  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."
warner25 3y ago
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.

legendofbrando 3y ago

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.

joshstrange 3y ago

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.

layer8 3y ago

And “ask” as a noun is an abomination.

electrondood 3y ago
Let's table that for now and see if we can fast-follow with an iteration to our nouning paradigm.
- Vicinity9635 3y ago
  [dead]
- oblio 3y ago
  Oh, and "table" as a verb can mean either postpone of start it now...
  - layer8 3y ago
    Like “drop” can mean “release” or “cancel”.
    - oblio 3y ago
      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.
johnisgood 3y ago
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?!

generic92034 3y ago

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-should-ask-ever-be-used-as-a-noun https://english.stackexchange.com/questions/4246/can-or-shou... Just in case others are similarly affected.

electrondood 3y ago
That's a really good teach.
doodpants 3y ago
Thanks for the inform.
Hackbraten 3y ago
That was an interesting read, thanks!
j-a-a-p 3y ago
Nice one, when I read it, I assumed a typo and that task was meant.

jwsteigerwalt 3y ago

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.

onehair 3y ago

your > Not wanting to seem dumb is to me the root cause, not the imprecise asks

balderdash 3y ago

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.

dkarl 3y ago

> 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.

lukas099 3y ago

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.

danielmarkbruce 3y ago

Even though it sounds crazy, using a ticket system like asana or jira for every request is quite effective.

Minor49er 3y ago
What's crazy about that? It's the best way of tracking requests and seeing where an employee's time is going
- danielmarkbruce 3y ago
  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.
  - Minor49er 3y ago
    Don't marketers often do something like this though? They usually track "deals" or "projects" which get logged in a system of some kind

CoffeeOnWrite 3y ago

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)

ram417 3y ago

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/ https://pcounsel.blog/always-give-a-good-reason/

icedchai 3y ago

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?"

seanwilson 3y ago

> 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)

pc86 3y ago
> Over email though, I end up spending more time articulating what I'm confused about and trying to pre-empt possible replies because it feels more formal and interruptive I would try to fix this first. You're putting constraints/feelings onto email that other people don't. Just fire off an email with your question(s). Unless you're emailing the CEO or something, just type your questions stream-of-consciousness and hit send. Don't be afraid of immediately sending a second email "oh I forgot this question too, thanks! $QUESTION" Take a look at https://twitter.com/TechEmails 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.
- 3y ago

john-tells-all 3y ago

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!

scarface_74 3y ago

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.

__MatrixMan__ 3y ago

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.

neilv 3y ago

> 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. ..."

tonymet 3y ago

Request

alexashka 3y ago

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' likes not having clear guidelines because then they get to play politics, which is the only thing most of them are any good at.

irrational 3y ago

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.

WendyTheWillow 3y ago

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.

Vicinity9635 3y ago

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?

sib 3y ago
>> 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...)
- Vicinity9635 3y ago
  [dead]

w10-1 3y ago

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.

blueyes 3y ago

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.

moandcompany 3y ago

No Hello: https://nohello.net/ https://nohello.net/

orblivion 3y ago

> 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?

SilverBirch 3y ago
You spend the extra 10 minutes, and not tell him, immediately you're a 1.5x engineer.

SilverBirch 3y ago

> “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.

eternityforest 3y ago

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've also done this kind of thing to myself plenty of times when in a hurry.