25

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.

yankees13
  • 411
  • 5
  • 10
  • 24
    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
  • 42
    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
  • In software we have the 80/20 rule, 80% of your work takes 20% of your time, the other 20% of your work takes 80% of your time. This is because if you try to make exact estimates you've already setup yourself to fail. (it's extremely rare everything goes according to plan at the best of times) that said it's good to figure out about how far off your estimates you typically are and learn to adapt. Effectively I've found I pad my times by roughly 20-30% which typically lands me right around the what most items real take. so you make most deadlines with the rare miss. – Eric J Fisher May 12 '15 at 20:27
  • @JamesAdam Yea I was kind of getting that vibe the last time we talked, before this PIP started. I've been working on side projects in my spare time to get into something I'd rather be doing anyways. Hopefully it works out. – yankees13 May 13 '15 at 00:10
  • @TheWanderingDevManager I've been wondering the same thing. But I think part of the reason is because our group doesn't take on work that's beyond a certain scope. So we do a rough tshirt size, and if it falls below an XL, it's something we take on. Once requirements have been finalized, we then do a more detailed design meeting where we break it down by tasks and estimate them. At this point we can modify our tshirt size if we uncover a bigger workload than originally anticipated. Also, most of the work we do is date driven lol. – yankees13 May 13 '15 at 00:18
  • There's been alot of mention about whether the PIP is just a formality at this point and that they already know they're canning me. Should I go up to my boss and straight up ask him? – yankees13 May 13 '15 at 00:54
  • 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 04:57
  • Is your question about how to get better at estimating tasks, or about whether it’s fair that you’re on a performance improvement plan? – Paul D. Waite May 13 '15 at 08:09
  • 1
    Talk to your team about the Scotty Principle. – A E May 13 '15 at 10:04
  • @PaulD.Waite It's both. I want to learn how to improve. But I also want to make sure my performance is being evaluated fairly and that their expectations aren't unreasonably high, as far as expecting me to estimate work on systems I'm unfamiliar with and then hit those estimates. – yankees13 May 13 '15 at 13:12
  • Your boss needs to look up the word "estimate" in the dictionary. Even the best "estimators" do not get things right 100% of the time, there is always something unexpected that can crop up to mess up the best estimates. Where I used to work, we had an estimating tool that took into account how many lines of code were needed, how many database changes etc and that gave us a rough estimate. We then added 50% to that and it was usually quite accurate but always a generous estimate in case things took a bit longer. – davidjwest May 13 '15 at 13:47
  • @stuter12: okay. I’m not sure if “how do I get better at estimating” is on-topic for this site. (It might well be; I’m not too familiar with the principles.) The fairness one seems to be. It might be better to ask the questions separately. – Paul D. Waite May 13 '15 at 14:38
  • 1
    A search for "estimation" on http://programmers.stackexchange.com/ yields many results. Regardless of whether you stay with your current employer, you will want to start working on how to estimate better. The aforementioned search will probably reveal a number of resources; among my favorites is Steve McConnell's book, Software Estimation. – Andrew May 13 '15 at 18:16

6 Answers6

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.

PTN PNH
  • 379
  • 2
  • 3
  • 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
  • 13
    +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
  • 3
    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 00:46
  • 6
    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 07:10
  • +1 Exactly. PIP is more humane way to firing you (OP) outright. Start looking for a job, it is over for you in current company. – Peter M. - stands for Monica May 13 '15 at 12:53
  • 2
    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
39

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.

Community
  • 1
enderland
  • 110,742
  • 49
  • 328
  • 478
  • 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
  • 34
    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
  • 1
    @Lawtonfogle 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 too - it's possible this is just a formality or a mistake but either way they have to follow through on it or it will cost them their job. – enderland May 12 '15 at 18:32
  • @stuter12 that's how you learn, too. You learn by understanding what you do and why - if you are missing estimates, blindly hoping you get "better" without a plan is just wishful thinking. But if you start doing something different this will at the very least help you have better insight and perhaps even surprise you and your manager. – enderland May 12 '15 at 18:34
  • 1
    @enderland OP has signed something, but getting rid of a good employee because of a small issue is stupid when you consider the cost to replace them. Sticking to rules like this just because they are the rule is the sign of bad management (either the manager for sticking to the rule so tightly by choice, or the middle manager for enforcing managers to stick to the rule). All in all, I would be dusting off my resume and looking for a new position. A 'I switched jobs' is far better than a 'I was let go for a stupid reason' even when it really was a stupid reason. – Lawtonfogle May 12 '15 at 19:28
  • 37
    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 06:01
  • 1
    @PaulDraper That would hit too close to home for most people :p – thanby May 13 '15 at 13:22
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.

Kate Gregory
  • 150,088
  • 64
  • 339
  • 452
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.

HLGEM
  • 142,324
  • 26
  • 258
  • 516
  • I would also suggest giving up on estimating hours. Instead, estimate effort (something like https://www.scrumalliance.org/community/articles/2014/january/a-practical-guide-story-points-based-estimation.aspx), 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!)

Rocky
  • 1,163
  • 8
  • 10
  • 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.

blankip
  • 22,297
  • 7
  • 56
  • 86
  • 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