I had an end-of-FY review with my manager and while basically all of the feedback is positive, one negative bit of feedback was basically "I'm expecting you to work faster in the future".

Now this feedback seems clear cut, but it is in reference to a previous project that I worked on, which was my first project at this company, which was pretty bumpy due to lacking any sort of estimates or breakdowns for the stories that I worked on, which were often lacking even basic descriptions.

This project was led by a person, who did that for the first time and did not realize/consider the complexities involved in this part of the project. I was quite new to the team/company/product and did not realize the complexities until I was mid-way through. I did actually raise the lack of estimates as an issue at the start of the project and a few times throughout, however, that was largely dismissed/met with conflicting advice.

When my manager brought this up, I basically said that "I would prefer to not use project X as a measure of the speed of my work, since measuring the development of unestimated/unbroken-down stories, which were lacking detail is not a good way to measure somebody's speed of work". I also stated that "while I'm expecting to pick up the speed as I get more familiar with the team, project, product, I will not be taking responsibility for other people's mistakes" and that "this project was a failure of leadership/management".

As you can tell, I was rubbed the wrong way by this feedback and did not agree with that. Besides this, me and my manager and the team are on good terms. The current project, which was actually estimated and broken down is going well. I referred to this as well.

I wonder if I handled it as best as I could and if not, what should have I done differently or how to handle it in the future.


Edit: just to be explicit about this - I've given a lot of feedback to my team and my manager throughout that project about all of the ways in which we could improve our processes, which was received with lukewarm responses.

I was really vocal about the fact that having no estimates and no breakdowns was a problem. I most definitely did not go behind anybody's back and neither did I fingerpoint. There seemed to have been a disconnect between what the upper management thought the project should take and what it actually took and the reason for that in my mind is what I mentioned before - lack of estimates and breakdowns.

So I was just not overly happy having that put on my shoulders during a performance review, as that's the same as me blaming my manager for poor-quality code - it makes little sense. Especially considering how many times I brought this up in our 1:1s before.

  • 3
    I'm not sure that there's an answer we can really give here. I'm not at VTC yet, but I could be convinced - What has been said, has been said - you can't go back or improve upon it. In terms of how to handle it in the future - that really depends on so many variables, it would be too broad or opinion based Commented Jul 5, 2023 at 2:43

7 Answers 7


The project probably was badly managed, but by trying to rebut every element of the feedback, you're missing a chance for a more productive conversation with your manager. It is also going to come across as not fully taking responsibility for your work.

Perhaps a more diplomatic approach, without rolling over, would be to say

  • You understand the feedback
  • You agree that projects of that size and complexity should be achievable in a shorter time in the future
  • You think the challenges on the project were less about technical execution, and more around understanding the problem
  • You've learnt more about the working styles of your teammates and stakeholders, and will be more active in defining the work needed going forward
  • The project was a team effort and the whole team has things to learn from it

Is there an expectation gap here as well?

Depending on the organisation, fleshing out detailed estimates and specific tasks from high level guidance may be part of the responsibility of the developer. This can be healthy - it means you are accountable to your own estimates, and develop more of the solution, based more directly on your understanding of the problem, and discussion with stakeholders. This is often the case for organisations without product or analysis teams, and can be a successful way to work.

One of the things the boss may be telling you is that you need to define your role more broadly than just cutting code. If your response is focused on "I cut code really well, when I'm given a high effort, detailed spec", then who writes that spec? You may be implicitly telling them that you can only do part of the expected job.

