I did that and gave it to him. The next day he called me into his office and told me that he and the customer had already agreed a delivery date and that I had to edit the plan so that it would be delivered on that date. That date was two months earlier than my estimate, 20% less elapsed time.

I tried to argue that we didn't have the necessary resources (software developers, hardware development, circuit board design and manufacturing, prototyping, etc.) to do it any faster but he insisted. So in the absence of any way to cut the time in a way that really made sense I just cut about 20% off each of the items on critical path of the Gantt chart and gave it back to him.

He seemed happy then but he was much less happy when we delivered on time and under budget according to my original estimate.

I don't "effectively suck", I disagree with them on the timing. I'll explain my reasoning, and if they cannot accept that, then it's out of my hands; they have chosen to cut corners.

I know this is somewhat naive; not everyone is in a position where they can pick and choose what companies they wish to work at. But still, such a company would be a terrible company to work at.

When an engineer says they need 4 weeks instead of 2 it's my responsibility as a manager to get into the details, not as a way to micro-manage but to help my team be more confident about the 4 weeks timelines. Often times the engineers have a "gut" feeling but aren't sure about "why" so I push them to spell out that "why".

To answer your question; "b" is just about the worst possible option. It not only makes you look bad but also the whole team will get labelled; remember that your boss also has someone to answer to and it'll make them also look bad. Never keep your boss/manager in the dark. Push back with data and educate them as to why it takes 4 weeks instead of 2.

As a senior developer, I don't like this sentence. If you want an estimate on a certain job, you ask your team. If you want to know what can be done in a fixed time-frame, you ask your team.

I don't take "imposed" timelines well. In such scenario's, I make it very clear who is at fault when deadlines are not met (hint: it's not me or my fellow developers). When you push back on this, I will ask who made this unrealistic estimate. Ah? You mean the people who know the least of the work made the estimate? Well, then it's normal the deadline was shit, no? Maybe next time, ask the developers, they probably are the best at making estimates of their work.

When you say "gut" feeling of developers, you probably mean the instant reaction they give when you tell them the timeline. Well, it can't be "informed" because you didn't ask them to make an estimate did you? Developers need time making an estimate. "Gut" feeling is probably your developers thinking "WTF?!?!?!?".

I always educate my managers on who makes the estimates, how much time it takes to make the estimate, and how estimates and deadlines are not the same. I hope you also have a senior developer under you who can educate you on this topic ;).

The biggest problem I run into is people not being clear (or not knowing themselves) whether they are asking for an estimation or a commitment. "How long do you think X will take?" sure sounds like a request for an estimation, but if they follow it up with "Great, I'll tell the customer it will be done by then.", they clearly were looking for a commitment instead.

Many people will feel resentment over what is essentially continuous doubt and having to spend time to push back that could be spent thinking about the problem, diving in and making a better idea later. Additionally, your way of presenting the argument seems harmless and emotionless, yet reality is often far away from this. A slew of social dynamics take place which make developers say things to get managers out of their hair more than truly having a discussion on how long it takes.

The far majority of managers also impose these deadlines without clear rime or reason ("because the customer wants it"/"because sales said so", at best). What's really going to happen if we estimate higher and end up overdelivering at the end? Are you truly going to lose customers, or are you just trying to pressure people in "being accurate", which often devolves more into having one's subordinates take the blame and the fall for underdelivering?

With all due respect, it feels like we are normalizing things for the sake of manager's security without much reciprocation (only make-believe that it is being reciprocated).

You seem to dismiss entirely that doing a proper task breakdown is a way to think about the problem, revealing unknowns, clarifying requirements and making sure as many steps along the way as possible are clear and actionable.

In an ASIC project, if you miss your tape-out deadline, your time to market will be delayed by several months until the fab can find a new slot to fit you in. This can cost many millions of dollars. Accurate development estimates are important.

