[padobson]

It's actually not micromanagement. It's micro-documentation, which provides more autonomy to the developer, not less.

The micro-tasks I'm describing go into a project management system. They are either assigned to or picked by developers who complete and document the micro-tasks on their own. Because the tasks are so small, there is almost no management of developers required.

Finally, it's trivial to find out where project estimates went wrong, because any hidden challenges are well-quarantined in the micro-tasks. If the task isn't well documented, it's still pretty easy to go to the developer and find out why it took longer than estimated.

[alexashka]

In no-developer-experience-manager's worldview, this is actually a good idea.

If development was so easy that a manager who doesn't understand programming can break developer tasks down into small chunks - we'd live in a completely different universe!

In reality, management breaking anything down into smaller tasks, instead of people who will actually do the work, breaking things down, is going to lead to ZERO architecture and a shit codebase, 100% of the time.

That's if you're lucky and the project is a clean slate.

Existing codebases are full of code smells that'd take days to comprehend, days to chase down and comprehend what the actual requirements were/are because those are never properly documented, and then re-write that 'micro-task' so that the next developer doesn't have to spend their days in hell.

Oh, this'd need to now be tested, there'd be new bugs, and those would need to be fixed also.

So instead, in the real world - your micro-task gets handed down, the developer doesn't bother understanding what the existing codebase is doing, they just patch it until it works, contributing to the unmaintainable piece of garbage that all developers with any self respect left in the world hate.

Since only the brave/crazy ones will say 'this micro task will take 2 weeks instead of 2 days because the existing code is garbage', those brave ones will get replaced by those who will say 'yes, 2 days'. Your project will need more and more time per task, and more and more developers doing maintenance, but the managers will continue reporting successful micro-tasks completed on time!

I've just described corporate programming and how you're directly contributing to the hell that it is.

[dragonwriter]

> In no-developer-experience-manager's worldview, this is actually a good idea.

More precisely, a no-development-management-knowledge manager’s worldview.

While obviously development experience can be a source of development management knowledge, there's no reason it should be the only source, and development managers ought to be screened for job skills as much as developers are.

[alexashka]

I don't see any reason why it shouldn't be the only source - even at McDonalds, managers graduate from being regular burger flippers.

That's why McDonalds works, and software development is a perpetual disaster - McDonalds understand that to manage even something as simple as flipping burgers, you need to have done it yourself first!

It's the arrogance of business school management that's responsible for a great deal of turmoil across many areas of everyday life. Just imagine going to school for something that's not difficult, to 'learn' how to boss people around. For good pay!

Isn't that the dream of every non-creative, lazy, half-wit you never want managing anybody ever? Yes... yes it is...

This is a recent phenomena on a mass scale and it isn't going to last - getting high rank without having earned it has always been a complete disaster, just look at any point in history.

[padobson]

In reality, management breaking anything down into smaller tasks, instead of people who will actually do the work, breaking things down, is going to lead to ZERO architecture and a shit codebase, 100% of the time.

This is just another way of saying management is incompetent. There's no project management strategy that is going to overcome incompetent project managers.

[doseofreality]

So, if a developer takes too long developing the pre-defined micro-task which you've assigned them, you have to followup with them and report on why a micro-task took too long?

If this isn't micromanagement, what would you define as micromanagement?

[beegeezuz]

Exactly, I see Devs in our company having small meeting all the time to discuss the most ridiculous things that you could imagine... if Eng ever get micromanaged like this, I'm out in a month.

[chrisbennet]

A month is too long to wait. Break it down into smaller units... ;-)

I think some managers just don’t have enough to do so they make work for themselves (and everyone else). Like a border collie with no sheep to herd, they will start herding ducks, children, etc.

[fao_]

Hey, this post (and all of your posts) are marked as dead. ~I'm not sure why~

[ethnicify]

Please, help us understand how having a 60 item worklist per week is "micro-documentation". I'm sorry, but you haven't really worked with or had training from real-world engineering managers.

For the engineers, and yours, peace of mind and progress -- please spend some time with stellar execution managers that understand software development is a people problem, not a project management problem.

[padobson]

Good engineering managers (preferably someone who knows how to write code) are going to be able to break tasks down effectively. So yes, it always starts with people.

And I agree with you: talented people, be they managers or developers or janitors, will be able to overcome any process or planning shortfalls.

But there's no difference between what I'm describing - a project manager breaking down features into bite-size bits of work - and a developer taking on a single feature and writing down TODOs in code, on post-its, on a white-board, or in the comments of the project management software.

The difference is one of documentation and communication to stakeholders - which is the PRIMARY problem with software estimation. There are ALWAYS unknowns in software. A team leader needs to be able to go to his boss when something is falling behind and say, "We didn't anticipate this. This is the reason it's taking longer".

This is FAR superior to going to the developer and asking them why feature X is taking so long and having them compile a report from Notepad/post-its/white board scribbles. With my process, you can just pull up the project management software and find the tasks that went way over, and the developer stays almost completely insulated from management.

I'm sorry, but you haven't really worked with or had training from real-world engineering managers.

This is the worst kind of condescending ignorance, it betrays an inability for civility that I wouldn't tolerate in a colleague.

[ethnicify]

Apologies, your perceived "view" of engineers had me fuming. I din't mean to attack you - but I understand where you're coming from.

It is not your fault if your leadership demands detailed answers as to why X is off by Y days. All you're doing is cascading that mistrust/poor management skills to your engineers. I understand what you're doing is the most reliable way to do it, but there is a better way. This is why I mentioned its a people problem.

The better way is to not break down things into hourly tasks but weekly sprints as most teams do. Let your engineers break that down into how much ever granularity they're comfortable with. If something goes off track, build communication trust that helps them keep everyone in the loop and work towards a common goal.

As a product person, I've had the fortune of working in two of the big 4 with some of the best engineers there is - so maybe that contributes to my worldview and it might be terribly biased.

Thanks for explaining :)

[drharby]

Ive developed a habit of doing this very thing, to the point of drafting release schedules to communicate deadlines to management. I love the liberty with my job but you can hang yourself if you don't watch it

[aje403]

I would definitely consider a gulag over this