22

I've been working at my current company for about 2 years. This is my first programming job so I don't have much reference.

Since day one I've had to give estimates on changes to code bases I've never seen, or had maybe seen a small piece of a gigantic application. The applications themselves are not well documented so I have to ask a lot of questions to figure out what the user story is actually referring to on a basic level. My estimates have gone over frequently as a result. I was talked to by my manager a couple times about hitting my estimates/commitments.

We recently broke our department up into kanban teams. Our team handles the small modifications to existing applications (features that the business unit requests that are too small to be their own projects). Every week we have a design session to get our estimates in place for upcoming work. Since I've been on this team, I've been working on yet another application that I've never seen and is poorly documented. We give estimates as a group and everyone agrees or disagrees. Last week my manager put me on a performance improvement plan because apparently I'm still missing estimates too much. It's effective for about 2 months at which point if things haven't improved I'm basically out the door. We both signed and dated it.

Today we had a meeting as a kanban team and basically we're realizing everything is being underestimated. We're supposed to be getting 95 hours of task work done per week and, based on previous estimates, we're at about half that because unexpected things come up that weren't discussed at design. Our team is a mix of junior devs and senior devs. It just kind of surprised me today that as a team we're way off on estimates yet I feel like I'm being evaluated more severely. Maybe others are on PIPs too, I don't know.

How do I get better at estimating this stuff if I have limited experience with an application?

Okay so alot of feedback here. I guess my next question, since I'm most likely out of here in a couple months, should I quit and find something else, which will most likely be a job I take in despair because I need it so it might be the same type of environment. Or do I do my best while I'm here, get unemployment for a few weeks while I focus all my effort on improving the skills I need for the job I want, and finding that specific job? So basically it's a 'quit' vs a 'let-go', but honestly either way I doubt I'd have a good reference at this place so it probably doesn't make much difference from a resume perspective.

  • 23
    And if your team is planning on a full 40 hours per person per week, then they are doing it wrong. No more than 6 hours tops a day for planning deadlines (as opposed to just hours for the project)as other things like vacation, jury duty, HR meetings, general team meeting, etc have to come out of that time. In all jobs there is about 20-25% indirect time that has to be factored in to deadlines.. – HLGEM May 12 '15 at 17:14
  • 41
    So, multiply all your current estimates by 2 and perform work on that basis. – Vietnhi Phuvan May 12 '15 at 17:15
  • 6
    Definitley pad your estimates until you get better at estimating. Setting a easy target and hitting it is better than setting a hard target and missing it. – Myles May 12 '15 at 17:26
  • 5
    If you are doing Kanban you don't have estimates, you should be watching Work In Progress limits and average cycle time????? – The Wandering Dev Manager May 12 '15 at 18:24
  • 11
    I'm sorry to hear about your situation. I think a more appropriate question to ask may be "What percentage of PIP'd employees pass this plan?" as opposed to "is this just a formality you're taking before firing me?". Do start the job search NOW. You've been at the company for 2 years, so there are no red flags to other employers, but a job gap certainly will be a red flag. I know this is personal, but I think that updating this post with the final outcome of this situation may help out a bunch of people, especially those to ashamed to post. I'd be curious for the stats. – Maciek May 13 '15 at 4:57
35

Something to ponder - if everything seems to have unexpected things come up that make them take 2x as long, perhaps you should be planning that something will come up and make tasks take twice as long?

How do I get better at estimating this stuff if I have limited experience with an application?

  1. Stop trying to do it by yourself. Find someone who is good at estimating (or your boss) and ask them to help you. Have them explain why they make the numbers they do.

  2. Document what you expect to have to do for these tasks more detailed (this will help anyways)

  3. Keep track of how well you hit these estimates and document what things you missed from the above list of expectations

You want to avoid at all costs missing estimates in the future.

Keep in mind higher but more accurate estimates are generally better than lower, missed ones.


