Hmmm it doesn’t seem unreasonable in that context? You’re really asking people to work more effectively, to accomplish the same amount of work more quickly.

It’s like asking sales people what their quota should be. They pick a number that is no-brainer hittable, because there is a lot of complexity and many unknown variables in getting deals signed, so to prevent looking bad they’ll pad their number. But their no-brainer number is below what the business needs.

So you tell them their quota is going to be a bit higher. They’ll have to stretch to hit it.

And it’s even MORE important since their comp is DIRECTLY tied to hitting that number.

And yet sales people aren’t writing article after article about how self-set quotas are sacrosanct, should only settable by sales people themselves, and how clueless management is to try to get more performance above the no-brainer target.

If you asked the sales team about a specific deal and they said "We estimate a 70% chance of closing the deal. It'll bring in about $5m in ARR."

If management responded "Could you make that 80% and $7m ARR?" I think that would be a closer analogy.

Sure it might be possible to improve the odds of closing and jack the price up at the same time - just like it might be possible to complete that feature in half the time - but somebody will have to make some major changes or concessions somewhere to make it happen.

The best case is to:

- line up the work in order of priority, taking into account prerequisites

- have sufficient stories in a ready for dev state

- during crunch time, be strategic about ticket assignment (you pay for this in the long term with a less-well-rounded team, so be careful)

- make sure to evaluate every feature to ensure that there are no "nice to haves" mixed in (when under time pressure), or move them to bottom of backlog

- selectively consider consulting with other teams, outside experts (but be sure to really time box this tightly and cut it off once work is under way)

- remove extraneous meetings & distractions; empower devs to decline meetings / block calendars

- borrow from the future by raising the bar on refactoring (ie, only when cost-benefit clearly pays for itself before deadline)

- be very careful that you don't make this approach the standard way of working

Legacy management steeped in manufacturing has entered the chat!

The truth is it really doesn’t matter how many features you deliver, or how many cars you produce.

The real impact is from managerial decisions on customers and products. A car company that does not produce as fast as it could, but produces high-quality, is still going to sell everything that they can make. Same in software. I would argue this is Microsoft and Apple’s model.

If people want it, they can even raise the prices and it won’t make any difference if they make more of them. The same truth exists in software, but everyone wants to talk about productivity because management wants to feel like they’re getting a good deal for the money.

But they’re focused on the wrong aspect of their business. It’s the same as the car business. In software, we say that sometimes you have to slow down to go faster. That’s kind of what Toyota did. Focused on quality, and now they’re making more money than anyone else.

A better comparison to software I think would be construction of a novel building. Try constructing a geodesic dome house with no experience, and little knowledge of the issues you might run into, but then you’re asked for accurate estimates and then pressured to shorten them.

I need to write 10 more lines, code for 10 for minutes, etc.

Or my personal favorite, bugs fixed!

https://devhumor.com/media/dilbert-s-team-writes-a-minivan

A program is not just a program. A bug fix is not just a bug fix. They are not fungible, while sales, definitionally due to the exchange of money, are fungible.

I'd claim that businesses are biased toward chasing a highly fungible sales model, to the point of eliminating the need for a salesperson altogether, and so naturally sales tends to the right.

Whereas with code, deleting code and writing less code is very much preferred because each line of code written increases the complexity and risk in the system.

This is why business teams who are shirking discovery and instead focusing on the anti-pattern of trying to increase engineering productivity is such a massive mistake. Not only is the team pooping out code that doesn't fill a need (and hence won't be monetized), but they are also rapidly increasing complexity and opening the business to future liability when the code causes customers to seek remediation.

The quarter driven nature of most companies amplifies this bad behavior. This is why we see this revolving door of executives who come in, drive some bad initiative to incompletion, declare success and move on before their chickens come home to roost.

Everyone in this thread is trying to point out to you that your assumptions about sales are the same as the LoC assumption that equivalently clueless people make about software.

And a phone call doesn't mean a sale closes.

See conversation upthread.

At some level. But numbers aren't created equal and sales reps aren't usually supposed to be calling numbers out of a telephone book. Depending on the type of sales rep, they're hopefully reaching out to people who have been qualified to some degree. The email I got from a sales rep at my own company on Friday afternoon asking for a call about my requirements? That wasn't a well-qualified lead for whatever reason. (Not their fault; I'm sure they're just working from a list.)

This isn't to argue that we should just believe developer estimates unconditionally. That's a bigger rabbit hole that I'm too tired to go down right now.

You can absolutely work to find other creative solutions to the same problems, or understand what scope is acceptable to cut to meet some goal. That's very different from "I want you to do exactly the same work but just do it faster".

There's plenty of decisions devs make that impact how quickly they deliver a solution.

What’s the incentive for a developer to inflate their estimate? The only reason I have to inflate an estimate is if I know some non-engineer boss-type is going to swoop in and try to convince me to lower it.

Deliver under estimate and get a bonus, raise, influence, or just plain old "well done"

Be lazy and only work half the time while delivering "on time".

Only work on the project half the time, spending the other half on something more worthy/interesting.

This is actually a pretty common motivation for devs who work under legacy management.

Under-promise. Over-deliver. I'm not doing software development most of the time but it absolutely works out better for everyone concerned if I get things done on or ahead of schedule without mostly having to resort to a lot of unnatural acts to do so. If there's a real need for something faster, I'll tell people I'll do my best and (usually) I can get there absent blockers from dependencies. But I try to manage things so that I can meet/beat estimates sanely. It probably helps that people think I work quickly even given some sandbagging.

