Comments on: I'm so meta that my brain don't fit

Question: I'm so meta that my brain don't fit

LogicalDash — Tue, 04 Sep 2012 04:36:42 -0800

Help me increase my metacognition. How can I best guess when my understanding of a task is adequate to the task?

So I've got an awesome internship that has me assisting with the maintenance of a database for a college. I've carved out a niche for myself writing SQL queries. Everyone else at my office prefers to delegate the task of writing queries--normally to an application rather than a person, but sometimes the application can't handle it, so I do. Many days, that's quite enough for me to pull my weight.

A week or so ago, I was asked to keep track of the relation between one variable and another. One of the numbers was the operating budget for a division of the college, so in hindsight I should have twigged that it is important to know the status of that number right now. I did not, and instead, set to making a graph of the two numbers over time. I'd mentioned that approach to the boss, and she said it was a good idea, but I guess she didn't really expect that I'd jump the queue and start working on the graph without reporting anything to her first.

I want to avoid that sort of error in the future. Two approaches suggest themselves:

Report what I'm doing right now, a few minutes into the task, so that if I've gotten terminally sidetracked I can kill it while it's young.

Develop a set of heuristics to separate the more important parts of a task from the less.

Both approaches have their strengths and weaknesses. It won't always be practical to report--well, I can send email, but I can't always expect a response timely enough for this purpose. Heuristics are nice, but somewhat by definition, they are often wrong. They're good for first guesses, but first guesses are only good if there are second and third guesses down the line.

What sorts of things should I report? What heuristics would be best to start? Is there some other approach I should try?

Snowflakes:

I am somewhere on the autistic spectrum--diagnosed asperger's. I can behave like a fully functional social entity for around an hour at a time, after which I have to cut corners: asking what the topic of a conversation is at the moment, moving to a low-noise area, etc

I'm a senior in college, for computer science. Actually I've been at college off and on since 2006. I have never lived on my own; the closest I've gotten was a few years in dormitories.

The internship is paid, hourly, no benefits.

Though it wasn't precisely arranged for me, I got the position because my mom knew my boss. I had an interview and stuff.

I am on good terms with my boss, who has autistic children of her own.

If you try to, eg., suggest that I report everything, I will only be able to use so much common sense to restrict that answer to, eg., "things I do at work;" to me, it is not obvious whether tasks for the other boss should be included, how many times I need to be reassured that I'm on the right track before I can suspend my reporting until the task is done, and so forth.

By: jon1270

jon1270 — Tue, 04 Sep 2012 05:11:02 -0800

It might help us understand your situation if you were to describe last week's problem in greater depth. Saying that "...in hindsight I should have twigged that it is important to know the status of that number right now. I did not, and instead, set to making a graph of the two numbers over time." does not make obvious the difference between what you did and what was wanted.

I also don't know much about autism so I apologize if this is useless advice, but my approach to understanding what is being asked of me is to seek an understanding of the bigger picture:

Why are we doing this?
What is this for?
How will this be used?

Those are the questions I ask. If I understand the context in which a particular task or work product is supposed to fit, it's usually fairly easy to tell whether what I'm doing will meet the need.

By: evil holiday magic

evil holiday magic — Tue, 04 Sep 2012 05:25:55 -0800

It seems to me that you're assuming the issue is with you, and that might not be the case. People are incredibly poor communicators in general, and delegation is an acquired skill. Even without autism-spectrum stuff to contend with, there are good reasons not to accept the "gist" of poor instructions.

I'm just saying don't get too self-critical. Moving forward...

One way or another, you'll need clarification of the tasks requested. I don't know how you were asked to track the variable -- verbally, by e-mail, or otherwise -- so I don't know how practical this is, but I approach requests the same way a drive-thru handles its orders. That is, I confirm. I confirm until there's no room for interpretation. When I get a request, I rephrase it, maybe add a few key details, and repeat it back as a question.

