Ask HN: Will software get shipped without any management?

3 pointsvpEfljFL6y ago4 comments

I was thinking about necessity of standups/daily status reports in the process of software development and I'm wondering what will change if we get rid of any form of management. I mean don't do standups, don't formally plan for the future work, don't assign tasks and so on.

The only thing that will remain is the product owner will create issues to implement features clients want (but team also can create issues). Then it will split up by the team without any form of formal process. Anyone can pick any issue to work on.

Like idealised Valve && GitLab && Basecamp culture but applied to < 10 developers on a remote team.

The base values of the company are defined as `deep work` and `asynchronous and open communications`

What do you think of the idea? Do you have an experience of working in such environment?

As a developer you process will look like: - choose the issue to work on - ask questions if you have some - check for maximum time (in weeks) we can dedicate on this issue (if it's defined) and if it doesn't fit with your expectations ask to reconsider the scope (but you don't track time on the issue) - get offline and work on the issue

Also, each 1/2 days make a review of awaiting PRs and check for questions your team has (you are expected to ask them in public channel, pm can be used only for private discussions not related to project like personal questions or so).

Finally as most of the time you work alone and do not collaborate much, there will be optional pair programming sessions or weekly video calls where you can discuss any topics you want.

Ask HN: Will software get shipped without any management?

3 pointsvpEfljFL6y ago4 comments

Like idealised Valve && GitLab && Basecamp culture but applied to < 10 developers on a remote team.

The base values of the company are defined as `deep work` and `asynchronous and open communications`

What do you think of the idea? Do you have an experience of working in such environment?

Finally as most of the time you work alone and do not collaborate much, there will be optional pair programming sessions or weekly video calls where you can discuss any topics you want.

4 comments

4 comments · 3 top-level

WheelsAtLarge6y ago· 1 in thread

My genral experience is that self control is the issue. Short term we are willing/able to complete tasks with out supervision but long term we start to take short cuts to the point that eventually all work becomes subpar without supervision and QA.

What I suspect would happen that for a short time you would see no changes but little by little productivity would wane until someone would need to step in and set the system back in to a productive system again.

So, no software will not ship without proper management.

vpEfljFLOP6y ago

Thank you for the answer. I have couple of points to elaborate.

> that self control is the issue

Self control is always an issue and in general we all have periods of low productivity. If you feel like you can't produce anything useful today due to emotional distractions or general slack you can take the rest of the day off.

> What I suspect would happen that for a short time you would see no changes but little by little productivity would wane until someone would need to step in and set the system back in to a productive system again.

What if "management" system wouldn't introduce real productivity gain for creative workers and all we have is visual productivity and just low productivity all the time on average? I'm wondering will the productivity boost happen if we eliminate any form of psychologic pressure?

Why productivity will wane if you allowed to work on anything you want? You work in a small team and can pair-programm and just talk weekly to your colleagues on calls if you feel like you need to discuss something.

bigiain6y ago

I think you'll end up in one of two scenarios there. Either a) the devs and product owner will assume a bunch of the "management roles" as they self asses priorities and choose which issues/tasks to do next, or b) they will choose issues and tasks without any regard for "management roles".

a) May work, depending on the maturity of the dev team (not naively measured by age or years of experience, although both those have some significant correlation to "maturity" in this sense) - and their alignments with the client requirements. This is certainly something I've seen work with remarkable speed and success with the right team solving a problem they understand and are motivated to get right.

b) is likely top result in only "interesting" tasks getting done and "shiny new thing" architectural decisions and "resume driven development" happening - and client needs and expectation remaining unmet.

Devs like to look down on "management" as a role, probably deservedly so given how much "bad management" is on display across the industry. But great management is just as much a "super power" for a team as having a great tech lead. The "10 x" dev myth has at least a basis in reality, there is without doubt the same kind of mythical unicorn manager also based in reality - people who's ability to multiply the effectiveness of they team is real and powerful.

billconan6y ago

I think many great open source projects don't seem to have a strong organization.

j / k navigate · click thread line to collapse