Sales quota is a target, estimate is not a target.

> And yet sales people aren’t writing article after article about how self-set quotas are sacrosanct, should only settable by sales people themselves, and how clueless management is to try to get more performance above the no-brainer target.

You mean you've never came across any post where people complain about unreasonable/unrealistic sales quota?

Depending on the economic climate and the situation of the company in the marketplace this may be accurate.

If you've got good sales people that are already selling as hard as they can't you won't be able to squeeze much more out of them if the economy tanks and nobody wants your product.

I'm sure there are sales people who have quit due to "the beatings will continue until the morale improves" situations where their quotas keep going up, which cuts their bonuses, effectively acting like a salary cut, in a bad company.

https://www.justice.gov/opa/pr/wells-fargo-agrees-pay-3-bill...

This would be perfectly true if you replace it for a sales estimate, instead of quota.

The problem here is incompetent managers lying to inexperienced developers to get them into an expensive contractual obligation. It's borderline fraud, and yes, that means working with that manager is something to be avoided.

But going to a developer and plainly demanding him to finish the work on some time can be as perfectly fine as doing the same with sales people.

https://devhumor.com/media/dilbert-s-team-writes-a-minivan

The problem is that sales can be objectively measured by management. In units.

How does management measure development output?

It can be done, but it take an experienced eng leader to do it.

Asking meteorologists for sunshine is unequivocally unreasonable, so what you are saying here, I believe, is that the analogy does not apply to sales people, and arguably not in the case of devs either - which I agree with, up to an ill-defined point where wishes lose any contact with reality in any circumstance.

Not really, because those are not estimates. Also, consequences are different. With programmers, consequence is typically very buggy and hard to maintain software.

With sales, the consequence is a lot of fraud, followed by firing of every who is not comiting fraud and then even more fraud.

P.S. Not really, you covered it nicely under fraud

It is very much unlike operating an established manufacturing facility. But, about two thirds of dev work has a lot of parallels with creating a new manufacturing facility that manufactures a new kind of thing using new materials and techniques. The primary parallel is that a new facility requires a lot of discovery. Whereas if operating an existing facility constantly required a lot of discovery that disrupted operations it is likely the business team would pivot to something more lucrative.

Sadly most developers work in companies that have a manufacturing management system, which is inappropriate for managing development work, primarily because of pressure+timeline patterns typically applied via silo on silo kingdom building.

If they are in the majority of developers being mismanaged to crank out software that nobody wants, then have them code in an open office space with bullhorn wielding circa 1890s speed bosses yelling at them to type faster. It really makes no difference as most legacy business teams shirk their responsibility to get out of the building and figure out the real needs anyway, so might as well let the devs work on their craft until a real opportunity to make a difference comes along.

I've been a developer, PO, manager, director, CTO, the whole thing. I'm still shocked by how most (not all, but most) developers are simply too disconnected from the reality that, yes, they do need to provide value, and yes, that value does have a time factor. Lucky are we as developers, that people actually ASK us how long it will take, and give us the opportunity to explain it, push back, and actually defend your estimates. The sad reality (at least from 90% of my career), is that developers are rarely able to actually engage in business-level conversations, and actually express their thoughts/ideas/concerns/proposals, in a way that it drives the conversation forward. In a way that helps PMs and managers actually see the complexities of the work, and engage in healthy cost/benefit discussions.

The simplest solution to this is to make them an actual part of your business. Do your lead devs assist business meetings ? do the dev team get the numbers, get a look at the budget, work with you on the roadmap, look at the user research and brainstorm the features with the business and UX people ?

If not, why would you expect them to understand the business ?

The other side of that dev/business separation: as you put it, that creates a holy land of software development, as everyone has their own silo while expecting other specialists to be well versed into their own problematics.

I think many businesses are working dispite extremely siloed roles for their team members, and people tend to think that's an OK way of doing things as money keeps flowing in.

It definitely needs to be a 2-way bridge, and when both sides can and do come together, great things can happen!

Nonetheless, do you believe the opposite is true? If a developer doesn't feel like they are adopting the perspective of the business, are they a disposable resource?

that’s like a sales guy closing a deal…

you did one piece of the puzzle and dealt with one type of headache

you clearly have no clue what founders actually do

Well not me if you read my comment.

Also given that you don't know me but you immediately made a personal attack based on your own misunderstanding... you kind of proved yourself wrong. That's why people don't talk to you.

Not defending the parent comment because it's way off base. But come on. You've never seen non-development stakeholders struggle to accept devs communicating uncertainty?

I put plenty of effort into trying to understand. 95% of the time there's no business reason. Most of the time someone just wants to put a number on their powerpoint for some organisational politics nonsense. Sometimes the business wants to decide whether to do thing A or thing B (in which case they have a legitimate need for a relative estimate, but not an absolute one). Occasionally there's a real deadline, in which case again they don't actually need an estimate, they need a "can we hit this date y/n" (or, more usefully, "what do we need to do to make this date").

I'm very happy to work as closely as possible with the business. The reason I'm writing software at all is usually to solve business needs, after all. But when it comes to estimation it really is a case of them being wrong and us being right. (The best businesspeople don't work in terms of estimates in the first place; I don't know if estimates used to work at some point in the past and have been cargo culted since, or what)

> why shorter is always better than longer

If shorter is always better than longer then all my estimates are now 1 day. Does that makes things better?