A proper work breakdown may cost a lot more than 30 minutes. In any ticketing system, this can be inserted as subtasks which immediately grants an, admittedly superficial, level of transparency into how far the entire thing is done. If you truly want thinking to be done, surely you would agree talking it over for 30 minutes doesn't imply a whole lot of thinking, as much as it implies a whole lot of talking. At that point, just take a step back, chill, tell the developer they need a strong defense and teach them to provide that defense in whatever way suits them best that still makes the point come across.

Software development as a field has made such a knee-jerk reaction against failed projects, it now overemphasizes "security" and "correctness", and tons of red tape, on top of methodologies which inherently should already fix most of the problem. Aren't we supposed to work iteratively so managers can make a proper forecast? Let the actual data speak for itself and don't bind too strongly to the words of the individual. The far majority of people do not work on projects that truly require tight deadlines, yet almost every software company out there is trying to emulate this high-pressure environment without clear insight as to why people join a low-pressure environment to begin with.

That's before going into the long-lasting effects of such a dynamic, and potential escalations. The most obvious one: dragging in part of, if not the entire team, for every little thing.

Also, none of this happens on the spot; as in "tell me right know why it takes 4 weeks, let's do a 30 mins white board session". Having been an engineer I totally understand interruptions and, as a manager, interrupting my team is like shooting myself in the foot. When I say "conversation" it happens asynchronously over several days. I encourage them to spend a day or half a day to work out task break downs and dependencies because it takes a different frame of mind to "plan" a task as opposed to "working" on them.

> Are you truly going to lose customers, or are you just trying to pressure people in "being accurate",

It's a combination of both though I wouldn't phrase the latter as "pressure" or "being accurate". It's a way to discover information that will increase my team's confidence in delivering the project. As we all know most of the project failures are not because people slack but because they uncover a dependency too late down the line or they don't validate an assumption or a new constraint is discovered. Most of which could be accounted for with a simple planning process.

I do recognise though that most engineers don't like planning or task breakdown and so I spend quite a bit of time to take much of the heavy lifting so that they don't spend more than 10% of their time on it. As a manager I am held accountable for my team's delivery and I absolutely want engineers to be spending most of their time on writing/delivering software. One example is I don't ask for plans/task-breakdowns for anything less than a week. In fact there's not even a debate; on the contrary if an engineer says 3 days I ask them to round it up to 5 days (a week). Only for tasks that are longer than a week I may get into the details and for more than 2 weeks it's almost mandatory.

> developers say things to get managers out of their hair

This seems like a well and truly dysfunctional team. Engineers and managers are partners and only when they work together can they deliver something meaningful. I would address this mis-trust or friction first because if there's no transparency within a team then all bets are off. We'll end up with a series of failed projects, burnt out engineers, operational nightmare and what not. What I've noticed is these social frictions end up manifesting as "estimation problems" and people try to address the symptom by trying out different project management processes each of which fail spectacularly.

>I do recognise though that most engineers don't like planning or task breakdown

I don't think planning or task breakdown themselves are the issue. Rather, it is a strong binding towards what is estimated when in the back of the head, there is always the looming threat of a missed dependency in a piece of legacy code one forgot about. Individuals can capitalize on missing ETAs by bundling them and still serving a track record which is largely coherent with the total estimate. They lose that power once a second or third party shifts the weighting and places a disproportionately high focus on missed deadlines over overall productivity and crucial deadlines being hit. That's when people start inflating estimates to give themselves security. Which shows up in the statistics as "perfect estimation", as unlike an underestimation, an overestimation can masquerade as a perfect estimation as long as someone doesn't investigate deeply (which itself is costly).

>This seems like a well and truly dysfunctional team. Engineers and managers are partners and only when they work together can they deliver something meaningful

Disclaimer: I'm moving the goalpost of the discussion here. I agree with the idea that managers and developers should work together, not against one another.

Unfortunately, this is the part where idealism and reality clash often. I question whether the majority of places execute this way, even if they claim to value the same idea. Given the inherent power imbalance between management and developers, it is just too easy for management to force its point of view and normalize away any dysfunctionality. Most developers won't quit on the spot: they still need to eat, don't perceive an abundance of jobs, etc.. The entire thing sets itself up for a frog in boiling pot situation, where as long as the management layers don't massively mess up, developers will continue normalizing away more dysfunctionalities.