On the other hand, the boss may well know the project was an underdefined mess, but just want to make sure you don't use the time it took as a baseline for future work.

  • 1
    That's some great suggestions, thank you! Fleshing out detailed estimates and specific tasks being a dev responsibility would be okay, however, none of that was communicated to me, and even if it was - that would have resulted in the project being considerably behind schedule anyway. I'm used to estimating projects as a team to get high-level estimates and then refining the backlog in sprint planning. Here it seems that somebody just "guesses" an estimate, then complains when it doesn't align with reality, which I think is an inherently broken system.
    – Web Dev
    Commented Jul 6, 2023 at 6:17
  • 14
    "however, none of that was communicated to me" - this is again a defensive stance instead, exactly what the answer covers. Try to focus more on the future and instead of blaming others not doing their job well, ask questions and go for a consensus on how it should work in the future. Commented Jul 6, 2023 at 7:58
  • 2
    @WebDev It sounds like they are using a kind of folk waterfall planning method, then. On the one hand, yes, you will have to continue being diplomatic and ensuring you don't come across as evading responsibility. On the other hand, I would guess their software work routinely runs over, if they don't have any way of learning and refining rough plans into detailed ones as they go. So all the devs would be getting this feedback all the time. Now you know the lay of the land, you can at least be a bit more thoughtful in your own planning and estimates, and spread better practice where you can.
    – Adam Burke
    Commented Jul 11, 2023 at 0:02
  • @AdamBurke "but by trying to rebut every element of the feedback" Where did OP refuse EVERY element of feedback? Seems like it was just one, against "speed", which is horrible feedback to receive without solid examples.
    – 8protons
    Commented Jul 16, 2023 at 20:25
  • @8protons every element he asked about here ...
    – Adam Burke
    Commented Jul 17, 2023 at 0:11

Well, what you said was basically:

It's not my fault. The project manager screwed it up.

As a manager, not only does this mean that you won't improve on your second project with that PM, you also have no problem blaming other people. It doesn't matter whether you are right or wrong. You badmouthed someone behind their back. There is no reason to expect you won't do the same with me when I turn my back to you and go into my next meeting. This will undoubtedly leave a taste of "I may have to get rid of this employee if they stay on this path" in the managers mouth.

Now, lets picture what happens if you frame the whole situation positively:

I think I already did speed up a lot in this follow-up project. I get a lot more done per day than before. It would be unfair to take all the credit though, the new PM does a great job at managing this, it makes my work so much easier and faster. If I could make a suggestion, I think everyone would benefit if all our projects were managed that way.

If you had specific examples of what helped with the new PMs way of doing it, that would be even better.

Now, you are no longer the non-improving complainer, you are the person praising others for their good work, making suggestions to improve the company workflow for everyone. And you also snuck in the fact that you already improved.

Good vibes all around. Not only did you agree to improve, you already did. And you never said a bad word about anybody. Perfect. Meeting concluded, all goals reached.

  • Well, I didn't really badmouth anyone behind their back. I just responded to my manager trying to blame me for their mistakes, by pointing out that I think the mistake was theirs. I don't badmouth people behind their backs. I generally avoid conflict, but when I don't, I tell them straight up. I also gave lots of feedback (see my edit) throughout the project, to which the manager mostly agreed, without really actioning much of it. So I feel like my previous feedback was noted and ignored, then I got blamed for the problem anyway.
    – Web Dev
    Commented Jul 6, 2023 at 6:23
  • 37
    @WebDev please take this gently, but you've received some answers saying "you've missed an opportunity to benefit from feedback by arguing with it instead"... And you're arguing with them instead of benefiting from them.
    – CharlieB
    Commented Jul 6, 2023 at 7:38

When I don't particularly agree with something, I would ask my manager how they would have handled the issues.

You said that there were issues with un-broken down stories and extra complexity that you hadn't realized.

I would ask my manager how she/he would have dealt with the issues.

The manager is there to guide you. Let them do it.


I think it also depends on the way your manager said it. Perhaps they didn't mean it as much as you thought - from what you said, the person seems to be pretty chill. That said, you have every right to be unhappy about it. You did what you could, and there were things that you couldn't control.

I think you were right to say "I'm expecting to pick up the speed as I get more familiar with the team, project, product,..." but that's all.

Even if you were right, the "I will not be taking responsibility for other people's mistakes" and "this project was a failure of leadership/management" parts are unnecessary. Unless the manager was an ass to you, sometimes it's not always about right or wrong. That can leave a bad impression, which may or may not help you out later on. It's better to ease out the situation.