Nah. Internal competition is a negative for the business. Selfish individuals do it so that they can get better results for themselves. Refusing to take part is the right thing for the business.

You don’t own 100% of your time when participating in group activities.

You said "Thats how coalition-building, budgeting, and reporting works in business." In my experience that's only true in the bad kind of business where there's too much internal competition.

> You don’t own 100% of your time when participating in group activities.

You're responsible for your time. You should share it generously with people who want to put it towards something productive, but you should also push back when people want to waste it.

And yet, none of the politicians are going to toil to make the deadline work. There is no gain to be had for the actual engineers or the actual business.

How about this, tie a deadline to a well-defined bonus that only the engineers would receive and staff the project with ALL the engineers you can get. This will allow political heads to keep doing their coalition-building while engineers also receive some benefit for their toil.

If you are unwilling to share the rewards of the toil, it is no surprise that the actual people doing the toil don't care about your coalition-building nonsense that doesn't even help the business in anyway. Your coalition-building vs their own time with family/friends, not a difficult choice to make.

Happy to share in the spoils and many companies do this with stock/options of course - but don’t think for a minute you live in a walled garden. I mean, you can, but then you get zero input into things like deadlines; you’ll simply be ignored or moved out of the org.

Your comment is essentially “I want all of the responsibility and none of the accountability”

Where exactly did I say that organizations exist without administration. All I pointed out was that if the rewards are not shared with people, people will not do the work.

But since you are writing this from a org structure perspective, I can alsosay that administrative work can be done by HR. Eng management can be left to handle engineering direction and task. Specifically, the political org structure is not a necessity - it is only something that low IQ can understand. A smarter structure is technical leadership all the way up to VP + HR that manages pay and promos.

The reward is your salary/bonus/stock, and it obviously works… because work gets done and tech talent is well-remunerated for it. The technical leadership structure you seem to be recommending already exists; plenty of ELTs have or are comprised of experienced people with deep technical roots.

By that logic, responding to requests for estimates with sarcasm and cynicism also works, because work gets done and tech talent is well-remunerated for it.

No offense taken. I am in the US and worked for 2 of the FAANGs and 2 FAANG-adjacent startups. The work culture in each of these companies is so terrible that even $400k/year is not enough renumeration for that kind of pressure and political nonsense.

