Is it the norm: Manager demands estimates before requirements can be analyzed
Posted by theeburneruc@reddit | ExperiencedDevs | View on Reddit | 117 comments
A new task has come my way. To even begin to understand it, I need to talk to business, to end-users, and to developers, in order to understand the breadth of the work. But, before I can even get to doing any of that, my manager (not project manager), is demanding that I provide everything from: the written list of requirements and design, and estimates, and dates, for dev, testing, qa, prod implementation, etc.. I gave him a rough list and rough dates, considering I have little to no information right now, yet he was not satisfied. Is this the norm and what are you supposed to do in this case.... I already explained to him that I need to talk to people before I can create any such estimate..
tiethy@reddit
Generally I just set something up based on the information I have on hand. If I need to:
Talk to business
Talk to end users
Talk to developers
Then that’s what I put down when I’m asked for estimates.
Need to talk to business to determine their requirements, meeting set for date Y.
Need to talk to end users to determine their requirements, meeting set for date Z.
Need to talk to developers to determine costing and staffing, meeting set for date X.
Once previous 3 steps have been completed, we should have the information we need to put together a plan- we estimate the plan to be ready by date A.
Written list of requirements: TBD by date A
Design : once we have requirements, will set up meeting by date B with UX and follow up on ETA
Dev: once we have requirements, will set up meeting by date C to provide estimates.
Testing / QA : 1 week after dev complete
Prod implementation: QA + 1-2 weeks depending on bugs
binaryfireball@reddit
I would laugh at him to his face.
ch4lox@reddit
Extremely typical dysfunction, guaranteed to burn out people and result in missed timelines and finger pointing.
theeburneruc@reddit (OP)
And what do you think is the ideal alternative
ch4lox@reddit
I may not be the right person to ask.
I left 25 years of software engineering, the last 10 of it consulting in many industries looking for a better answer, to instead start a residential home building company a few months ago (though I do have one or two small projects for long term clients I sometimes still help with).
theeburneruc@reddit (OP)
How..... did you make that pivot? How does one even learn the ins and outs of home building when never having worked in the field, or at least not with priority?
ch4lox@reddit
Oh, it's been a real journey for the last few years...
I've spent a few years learning about the latest advances in "Building Science" (basically thinking of the entire thermal, weather, and water vapor management of the entire structure vs just disjointed building steps)... On my own, reading books and online material, and then later going to relevant conferences and meeting people who have been working in the industry via some meetup groups... Building Science is a bit like open source development.
As far as the structural engineering side of things, if you start with simpler structures, you can find nearly everything you need to construct typical wood framed buildings in the IRC code book, from framing details to joist, rafter, and header span tables with saves a lot of time and money if you can keep your projects within the prescribed guidelines.
Obviously, more hands-on time with building is important - you can volunteer and learn a ton hands on with habitat for humanity.. I've also always been a hands-on person, a few remodels of my own in the past.
I've also taken the step of relocating from Las Vegas Nevada, to Rural Vermont, after a multi year RV trip searching for the right place to start this company and raise my young child... Local building codes, zoning, local building techniques, local climate (especially wind and snow loads), geography and soil types, frost lines, etc, are all important factors.
The relocation was essential to the process because I knew I needed to reduce our monthly bills enough to handle the initial reduction in income I'd likely face.
One surprising thing that helped, was that right after the relocation, I joined the local volunteer fire department - that was a critical step to help me integrate quickly into the new community and meet many people who are in the trades or could facility networking opportunities.
theeburneruc@reddit (OP)
What a seemingly impossible feat to do that all without really working in the industry, congrats. At what point did you feel that you knew enough to provide value to a customer base? Where did you first turn to for your learning? I'd love to learn about pre-cast concrete, but to just find a course about it in the wild isn't too easy, let alone turn that into a competency that can provide value.... thx for the insight albeit offtopic
ch4lox@reddit
As far as precast concrete, I have used a few precast components on my two builds so far... both projects needed a septic tank, so I worked with two different companies figuring out their different options for the types of tanks (septic, aerator, pump).
For my personal home, I actually spec'd out my own precast cylindrical chamber and manhole for my well pump equipment (manifold, wiring and switching, and pressure tank) underground vs a more typical well house or basement install for those components.
I'm curious what you'd like to learn about? Of course we're way off topic now.
TruelyRegardedApe@reddit
Hey @ch4lox, if you dont mind me asking. What is your age? I made a pivot into software development in my early 30s. I've considered doing something similar to you. I just turned 40, and Im just concerned the amount of time required to do another transition not being worth it. eg learning, getting hands on experience, starting at the bottom, pay reduction, ect.
ch4lox@reddit
I'm 44 now, I started working on my learning for this process around 39-40
TruelyRegardedApe@reddit
yeah, I would have the same concern you mention, risk of injury is higher. I currently do quite a bit of work on my house and am very active. What would you say is a good incremental next step to go from DIY/hobbyist toward running your own building company. I do have some building experience, I worked on a framing crew during summers to pay for college. I recently rebuilt my own roof.
ch4lox@reddit
Volunteering with habitat for humanity would be a helpful, researching building science topics would be good too.
ch4lox@reddit
Oh man, it's hard to explain... I've always been pretty good at figuring things out and self-learning - it's how I ended up in software engineering after my years as an M1 tanker in the Army - I just fell into software because of the demand and because I enjoy learning and solving problems...
Repairing a toilet drain and troubleshooting an intermittent network latency issue are the same to me. I never really understood my engineering co-workers who had difficulty troubleshooting their own computer problems, so many people seem to wear blinders.
The big thing is to always accept that there is more to learn, and to not be afraid to say "I don't know" and dig in until you find the answer... This mindset is even more rare in construction than in software, and so far it's a real advantage - customers and good subs appreciate a straight shooter.
TheDotNetDetective@reddit
I can't tell you how inspiring this post is, nearly 20 years in the software industry, and seriously been considering a pivot to renovations/residential construction.
I wish you tremendous success.
ch4lox@reddit
There's a lot of demand, and not enough people going into the industry. I think you'd be surprised at how quickly work starts to line up.
morswinb@reddit
I am learning how to drywall this Summer, can I apply?
ch4lox@reddit
Sure! Though I'm looking for people willing to do every aspect of the job, at least while we're just getting started.
farox@reddit
Close to 30 years here... Hows it going?
ch4lox@reddit
It's the least stressful job I've had in years, and finally feel like I'm accomplishing something that really helps my community and families instead of chasing investor and executive enshittification whims at big corporations.
I'm focusing on energy efficient starter homes for middle class people at a reasonable price (in a rural area of New England)... This year is really all about discovering all my costs and figuring out my supply chain details.
The biggest concern is that while I have a small crew, I still do much of the work, so an injury (easier to happen as we get older) would really derail things.
Project planning and managing a team of people and subcontractors (only when necessary, to try to avoid cost and timeline problems), translates across industries.
farox@reddit
Amazing, good luck! Maybe look into an insurance, to have something at least in the worst case.
I still haven't found my way out yet, but glad to hear it works for some.
ch4lox@reddit
Thanks for the encouragement and kind words!
morosis1982@reddit
You say no. Assert that you won't give an estimate without any discovery.
thekwoka@reddit
Massively over estimate everything, and then mention that if you upfront spend X time doing investigation, you can likely give a shorter/cheaper estimate.
webbed_feets@reddit
I like to do this, but it doesn't work with especially incompetent managers. They'll tell you that timeline is too long then add an experienced junior or contractor to "cut the time in half".
LogicRaven_@reddit
The alternative would be to stack rank ideas, work from top down, cross-functional discussions on scoping and breakdown. Not using estimates for setting arbitrary deadlines, but an alternative like now-next-later roadmap. Review the stack rank and replan periodically.
It's just many corporate environments don't have the motivation to do this. People are promoted on visuals, not on results, so they are more interested in pushing through their feature than in agreeing on a stack rank of features.
nutrecht@reddit
I stopped caring about what individual managers want a long time ago. I care about what the business as a whole needs and delivering that. If that pisses off some individual nobody; go right ahead. I'll go work for your competitor then.
PmanAce@reddit
Get the requirements written down from the stakeholders and then do the analysis and speak to whoever you need to so you can accurately estimate.
prettycode@reddit
An investigation/spike period or work items. Itemize the things you need to do to get ballpark and turn that into work. The deliverables are stories or requirements for the implementation.
CardboardJ@reddit
Not doing any of that. It's all a waste of time and resources.
amlug_@reddit
We usually create "spike"s in my current work, like 1 week task to investigate and treat it as any other task in the sprint. maybe something like that would work?
theeburneruc@reddit (OP)
so is your product backlog essentially empty at the beginning, and then being filled by that sprint task you mentioned?
HoneyBadgera@reddit
No, the spike is just another task in the sprint. It’s just more open ended in terms how long is needed. Normally i ask for the team to time box them and then create a new spike to continue if needed.
Any tasks created out of the spike are then refined and estimated as normal for a future sprint.
passerbycmc@reddit
For my new job on a new product the backlog started out as 80% research and discovery type tasks. So people could research and explore ideas then make new tickets based on the outcomes.
ElasticSpeakers@reddit
The spike is one of many things you would be working on in that sprint (not to mention everyone else on the team who is doing non-spike work). Then the thing you spiked on, you review your findings with stakeholders and your team, then the decisions are made about what to actually plan to accomplish. That could be for the next sprint, or other longer planning iteration (quarters, etc).
z960849@reddit
Whatever you think it is just double the estimate. Tell them if you have a better estimate if you talk to more people.
amlug_@reddit
No, it is an old and ongoing project. For instance we recently needed mtls auth for certain clients, and there was a task to collect the detailed requirmeents and create a "doer" tasks to implement it. It's basically a way of saying "i need a week or two to make educated estimations"
Fluffy_Yesterday_468@reddit
Just gave a really broad estimate like sometimes mid next year
zica-do-reddit@reddit
Is it the norm: manager wants baby before sex?
metaconcept@reddit
I estimate about 9 months of work, so with 9 developers we should be able to deliver in one month.
267aa37673a9fa659490@reddit
Well if the Nine Mothers of Heimdallr can do it, I don't see why can't you.
MoreRespectForQA@reddit
Make that two weeks. You've neglected to account for the game changing nature of AI.
Affectionate_Horse86@reddit
Fine, but we have budget constraints. Those 9 developers can do it in three weeks if they are team players and work weekends. And make those nine six as we have headcount limitations.
PragmaticBoredom@reddit
So to clarify: You received a ticket that isn't well-defined enough to estimate. You want to talk to people to gather requirements for the ticket. Your manager wants an estimate before you can talk to people?
There's a lot to unpack here, but the first question that comes to mind is: Is it normal for your company to put the requirements-gathering and other product management work on the engineers? It's normal for developers to have to do some communication and requirements collection themselves, but you shouldn't be spending your days doing project manager work.
This might be where some of the confusion is coming from. Instead of trying to tell your manager that you need to go do product management work, try explaining that the ticket isn't complete. Who wrote the ticket? Get that person involved.
theeburneruc@reddit (OP)
Yes that is what the manager is asking.
It is the norm when a PM isnt assigned, but usually only senior devs provide the estimates.
Reaching out to the ticket owner has just led to me having to reach out to business and end-users for further information- at the end of the day it lies on me to gather the info needed. I thought that was the norm.
CardboardJ@reddit
No. Hard stop. You ask your manager or PM to gather the requirements and talk to the end users and demand written documentation of who wants it and why. None of that should be your job. Once your manager knows what needs to happen you sit down and have a conversation like adults.
Abject-Kitchen3198@reddit
I'd actually prefer the direct communication as a senior developer. It could provide much shorter feedback loop during refinement and implementation, and we may optimize the solution by better aligning it with the current system. There are situations where the machine is well oiled and written requirements handed to developers work, but not every project is like that.
CardboardJ@reddit
It's about accountability though. If you're not insisting on at least bringing a manager along for the ride then you're just going rogue. Someone else needs to sign off on what you're doing and agree that the estimate is worth the cost. I used to love talking to customers (still do actually) but its not my place.
Ask yourself if your manager ever tries to argue estimates down, or gets upset when a deadline slips for a legit reason? Do they even give a shit about anything but hitting their arbitrary kpis this quarter? Are you empowering that ignorance?
I've been thrown under the bus too many times because I cared too much about doing the right thing for a customer. Never go it alone. Always make sure someone above you cares and has skin in the game.
Abject-Kitchen3198@reddit
I assume that manager would have approved the broad scope and would be in the loop to steer direction as the work progresses.
CardboardJ@reddit
You would assume correctly, but see it from the manager's perspective. If you go 6 months and the manager doesn't have to be involved in a project except for the occasional steering and direction change, that manager is going to assume that the project is easy. It's easy because they didn't have to do any work. It doesn't have impact to them because they're not fully involved. They're going to naturally ask questions like why is this taking so long? Can we get this done faster? Why is this costing so much?
At the end of the 6 months, your manager will rate your performance. Do you have impact? Did you do something impressive? Maybe you did, but your manager won't feel it like they would if they were along every step of the way. Your manager may view requirements as unnecessary even if they came from the client. All these requirements will then be viewed as engineering going rogue and doing unnecessary things.
When budgets get tight (and they are tight right now), do you want to be the one getting thrown under the bus because you're being wasteful with company resources?Or do you want to be the one that's delivering important customer value?
secretaliasname@reddit
It’s taken me way too long to realize this dynamic with my manager. I’ve realized my performance assessment is most closely tied not to my output or work effort but to how I involve them in ways that hi-light the work.
To little engagement even if everything is going fantastic, hitting milestones, they don’t see the work and assume it’s either easy or I’m not working hard. I might be moving mountains for them but it’s not visible to them. Bad place to be.
Just the right involvement where they are there for key decisions, occasionally dip their toes in to experience the work first hand and they think I’m kicking ass.
Too much involvement and I needed too much help.
Most management also fail or refuses to understand the differences between estimates and promises. Statistically a good estimate of an uncertain process would be late 50% of the time but on the mean be correct. A promise date would be met like 99% of the time and also be set longer than necessary 49% of the time. Scheduling off estimates you know you can hit is VERY suboptimal but seems to lead to happier managers and stakeholders. I actively lie on estimates now and everyone is happier since management cares more about hitting milestones rather than completing work in the shortest but unpredictable amount of time.
Abject-Kitchen3198@reddit
I'm assuming agile setting where people are working collaboratively in small batches.
Affectionate_Horse86@reddit
It could very well be his job and I actually run away from places with a PM or where the manager specifies everything. They wouldn't need staff level people if that's their modus operandi.
But then, I'd schedule the requirement gathering with its own time estimate and the availability of the people I need to talk to as a potential blocker. Only when this dependent task is done, we can talk about planning the main task.
A bit different when you're in quarter planning phase. There numbers are pulled out of thin air. But it doesn't matter because I still have to see a place where projects are not completely reshuffled two weeks into the quarter (for some reason engineers need to be precise with their estimates and punctual with their deliveries, but managers can be late for something that they know with absolute precision will happen every quarter)
PragmaticBoredom@reddit
Gathering additional requirements and talking to the owners of the different domains is the norm.
But you shouldn’t become the point person for deciding what the feature actually is AND also have someone you refer to as the ticket owner. This situation leads to the ticket owner either getting free credit when it goes well, or having an easy scapegoat (you) when it doesn’t go well.
It also means you’re doing work that isn’t accounted for, which is why you’re already running into issues with your manager not wanting you to go do this work that the ticket owner should be doing.
secretAZNman15@reddit
Do you have to report how much time it takes to estimate estimates?
theeburneruc@reddit (OP)
Yes
kondorb@reddit
Software engineering doesn't work like that. Even you take all the time you need any estimates resulting out of it will have precisely zero value. Software development process cannot be predicted like that, it's a discovery and invention process where almost everything is an unknown.
theeburneruc@reddit (OP)
Thanks, any more advice on what the better alternative is, or how to fight back? The manager is a developer from way back in the Visual Basic age and always talks about how amazing he was as a developer. . so to convince him that I am more competent on anything is likely impossible, I can only ever lightly suggest something.
mgodave@reddit
Lots of great comments here. I won’t comment on any possible organizational dysfunction because I don’t have much to go on so I’ll just answer with my usual approach. In general, when I’m presented with these situations, I will give a wildly large estimate and a confidence value (High/Medium/Low, usually “Low”). The estimate is not just a random guess, I’ll try to ballpark a high level approach in terms of very high level milestones/steps, assuming I have enough information even for that, and write down risks that would make it longer (external dependencies on other teams, learning a new piece of tech, etc…). I’ll also highlight areas where I need more info. I will try to schedule in an early set of steps for requirements gathering/etc. write it all in a doc and get your manager to approve it. I try to give people the benefit of the doubt but if you are worried about trust with them, get them to approve it in writing. Give frequent updates in writing as well. Constantly update your estimates as you get new information and solicit feedback from your manager and partners on any tradeoffs that need to be made in order to meet the schedule or the feature set. You will usually have to trade features for time and vise versa as roadblocks occur.
Embarrassed_Quit_450@reddit
Your manager is looking for somebody to blame if things go wrong. Don't give a number you're not sure will work.
flavius-as@reddit
You ask him if he wants a good estimate or an estimate soon.
He'll want one soon. Fine.
Then you write to him in this format:
Based on my intuition and expertise and the little available information, the project will take between 1 week and 1 year (some absurd range).
The reason for this wide range are the risks and uncertainties around the project:
With appropriate time allocated to further research and clarification, I can try to narrow down this range.
Glad I could help
Your's Sincerely, X
Satoshixkingx1971@reddit
I would have them submit estimates to you and then you can correct them. If they have to do the work themselves they might be more apprehensive.
Factory__Lad@reddit
There’ll be some even less well informed person above him who also keeps asking for “estimates”.
It’s like mediaeval Russia; most everybody is acting as a human shield.
hashedboards@reddit
I get asked this every time and the answer is always no you have to wait. The red flag is if they don't take no for an answer and try to argue it out.
armahillo@reddit
“This will take somewheree between 1 and 10,000 hours, depending on requirements”
tiplinix@reddit
And that when these shit managers take the lowest estimate and call it a deadline.
MoreRespectForQA@reddit
*shrug* if they're the ones making commitments, they're the ones whose butts are on the line.
They'll try to weasel you into making commitments ("how long do you think this will take?") but you can easily deflect these weasel attempts and guide them towards the path of least resistance ("that depends if you are asking for a commitment or an estimate. if it's an estimate, 2 weeks. if it's a commitment, 3 months").
tiplinix@reddit
Sure, but it doesn't stop these idiots from trying to put pressure on people and even if you are able to ignore it, there's always going to be other people that can't and it can create some really toxic environment.
metaconcept@reddit
Don't do this. The managers and client will only hear the part about it taking 1 hour.
Fuzzy-Race-2598@reddit
I faced this a lot. People came with very random requirements which requires way different systems than what we have ever built in the company and asked to give a rough estimate. More often than not, the estimates turned out to be wrong and I got blamed. Now I use a bit of a different approach. I write down whatever the requirements they are vaguely explaining and ask them to sign-off on the requirements so that we finalize on scope of work and then we move to estimates. Seeing such vague requirements more often than not they get triggered and start refining the requirement doc. This gives me time to gather better system design and come prepared for the next meeting. Also, the requirements become a lot more clearer than before. It has certainly helped me wade off projects which were anyways going to be scrapped and also helped me gain better credibility. Try it out and see if it works for you.
GoonOfAllGoons@reddit
He's playing "guess the number I'm thinking of."
Ask him what the estimate he's looking for is. Make sure you have pointed that out.
MutMan78@reddit
This is very common. One technique that I've found helpful is PERT estimating. This is a three point estimation technique. I have a spreadsheet that I use that will take the three estimation points and shows various confidence based estimates. This is not perfect by any means, but I've found that it can help quantify how ambiguous the ask is. If the ask is very vague, the range in the estimates will be huge.
hw999@reddit
Id be ok giving t-shirt sizes early in before requirements, but ninway im ageeeing to a date.
Your boss sounds like a micro manager. I'd either look for another job, or try alot less hard to aoid burnout in an environment like that.
gomihako_@reddit
That doesn't even make any sense.
burger-breath@reddit
Gathering requirements and building a realistic project plan with needed headcount resources, timeline estimates, budget outlay, major risks/unknowns, etc. is work. Ideally it counts as work in whatever agile/kanban/blah system to which you are held accountable. If it were me, I would highlight to my manager (and ideally do it in a way where the skip will see it) that running off half-cocked on a major initiative without doing this up-front work is a huge risk to the success of the project, and, depending on the expenses/customer-impact, to the business itself. Get it all in writing in Slack/email/whatever and, again, try to engineer a situation where the skip sees it sooner rather than later.
chimpuswimpus@reddit
Don't worry about it. In an environment like that they'll be so used to the noise of deadlines flying past they won't even notice once more.
and0p@reddit
That sounds familiar, unfortunately. It sounds like you're not a run of the mill individual contributor so you might have some ability to really push back. I've found that if I just say "I do not have enough information to provide what you're looking for" they eventually let up. But it's important to stick to your guns on that. And I'm not sure what the actual culture is there.
Potato-Engineer@reddit
You can also give an imprecise estimate. The real question is whether you say "three weeks to three months, I need more data" and your manager hears "shipping to prod in three weeks."
thekwoka@reddit
that's why for 3 weeks to 3 months, you say 3 months to 5 months, but that with some investigation you might be able to bring it down.
frustrated_dev@reddit
I would go against the grain and say it's normal at a certain level. Say senior+. Ideally staff/principal level.
The more experienced you are, the more you are expected to be able to make calls without all of the information.
Estimates aren't set in stone and can be managed after being made. Early estimates like this should be t-shirt size - small, medium, large, XL
yoggolian@reddit
And much more normal when everyone has some shared context - where you can get alignment on something like “that sounds a lot like project XYZ from last year because of, and we estimated that at 3 months once the requirements & ux was finalised, but it really took 7 because…” - expecting this from a junior, or even a senior+ without the common context isn’t reasonable.
boneskull@reddit
Estimates like this have a funny way of becoming “commitments”
JWolf1672@reddit
I'd have to agree with this, we do t-shirt sizes for this stuff and would agree that I didn't start getting these requests until I got senior
valkon_gr@reddit
No other road to choose than overestimating
Intelligent_Water_79@reddit
So rather than estimate and multiply by 3, multiply by 6
nutrecht@reddit
Bad managers are common, but I would not say this is "the norm". I just don't play that game. If someone asks me an estimate without allowing time for analysis I'm just going to give them a wildly overinflated guess.
Then they'll just go to some junior developer who doesn't know how to play this game, that will then comply with their demands and give an 'estimate', and then that poor junior is going to be tasked with delivering a "thing" no one knows the details of.
I was that junior in my 20ies, I'm 45 now. I completely stopped caring about what these kinds of managers think.
IngresABF@reddit
You tell your manager to get fucked. In whatever language you’re comfortable with. Show some spine
Andrew64467@reddit
As others have said this is a terrible way to do software development. If you really can’t persuade your manager to use a sane way of estimating then the only thing you can do is pick the absolute worst case estimate and then double it
Comprehensive-Pea812@reddit
yeah they tend to do that. and if only they understand the level of confidence of an estimate changes over time. in the beginning accuracy should be very inaccurate and as project goes estimates will evolve.
tjsr@reddit
It depends on your definition of estimate. If it's just estimating story points, and the approximate size it's likely to be compared to other similar cards estimated in the same way, then sure, it gets you in the ballpark - it's an estimate after all.
But I suspect more likely what's happening here is this is another dysfunctional organisation who equates story points to time or similar, and wants things committed to (and hence it's not an 'estimate').
TheOnceAndFutureDoug@reddit
I usually ask for a ballpark with "I'm not holding you to this, I just want to get a rough idea if the lift is worth it or if we even have time to consider it."
If the from-the-ass guess sounds like a reasonable amount of effort we flag it for someone to do a real estimate. Which we use for the actual scheduling of the work.
If your manager is taking your random guess as gospel you need to sandbag. The normal rule is you double estimates but in that situation you double the double, if not more.
qweick@reddit
Have you done it before? Then I'd expect it should be possible to come up with a ballpark estimate (a range)of some assumptions and needed clarifications to move forward.
If it's not possible (which is totally valid), then that's how it is and you need to outline steps needed to gather the knowledge to make an estimate.
Try asking yourself probing questions with an increasing # of hours. Can it be done below 10 hours? 100 hours? 500 hours? 1,000 hours? 10,000 hours? Engineers are surprisingly good at answering gut/intuition driven questions. Maybe you say okay it's between 500 and 1000 hours based on current knowledge. Then try to outline what knowledge is missing (like requirements) and estimate effort needed to acquire that knowledge (usually 10-20 % of the ballpark)
And get a raise as now you're solving high level problems.
Downtown-Ad-9905@reddit
start looking for a new job
SellGameRent@reddit
I'm really good at giving estimates before looking at requirements.
It'll take me about 5 years
PM_40@reddit
Explain to the manager like they are in high school why you cannot provide estimates.
BothWaysItGoes@reddit
It’s the norm to ask for estimates, it’s not the norm to be dissatisfied with rough estimates. It’s
itijara@reddit
Is it the norm? At some places, yah. Is it good or make sense? No. Most of that work is your manager's job, so they are basically having you do their work.
This sort of stuff is why I left my last job. Every time I asked for more information, I got a "just give your best guess" and when I did, I was told it was too much. If I capitulated and reduced my estimates, I got chewed out when things went over. It was a lose-lose situation.
shifty_lifty_doodah@reddit
I like to give ranges in this case. I make a little table and list out different things and a range of how long they might take. I purposely don’t make it beautiful or polished and include unknown buckets so it’s clear we don’t know for sure. I advertise upfront that these are rough estimates.
If you don’t know requirements, then it’s pointless
sbox_86@reddit
I'm commonly asked to do a Rough Order of Magnitude (ROM) estimate. Takes no more than an hour. I don't talk to anyone. With minimal information on the ask, I apply some very liberal values for how long everything will take, then apply an uncertainty multiplier (1.2 is pretty good) to the whole thing. The estimate is worth what my manager paid for it (not much!) but they're aware of that; the point is for planning purposes to understand capacity and cost vs the value of the ask.
On the flip side, if you're actually being asked to come up with hard estimates that will be held against you, that's pretty dysfunctional. You either need to manage up a little and coach the manager on how estimating works in our profession, or you need to find a less dysfunctional shop.
metaconcept@reddit
Pad the estimates based on uncertainty.
I know exactly what's required and all pitfalls have already been anticipated: 1x
I know what's required but can't predict all problems: 2x.
I have an idea of what's required but I don't know how to implement it: 4x.
I have no idea what to do yet: 8x.
So if you have no idea and it looks like a week of work, your estimate is 8 weeks.
No-Economics-8239@reddit
Vague requirements get vague estimates. Certainty isn't a popular situation in this industry. And estimates without having all the information you think you need is... fairly common? Part of the issue is that an estimate is just a guess. How much information do you need to make a guess?
Communication, as usual, is your friend. You can, for instance, usually start a more productive conversation by including your confidence level along with your guess. If you're really doing an estimate, you will include a range. Traditionally, the more you increase your range, the more you can increase your confidence level.
The secondary issue is a disagreement about how much information you need to gather before you provide your guess. If they want a completely wild off the cuff guess, they likely don't want you to spend a week collecting requirements first. So you can possibly cut off such disagreements by getting on the same page about what they are really asking for and what they expect to be able to do with it.
Unfortunately, it is not impossible to have a manager who wants to be able to plan out months' worth of work and commit to deadlines with your wild ass guesses. Your job should then be to try and manage expectations. Just explain the facts as you see them.
There is no need to proselytize or catastrophize. They are unlikely to want to know your feelings. What they want are solutions to their problem. Finding out what their problem is can be to your benefit if you want to be in a position to really help them.
compubomb@reddit
This is like demanding someone give you an estimate prior to know what / how your going to build a facility. You have to invest time and money just on the plan to figure out the real cost.
LuckyWriter1292@reddit
I would say "until I can confirm all requirements, I cannot give you an accurate timeframe. I'm working on a,b,c,d,e,f,g-z, we have already prioritised and promised other people in the business that these (x) will be delivered by y.
Do you want me to still make the current tasks a priority or do we need to communicate slippage and I will work on this new task."
If everything is a priority then nothing is and if things keep chopping and changing then nothing gets finished.
I quit a job because a non-technical manager was setting unrealistic time frames without any input from the devs - if you feel like you aren't being heard then it's time to look for a new job.
jdlyga@reddit
This is a rookie mistake for a software engineering organization. It’s typical for people that don’t really understand software development. It’s a mix of waterfall style upfront planning with hard dates for every phase of development, and just starting work and figuring it out. You can’t have your cake and eat it too. Hard dates and details plans need detailed analysis. Unless you fudge it by giving estimates 3x as long as you expect, this is a very clear recipe for disaster.
jdlyga@reddit
That’s managers using waterfall processes with agile methodology. They want to have their cake and eat it too. You either need to give very rough 3x estimates, or be given enough time to analyze requirements.
One-Vast-5227@reddit
10million person days
bulbishNYC@reddit
Hold on, requirements do not come from engineers, you should be given requirements. My managers keep asking me for estimates too. I usually say: estimate will be provided when finalized requirements are received from Product. I know they never will be, and this seems to buy me some time.
In general managers have a system to their madness. Today is beginning of Q3 and I dare to suspect the big boss is asking - what are we delivering in Q3? Now they are scrambling to put together slides in a rush, and you will be expected to estimate a each project from a ppt slide. One thing that helps me is I know quarterly planning is coming, and start harassing Product for upcoming projects and requirement workshops a month ahead of it.
GrapefruitMammoth626@reddit
Estimating is painful. So much is unknown until you actually try going down a solution path. It’s true that with more experience you can get a better intuition based off that past experience. But just trying to do some theoretical research ahead of time, just feels like too many unknowns. Sometimes someone higher up does the estimate and you’re forced to work under that, only to discover it was unrealistic and you look bad. It can be messy.
ListenLady58@reddit
Yep typical stupid manager who has no business being in engineering at all.
rayfrankenstein@reddit
Generally the worst of the worst pull this crap.
My advise is to sandbag the living hell out of it, resist any and all attempts for them to increase scope, ditch agile/scrum, and generally treat “estimates without exploration” as management breaking their half of a social contract and consider yourself free to do the same.
GrizzRich@reddit
Your ability to estimate the work effort required to complete a task depends on the complexity of the work they've asked for, the degree to which you know the systems involved, and your own experience.
As an example, if you were to ask me how long it's going to take to do X small thing to system A that I'm accountable for, I'll probably be able to give you an estimate that'll be reasonably accurate. However, if you were to ask me to design a next generation order management system, it'll take me a few weeks before I can produce an estimate that I'm even half-way confident in.
Asking for specific dates is, IMO, useless. Dates are downstream of resourcing. I would also probably be reluctant to provide the design that early unless it is a straightforward ask.
So depending on the specific context, asking for estimates could be reasonable. The other artefacts they've asked for seem less reasonable to me.
morbidmerve@reddit
Not the norm but very common no theless. You can not work like this tho. If you are not being paid higher than the ceiling, then this is way too much responsibility. Estimating this stuff at face value is CTO level work.
theeburneruc@reddit (OP)
That is enlightening, and so it may be the case that I am being taken advantage of quite often this way.... considering I am one of the more junior devs on the team, what responsibility does a dev have in helping to provide any of this information? I would be solely responsible for creating the build guide for this, which would be implemented in prod based on my research and determinations, so perhaps that is why I am also expected to provide all this estimate information? The change is not big, it is essentially upgrading an existing middleware, so perhaps that is why a CTO/PM is not involved?
morbidmerve@reddit
Yes compare the impact of the task and its worth to whatever is required of you. But generally speaking i tell my guys: “if you can not speak to someone directly to get information or make a decision, then the organizational structure will prevent you from building the right solution”. This is mainly because most tech debt or shit legacy code is a direct reflection of shitty administrative decisions.
If the task is not intense, then take the risk and make the estimates, but demand that someone with experience review the work if at all possible.
morbidmerve@reddit
Source: i am a CTO
JWolf1672@reddit
For myself it's not uncommon to be asked to give a swag/t-shirt size for an epic before we do a break down of the work and requirements to get a better overall understanding and estimate.
luckyincode@reddit
I got the last two DevOps tickets and they were empty. It’s my second DevOps ticket at a huge company. It’s a joke.