How do I fit in to a new work culture without losing my mind?

September 27, 2009 4:54 PM

I'm exhausted from trying to understand the working environment at a new job, and hoping the hive mind can help me figure out how to become better at this job.

I started a new job two months ago doing business analysis for a growing company. It's a new position for the company (they've only created an IT department within the last year) and a new position for me (I've mostly done database and software development for teachers and librarians).

These aren't computer people. I don't expect them to know the intricacies of software and hardware or formal business terms to describe their requests, but I'm finding that I'm not very good at getting information out of the user base and I'm not fitting in with the corporate culture.

Here's examples of where we're clashing:
1. I received a one-sentence request from another new hire to "Install X software on his machine".
I can't find x software documented internally, or any x-ish install programs on any IT-owned servers. I send him an email asking what's X software and where can I find it? What's it used for? Do you mean y software? I get verbally spanked: asking for specificity was perceived as combative and rude.
2. I was tasked with documenting and expanding a series of linked spreadsheets, and warned that each one takes "like an hour" to open. I start working on the spreadsheets. Each one does take within 10 minutes of an hour to open, and I keep asking why the user base is expecting the work to be done in less time than would be possible to even open each spreadsheet if each one takes "like an hour". I get verbally spanked again: taking user timeframes at face value is perceived as pedantic and willfully stupid, because the reported user experience of taking an hour to open each was meant figuratively, not literally - I should have known and reported the speed as indicative of a larger problem.
3. I get a request to run a new data query from a department from a set of written specifications. They're not sure where the data is stored. Or what it should look like. Or if we even store each particular piece of information. I'm told to make a best guess at the content and pass it back to them for validation - and I hear back that the data looks good. Weeks later, I hear that the final result was both incorrect and incomplete. I get verbally spanked for expecting other departments to correctly validate information, and especially not to accept specs or validation from one particular individual to ever be correct.

Jobs are hard to come by right now and I genuinely like the people I work with (although I find the culture to be something that definitely takes some getting used to). Is this just a bad fit?

posted by soft and hardcore taters to work & money (19 comments total)

Perhaps you should arrange to communicate your questions about requests like you mentioned in person rather than shooting back with emails? I've found that people tend to take emails asking for clarity rather personally, like they think you're trying to look smarter than them. The same questions asked in person get a better response.
posted by Burhanistan at 4:57 PM on September 27 [4 favorites has favorites]

What about the other IT people? Who would the spankers have you ask for clarification if software is undocumented and unfindable? I mean really, someone was dealing with this stuff before two months ago, no?
posted by rhizome at 5:13 PM on September 27

This is a hard situation to be in, and I know from personal experience.

The honest answer here is that non-technical people just want their software and hardware to work, and don't care much at all about the details, just like a surgery patient just wants his body to work and doesn't care about the details of the procedure.

You need to figure out a way to essentially have a better bedside manner with these people. What are their concerns? What problem of theirs are you tasked with fixing?

You need to figure out a way to communicate to your coworkers that you are looking to help them. Posit the problem as one whose solution will benefit them, but only if you can understand in more detail what their problem is.

Note that this often requires face-to-face conversation, or slightly worse, phone conversations, as opposed to emails.
posted by dfriedman at 5:13 PM on September 27

The advice above is excellent and well worth following. I have just one idea to add:

Part of where you seem to be having difficulty with your "bedside manner" (as dfriedman puts it) is that you don't have much idea about your user base's needs and perspectives. If you haven't had much contact with typical users, it's hard to understand where they're coming from.

To get that sense of your user base, go on a "listening tour". Schedule one-on-one meetings with key managers, set up casual lunches with groups of lower-level employees. Ask them what their ideal business analyst would be like. Find out what their goals are, and brainstorm with them how the IT area could help them meet those goals.

If there are other current or former business analysts at your current company, they could help you understand some of the "unwritten rules" that have been baffling you. If there aren't any to be found within your company, cozy up to a professional association or hook up with some business analysts in other companies.

The verbal spanker might also, in a calm setting when he/she isn't responding to a complaint, be able to help you grok the culture so you'll be less likely to run afoul of it.

Good luck!
posted by DrGail at 5:37 PM on September 27

Be kind. Sometimes requests to be specific can be, well, rude. Or they SEEM rude to non-computer dudes. As a former IT-ish guy I know that it DROVE ME UP THE WALLS when Office Drone X couldn't find a program to open a .txt with. But you need to be patient and phrase things carefully. All these people know is that they're on a deadline and the computer they're using- Which you are now the avatar of- isn't working. Hence, your problem.

Just be careful with your wording and be patient.
posted by GilloD at 5:37 PM on September 27

Get out on the floor and start developing relationships with people. It is alot easier to not get 'spanked' when people know who you are and think your a good guy. You will also find a lot out by just talking with people. You shouldn't be referring 'I don't know what software your talking about' directly back to the users. You should be query I.T. first, and then reporting back as to how your going to help them solve their business problem. For example, if they are requesting Microsoft Access and you don't have the licenses for it, figure out what they are trying to achieve and see if you can't solve it with another tool.
posted by jasondigitized at 5:54 PM on September 27

Sounds to me like you work in an office full of dicks:

1.) (depending on the tone of your email response).. is pretty much exactly what I do when someone asks me to install some unknown software. I reply back telling them I can't find any documentation or install media.. and I'll need more information (or media) from them if they expect me to install it. Being "verbally spanked" for asking that?.... is ridiculous and impolite.

