How can I meet the expectations of my manager?

Question

I can’t seem to be doing my work right because of miscommunication.

I’ve been employed at a well-established company for over 3 years. We started as a small IT department and it was up to me to both develop new features and maintain the existing code base which I believe I had been doing well since I haven’t experienced any issues so far.

Ever since our company created a new product which takes a significant amount of time and effort on our part, it is my task to develop backend services and I have been receiving negative feedback for the quality of my work which I feel has not changed since. Every time it is one of those issues: it’s either there’s some requirement I am not aware of and I am supposed to know of, I am submitting my results too late and I was not aware that there was a deadline or the actual work misses the expectations that were set or does not fulfill them completely. Or a mixture of all three.

In order to resolve those issues I proposed to set concrete deadlines for me where it’s clearly communicated what will be tested and for what purpose. I also proposed to shorten the development cycles since my work seems to be missing the expectations. Please understand that there’s no official specification set in place, most of the requirements are set forth by the management and are often communicated verbally.

However, my suggestions were not considered. I am supposed to “fit in” and “know what’s expected of me”. I feel that there are hidden expectations and deadlines which are not communicated. When I’m trying to resolve the problems, the manager mostly reacts with anger and strong language.

It has not always been like this. Earlier, we were on much more clear terms on what is going to be tested and what should be produced. Moreover, I also do some work for a different company and we always seem to be getting along.

The issues have started since the introduction of a new product and a new division of the company that was completely dedicated for this product (as well as becoming a separate legal entity).

What is clearly missing is that there’s a lack of proper communication on what needs to be done, what will be tested and on what date it’s going to be tested. What can I do in this situation?

Answer 1

That is a tricky situation. You are asking for the right things: setting clear goals, requirements, metrics and schedule is absolutely best practice and your managers refusal to do so is worrisome and unusual.

If possible, find out WHY that's the case. It could be harmless (stress, incompetence) but it could also be nasty: you are actively being managed out the door, they don't want you around any more, or it's just bad corporate culture. Try observing what happens with your peers and in other teams. If you are comfortable, talk to your peers and find out how the are being treated.

Here are some options:

1. If your boss is not writing things down, you do it for them. When you start a new task, write down the requirements, acceptance criteria and a rough schedule. Then send it to your boss: "Hi boss, here is what I'm planning on doing. Can you please take a look and check whether I have captured the assignment correctly? I'd be happy to adjust as necessary".
2. Make sure you check in frequently on progress with good status updates. If you don't have a regular 1:1, ask for one to be created. For each project make sure you can present what features are done, how you are doing against the schedule and where there are issues that may require help and intervention.
3. Look for a new job. If the reason your boss behaves this way is because they are one of the "nasty" ones, you probably have no future in this place.

Answer 2

I wouldn't lose hope. By the sounds of it, I don't think you are being actively "managed out" of the company. It sounds just like weak or incompetent leadership. I will try to answer each one of your "issues" individually:

there’s some requirement I am not aware of and I am supposed to know of

Now, clearly it is unreasonable for you to build software to satisfy a requirement you were unaware of. I think the key thing to keep in mind here is why were you unaware of it? If it's a requirement, then actually, it is kind of your job to be aware of it.

It comes to down to the question: where do requirements come from anyway? If you get your requirements from your manager, well then you shouldn't be surprised if you end up building a pile of garbage that no-one wants. Why? Because the requirements don't come from your manager. The requirements come from the people who are paying for the software to be built, or their proxies. This means people like business stakeholders, product owners, and business analysts.

So the key to knowing what the requirements are is: don't wait to be handed the requirements by your manager. Find out who knows them, and talk to them directly. It will likely be more than one person.

However, in certain cases (read, in a lot of cases) it may not be possible to gather all the requirements you need. In this case you need to make assumptions in order to move the software forward. Whenever you make an assumption, recognise that is what you are doing, and document it to your manager. Be clear that you are making an assumption in order to move forward, and call out the possible impact to the delivery. If they don't respond, that is what is called implicit approval. If you are called up on it later, you can just show the email as evidence that you had approval.

If you learn of requirements late which will effect the delivery of the software, it's your job to let your manager know about this. For this, see the section below.

I am submitting my results too late and I was not aware that there was a deadline

Unlike requirements, deadlines do come from your manager. As a software developer, it is part of your job to know what the deadlines are for the work you are doing. There is little excuse saying you were not aware of a deadline when delivering work late.

Without knowing deadlines for all your deliveries, you will not be able to manage conflicting demands on your time, prioritise work items, or make key design decisions about the software you are building.

Luckily this is easier to fix than not knowing requirements: ask your manager when they want this stuff by, and then send an email to confirm that you understand correctly. If they are unable or unwilling to provide a deadline, then suggest one which gives you enough time to deliver. Again, if you don't receive a response that means they have implicitly approved you to move forward.