Perhaps if it happens again, it's fine to say all of it.

  • 3
    My manager is pretty chill, agreed. I did take it quite personally too. I have never had such feedback before, after more than a decade of working in different jobs. I also worked pretty hard and was really stressed, getting this project over the line. The main reason why I said those things is because I have seen people being made scape-goats before, getting blamed for management decisions or mistakes and I did not want to be that. I usually avoid conflict, however part of my manager's feedback was for me to be more assertive, so that's what I did
    – Web Dev
    Commented Jul 6, 2023 at 6:20
  • I see. I think it depends on many factors, but mostly the way your manage delivered the feedback. Probably the wrong way at the wrong time. I guess the only thing we can try is to control. This is the first time, after all! Commented Jul 7, 2023 at 19:25

"work faster" can mean many things. One could be to deliver sooner, which in turn could be caused by doing more than was asked for.

So one interpretation could be that you are productive enough but you polished the product for too long after you could have delivered. That might be easy to change.

Also the "really vocal about ... lukewarm responses" make me think that you might be rubbing them the wrong way too. Perhaps what you should just be saying could be "We would like to ship as soon as we are done with a satisfactory quality. How do we determine when this is the case?" (in other words when it goes from no to yes). This is important because the organization does not agree right now.

  • 2
    The op stated "this feedback seems clear cut" I disagree with that - bluntly did the OP make a mistake (such as delivering more than required) or is the boss simply asking the OP to put in more hours. The OP needs actionable feedback in order to make a change - if the OP didn't get actionable feedback, they should clarify the meaning.
    – DavidT
    Commented Jul 5, 2023 at 23:52

Do you want to continue to work with these people, to improve your satisfaction with your work environment, and for your managers to be satisfied with you? Then "this was a failure of management" is taking things a step too far. Probably two steps too far for a relatively new hire.

Other people have said the stuff about taking vs. deflecting responsibility, and looking towards the future instead of the past, so I'll take a different, and maybe slightly crass, approach: painting people into a corner may be a way to get them to do what you want in the short term, but it doesn't work for a longer-term relationship. Give people room to maneuver. Give them room to save face. When it's necessary, give them the opportunity to correct their mistakes without ever admitting they made a mistake. Even when you're 100% right and they're 100% wrong.

But also, realize how rare it is that you're 100% right and they're 100% wrong. Look for the other side and offer something in compromise. Say "yes, I will do a better job of prioritizing", or "yes, I will do a better job of clarifying ambiguities up-front" or even just "yes, I think I've learned a lot and things should go more smoothly in the future" while also making it politely clear that you feel that there are improvements other people could make. When you offer something, even a token, other people are in a social position to offer something back to you and be magnanimous about it. When you make demands, what you receive will be what others are required to give you.

Again, you may be correct that you're owed better definition of your tasks if management expects you to complete them on time. The question for you isn't whether you're right or wrong. The question is whether you want to permanently frame your working relationship in those terms, or whether you want it to be more collegial.


One thought, from my own experience:

Given time, I prefer to analyze a problem in depth and try to find the best solution -- elegant, performance, scalable, exhaustively tested, all those good things.

But approaching it that way does mean a longer delay before I'm ready to commit a solution. And sometimes none of that actually matters; what is most important is that the fix address the specific test case that is failing and be available ASAP.

I've had to learn to accept that sometimes all the stuff that I consider best practice really isn't appropriate at that moment. Performance of something not in the application's inner loop may be irrelevant. Generality is great, but not if it costs another day and the customer is losing a megabuck a day to the problem.

In theory, practice should follow theory. In practice, sometimes an imperfect solution is actually better. That's the difference between computer science and software engineering in a nutshell, and in business you're mostly engineering rather than conducting science.

If this feels familiar, the solution is sometimes to get the quick-and-dirty-but-good-enough solution out immediately, even if it's ugly -- but with comments calling out its known flaws -- and then open a second work item to revisit it and "do it right" when time permits. That gives the customer the quick fix they need, while reminding yourself and the team that you have accepted technical debt that will need to be paid back after the crisis is over.

Also, it helps if you can have something basic in place early, both to show that you understand what is being asked for and to start gathering feedback about what is most important.

"Make it work, make it good, make it great", as Steve Boies often said. And show your progress.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .