Strategies to talk about my low perfomance to my boss

Question

After reading the answers to Fired for the third time especially this one, I think I'm one of those who refactor code too much. I already got the feeling I'm not delivering before this, because I spent (and still am spending) too much time on my project, but this was a real eye-opener.

My situation is the following:
I'm the only one working on an big app, in winforms, which I am not too familiar with, with much technical debt (as in there is not a single pattern implemented, except for singleton) and I'm trying to get simple things to work (as in Drag&Drop, implement a new grid, ...).

I try to get distributed code together and abstract it, but this takes time and already has introduced an embarassing bug. For the current project I gave my boss an estimate and I can not hold it, again. I left similar projects on this app unfinished, because I moved on to others.

This leaves me with the feeling I am not adding (enough) value to the company, as some other -smaller- projects are getting done. I am ready to confront my boss with this feeling and admit I may not be qualified to do this on my own, but if I do this, from my experience (and other questions here) I think I should have a strategy and some options ready.

Good things are:

• Before this my performance ratings were good.
• My boss has not openly mentioned anything regarding my performance, yet.
• My boss is lenient and if I get this conversation right, there might be next to no negative repercussions.

What options do I have to go on with? Should I (not) talk to my boss? Which options should I present to my boss?

Answer 1

Keep in mind the OP in the questions you linked were told they were underperforming and given a chance to redeem himself/herself. Based on the OP's own admission, he/she refused to do the work and instead focused on refactoring even after the deadline and point of being able to redeem. It's sort of like if you hired a painter to paint your house and he's tearing down plywood and changing the pipes and doing everything but paint. You'd tell him you want him to paint but he refuses and keeps doing these so-called "paint prepping" work. Would you want that person to keep "painting" your house? It sounds like you were not told this.

It may be your boss understands it is a hard thing to modify. Being a one man team, it's understood you'll run into bugs and errors, maybe big ones too.

In all I wouldn't tell your boss you're underperforming. Just talk to him about expectations and if you're meeting them. Also bring up the bit about the hard to managing code and the fact you're spending time refactoring.

Answer 2

I think the best approach is to be honest to your boss and tell him that the code base needs to be refactored in order to be easy to manage in the future.

Answer 3

Open and honest communication is your friend here.

The good news is that you have had good performance appraisals in the past, and haven't heard anything different in the meantime. While managers don't always heap on praise when things are going right, they will usually be pretty good about letting you know when they see a problem. The fact that manager hasn't said anything to you is a good sign that you are at least meeting expectations.

That being said, there is nothing wrong with asking for feedback. Have a meeting with your manager and ask for an honest assessment of how you are doing. Don't tell them you feel you are underperforming (there is no upside to that), but ask them what they think you could be doing better. Managers love employees who are proactive about self-improvement. Be ready to receive criticism, it isn't always easy, but remember that you are doing this so you can be a better performer in their eyes.

As for missing estimates because of unforeseen technical debt, it happens. Dealing with the unknown comes with the territory in this profession. With experience you will get better at predicting it and building it into your estimates. The key is to be honest about it and give regular updates about what you are doing, what challenges you are facing, and why it is taking longer than you thought. Missed estimates are annoying for a manager, but most managers just want to know what is going on so they can plan around it. It is much worse for a manager to be blindsided by a missed deadline because they didn't know you were having problems.

So if something is taking longer to implement than you originally thought because the codebase is an awful mess, be upfront about it. Communicate what you plan to do about it and keep your manager up to date on how it is going. And if you have to face a decision between a quick fix that adds to the technical debt or taking a lot of time to fix it the right way, present those option to your manager and let them make the decision. That's what they get paid to do.

Answer 4

For the current project I gave my boss an estimate and I can not hold it, again. I left similar projects on this app unfinished, because I moved on to others.

If by "unfinished" you mean that you abandoned some requested features before implementing them because you couldn't get them to work, you should talk about that with the boss.

