Comment by Guthur | Hacker News Reader

Comment by Guthur | Hacker News Reader

Parent Full thread

In my experience with internal dev teams there are very rarely any real deadlines. They do exist; fixed product cycles, government mandates, but most of the time its made up arbitrary marks in a calendar, sprint deadlines (yes, these are deadlines), quarterly goal deadlines, yearly objectives etc.

Deadlines are just lazy management, we feel we need to set deadlines to motivate people and drive delivery, the problem is that the motivation is built on fear and are very poor at actually achieving quality outcomes.

One of two things is likely to happen with deadlines as your main motivator (a) they are ignore completely with very little impact on a workers motivation, this is likely a very disengaged workforce or (b) they are feared and drive an individual to try to hit the deadline not matter the cost either in quality or their well being, both are ultimately bad in the long run. Also we're also susceptible to Student Syndrome [0] which can exasperated scenario (b).

I believe that we are constantly stuck in rewrite cycles because we are forever rushing to meet arbitrary sprint deadlines.

Leadership should be using development metrics to try to estimate delivery velocity and understand the selected priority order for delivery, but don't turn those into deadlines, keep the system in control so that you can be accurate to your projection.

[0] https://en.m.wikipedia.org/wiki/Student_syndrome

I think there's also a third option - that the deadline energizes. I've been in teams, where the team as a whole set a completely arbitrary deadline for the functionality they'd like to have done by a given time - and that worked well to motivate team members to hit it. Granted, this is probably not the norm though, but it's not impossible.

I think there's a large difference between arbitrary deadlines that the team themselves set and buy into as a rallying cry vs. an arbitrary deadline that was externally imposed upon a team, often without full context provided to understand the relative priority of features as well as whether the deadline itself is negotiable.

There is a away to set goals and these can have a time component, daily todo list, weekly goal. But as you mentioned this works when they are a personal tool, and best when broken down into small achievable increments.

From what I've seen that's a "this is the last thing I want from this team, and I fully the best people to leave immediately after" option.

i feel like everyone in the industry ought to do a couple years in a small eat-what-you-kill consultancy early in their career. When not delivering what you promised when you promised it means the lights don't come on tomorrow you get very good at estimation and delivering on time... or you find a new way to feed yourself.

I think a large part of this topic isn't about a team making a promise and not living up to it. It's about a business (management) wanting to make a promise and getting the team to accept responsibility for it. So let's assume the estimate is very accurate but the business wants it done in half the time. When the project runs past that date being able to point to a very accurate estimate and say I told you so isn't very productive. So we need strategies and techniques for dealing with the mismatch between the desires of the business and what can actually be delivered in a given amount of time.

TFA advocates for bargaining on scope, where I prefer to start the conversation by asking about both scope and timelines to understand which parts of the overall request are negotiable. This is also a great opportunity to make sure the business context is well understood so everyone understands what success means from the perspective of the business

You might then find every single feature really is necessary and the timeline can be relaxed. Audit compliance can be an example when it is something new to an org. You are either going to pass or fail the audit, so there isn't really room to reduce scope. But you may be able to negotiate on the timeline.

Reply on news.ycombinator.com