Just a general note, regardless of what the reasons the PIP was initiated, the OP has signed something indicating the problems and needs to work earnestly towards resolving those issues. This related question has some good insight about other ways to save your job during a PIP (it's hard and in some cases impossible) - it's possible this is just a formality to them losing their job but either way they have to follow through on it or it will 100% cost them their job.

  • 1
    I think it'll definitely help me to document my thought processes/actions to some extent as I work. Sometimes I go over an estimate without thinking about the fact that I'm doing something that wasn't accounted for. – yankees13 May 12 '15 at 18:22
  • 32
    That this is seen as a problem with OP's performance instead of one with his estimations is a work place smell. Honestly, if OP is doing good work and is just bad at estimating, that would not be reason enough for a PIP. And if someone is known to be bad at estimates, the manager should ensure one of the better estimators on the team reviews the estimate before sending it out to the customers (especially after the first few misses). – Lawtonfogle May 12 '15 at 18:26
  • 34
    Captain Kirk: How much refit time before we can take her out again? \ Mr. Scott: Eight weeks, sir, but ye don't have eight weeks, so I'll do it for ye in two. \ Captain Kirk: Mr. Scott, have you always multiplied your repair estimates by a factor of four? \ Mr. Scott: Certainly, sir! How else can I keep my reputation as a miracle worker? – Mason Wheeler May 12 '15 at 20:53
  • 4
    @Lawtonfogle - Actually I have worked in meat grinders that cared more about the numbers than the work being performed. The only long term devs they had were good at hitting agressive targets with crappy implimentations that came in on time. They were seen as superstars... – IDrinkandIKnowThings May 12 '15 at 21:10
  • 4
    @MasonWheeler, yeah I laugh every time Kirk/Scott or Picard/La Forge talk. It should be the other way around. "Kirk: How much refit time? Scott: One week. Kirk: Let's say two weeks." Eight weeks later, it's still not done." – Paul Draper May 13 '15 at 6:01
40

I'm afraid you're asking the wrong question. The real question is whether you should stay at that place.

Most likely they have made up their minds about firing you and the performance plan is just a formality they have to do to have "evidence of poor performance" before letting you go.

By far your best course of action is to start looking for a job and quit on your own.

My advice comes from working 7 years in a company like that (Bloomberg LP). They would try to squeeze every last drop of performance out of you by first pressuring for over-zealous estimates, and then throwing a bunch of bugfixes at you demanding that they be done in parallel with your project, and then scolding you for "missing the self-imposed deadline". I've witnessed a lot of people being put on unrealistic performance plans. I've never heard of anyone finishing a performance plan and staying at the company.

I even once forced out my subordinate by putting him on an informal performance plans (while he thought it was a formal plan). He waited till the end of the month and quit. (As a team-lead, your managers demand that you either "improve" your team's performance or fire your weakest team-member to keep the others in fear).

Quitting that job was the best decision I made in my life. After taking 6 months off, I easily found a job that is superior in EVERY aspect (pay, attitude, opportunity, satisfaction).

Don't put up with this. It will only get worse.

  • 2
    Seems like a valid argument. One point, they may or may not be planning to fire the OP, but they probably won't ever promote them again. – Mark Rogers May 12 '15 at 21:12
  • 12
    +1 for "I've never heard of anyone finishing a performance plan and staying at the company.". PiPs are rarely used correctly and any decent manager won't bother with such arbitrary documents but will intervene much earlier with ongoing assistance if an employee is struggling. Your final line is probably the best advice OP can get here. – Lilienthal May 12 '15 at 21:17
  • 2
    My manager has intervened prior to this. He has made attempts at helping me by having regular chats about what I'm working on and if I'm stuck on anything. I feel like he does have good intentions, so I'm not sure if the decision has already been made or not. But fwiw, regardless of the PIP situation, this isn't the type of job I want and I'd be looking elsewhere anyways. The only other wrinkle at this point now is how to explain this work experience to the next place. – yankees13 May 13 '15 at 0:46
  • 5
    Quite apart from the issues regarding the tenor of the company and management, the OP should also be asking whether they should stay because two years spent fiddling with small changes to a variety of elderly, poorly-documented applications is not a great way to start out a programming career. Don't get me wrong, you'll learn useful skills, but you really need to mix that up with also learning some useful skills at developing software, not just maintaining it. – Carson63000 May 13 '15 at 7:10
  • 1
    This is the correct answer, agile methodologies used as individual performance metrics is a huge red flag, and a performance plan is a clear sign someone wants you out. Unless you can identify who that is and be reasonably sure they are on their way out start looking. Even if they are fired tomorrow you still are that much closer to being fired. – Bill May 13 '15 at 17:14
7

Your boss is presumably expecting you to do one of these things:

  • get better at estimating. This requires retrospection (on your own or with the team) when things are finished. Forgot to allow for rework? Didn't realize how different the production system was from the test system? Never used technology X before? Learn from that. Allow for that next time
  • pad your estimates. If you are always going over 50%, when you think it's 10 say 15. At least have this level of understanding of your estimating ability
  • cut your coat to fit your cloth. Get it done in the time you said you would. Maybe you test less, maybe you write a less general solution, maybe you stay late and don't count those hours, whatever.

Set aside your worries about whether others are also being punished for doing something wrong and focus on no longer doing something wrong. As a first approximation, just bumping up your estimates and taking on less work is a good start. If the group won't increase the estimates, then you have to face the possibility that you're not so much bad at estimating as bad at executing. It sounds like your group retrospective is leading to the conclusion that estimates are the problem, though.

7

First you know you are consistently underestimating, so you know you probably need to add more time to every estimate.

But how you get better is by keeping records of estimates and actuals and then using them to give a better estimate than before. If you aren't familar with the application, add time to the estimate over what it would take if it were an application you know well.

Another thing to do is to break your estimates into smaller pieces. If you have subtasks and you add them all up, then you are likely to have a better estimate than if you give one number. We also add time for all the things not directly devlopment but which must be done and you may be forgetting those. It includes answering emails on the subject, meetings (espcially if you have daily meetings), research (this will be high if the application is unfamiliar), writing unit tests, doing the testing, anything assoicated with source control and doing a build, creating action items for QA, and pushing the code to multiple environments, fixing QA bugs etc. And always pad a bit for unexpected things.

  • I would also suggest giving up on estimating hours. Instead, estimate effort (something like scrumalliance.org/community/articles/2014/january/…), and calculate hours from collected data. The problem with estimating hours is psychological. Your initial estimates begin to drift based on the adjusted estimates. Over time, this undermines the data you've collected somewhat. – Rich Remer May 13 '15 at 19:59
3

OP, you asked, "is this fair" -- unfortunately, fairness doesn't really matter because the outcome for you is independent of the fairness of the PIP you signed.

You're on a 2 month performance improvement plan, so however your performance is measured, if you want to keep this job, you need to do a fantastic job and meet or exceed those expectations. So yeah, you need to get better at estimating or put in more hours to meet deadlines, or perhaps a bit of both.

The PIP is a way for your boss to fire you in 2 months and, frankly, it sounds like you're on your way out. I think you should do the following:

  1. Do a great job. Make better estimations. Finish on time. (It's better to overestimate time needed, like others have said.) You need to show them how much work you can get done in 2 months and they need to understand why it took 2 months and is time well-spent. Make sure they know why, don't assume!

  2. Work on your resume. If you end up getting fired in two months, it won't be a surprise. You'll know if you're meeting expectations or not. Be prepared for the worst. It doesn't hurt to start looking around for a new job if you think it will go that way. It's also much easier to get a new job while you're still employed.

Yes, life will be a bit stressful for a couple months, but you'll get through it. And if you learn how to meet their expectations at work, you'll keep the job, learn how to estimate better, and score the win-win for everyone involved. (But have a contingency plan, too!)

  • 2
    "If you end up getting fired" is a big if. I have only ever heard of one person on workplace SE NOT getting fired after being put on a PIP. These are dismal odds. Use the time more wisely: Build resume, interview, gtfo of there. – L0j1k May 12 '15 at 23:36
0

The first thing you need to do is figure out if your skill level is causing you to work slower than the rest of the team. Most people can honestly answer this themselves. If you can great. If you can't talk to some team members and get some feedback on your skills.

Second, when estimating how long it will take you to do something are you factoring in overhead? I might say that it will take me 15 hours to add new feature X. However I know that I might have to send out 10 emails on feature X and get feedback. That in itself might take 10-15 hours of going back in forth. Of all the estimation mistakes for my programmers this is the #1 issue. Especially when you are dealing with a client or PM that really doesn't know what they want or what they are talking about.

Third, are you spending your time dedicated to your task? Are others asking for help from you all the time? Do old assignments pop up for a half an hour out of your day? Things like these are total time eaters.

Fourth, like you said you are working on someone else's mess. I don't see how I would expect any of my employees to give an accurate estimate based on "some" information. In my opinion your manager should be forecasting these things, not you. Then your manager could manage the mess of code and the three things above.

When you have all of these factors in place, you need to talk to your manager about how you should deal with these issues. If it is simply that he wants you to give larger estimates that is fine and easy to deal with. But he may want the estimates shorter and want to fix issues with the communication in the team, your skill level, or how the code is handed to you.

You aren't going to go anywhere with this manager until you figure out if his problems are with accounting or efficiency. If it is accounting then just add more buffer to your estimates. Also I suggest having a team member that is meeting their estimates give you advice on how long your next few projects should take. You can probably figure out your estimation deficiencies by getting in the head of a good coworker - who knows they might just think of a number and triple it.

If it is an efficiency thing and has to do with your skill level, then you probably need to get help from teammates more whenever you are stuck. If there are other factors hindering your efficiency then you need to document these and relay them to your manager. I would not assume that your manager just wants you to double your estimates and not communicate the real issues until you hear it from him.

  • I will admit some of it was my fault of not getting help soon enough. But that was pretty much what brought on the first couple talks. Since then I felt like I've addressed that and was still put on a plan. – yankees13 May 12 '15 at 18:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.