New job boss talks too much detail and loses me

Question

For the last few years I've been self employed as BI contractor using a particular tool. That market has dried up and I've taken a perm role an information Architect.

I knew this role was a bit of a change for me so perhaps a gamble and two weeks in I'm finding it particularly stressful.

The biggest stressor is my boss (a more senior Architect). He is a nice guy and clearly intelligent. In nearly all of our meetings he loses me in the detail of the project. He's now provided some very ambiguous objectives. When I ask for requirements he says the project is tactical and we can't ask the business for any.

I've told him he is often talking it too much detail and when I try and simplify the objectives and requirements he gets frustrated with me. Has anyone been in a similar situation and can offer some advice ?

<Edit in 2020> So after 6 months I quit the job. 12 months later I heard from a colleague the company lost it's fuding due to failing to deliver (was no suprise to me). It was a poisoned chalice, I still learnt from the experience though.

Answer 1

I have never found too much information to be a problem, only the latter. You were probably joking about getting a job at Tesco's supermarket, if not, it's an attitude that won't help you; try at least to find something else technical.

But remember that we are all a little under water at first, on every job (at least, I know that I am, even after "several" decades), but you will eventually find your feet. In the meantime, is there anyone else you can talk to?.

With respect to "I'll just knock something up quickly and see if it's what he expects" - deliver early, deliver often. Every few days if possible - don't wait until you think it is complete.

I am currently on yet another new contract & every few days I approach the guy I report to, tell - or show - him what I am doing, and ask if I am heading in the correct direction, or going off course.

Answer 2

Think of the problem as a business and technical challenge. That's what it is. It is not your personal character deficiency.

There is nothing wrong with listening for a few moments then saying "please let me restate what you just said. That way we'll both know I understood." You can also say "wait, help me understand what you just said." The trick is to ask for his help.

You're an architect by title. The heart of an architect's job is making clear and simple plans for builders to follow. It's well known in IT that clear plans help lead to good systems. So don't stop striving for clarity and simplicity.

Think about why you can't keep up with your colleague. Is it because

• you need to learn more about a specific area of your job?
• you don't know some parts of your company's set of tools?
• you don't know the company's internal jargon yet?
• he talks too fast?
• his thoughts aren't clear?

The first two of those reasons are your responsibility to fix. Time to hit the books. Tell him you are scrambling to come up to speed on those topics.

The rest of the reasons are your joint responsibility to fix. System design is hard work. Most of that work involves converting murky ideas into clear ones. If his thinking isn't clear, don't hold it against him too much. Part of your job is to take his murky ideas and make them clear.

I suggest you have a conversation with him about his frustration with you. "I can see you're frustrated that I sometimes don't follow what you say. I'm working hard to learn this job and learn to understand you better. Do you have any suggestions about helping me come up to speed more effectively?" You're gently reminding him that part of his job is to make you successful.

Keep this in mind: it's no fault of yours you have things to learn. We all have things to learn, no matter our level of experience or time in job.

Answer 3

I don't know what your role is exactly, but if you're a consultant, you might be expected to propose solutions based on the objectives and first ideas provided.

When reading your post I had the impression you expect very clear requirements to be provided. This might be the modus operandi in IT, but as a technology/ data consultant I was normally expected to propose a good, viable solution by evaluating different options and presenting the best one for acceptance by the main stakeholders. Of course, this proposal gets frequently modified a bit in the course of the discussion, but my point is: I wasn't just provided requirements - I was expected to define them first.

It doesn't need to be the case in your situation but it's worth clarifying with the client.

Or just try preparing a concept of a project to fulfil the objectives and see what the reaction will be.

Answer 4

Most projects go through a series of steps starting with some domain need, such as a business objective, and ending with a working program. Generally, the more senior a developer, the earlier in the process they can get involved. You are now being shown the business objective before there is a clear specification. It is not that your colleague is failing to communicate information he has about the requirements. The requirements do not yet exist. You will be helping to bring the project from business objective to requirements.

Rapid prototyping can help clarify thinking in this sort of situation. It is well worth trying "I'll just knock something up quickly and see if it's what he expects."

If it is not, rather than getting a job at Tesco, try to understand what he likes and what he dislikes about your prototype, and write another one. In the next prototype, try to keep the things he likes, change the things he does not like, and otherwise keep it as simple as possible. Think of it as an iterative search for requirements.