221–230 of 464 posts
"I just want to make sure ..." vs "I want to make sure ..."
"Just letting you know ..." vs "I want to let you know ...", "I want you to know ..."
"This is just one example ..." vs "This is one example ..."
"I'm just going to unblock ..." vs "I'm unblocking ..."
I struggle with this myself, it's a self-effacing learned behavior.
Earlier quoted context omitted.
The next trick to learn is that the customer will still blame you for not telling them that landscape won’t fix it. Then you’ll waste less time the next time your customer asks for something stupid. Fail fast can work well for client management.
Solid advice. I shouldn’t have pushed so hard to get heard. Should have just made it landscape (which took minutes) and let it fail. The trick is balancing that against wanting to be a consultant to them (i.e. somebody who knows what he’s doing and offers viable solutions that they themselves can’t think of) rather than a mindless pair of hands that gets directed by them to throw code at a wall.
I’m not exactly sure why. Maybe paying hundreds of dollars an hour is a sort of status symbol?
Earlier quoted context omitted.
The next trick to learn is that the customer will still blame you for not telling them that landscape won’t fix it. Then you’ll waste less time the next time your customer asks for something stupid. Fail fast can work well for client management.
Solid advice. I shouldn’t have pushed so hard to get heard. Should have just made it landscape (which took minutes) and let it fail. The trick is balancing that against wanting to be a consultant to them (i.e. somebody who knows what he’s doing and offers viable solutions that they themselves can’t think of) rather than a mindless pair of hands that gets directed by them to throw code at a wall.
Anyway, they can recognize the failure of {y}. Now it's time to make my suggestion again, not in an asshole way, but rather: "I think we should do {x}" as if it's the first time I said it; or "Let's revisit what you're trying to accomplish here."
The happy story would be that people are abashed at my great wisdom and sorrowful that they did not heed it. More accurate story is that no acknowledgement of anything occurs, but they are more receptive in the moment, and even a bit more receptive in the future. Took a long time to arrive at this, sadly, my great wisdom notwithstanding.
And if you're a woman, cut the word "just" from your vocabulary, especially in professional communication. It diminishes your voice. "I just want to make sure ..." vs "I want to make sure ..." "Just letting you know ..." vs "I want to let you know ...", "I want you to know ..." "This is just one example ..." vs "This is one example ..." "I'm just going to unblock ..." vs "I'm unblocking ..." I struggle with this myse…
Not saying it's not good to learn about how "just" might be perceived or avoided but I am surprised this article is getting so much support. I feel like in the environment I'm in "just" never implied anything negative (e.g. lack of understanding on the receiver's part, making it seem like they should have considered ... but didn't, etc.), rather: - I don't yet understand why steps x, y, z are necessary. To me it woul…
Earlier quoted context omitted.
“CNR, not enough detail, ticket closed, reopen with more information if your problem persists”. I don't have time to dig information out of people in order to try to help them, if they can't make any effort to help me help them when I ask for more information. This is of course one of the reasons I'm not generally client facing these days!
I have the opposite problem with many technical support teams these days. I supply them with a full breakdown of what error I encountered, the reproduction code/commands/data, my configuration, what I think happened, how I tested for that, alternative explanations I came up with and tried, traces, trace markers, vendor-standard dumps, and a call to action of the next piece of information I need (usually an explanatio…
This is likely to be it: perhaps they are effectively paid by the ticket or response (due to how pay/bonus/other structures align) so paying attention to all that information costs them significantly. Their ideal is to get a reply to you ASAP so they'll prioritise tickets where they can bang out a link to an existing knowledge-base article.
> No shade to the offshore teams
In some cases it may also be that they are employing cheaply rather than not carefully, so some of the people aren't great to start with (either technically, in terms of their claims to understand English well, or both), but I think you are right generally to give them more credit than that and suggesting that most of the time it is due to unhelpful metrics & targets (you get what you measure!). That and failing to provide sufficient support/documentation/training to the people trying to help you (sometimes you might know far more than them as they first saw the system last week).
> Most of the time they simply escalate the case straight towards the development team
They are likely not to do this on first response, even if it is very much the right thing to do in a complex case, because of a negative metric deliberately in place to reduce load on dev teams (which may be as under-staffed/under-trained and more over-worked than the support team).
> I have the opposite problem with many technical support teams these days. I supply them
I try to be forgiving about lack of information in the initial request, as long as they are understanding about my response being a curt “I need more information” and a list of example data¹. If I ask for more information and just get a vague response, that is when I knee-jerk hit the CNR button.
----
[1] the standard “what was on-screen, details of the form you were editing², what did you do, what did you expect, what happened instead, include error messages³ and data you entered², and at what time did this occur (be as accurate as you can)⁴…”
[2] which parts of this may vary significantly depending on the situation, and providing all possible information may be a waste of their time and mine, which is part of why I try not to mind the initial information being slight vague.
[3] this doesn't tend to vary, as a rule I always want to know any messages that were emitted and feel justified in being immediately irritated when this data isn't included from the start - “I got an error” does not suffice.
[4] this can be as vital as the error/exception messages, sometimes more so, if I need to go diving into logs for further clues.
And if you're a woman, cut the word "just" from your vocabulary, especially in professional communication. It diminishes your voice. "I just want to make sure ..." vs "I want to make sure ..." "Just letting you know ..." vs "I want to let you know ...", "I want you to know ..." "This is just one example ..." vs "This is one example ..." "I'm just going to unblock ..." vs "I'm unblocking ..." I struggle with this myse…
Earlier quoted context omitted.
Venting is a pretty normal and healthy way of dealing with emotions.
And responding to venting with advice/criticism is also (clearly) perfectly normal right?
In some contexts, though, offering advice can feel like you want to close the person down rather than listen to them, that you think their problems aren't serious enough because you'd solve them easily. I'm guessing you've had at least one occasion where you have a work issue, and your manager is casually dropping solutions that didn't work, and you were frustrated with them as a result.
As such, the consequence of offering solutions is that it can damage your relationships with people, or at least not use an opportunity to strengthen them.
Earlier quoted context omitted.
Food for thought: It's quite possible you're not understanding the client well, and are indeed wasting their time. I've worked with contractors where you know what you want and why, but the developer insists on throwing up a lot of objections on how it won't solve the problem for x or y reason. Changing the orientation of a PDF seems like the kind of request that should be straight forward and not require a lot of he…
I changed the orientation of the PDF as requested. This did not add any white space next to line items, since the line items table uses 98 % width either way, unlike when printing from Excel I guess. This is what I tried and failed to get heard yesterday. Also now in Landscape the cover page header takes up like 50% of the page. But hey “just make it landscape”. What the client needs me to do, I suspect without being…
It sounds like you can’t communicate with your users, which could be the meta-problem that you need to fix.
When you have a problematic person in the middle, sometimes you can set up covert channels of communication (risks, but rewards too). Problematic people are often causing problems within the organisation too, so you can find champions that will route around them.
Edit: Politics are important, but sometimes you are getting paid to solve a problem, perhaps using unofficial nefarious methods. It requires a lot of skill, and you need to avoid traps, but again that is part of what an external developer is paid for?