Dealing with "work faster" feedback

Question

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.

Thanks!

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.

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

"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.

Answer 6

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.

Answer 7

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.