I say, "OK, I'm going to [do some series of things]."

If that's not what they had in mind, then it can be hashed out right there. If they're still vague, or don't quite understand the request themselves, I send the concerned parties an e-mail as, or before, I start, telling them that I'm going to proceed to do x, y, and z, unless otherwise instructed. Then they have a chance to reevaluate the plan and change course.

If they didn't change anything, and yet it still wasn't what they wanted, I have a record stating exactly what we'd agreed upon. That's known in the industry as "covering your ass."

My recommendation is not to let anyone just pass by, make a vague request, and expect you to fill in the blanks. Clarify it then and there -- it saves everyone time in the long run, since it's better to spend fifteen minutes getting it sorted than it is to put hours into something that can't be used.

Over time, it'll become easier, and communication will improve between you and your coworkers. But there's a learning period everyone has to accept.

By: dgeiser13

dgeiser13 — Tue, 04 Sep 2012 05:26:04 -0800

By: LogicalDash

LogicalDash — Tue, 04 Sep 2012 05:26:49 -0800

I'm pretty sure I can give this much detail without violating confidentiality:

The college gives some scholarships. The requirements for these scholarships are fairly low, so most entering students (i.e. first-semester freshmen) get them.

Most entering students don't actually attend the college. They submit an application and get accepted and then go incognito, not responding to anything the college sends them.

Admissions and registration is supposed to mark such students Withdrawn from Admission, which releases the funds allocated to their scholarship. They haven't been doing this very often.

I was supposed to track the variation in the admissions, the withdrawals therefrom, and the scholarship budget. I interpreted this to mean I should make a graph. This turned out to be more complex than expected; the data set is enormous.

I was actually just supposed to call up those three data and report on them, eventually getting familiar enough with them that I could tell when something weird was going on in admissions. The graph thing would have been nice too.

By: LogicalDash

LogicalDash — Tue, 04 Sep 2012 05:27:30 -0800

In retrospect do you feel like the task, and the end result that was needed, was explained clearly and you missed it for whatever reason? Or did the explainer(s) not do a good job of telling you exactly what was needed?

Most of the time, these experiences feel exactly the same to me, and I can only tell the difference after prolonged study.

By: LogicalDash

LogicalDash — Tue, 04 Sep 2012 05:28:49 -0800

I suppose I should have mentioned that I've been at this internship for about a year now, and the miscommunication described here happened like two weeks ago.

By: evil holiday magic

evil holiday magic — Tue, 04 Sep 2012 05:37:28 -0800

I would interpret "tracking" the data much as you had.

If you were asked to "track" the data, rather than say, look at it periodically, report any anomalies, then I don't think you were in error.

The issue is people say one thing, and mean another. One solution is telling them your interpretation so they can "correct" you, or otherwise getting at what they actually mean.

By: LogicalDash

LogicalDash — Tue, 04 Sep 2012 06:16:56 -0800

I don't remember what verb she used. It's possible that part of the problem is hers.

Even so, this is a problem that seems to come up a lot in ordinary communication, and I don't feel like I met her part-way. It was six hours after I got the assignment that we touched bases and found that I'd been working on the wrong thing.

By: J. Wilson

J. Wilson — Tue, 04 Sep 2012 06:32:05 -0800

You spent a few hours working on what you mistakenly believed the project to be. It's really not a big deal.

There's no way to guarantee that you won't have communication errors with whomever you're communicating. There just isn't. As for whether it's cool to report "what you're doing right now, a few minutes into a task," that depends on the other person's preferences and you may need to be able to read some social cues to test those waters. But if I had to guess, I'd say you're not asking questions to make sure you understand your assignment in the first place (or when those questions arise), and that is a concrete step you should take.

By: vytae

vytae — Tue, 04 Sep 2012 06:39:56 -0800