It would be better for your ego, and better for the client if you picked small things you can do and implement those. As you do that, you will get better and the client will get an incrementally better product.

Pick some things you can do, go to your boss and get buy-in for those to be the next deliverable, and deliver. Your moral/confidence will increase.

Answer 5

Let me give you a different POV. I was CEO of 2 successful businesses (not safe for health), so i want to give my opinion as if you were an employee of mine.

My company is my daughter and best employees are the ones that demonstrate to care about my company and that are really happy in creating a tight-knit team. Always remember this when you want to have a talk with your boss, don't focus on yourself but look at the bigger picture.

Best an employee in your position could do if i was the boss is come to me and talk honest. Not blabling about his own feelings but honestly talking about his own performance compared to the company.

You nailed it pretty well

I'm the only one working on an big app, in winforms, which I am not too familiar with, with much technical debt (as in there is not a single pattern implemented, except for singleton) and I'm trying to get simple thing to work (as in Drag&Drop, implement a new grid, ..).

I try to get distributed code together and abstract it, but this takes time and already has introduced an emabrassing bug. For the current project I gave my boss an estimate and I can not hold it, again. I left similar projects on this app unfinished, because I moved on to others.

This leaves me with the feeling I am not adding (enough) value to the company, as some other -smaller- projects are getting done. I am ready to confront my boss with this feeling and admit I may not be qualified to do this on my own

Go to your boss and say this exact line adding that the whole argument is related to the company and the team that you like and strongly want to succeed.

You said yours is a good boss so i am pretty comfortable in giving you this advice. Be honest and give your boss the possibility to chose the best for the company without putting your mates and your boss in a bothering position for a selfish worrying. I would pay double the paycheck for an employee that i am sure can go after himself and be honest for the sake of the company.

Answer 6

It takes you time to abstract code, has introduced a bug, and no-one has asked you to do this. So you need to consider why do you think this is important? What is it adding to the project? Is it really necessary?

In the past, I've seen a number of people have a great temptation to do this sort of "busy-work" when they don't know how to do the thing they're supposed to be doing. But at least if they refactor it it must be getting better and maybe then the solution will drop into their lap.

If you have strong solid reasons for refactoring then take those to your boss, explain to him why you think that the code needs refactoring and that's why you are taking this approach, but it will take more time. If he agrees, he'll know what you are doing and why it is taking time and you should be fine. If he disagrees you will at least get more specific direction from him.

On the other hand, if you find you are refactoring the code "just because" then you definitely need to stop. You say you are trying to add simple things like implement a new grid but is the problem that you can't find where to add it? That you try to add it and it doesn't work? Clarify what the problems on that fix are, then take that to your boss. Having strategies for a meeting like that are good, but if you really need to just ask for help, then go ask for help. But be sure you can detail what you have tried and what the results were.

Answer 7

Things are not necessary bad :)

already has introduced an emabrassing bug.

There are no embarassing bugs. Everyone makes mistakes - that is normal. What you can do is try write as much tests as possible (unit, functional, integration, etc). This will not prevent bugs, but should reduce their numbers.

I gave my boss an estimate and I can not hold it, again.

From this I can conclude that you are a young engineer. Maybe you should work on your estimation skills. For better estimation, you need to have some experience. Also, you can try monte carlo estimation method.

If you are not sure of your progress, or your performance, you can always ask your boss what he thinks, but without mentioning that you think it is bad.

Answer 8

It is good to be self critical, because only then can you truly improve yourself. But don't let yourself be fooled that you have low performance. If your manager is unhappy with your performance, they will tell you.

That said, a giant red flag here is that you're missing estimates. When you miss an estimate, you need to know why. Then you either eliminate the why or you factor it into your next estimate. If you're missing because of refactoring, that is a problem. The problem isn't that you're refactoring, but rather that refactoring isn't being calculated as part of the estimate.

So I recommend not discussing it with your manager at all. Don't give him a reason to go looking for a reason that you have low performance!! Instead, do the professional thing: learn from the past and incorporate it into your future. And the first way you can do that quite easily is by making sure your estimates reflect the work you plan to do.