I've seen this happen both with technical managers who no longer have to work with the tech themselves, and non-tech managers who have zero understanding of the entire thing. Power is intoxicating. The required empathy to deal with these gaps in perspective is a trait the far majority of people don't possess. The aforementioned power imbalance and other traits (maybe not in Silicon Valley, but here, management is both more prestigious and pays better) causes people without that trait to pour in, often selected by people who were lacking that trait to begin with. We get massive amounts of practices with zero support, because that same gut instinct that developers get berated for, many managers will often use to claim their way is better, disregarding any counterargument to their own whimsical feelings. If not gut instinct, it's some snake oil salesman selling a practice which, again, has zero support.

As a manager, isn’t your job to understand the well-documented problems with direct time estimates of knowledge work even when the work is being estimated by subject-matter experts who regularly perform the type of work being estimated, and understand and coach your team on use of the known techniques with that mitigate that somewhat (among which “managers getting down in the weeds to ‘provide confidence’ is not particularly prominent), so that you develop as-decent-as-practical estimates with, over time, enmpirical error bars without unproductively wasting everyone’s time and morale in exercises that can be assured to, in general, fail to.refine them meaningfully, rather than engaging in self-deluded pop-management-culture self-ego-stroking approaches that let you feel useful, even though they are known to make estimates worse.

Programming is a million details codified, each code-line/detail is easy but the whole is complex.

If you really want to know become a team lead instead of a team manager and just code alongside them (and preferably take the easy parts to give the glory to those under you). I’ve tried it and the colleagues where over the moon.

At my previous client, I had a "IT supplier team lead" that kept promising stuff delivered in x days even tho that x months later, the stuff wasn't working. He was seen as a god. Nobody called on his bullshit but me, later on, management was telling me that I wasn't a team player, good stuff.

No, I tell my boss that he sucks and it will take me 4 weeks instead of 2.

A+C is probably the most common where I'm at (enterprise SaaS), though its usually with management's knowledge/understanding. We wind up rushing something out to meet the client's direct need to hit their deadline, then figure out generalisation afterwards (which admittedly does drag out and has its own issues).

As a genuine question, is this approach abnormal or bad?

I'm on the technical management side of the whole thing - am I screwing my staff by encouraging this?

We want to shorten that generalisation process but that (internal) pressure to just close it out seems like the lesser of two evils when compared to the sorts of pressure that clients paying significant $$$ apply

Isn't that how it's supposed to be?

When I tell them that they were too optimistic, their usual reply is that I need to get back to them as soon as anything changes for the worse. Otherwise, truck along and do it.

If I say 'nope, 4 weeks' right off the bat, there's usually a step where they consider if it'll be worth it in that time (or possibly longer) and they tell me when to ditch it and move on, if it's really going to be that long.

And it happens sometimes, even on projects that I really wanted to do.

The opposite happens, too, though. Sometimes they think it'll take longer than I think, and I tell them in that situation, too.

Basically a) is your chance to recalibrate the expectations, and if you don't do it you'll be stuck forever meeting random deadlines (well, even if you do it you're still not out of that cycle, but at least you're setting precedents)

However i want to make a point about cutting corners - in my experience, its a jusdgement call on what's essential, and whihc corners can be cut. I've seen engineers spend loads of time on things that in the end did not matter, etc. So I would say that's an inportant conversarion to have.

Assuming the company hired me because they had a gap to fill that I fit in and also that I delivered so far in reasonable velocity: if it's really so pressing yet unpredictable to deliver, I'd take the time to analyze the task and explain the boss what parts would take how long and why. If it's a good boss, he or she will either prioritize sub-tasks or talk to the other stakeholders and change requirements, i.e. adapt requirements to reality.