I think evil holiday magic has the right approach, above. When somebody requests something, you can say, "So what it sounds like you're asking for is X, is that right?" where X is a description of the end result restated in your own words. If you have an idea in your head already of how you're planning to present the desired information, ask the person if that's how they want it: "So if I get you a graph of variables x, y, and z over the last 5 years, would that work?" or "Do you just want a written list, or do you want it in a spreadsheet so you can more easily sort the data?" If you don't have any idea yet how the output of your work might look, you can throw the question back to the requester: "What's the most useful way for me to get this data to you? Graph? Spreadsheet? Monthly email? Customizable report on the corporate intranet? Something else?" The key is to know that you're probably always making assumptions about what they want, so you should always restate the project as you understand it, giving them a chance to correct you. Don't just do this when things seem unclear; if anything, it's more important to verify that you're on the same wavelength when things seem really obvious to you.

By: viggorlijah

viggorlijah — Tue, 04 Sep 2012 07:06:17 -0800

You may want to estimate the time a delegated task will take and apply a general rule to it, e.g. if a task will take less than two hours, I will interpret the instructions directly. If the task will take more than two hours but less than a day, or is less than two hours but repeats weekly etc, I will send an email to the person assigning the task that outlines what I interpreted the instructions as and ask them to confirm before I start. If the task will take more than a day, I will send an email and request a brief meeting to confirm and detail the instructions in person. Basically balance the time to confirm and communicate against the risk of having to spend time re-doing as task.

If it helps, what you are looking for is "how to manage up" in business talk, and is a common work challenge. A great manager makes this effortless, but most people are just okay managers and need employees to figure out instructions.

By: wenestvedt

wenestvedt — Tue, 04 Sep 2012 09:00:24 -0800

evil holiday magic is hinting at what vytae describes: a technique called active listening. There's lots to read online about this, and it is a VERY valuable (and simple!) tool for ensuring both that you have understood the request, and that the requester themselves is asking for what they really want.

Lots of people tell you to do something, then they look at the result and realize it isn't what they wanted. When they hear you describe back to them what they just asked for, it offers a chance for them to stop and amend the request.

This is, of course, no reflection on you! :7) You sound like you're on the right track.

By: Tell Me No Lies

Tell Me No Lies — Tue, 04 Sep 2012 12:17:40 -0800

In industry we frequently deal with two documents, the PRD and ERD.

The PRD is the Product Request Document, provided by marketing or whoever the customer is.
The ERD is the Engineering Response Document, provided by engineering.

At their most basic the PRD says "Here's what we want" and the ERD says "Here's what you're getting."

It sounds like you won't be getting any sort of formal PRD in your environment (which is okay, they're more appropriate in large corporations) but that doesn't prevent you from writing an ERD. Try to keep it under a page for projects like you're describing, but get your customer -- in this case your boss -- to read it before you get too invested in your code.

The basic outline is this:

Title
Summary
Description (detailed description of request)
Required Resources (in this case, the SQL database)
Deliverables (with sample output -- charts, tables, whatever it will look like)
Unanswered questions (whatever the customer left out)

As I say you can keep it short but the process of writing it out will usually reveal what you don't know, and will allow you to enumerate the questions you need to ask.

In a lot of ways this process is like the Active Listening mentioned above, but it adds some structure and gets it down on paper so you don't have to process things in real time.

By: jander03

jander03 — Wed, 05 Sep 2012 07:27:41 -0800

This is common in any office: Someone makes a request. Another person receives the request. Both people understand the request in a different way. It happens when people use (and then accept) ambiguous language.

You will get better at asking the right questions to clarify requests. One day, you will make a request of someone else and it won't be interpreted the way you intended. Try to remember that it happened to you.

By: LogicalDash

LogicalDash — Wed, 05 Sep 2012 18:13:13 -0800

It's possible that my boss's reaction was stronger than it really should have been because she's spent much of the summer at The Other Office. To her, the one day was a much bigger deal than it was to me--I'm a scarce resource.