What I learned by working at startups after FAANG is that FAANGs are able to have such poor management practices (e.g. fiefdoms, politics, perf reviews) only because they can hide behind infinite revenue. Startups (

Except to many it is - and I’m perfectly happy arguing from the majority in this case, because the failure rate for companies that do not adopt many of the best practices you rail against is extremely high.

You also seem to be making arguments for things that already exist and are universal, like performance-based comp, etc.

This appears to be a form of projection because that is not what I was arguing for. And things that "already exist" don't always exist. They especially don't exist in the form they are in FAANGs.

In fact, in my experience, the companies that copied FAANG style are the ones that suffered more than other companies that did not adopt those practices. Having worked at pre IPO companies that succeeded and that failed, FAANG-style heavy management is the single biggest reason for company failures because every IC matters in these companies, and poor management practices affect actual product outcomes a lot more in smaller companies.

Once again, you are missing the point of the last post which makes me suspect you are exactly the mediocre manager who gets complained about a lot. Let me guess, you hold weird ideas such as "If they don't do XX, YY, I will fire them" - never once blaming yourself for hiring them in the first place.

No amount of effort on either your or my part is going to make the baby appear faster.

> Do you need to grow your own, or could you adopt?

> Is it about birth itself? Does it have to be a human baby?

> Does the baby need to be related to you?

> What if we hire a baby actor?

…

The managers who complain about their devs not thinking at the business level are usually the ones shooting them down when they do. Why are the coders questioning why we need the baby?

From my personal experience, people are often positively delighted when you make an effort to try to understand them and their needs.

Not shooting down your experience, but from my perspective it could be seen as a straw man argument in favour of never trying in the first place.

My observation is that it is ultimately organizational culture that frames the way people communicate and how they understand each other. Individuals can move the needle a bit depending on the size of the company and their position in it. But largely they are powerless against the prevailing culture.

In a healthy organization, your efforts to understand the rest of the business and its needs will be accepted as you intend and will benefit yourself, your team and the business. In the average toxic organization, your good intentions won't matter and your questions won't be received the way you intend. Staying upbeat and helpful in these environments might even result in you being punished.

They want to give you a vaguely defined blob of half finished specifications, and expect a perfectly accurate assessment of the time it will take, and also to be able to change the vaguely defined blob as they go along without effect on the given estimate.

To know how long something will take it is necessary to list all the steps taken to do the thing. That just isn't possible in software development. Developers can come up with a lower bound for a given set of requirements. And I think everyone agrees that they could do an accurate estimate assuming nothing unexpected happens. Then, in 95-98% of projects, the estimate turns out to be under-calling how long a project will take. The "developer estimates" becomes a measure of how much fat the developer feels like putting in the system this project.

Asking for estimates completely misframes the conversation. The question is what problems does the business have now, what problems are likely to develop in 6 months, and some input from the developer on the cost-benefit of trying to solve those problems. Then people make some qualitative decisions with an eye on minimising risk. The best outcome after giving software estimates is that everyone ignores and forgets them - anything else destroys business value.

That's awesome. In my feistier days I would have used that at work!

If devs do not know the customers/users nor interact with them then they can't really argue about the proposal's assumptions, it defacto becomes a demand.

With experience devs see such proposals with skepticism. A significant amount of our output ends up being useless, no matter how fast or well it was built.

If you want devs to focus on value creation you have to make it their job, they have to take ownership of the whole thing. When a dev can help a user or a customer they tend to feel fantastic about it.

But truth is business people think devs are inept at doing that so most companies are structured in a way where the only agency devs have is how much time they have to do something.

Devs always lean more cynical than the rest of the org, but the "prima donna devs refusing to acknowledge the need to deliver" schema only emerges in poorly managed organizations and teams. There is always some push and pull, but usually it's within a healthy balance.

I've always hated this sort of talk. The myth that some people are inherently creative, or inherently logic brained, or inherently buisness brained, or whatever, and never the twain shall meet.

I've seen a spectrum in most dev teams I've worked in. Those with good communication, those without. However, I've also spoken to sales, HR, etc people who paint the whole team with one brush and are afraid to come and speak to the scary code people. This, I'm afraid to say, is often because those people were also bad communicators.

I agree there needs to be more awareness of the buisness realities among developers (personally I think it leads to more fulfilled and happy developers, among other things), but I think that can't be placed entirely on developer's heads. They can't know how the sales team's meeting in morocco next week's call might affect things if they have no idea that the meeting is happening, who the client is, what that client means in terms of the industry, the likely things that client might value. They are adults. A couple of onboarding meetings, occasional cross-training does wonders.

And if they did know that? They might be able to quickly throw something together that has a good chance of really impressing that client. Or provide certain insight into what the company's solution actually does for the client.

And you'll be happy to know that these days I suss out the estimate the business team wants and give that estimate. Then carve out more time via scope exceptions. Then, because I can't carve out enough time to actually finish, deliver a release that looks finished to a QA team, but is actually riddled with customer operation interrupting performance problems, intermittent crashes, memory leaks and bugs.

Here is the very best part, the business team blames QA for not finding the problems.

It is a rare person indeed that can do software development and think (and talk) in business terms. As a dev, being able to talk in business terms about the problems you face in creating software is really, really handy.

But I can count on one hand the number of POs, directors, managers that want to engage in that conversation with developers. Most of the time a solution is thrown over the wall and developers are told to build a thing.

An actual conversation about a business problem between the people that actually have the problem and the people that will build the software that (hopefully) solves it happens way, way less often than it should.

Sure, if you’re a contract dev shop who is marking up hours, then longer is better.

That tech debt from 40 years ago was usually perfectly adequate back then. It's only tech debt now because it's become unmanageable due to changing environments, programming languages, APIs, security concerns etc.

I've never seen a set of business people in a software company that cares about any of these things.

Some PMs will say they care about tech debt which excites me but of course in 6 months you'll see they actually cannot give a shit but just use it as a tool to lower the estimates. If X takes 5 days but they want 3 they'll tell you "let's just add some tech debt" to convince you to promise 3, but they don't actually ever intend to work on that tech debt.

When it comes to burnout, I've literally never seen any person who doesn't consider this the fault of the employee.

I've seen VP level people who did things that are so absolutely insane that it resulted the project to be late with 100% probably from 6 months before, then when the day of launch comes it is indeed late, fire alarms are pulled, tons of people give on-call attention to our project, we hack something. Then VP says "whoopies sorry about the fire alarm, will never happen again". Lmao next thing that happens is that this person is promoted to SVP and does it again and again. "Rushing" is a good thing, if anything. Business is all about creating an artificial sense of urgency that could be trivially averted, but it was chosen not to.

People not doing right trade offs. Well again, it's on you if you do the wrong trade off. People will point at you and say this decision was wrong. That I had so little information and time to make that decision is very brought up.

That's why it's called tech debt, it accrues interest.

This is the problem with these kind of discussions. You cannot ignore everything else because everything else depends on 2 versus 4 days as well. Something that's done in 2 days can be exponentially worse than something done in 4 days such that in 6 months you can look back and rationally determine it was better to do it in 4 days.

A big issue is that "business side", including UX, mostly have zero scrutiny of what they spent their time on or when important work will be completed. Whereas engineers get scrutinized about tasks by non-engineers who can't and won't understand.

And frankly, many times this hand-wringing about estimates is because product and UX took way too long to "plan" the work to begin with. So there's some natural resentment from engineers about this.

However the analogy of a meteorologist seems poor as that job is focused on predicting the weather - the typical dev is focused on operating in that weather and comparatively inexperienced in predicting with great accuracy.

What's frustrating as a stakeholder is ludicrous estimates, which don't even start with the work time, let alone end up with a realistic duration. This is particularly true (and frustrating) at the micro task level, an area I'm often requiring items that take at most 30 minute to complete and are usually things I could do in less time if only I had access... You get a weeks long estimate back, even when it's incurring a serious cost in production and falls in the drop everything category (which obviously one wants to avoid but does come up). I get that none of those 30 minute tasks will take 30 minute alone as there's testing and documentation to add but the more bs level the estimate, the more it damages the trust relationship.

You can have agile flexibility or you can have lists of tasks that you have attempted to minmax that people are tracked to finish. Not both. Flexibility costs significant down time, if you're not being given it then you're not being allowed to be flexible.

What do you mean by "unintuitive ways of working"?

This idea gets a lot of pushback because we have it ingrained (not unfairly, either) that context switches are expensive for the reviewer. But the safe assumption is that they're less expensive than delaying another piece of work that's already got a lot of embodied but unrealised value.

The intuitive assumption is that person waiting on the code review can pick up another piece of work and make a start on it so they're kept busy, but that falls into the trap of having too much work in progress. The result is then (usually) that the returned code review is now waiting for whatever they picked up. This is one reason why the intuitive way of working tends to having throughput that's barely ok, and latency that borders on ridiculous.

The problem is unless you have fully-automated continuous deployment, 30 minutes is not 30 minutes. That 30 minute task needs to be vetted to ensure it doesn’t affect other departments, then it needs to be scheduled, announced, and deployed, which may involve 2 to 3 other people. As a scheduled task it’s closer to 2 hours across multiple people. As a hotfix or support ticket, it which becomes 4~6 hours of lost productivity for a hotfix if there is any kind of QA process beyond automated tests.

Add in six other people asking for “30 minute tasks” that have unknown impact on other people in the company and nothing will ever get done.

My team has workflows for hotfix changes, but it truly needs to be a drop-everything emergency that stops the company from operating. For all but the blindingly obvious, a department, head or higher, must make the request.

Not being able to turn around every urgent ticket is far less damaging than having a fix for one person cause problems for several other people or not delivering on large strategically-critical projects.

Even things that don’t blow up on those have so many hidden costs people don’t think about.

Why don't you? Surely there are ways of granting the required access in your organization?

If the answer is something akin to "not my job", then you have an organization that values intercommunicating pieces each with strict responsibilities. It should be expected that communication completely dominates output performance.

If properly tuned, such organizations can achieve good quality, and if the duties are well specified, also great throughput. But they will never have low latency, as turnaround time is sacrificed for other tings.

The example of a week long estimation for a trivial task is pretty much expected then. In a fully booked schedule, any new task is not likely to be scheduled for weeks. If that task then requires the attention of more than one person, because of the above fine grained responsibilities, those turnaround times really start to add up.

If that's not a good fit for the job at hand, the organization is just not suited for the task.

Some tasks take me 10 minutes but it takes me half a day to jump through all the hoops that our colleagues have thrown up. Excel approval sheets, annoying proxies with SSL inspection (try configuring all that in multiple docker containers), having no access to actually configure what I need to do so I constantly have to put in tickets to other teams..

The worst thing is when they then outsource the work and ask us why they can do it so much faster.... :X

The real problem is that nobody ever steps back and asks: are all these rules actually helping to improve quality of the software. Is the cost of the reduced velocity and overhead actually worth it in the end.

Then, the org does layoffs and all that policy is still in place without the necessary people to supported the bloated workflow.

If your two man organization if one person steals the source code or slips in some back door into the code, it should be somewhat obvious who did it.

On the other hand in that large enterprise someone doing the same could lead to an international incident. And with that many people you are going to have nefarious actors at some point and you need to think about how to minimize their damage.

It's likely you're falling into the same trap of understanding why Chestertons fence was put up in the first place.

Whatever 'deal with the devil' that existed when the fence was erected may no longer be relevant or worth the overhead, but the policies live on. There may even now be individuals who's jobs are now directly related to enforcing/implementing the policy, and they have an interest in perpetuating it at any cost.

While I agree with your sentiment, high quality software (and: what is high quality, anyway?) is not necessary the goal of an enterprise.

I'd compare it to the military's $435 hammer [0], from the outside you'd think it makes no sense, but that's the logical end of a series of processes that all somehwat made sense on their own.

A common issue I've seen is devs having to put their head on the chopping block when making estimates. After the second or third time they get seriously punished for blowing pat deadlines, they'll happily go with around 10 times their own estimate. But there's so many other incentives where going with a "done in 2h" estimate is just a bad decision.

[0] https://www.washingtonpost.com/blogs/wonkblog/post/the-penta...

The stories are real; they're not all "accounting misunderstandings" or what have you.

[1] https://www.airforcetimes.com/news/your-air-force/2018/10/23...

This works because almost never is the true scope of the work known when the ask is made, so it is usually pretty easy to say later "hey, blah blah blah wasn't taken into account for the estimate." Having a good relationship from step one makes it pretty easy to carve out the extra time.

There are some more lizard brained people who play hardball, but as long as I was nice in step 1, my VP handles them. Not sure what I would do if I didn't have a decent VP!

Learn how to actually do your job?

It’s always interesting to see toxic positivity painted in such a favorable light. Very glad I don’t work with you.

I'm in a team with a lot of leeway. No one is counting my hours, no one external look at our productivity, but when we're needed, we don't have time to polish our code. When i have a '30 minute' task identified, I put it in our morning review, and ask if something adjacent should be done while I'm on the subject. If there is nothing, I'll still take the full day (except if it's a project I know really well, in that case I take half), and take half a day to skim the code, and another half to update it (small comment, version upgrade, code improvement, renaming variables).