Answer 9

As others said...

1) approach boss / PM proactively & be honest

But, I would also add...

2) be honest that

a) you're forging new territory with the tools / code you're using (ie: you're not an expert, so they can't make project assumptions based on you being an expert in it)

b) it's a big hairball mess you're trying to untangle.. which increases

i. ) the time it takes to learn the code ii. ) the time it takes to make changes

What this will tell your project manager is that when it comes to time estimates (which PM's love, and which they try to hold everyone to) your estimates are just a shot in the dark and are wildly inaccurate. Not out of malice or stupidity.. just because this is new territory for you to cover, and the territory is very hostile (crap code).

So, instead of asking you for exact time cut offs (eg: "10 days to do this, 5 days to do that"... Critical Path Method / CPM time estimation) .. they should instead expect estimated ranges of time... more of a "I think it'll be 10 to 20 days before I can get this done."

And if they ask why the wild time range estimates.. you'll need to speak Project Management lingo and say you're switching to more of a PERT (Program Evaluation & Review Technique) Time Estimation method.

What PERT does is require people working on milestones to provide 3 time estimates...

optimistic (when it can get done in the 1% situaition when god is smiling on you and everything goes right)

pessimistic (the 1% time when satan is just pooping all over your project and nothing goes right)

most likely (a time you feel comfortable in hitting 50% of the time)

It's important to underline the fact that "most likely" is not "I'm 90% sure I can get the thing done in this time". No.. it's "50% of the time I can hit this estimate".

Because the opt, pes & most likely estimates map out to a bell curve in PERT...

opt = +3 std dev to right pes = -3 std dev to left ml = -2 to +2 std dev's inner bell curve

avg time to finish milestone = ( opt + ml x 4 + pes ) / 6 std deviation estimate = ( pes - opt ) / 6

(a PERT bell curve assumes 6 std deviations, because a +/- 4th std deviation level is going way out into "astronomically unlikely outliers" territory.)

PM's would take the time estimates and can do z-scores to get probability curves on when things will be done.

But, bottomline is that PERT is used to figure out which milestones are hazy.. something new and different enough that makes folks give shakey estimates will have a wider range then a milestone that someone has done before and is very confident about.

Your boss (if they're a PM or versed in Project Management) should hear the word "PERT" and start to understand that maybe they need to rethink how they view you working on the task.

Because while PM's often dig into the PMBOK and learn a lot of math and six sigma stuff.. eventually in the real world they get lazy and just switch to CPM methods or what-not and simply ask people to give them a SINGLE NUMBER time estimate for a milestone.

That's great for them.. b/c they don't have to calculate stuff to fit it into their network diagram and project tracker.

But, it sucks for the worker bee like you.. b/c then they hold you to an exact number / date... and in a project where you're doing something wildly different then what you've done before.. you don't need that kind of pressure.

~~~~~~~~~~~

It's also just good to let a boss know that, while you are a programmer, that doesn't mean you're an instant expert on everything programming.

I was employed as a an analyst / report runner at one place attached to a project management department, and I knew some coding so I automated a few things. Since I did that, they thought of me as "coder guy". So, one day director approached me to build out an interactive web site.. like ASP, HTML, the whole nine yards.. was going to be a company-wide project tracking web-site.

I'm looking at him dumbfounded, because he didn't seem to understand that a) that was WAY out of my wheelhouse, b) even though it was, I knew that what they were asking was something you would usually hire a team of prorammers to do.

I had to have an uncomfortable chat with the guy.. and I had to put it into language he could understand.

"Imagine you, the director of project managemet got transferred to be the director of billing"

"Ok.. that would be a change of pace, but I don't see what the big deal would be..."

"... in china."

"China?"

"Yeah.. china."

"But, I don't speak chinese."

"Exactly."

"Oh." (suddenly he realizes what he was asking of me)