If at any time, for any reason, you think you will not meet one of the deadlines, it is your job to immediately send this information to your manager, along with a new estimate of when you think you can meet it. This is very important, because it allows your manager to mitigate the effect of the missed deadline. Remember, everyone understands that software can be late, but they need warning if it will be late.

An important thing to keep in mind with deadlines - when your manager gives you a deadline, they are not telling you when you should stop coding by. They are telling you when they need working software in production (or whatever similar environment) by. It is part of your job to factor in QA and deployment overhead.

the actual work misses the expectations that were set or does not fulfil them completely

This sounds like it is more an issue of quality. There are many things you can do as a developer to improve quality outcomes - more automated testing being the primary one. Also, a closer working relationship with the QA people who will be testing your software is another. Often a close relationship with QA means that smaller bugs don't go into the register if you can close them off quickly, making these less visible.

Answer 3

Unfortunately, it's a very common situation that when companies grow, the early people are just not wanted any more.

(An example is Steve Jobs getting chucked from the first iteration of Apple.)

(The same things happens all the time in the world of sports, for example.)

This is very normal in programming, and something everyone has to face from time to time. It makes no difference how good you are.

Unfortunately if this is the case, there's nothing you can do. They "just don't like your style" anymore.

If this is the case, move on.

Unfortunately, this is a commonplace in programming, where companies/products develop and change really quickly; new people come along, new owners, new managers, and they simply want their own people, their own style.

The fake complaints they are stating are just rationales, not reality.

Again, unfortunately this is a standard and normal part of the business, particularly startups and new products.

Answer 4

Q. How do I find out about requirements and deadlines to meet my manager expectations?

I feel you are in a tough position because back-end do not have visibility like other services and they are often dismissed in communication and credit.

You seem to try to set a formal way to communicate back-end requests requirements and priorities since there is none but your valid demands have been rejected given it appears you are the only one with those issues.

Commonly, there is a lot of informal communication in a growing organization that did not update their processes.

A. In your position, I would investigate what is the source of communication of the other peoples: ux, front-end, etc.

For requirements information, I would aim everything related to UX/front-end because the specifications often start there. I would ask to join the front-end slack channel if there is any. Even attending some front-end meetings if possible.

For deadlines information, I would check with the person who seems to know the most of it: Product Owner, Customer service, etc. And I would also validate if there is some information discussed during lunches or before/after meetings.

Another impediment is that you are now split between two companies. Is there any conflict: like meetings in company1 overlapping meetings at company2? Is there an open space for company1 and a second open space in company2 where people discuss about requirements and meeting informally?

In addition, is your manager is using you as a budget tool? He is demonstrating that with one back-end person working 50% of his time for company1 and another 50% for company2 is not working so he wants a budget for a person that is entirely on the project?

I am not sure how the planning is done at the company but you may have to stand on your estimated and even buff them if there is any hidden scope so the manager can evaluate his un-communicated deadline will not hold.

In a more positive note, can you get in touch with who is using the back-end or who will test the parts you programmed to ask them which scenarios will be used to review if everything is covered?

Answer 5

I don't feel that communicating project requirements should be the purview of management, unless you're a very small team. Management should be responsible for communicating company- or division-wide goals, budgeting, hiring, ensuring employees have what they need to do their jobs, etc. It sounds to me like the response you've taken so far is to ask your manager to be a better project manager (provide clear requirements, deadlines, etc).

The problem is your manager isn't a project manager, so they don't think about your needs in those terms.

So here's a rough outline of the steps I recommend:

1. Find out who's making the decisions to which you're held accountable. From where do the requirements and deadlines originate? If they can be traced to an individual, talk to that person directly. However, it's possible such a person doesn't exist. ✝
2. Restate your understanding of your expectations. Do this as often as necessary. For example, you may send out a weekly status update where you list line-by-line what you understand the requirements to be next to your progress against those requirements. You'll notice that this very quickly turns you into a de-facto project manager, at least for yourself. This is okay, as long as you're not stepping on the toes of somebody else who's supposed to be doing this (which is why step 1 is first).
3. Commit fully to being a project manager, tracking deadlines and requirements and communicating them throughout the whole team rather than just yourself. If your reading of the situation is accurate, this can provide a lot of value to your team and make you visible to higher-ups in a positive way. I would only do this if a) You want to, and b) You've established a new track record for yourself through step 2.

Good luck.

✝ This actually happened to me. My team was presenting our project when we were almost finished, and the presentation turned into a whole slew of new requirements from the audience. I finally realized all of the requirements were coming from one person, and I should just loop him in early.