2.) They handed you a mess of spreadsheets that really do take close to an hour to open.. and then expected you to do what exactly?.... "Hey, lets hand the new guy a big steaming pile of poo.. and then berate him for misunderstanding us!?"... wtf?

3.) WTF?... You're given the vaguest possible instructions, told to make your "best guess" and then blamed when the end-result data is wrong?... thats insane.

Look.. some of the other replies here are correct,.. you can never go wrong with improving your "deskside manner"... but (assuming your descriptions are remotely accurate) atleast in my view, there is a limit to what you should be expected to take on. Your job is IT, not understanding other departments deeply enough to know if the data looks "right"... that should be their job. (If the data is "wrong", they should (politely) come back to you and say, "Hey, the output doesnt square up like we thought it would, we've made some changes to the query logic.. can you run it again and let us check the results?"

The problem I see.. is that the only way to avoid these types of misunderstandings is to be as clear and communicative as possible... but if you try to do so, they'll lash you for being "pendantic"...??.... Are they expecting you to just inherently KNOW every single angle/aspect of their business niche (on top of your IT knowledge).. so that you never have to ask questions?... cause thats not realistic. at all.
posted by jmnugent at 5:55 PM on September 27

non-technical people just want their software and hardware to work, and don't care much at all about the details

That's a true fact.

I am a non-technical person in my huge company. (Well, non-computer technical.) And I like all the really cool things my computer can do for me.

I just want my stuff to work. And I don't understand that:
A. the company doesn't own a license for that program and it will cost $5K.
B. the program looks pretty cool but I can do what I need with something the company already has
and furthermore, I don't understand that
C. the database isn't set up that way
D. if you are giving me a weekly report it is likely that a daily report takes time out of your day everyday. (I just want it everyday, don't you see that?)

Plus, I am used to being good at what I do, and I am stressed and overworked. So I don't want to feel stupid and I don't have a lot of time to dick around.

Other than that, I am really a pretty nice person.

So, for me at least, you need to:
1. Talk to me in person to find out if I have any idea what I'm asking for, if I really need what I'm asking for, how much it costs, how long it takes, etc., etc., etc.
2. You have to do that without hurting my feelings or making me feel like my time has been wasted.

I don't know what people at your company are like, but I think that people skills are important in your job.

And if you give them something that might not be what they think they want, you really do need to follow-up to find out if everything is ok.

Good luck!
posted by SLC Mom at 6:04 PM on September 27 [3 favorites has favorites]

I think that GilloD's distinction hits the nail on the head here: to your users, you are, to a large extent, a part of the computer. I typically know how a lot of this stuff works, and I've been guilty of this sometimes too: you're cranking out some work when, blam, you need such-and-such software package installed or access to this server or this problem in another system troubleshooted. The natural reaction for most of us is to lump the person in the IT department in with the software and systems we've been grumbling about. Users treat the machine as, well, a machine, and by the time they get to you, they've been cursing at the "bloody computer" for an hour or more because it's the machine that has been stopping them from getting their work done. When you come along to help, many users can't fully make the context shift between "making the damn machine work" and "interacting with a human being to collaboratively solve this problem" so they wind up treating you like part of the computer and curse you out too.

So don't take it too personally all the time. In some of these cases, you're coming to people who are already upset that they don't have whatever they want, and by the time they've called you in, their frustration is already several times higher than it ought to be given the situation at hand.

I want to second DrGail's suggestion of a listening tour. The more proactive you can be about providing people with what they need before they become frustrated, the better. I wouldn't put it as "how exactly did I piss you off before," but I would bill it as "what can I be doing that would help you get your work done." Then later, once you've improved on a bunch of people's major gripes about the current systems, folks might be a tad more appreciative of your help.

Another thing that might be useful is the creation of a more formalized process for some of this work. Obviously, I don't mean the bureaucratic "fill this out in triplicate and get it stamped by departments A, B, and C" kind of process, but a set of shared expectations around common tasks. If a big part of your job, say, involves running data queries for different departments, maybe have a documented system that more clearly delineates the department's responsibility for specification and verification and your responsibility for execution and clarification. That way, when angry word comes back weeks later that you've given them the wrong data, you can nicely point to the process, say that the data passed validation, and recommend that they submit a revised query if the original turns out to be unsuitable after all.

Using a ticketing system for these kinds of requests can be very useful as you can directly point to the correspondence and your management can see what has been going on. Come performance review time, you can easily spit out stats showing how many requests you've handled, average time per request, etc...
posted by zachlipton at 6:05 PM on September 27

It sounds like your main problem is that you formerly worked in a large organization with formal IT support like a help desk between users and technicians, and your new job places you very much on the line between people and their.

A bit of reflection on your incidents:

1. You get a request from a new hire. Asking the new hire for clarification is probably worthless, they're just as new as you are. It may be that you didn't know the requestor was a new hire, that will improve as you hang around longer and recognize people. In the future, consider asking for clarification from your boss, or the requestor's boss. You may need to emulate some humility in forming the request. At the moment you have the "new hire" card to play: "Hi, I received a request to install $foo. I've never heard of $foo, can't find it in our internal repositories, or on the internet. I'm a new hire at $newsys, might you have some pointers on this?"

When you do write for more information, take effort to frame the question in terms that it can help you do a better job for them, and maybe be just a bit less helpful. By asking "did you mean" questions, you can inadvertently steer the answer.

2. In these situations, your ace in the hole has to be a dedication to quality and excellence. When someone says an excel spreadsheet takes an hour to load, don't chalk it up to unrealistic user expectations. Don't blame existing IT or the people who implemented it. Fix it, or at least identify the root cause if some policy prevents you. Pointing out the flaw but doing nothing about it is not helpful.

3. Inferring from the context, part of your job as "business analyst" revolves around measuring the business performance of the company, perhaps for incentive pay. If you're auditing a business unit's performance, it's probably not a good idea to leave it up to themselves. Generally business analyst positions in small companies should be reserved for internal hiring, because it takes a long time to familiarize yourself with the company, what data is available and what data you start recording to accomplish the goal. It's a way different game than installing software or maintaining academic databases.

(Also keep in mind that there's going to be some turmoil over performance metrics either way. Any time compensation or formal review includes this data, there's incentive to change it or at least rant about how unfair it is, even if everyone else thinks it's fair.)

In general, I'd point out that input from your boss can really affect you more than intended. If the only in-person contact you have with your boss on a given day is a verbal reprimand, it doesn't matter how many congratulatory emails are sent later, you've just had a bad day. If you have a good working relationship with your boss, you might ask them for an informal evaluation.
posted by pwnguin at 6:50 PM on September 27

If you're getting verbally spanked by the same person every time, I'd be documenting all emails, communications, and talks that you have with this person in case you have to go to HR at some point about it.
posted by pised at 7:21 PM on September 27

Hi all - thanks for the responses!

Pwnguin's absolutely right - the only analyst roles I've even taken on before have been after being steeped for years in the company culture, and only at large organizations with a preexisting and formal IT and project management structure. This is an entirely new role and department; the other IT guy just handles hardware and steers clear of the users.

I think I'm getting into a feedback loop between SLC's mom's description of the user thought process and:

I want to help you get the data/software/process you've requested. And I don't understand that:
A. You don't know where it exists or if it exists
B. You aren't sure how to describe the scope of the current problem
C. You aren't sure what you want the end result to be

I don't want to hurt anyone's feelings or make them feel stupid or want to look like I'm trying to be smarter than the users - - they're the ones who've kept the company running, and they're the experts in their roles.

I guess my next question is can I develop people skills and a bedside manner that doesn't frustrate me or the users I'm trying to help?
posted by soft and hardcore taters at 7:46 PM on September 27

The place I'd start is that people don't make IT requests because they want a piece of hardware or software or some networking fix. They make IT requests because they have a work need that they want solved, and their request is a best guess and what will do that. So, you can practice both addressing the specific request (I've opened the first three spreadsheets and found that they do indeed take ten minutes on average to open) and also ask questions that get to why you are being given that task (does the loading time negatively impact productivity, I'd think it would, what other purpose is being used for this information, etc.)

If people are short with you it is likely that they aren't confident that the time you are spending talking with them will result in a meaningful improvement in their work tools. If you perceive that starting to happen you can step back to simply stating that your goal in the conversation is to make sure their problems are resolved, and if they are insistent that you do what was first asked (even if you think it isn't the best solution) you can agree to do it and then mention that you have other ideas if this doesn't address all the issues.

Final thing is that when you get terse concrete requests it is easy to think you are done, when you actually haven't solved the issue that started the chain of events. They asked for X, you deliver X, done. Right? Wrong. After you deliver X you need to check in and ask whether that has resolved all their issues or whether there is anything more that still needs help. If the problem that caused them to ask for X is still there, then they don't really care that you delivered it anymore, they still have their problem to deal with.

All of this sounds like a lot, but it can literally be a few sentences in a conversation. I 100% agree with the prior posters that this works best face to face or by phone, at least until you have a comfortable working relationship.
posted by meinvt at 8:11 PM on September 27

I gotta say, if I were on the receiving end of A, B or C, it'd be a pretty strong indictment. To reiterate, it's best to internalize that. If they don't know what the end result should be, neither do you. So refrain from using "you", for "we" (the company) or "the" process.

Instead of "What version of Adobe Illustrator do you need? Did you mean Photoshop?", try "What version of Illustrator do we use? CS3 or CS4?"

Instead of "I can't complete this until you nail down the specifics: How far back do you want reports to go?" perhaps "I'm working on the report. How far back in time should it go?"

Depending on the task, it may pay dividends to do interviews with, for lack of a less annoying term, "stakeholders". Figuring out what they currently have, do and want can help you resolve some problems and gain insight up front and in person, and you can leisurely schedule them before the work, whereas problem reports are generally handled as emergencies.
posted by pwnguin at 8:29 PM on September 27

Depending on the task, it may pay dividends to do interviews with, for lack of a less annoying term, "stakeholders".

We implemented an IT Steering Committee a few years ago. Meet once a month with 4-5 "stakeholders", have a management representative, and open the floor. Keep detailed minutes and follow up on those minutes at the next meeting. It's been pretty useful so far, and there's less of an IT vs Everyone Else vibe going on now.
posted by Burhanistan at 8:32 PM on September 27

"The place I'd start is that people don't make IT requests because they want a piece of hardware or software or some networking fix. They make IT requests because they have a work need that they want solved, and their request is a best guess and what will do that. So, you can practice both addressing the specific request (I've opened the first three spreadsheets and found that they do indeed take ten minutes on average to open) and also ask questions that get to why you are being given that task (does the loading time negatively impact productivity, I'd think it would, what other purpose is being used for this information, etc.)"

Hrm. This makes perfect sense to me (and no wonder I get parsed as rude): I think I'm being asked to do a task and try get the specifics to accomplish that particular task, when I'm actually being asked to investigate and address a work need.

Is this something learnable?
posted by soft and hardcore taters at 9:38 PM on September 27

As a support person in small companies for some years, I can relate to this type of problem. I've never worked in a big company culture except as an occasional walk-on consultant. Here are some of my techniques for getting people on my side.

Never assume that the person on the other end has any clue what they are talking about. Asking users for technical information is like blinking a semaphore at the moon....null signal. Be prepared to tone down your expertise to the simplest level possible. Pretend you are talking to a 12-15 year old, tone things down to the most basic level possible.

If they can upscale the conversation, great. Just don't expect it to happen.

Insert cultural modifers...'hi, how are you, how's it going' in any communications, especially email. Terse computer-like messages, while productive are interpreted by your clueless user as arrogance.

If there's any kind of real problem, go see them. Have neutral body language, put your brain in zazen and ask mild questions that explore the problem from their point of view. Only they know what the real problem is, and they can't explain it so better you go and see for yourself. Plus there's a personal element now, and be sure and thank them for their time.

Maybe this helps. I'd have to agree with jmnugent....if you're getting spanked for simply trying to understand the problem, that sucks.
posted by diode at 9:45 PM on September 27

I think your last response is insightful. In my (limited) experience, business analysts are not IT support staff; installing software would not typically be in their job description. Their role is to carry out needs analysis -- understand business processes and the needs, responsibilities and activities of a particular business unit -- and then translate those needs into specifications that other people (often developers) can use to set up new systems (e.g. wikipedia definition). If this is the case for your current role, then my sense is that you are approaching your job at the wrong level; as a solutions-focused IT support person rather than as someone focused on understanding the core business problem. That said, "business analyst" is defined differently by different organizations.

Is it learnable? Of course it is. You could do a formal program of study through the IIBA, or study from books to understand business analysis methodologies. But an important first step would be to work with your manager to make sure you have a clear understanding of what your role is supposed to be in the context of this particular organization.
posted by sevenyearlurk at 10:15 PM on September 27

Another thing to consider implementing or at least discussing is the difference between a "fix" and an "add". End users should be able to directly request fixes, because that is simply restoring correct functionality that way already there, but there should be some kind of approval process for adds. It should have to run up the management chain to someone who has responsibility for both the requestor's work product and your work product. (In a perfect world.) That way you aren't getting stuck with trying to make or break a business case for installing product X.

Another thing would be to separate out, at least for yourself, what the chain of command is. You work for your boss, and they are (in theory) responsible for your work product. So you might get yelled at by the VP of Bologna because your report didn't meet his unarticulated expectations, but that is completely different from getting yelled at by your boss for not rotating the backup tapes (or whatever).

This is one of the huge problems I see in IT. I'm a sort of consultant, so I am personally immune from it mostly, but the internal IT people I work with are constantly getting bogged down with making the VP of Importance's palm pilot work with iTunes and Lotus Notes, and having to ignore other more important things.

Another bit of advice would be to compartmentalize and prioritize "at" people. Never give the impression you are complaining, but when you get some oddball request, give truthful status reports and expectations. Like "Sure thing, I can look at that problem Tuesday afternoon. I have these other requests ahead of that, and I will look at yours when those are complete."

If I was in your situation, I would implement (at least for my own use) at project management or ticketing system. Everytime you get a request, submit a ticket to yourself, and then update that ticket with the time and statuses as you complete work on them. Not only does that allow you to show what your time is going toward, it allows you to prioritize and organize your work. You don't have to remember the thousand little requests, as they are on your todo list. When you are working on getting the right fonts for the meaningless status report, you can simply answer the phone and add the new request to your pile.
posted by gjc at 7:57 AM on September 28