If you work for a good boss/team/company, the effect afterwards will be that everybody will be more happy. Also on the long-term the project will be successful. So if making such a statement implies "you effectively suck", consider changing workplaces because this is unreasonable and even toxic. (Although even the most toxic places will give in if you have the patience and confidence to explain. If not, they'll definitely make sure to blame it on you.)

When your manager (never say "boss", because you are your own boss, they are the manager) says "2 weeks", at that point it's their responsibility. So as long as you don't say "I can do it in 2 weeks", it remains their responsibility.

So an easy way to respond is "I'll do my best", or "I'll see what I can do". In your head, you say "YOU said 2 weeks, NOT me. So if it takes longer, it's YOUR fault, not MINE". And then you work on the project like any other project. It's not about you being bad at your job, it's about the person being a bad manager. Keep the manager up to date on the progress.

Next step is to educate your manager. Don't fall in the trap of making estimates in 5 seconds on the spot. In this case, you could respond "2 weeks? I don't know, I haven't made an estimate on that." This way you indicate that YOU are the person who should do the estimate, not them. You could follow up with "Do you want me to make a detailed estimate?". If no, then indicate "ok, I'll see what I can do" as above. If yes, make a realistic deadline (NOT estimate, see below).

Bad managers come with all kinds of tricks to pressure you, like for example "The customer expects this to be ready in 2 weeks". At that point, you really need to educate them and show how reality works:

"Wow, I hope for your sake that you made a correct estimate. I didn't estimate the work, so I have no clue if this is possible. But you might be in a lot of trouble when you made the wrong call here". See what I did here? Managers try to push problems on you, don't let this happen. Always make it clear that the responsibility is always in their camp as long as you didn't make the estimate. If the 2 week deadline is not met, it's their fault of not asking you for a proper estimate in the first place, secondly for making a wrong estimate themselves, and never because you are bad at your job and should work overtime. Don't let bad management be your fault, because it isn't.

So when you can make estimates yourself, make sure you know the difference between an estimate and a deadline. Most managers think it's the same.

An estimate is "I think it takes around 4 weeks", which basically means "Best case it takes 3 (which it never will), and something might go wrong so it could be 6 weeks". A deadline always has a buffer built in. It's a worst case scenario. Your manager will ask for an "estimate", but 99% of the time it will be a deadline. So make sure your "estimate"=deadline includes a buffer of worst case scenario. If you estimate 4 weeks, they will promise it to the customer in 4 weeks. This is wrong of course, since there is no buffer. So say 6.

And this is how you keep your sanity as a developer. Educate your managers, because a lot of them are not really knowledgeable and experienced in dealing with proper software development.

It's not comfortable to do, but I will jump in and veto his commitments right there if they are clearly not attainable.

The stakeholders tend to be accepting of the fact that things are more complex to implement than just: "make the software do X", but my (technical) manager always seems a bit baffled. In the long run, I know he values this about me, but it frustrates me to no end.

So, you've never seen someone being a professional ? I've told my boss plenty of times his estimates are wrong, and that it will take longer. It's my job to know how long things take. If my boss thinks it can be done shorter, he better 1/ have the same work experience that I do and 2/ do it on his own.

Another approach which I follow nowadays is, agree but tell them that most probably I will miss the deadline.

You have two things... a request and a time frame. If they don't match? Admitting you suck isn't a realistic option. It's a lie to start with and it helps no one. Lying to your boss ("Sure, I'll get what I said would take 4 months done in two weeks") helps no one either.

Helps if you have some "street cred" to back up your claims... and you won't get that by saying "I suck" or "Sure thing boss".

We'll then have a discussion and come up with a hopefully more realistic estimate. This might include finding a different solution to the problem.

Sometimes it has to be done in two weeks, and then the issue is what we can do in two weeks. Other times it's just a bigger problem than what my boss assumed. And yet again maybe I'm overthinking things and it can actually be done in two weeks.

So d) which you miss, is about 4 months. Anything else is not professional and you cut corners. There is no such thing as 2 weeks in enterprise - hello world would take more with adequate docs, ci/cd, metrics, proj. management, optimizations, authorizations etc.

About your honest part - your boss should really have a lot better estimation of your skills (or he sucks at that too). I suppose you're preoccupied with their opinion of you rather than getting the job completed.