Push your IC to do the same. Imo it's more time efficient, the new-ish IC use that time to learn the older code, and in the end you will have less legacy issues (unless you make a big change).

Regular approaches, avoiding firefighting are essential to steady, stable states.

Then if I still have time I do reviews, administrative work and probably end the day there. The nature of our team make that time management suitable.

The real genius is to propose a simplified solution, by discarding some assumptions. This is the best and only way to shrink the schedule

I think it's less simplification and more precision and completeness. Obviously if you have simpler requirements they more complete and precise, but the requirement might not actually be simplifiable. In which case what you want is better specification.

"They write the right stuff" about the shuttle software group is basically a story about doing that: https://www.fastcompany.com/28121/they-write-right-stuff

In fact, what you are doing is tying the developer's hands and making it less possible for them to nimbly work around unforeseen obstacles or repurpose existing solutions without raising a "process exception" to reopen the spec or sizing of a work item.

Be clear about the goals but let the developer(s) who have their hands in the code make the decisions about how to implement it. That means you can't really roadmap a big project down to the minute, but those roadmaps were always lies so there is literally nothing lost except for some fantasy Gantt charts.

The problems with precise specs is that they miss all the dozens of edge cases and gotchas that don't crop up until you actually try to code them. Then you need smart, imaginative devs to ignore the specs and write something that people can actually use.

I've worked with devs who write _only_ to the spec and never diverge at all, regardless of outcome, in order to check off boxes and make their managers happy. Their work sucks.

(this might not apply if you are writing code for moonships)

If the requirements were actually precise and concrete, you could commit them to git and that would be the end of it.

The fact that they aren't is a sign of information deficit and this must be understood by all parties if we should have any chance of a productive outcome.

Requirements and roadmaps are very different in my opinion. Requirements say what the product needs to do, scaling and/or response time targets, systems or needs to integrate with, etc. Roadmaps are either a high level plan for where the project goes in the future or a list of seemingly arbitrary deadlines.

Both have their place, but in my experience the right balance has been precise and complete specs with a high level, flexible roadmap.

I've seen a project go from an empty repo to production in two months with a set of requirements that were completely unambiguous and rock solid. I've also seen ambiguous and vacillating requirements drag out the implementation a ~30 LOC feature for months.

I’ve also been a manager at 3 different companies, one of them my own, and my philosophy has not been to push deadlines or work, but to spend more time understanding requirements, and simply try to break down long-running projects into small pieces that can be estimated more accurately. One of the biggest problems I’ve witnessed in software is that estimates in units of years are always very wrong, while estimates in units of days or weeks are pretty good.

I have to agree with the parent; you’re making incorrect assumptions and maybe projecting your own bad experience, and ending up accidentally saying something that isn’t true.

Good communication isn’t adversarial: by the time it becomes adversarial, you’ve already lost. It can include solid documentation, taking the time to mentor others, respectful but clear code reviews, helping others argue your case for rescoping, presenting your work at meet-ups or conferences, hallway testing a new feature, listening to teammates explain an approach…

…and yes, sometimes negotiating capacity. If that feels like an adversarial conversation, then your manager sucks, and you should find a new one.

I’d wager portraying an important work relationship as adverserial and manipulative is why people downvote you. It’s a bit of an overplayed cliché with the bad boss.

Ironically you might be downvoted because of what you’re saying being misunderstood, which I guess is to your point.

He wants to present a low number, to encourage whoever he's dealing with on his end to do what he wants, gaining the benefit from that.

So he'll use every technique under the sun to encourage devs to give him a number he likes more, while never making it look like an order or coercion (which would make it his number - spoiling the whole play).

But when it inevitably takes much longer, he can point at the numbers the devs provided and say he was just communicating what they told him, so he's not responsible.

The only language these types understand is for requests for estimates to be "reviewed" to result in them always going up, to send a message.

For many reasons:

1) Estimations should be useful so business can adapt. In reality there's no adaptation of any sort, your PM will get the stick from its own boss that stuff needs to be ready by this or that more-or-less vague deadline. Thus, what am I estimating for if you don't care about my estimation anyway?

2) There are no incentives for teams ultimately to estimate anything realistically. What do you get for being accurate? A medal? In fact, all incentives go towards inflating the amount of work through estimates.

3) Ultimately all this dancing of estimates and rituals is nothing else but stuff that management embraces to appear more effectful and impactful than it really is.

To this day I still don't know how this event came to pass.

I've been on both sides of this situation. As an engineer I'm always adamant - yep, no way this could be done any faster and please stop pressuring me to just get the number you want to hear. It'll be done when it's done, and it'll be robust and good. Now please go away and let me cook.

But when I've been the manager pushing for smaller estimates, it's been because the business realities were that delivering *something* in a given time frame is critical. And if it requires making a house of cards and cutting corners, well at least we'll have survived long enough to deal with that problem later. And when I've been in that situation I received the usual pushback from engineering - the same pushback I would give in their shoes - that this is a terrible idea, will doom us to fail in the future, and we need to put in the leg work now to avoid future pain.

I've gone back to being an engineer but that experience as a manager has helped me quite a bit when dealing with this sort of divide.

You don't say "hey, how long do you need to do X, Y, and Z? Oh, no, that's too much time, how can you shorten it?"

What's unreasonable is saying "we need X in Y weeks, and it needs to be done properly". It will take a certain amount of time to do anything properly, and that doesn't change with pressure.

As a manager when I've pushed back on estimates it was because the engineers were pushing for "done properly". Where "done properly" didn't mean more features but building a more solid foundation. And I 100% understood the desire, but at a higher level the long term cost of not having that solid foundation was worth incurring.

Requiring both "fast" and "good" is foolish.

If corners need to be cut for valid business reasons then there shouldn't be any real push back from the devs, because they have the business context laid out for them.

Every dev I've ever worked with will say "yup, I understand. I might not like it, but I understand" when given the context of pushes for quicker delivery.

But that requires understanding on both side that you are sacrificing quality to hit a date, and that has its own costs.

Mostly this all boils down to: talk to people like they are you colleagues, don't order them around, find a solution together.

It's crazy because the customer gets totally hosed by bad software implementations, and if good working software is actually important to the future of the business, a slow march towards bankruptcy happens.

As an engineer, imagine living under this constant stress, missing time with your family and friends, and for what? Just to make your own manager's incompetent estimation look good?

I'm reminded of a manager that would add features as I was finalizing a release, sometimes hours before without telling me. He would even add features to releases that already happened. In his mind, he seemed to think that he could just attach the features to a release, and bam. it's done!

I've definitely seen devs assume too much needs to be done, just like I've seen non-devs ignore key parts of the problem that push up the time. Sometimes it's trying to make a general solution when actually what's needed is someone to sit down with a spreadsheet for a day.

> There is back-and-forth as the estimates are questioned for being too high, almost never for being too low.

I'm sure people will have flashbacks when I say this so sorry to those, but this is the issue addressed with planning poker. The idea being that you all say how hard the task is, without being affected by each other, and discuss when expectations aren't aligned. Someone is probably missing something.

I might think something is simple because I've not realised a complex part of the problem, or because I can see a nicer neater solution.

As a former freelancer I am a big fan of just getting a thorough explaination of the problem, maybe with me looking over the shoulder of someone who has to solve it currently. And then I vanish in a hole for a few days and return with the design proposal I think would most elegantly, reliably etc solve the problem.

Unless we are speaking about people who have good experience with complex problems, most people are okay at describing their problems, but suck at proposing solutions (they are always modelled after the limited things they know).

> most people are okay at describing their problems, but suck at proposing solutions

Yes, it's best to focus on their problems and the consequences of proposed solutions. They shouldn't care about your caching strategy internals but they do care about whether stale info impacts their users or what scale it's reasonable to hit, or how much extra it'll cost to implement.

Absolutely this, and managers and pseudo-managers like product owners, business analysts and full-time scrum masters do too. I see a lot of weird requirements, often technical in nature, that nobody actually asked for, it was just a long string of people who just assumed. Like an infinitely scalable microservice architecture with a full SPA just to let a dozen internal users download some data as an Excel spreadsheet.

It isn't. Having a team which is both intimately familiar enough with the set of features as a whole, and understands how to use the system to get around the inevitable 'A does it in X while B does it in X*3', are both prerequisites. Suffice to say, with the amount of discussion based around Scrum being done wrong alone, neither of those are even remotely a given. This also doesn't take into account turnover and new features being able to remove a team from meeting those prerequisites at any point.

Too often it just devolves into people raising eyebrows at one another and either it becomes 'X will do it, so X's estimate becomes the value' (why even bother doing poker then) or 'take the average or minimum' which screws over anyone who estimated higher.

It identifies a lack of a shared understanding of the task. Or framed differently, it identifies when you probably all have the same expectation and you can move on.

Or we can dive into technicalities where it technically does solve the issue but does it poorly, and just happens to be better than any other system we know (also questionable).

You ask people how hard something is to do, make everyone actually answer before hearing others opinions and if people disagree you talk about it to understand why. These are all short term features.

The two things it deals with are:

* get everyone to say how big of a thing it is, find out if there's misunderstandings about what the task involves

* avoid people from being influenced by the fastest to answer person

That's it. It's a very basic communication tool.

The only reasonable response I've had is "I need 1-2 days to both push you on solidifying these requirements, and stop & audit the codebase to look for any risks before starting".

Is there anything I could be doing better here?

So you’ll have a bunch of one liner cards, but at smaller fidelity, like

- Make a bulk create API endpoint - Migrate data from old to new table

Then, if there are 5 or more cards there, make your estimate

((number_of_cards / number_of_devs) * est_business_days_per_card) + est_pto_days

It will not be accurate - but it will leave the PM and their boss feeling like the estimate was thought out and reasonable at the time, and any necessary delays will go over easier (“we estimated assuming every card was about the same number of days, but these two cards were large outliers that took longer than expected.”)

Much like the normal sprint process, but without the need to keep a track of sprint velocity beyond a gut feel.

Company Leadership asks for estimate with barely any information, I will then say that I need to learn more about the project and look into the codebase, leadership then says that they "just" need to have an estimate to approve this work and if they want to do this project at all. Around and around it goes until I give them a large estimate (which is large because of all the unknowns including the unknown scope) which is then too much and too expensive for leadership.

My peers and I, who would report directly to the CISO, loved the answer. One of the CISO's potential peers on the interview panel thought that the candidate bombed the question, because "shouldn't they just know what's needed?"

In Agile speak, that’s a 3 point spike ticket, for which the deliverable is a detailed set of requirements and deliverables with estimates with considered trade-offs. It’s a totally normal thing to do.

You can give an estimate before doing the spike, but maximally caveat it. Like “60% confidence it’ll take fewer than 3 weeks, 80% 5 weeks, 90% 6”.

I’d generally recommend refusing to give deadline estimates beyond a week or two (unless it’s absolutely necessary as it sometimes is), preferring piecemeal estimates (i.e. this project is composed of 7 deliverables each taking 1-2 days of work). Reason is that it might take 10 days of engineering work to do something, but due to shifting priorities etc., the calculus of computing a deadline is basically pointless.

If the “managers” don’t understand any of this, it’s never going to be peaceful unfortunately.

My guess is there is a happy medium between never changing and staying on the cutting edge. A place where you can ride the current of tech, FOSS, dev communities and talent pools.

If course what this looks like day to day and in pointing poker will vary. Ideally there is a seasoned architect on every team who can steer the biggest decisions away from the hazards.

I say this as the person who gets hired to fix things after they left.

    Leader: How long until you can hack the mainframe?
    Techie: The other hacker is really good; at least 2 hours.
    Leader: You have 1. Get it done!
    [commence flying around the 3d filesystem]

    [Techie thinks]: My actual estimate was 20 minutes. I can probably get it done in about 50, then I need to fly in the 3d filesystem for 10 more minutes looking busy so Leader doesn't get any big ideas.

Sometimes I see colleague developers estimate two weeks for a feature I consider one day at most, because they assume lots of extra functionality that wasn't actually asked for, or that I didn't realize would be necessary.

If you are asked to change your estimate, see it as an invitation to discuss the requirements and proposed implementation a bit more. Maybe something much simpler that brings you 90% of the way there is both possible and a acceptable. Meteorologists don't have that option.

I have clients asking 'just do the simplest thing you can do'; we present prototyped gui's then after approval fully designed guis and after that a prototype. They approve the first 2 immediately as they can't even be bothered looking at them; some, when pressed, will try the prototype and often still say 'yes great, let's go'. And then when it works and they can try it on the test server, they say 'no this is really not what we meant'. I have had this with 2 person mom and pop stores (long ago; I don't do those anymore luckily) to fortune 500 companies with the regional directors and global cto present to give their opinion. And this is frontend ... Backend, devops is another thing entirely, but there, is also a large difference between bare bones or gold plated.

I know the game by now, so these days we make a lot of money from this broken process.

It's all communication, programmers and stakeholders live in different worlds.

Feedback that you don’t agree with the estimate on the other hand, happens all the time. This is a completely different thing than a hollow request for “lower plx”.

Good stakeholders often do have a good idea of how long time things take. Maybe they worked as dev before, or with other clients. Leaving the estimation exclusively for the well oiled hero-team with perfectly calibrated velocity and ponies coming out of their retrospectives, as the article portrays it, isn’t always ideal either. Some tasks are new and unknown to them too, and honestly not all teams are that perfect. There needs to be a two-way dialogue about scope contra timing.

Of course there's blame on the engineering side of the table too. We chronically underestimate effort, not adding enough margin for unknown-unknowns. So we start working late. Sandbagging estimates. Telling the PM whatever he wants to hear just to end the meeting and get back to work.

Impossible schedules are toxic for people that care, and encourage apathy as a coping mechanism. If you put in a Herculean effort and ship on time you did what you said you were going to do, what, do you think you deserve a cookie or something? The other option is failure. Even if the PM or management isn't upset, engineers still feel the failure of not hitting a goal.

Engineers need to feel wins. Always shipping late because of impossible schedules means no project is a win, no matter how good the design is.

At a former job I found out after a couple years that impossible schedules was a business strategy by the c-level execs. It encourages engineers to work as 'efficiently' (i.e. as much) as possible. God forbid we clock out early because we're not stressed out about being behind. Learning that made me shift from caring to apathy. I left shortly after, but I wish I had stayed a bit longer, it might've been nice to have a job that I didn't care about so I could focus on other areas of my life.

Yes, in the most toxic place I ever worked. Gee, those are probably related, huh? The owner of the company was crazy. Not in a hyperbolic "oh yeah she's nuts" way but in a "she's either taken too much medication or not enough because she's unstable." Some of my favorite anecdotes, starting with one relevant to your comment:

1. After I provided an estimate of N weeks for a project, her response was "no it needs to be done faster than that." Okay, what features do you want to remove? What can be added after launch? "Everything is critically important and has to be available at launch, I thought it would take a day or two not weeks!" Finally she just wrote something about 80% of my original estimate and moved on. It took a week or two longer than I had originally estimated and it was fine.

2. Insisted on charging $10 instead of $9.99 because "the taxes get too complicated." Turns out rather than just using billing software like any sane person ca. 2010, she was using a calculator on her desk to figure out what clients owed and just typing that into an invoice and sending it. I bet 90% of our clients either overpaid or underpaid basically every bill by 1 cent due to her rounding in her head.

3. My favorite one ever was she was out on vacation one week, and while she was out we had some production issue over the course of a day and a half or so that was eventually resolved but she was cc'd on everything as she insisted. She pops into my office her first day back at like 8AM and says "I saw $THING wasn't working last week, everything's good now?" Yup. "Okay thanks!" and left. Comes in a few more times asking about $THING over the next hour, kind of weird but not unusual. Runs into my office frantic right before lunch "John Doe just emailed me, $THING is down!" Turns out she was just reading her Outlook top to bottom, so was gradually reading earlier and earlier emails. So in her mind $THING was totally fine and gradually slid into chaos as she read older and older emails.

That was an exciting few years, I have to say.

“The bearing of a child takes nine months, no matter how many women are assigned.”

Can't get better than this

[1] https://en.wikipedia.org/wiki/The_Mythical_Man-Month

EVERY EXTRA PERSON YOU ADD MAKES IT TAKE LONGER. The fastest delivery is a solo developer that you get out of their f**ing way and let them work.

"The late preterm singleton rate rose at an average annual rate of 2% each year from 2014 to 2019 (from 5.67% to 6.32%). The decline in the late preterm rate between 2019 and 2020 (6.32% to 6.30%) was not significant."

https://www.cdc.gov/nchs/data/databriefs/db430.pdf

Simply bullying for a lower estimate, which is what I see 90% of the time is idiotic. Basically demanding to be negatively surprised later when the estimate slips rather than positive surprised when the dev is able to beat their initial estimate.

The first conversation requires empathy while the second conversation is a pure power flex. So it is unsurprising which we get more of.