3 ms·

As a retired (read: old school) IT Exec the "flat" management concept has always intrigued (and terrified) me. Clearly a military like hierarchy doesn't work w

As a retired (read: old school) IT Exec the "flat" management concept has always intrigued (and terrified) me. Clearly a military like hierarchy doesn't work well in systems development. Most aspects of systems development are fundamentally creative processes that are somewhat diametrically opposed to being micromanaged. At least this is what I have found in my experience. As jofreeman.com notes there are fundamental constructs of organizational structure that are critical. Ie: one of the most important (IMHO) is the top down delegation of duties. A good leader ensures critical things like cross training and staff development are achieved. Bottom line: every organization has the same human dynamic - no matter how it's organized - if you get face time with the leaders, you wield power through association.

dnomad 8y ago
It's funny because I've always felt this is something the military gets right. (At least the Marines do.) The military understands quite well that most tasks cannot be planned or managed at all. It is never a matter of giving people scripts and having them execute scripts. The world is chaotic and unpredictable. It's also very hard for any one person to get anything done. Most work requires a team which introduces even more chaos, failure modes and unknown variables. Therefore the military introduces the concept of 'command'. Commanders are not there to micro-manage anybody. Good commanders understand quite quickly that they cannot control everything. Commanders are there to work with the chaos. Once you accept the concept of command the next step is the basic understanding that there are some people who are good commanders and others who are not just bad at it but they may actively dislike it. The commanders may indeed thrive off a certain amount of chaos and structurelessness may despise being "micro-managed." Give them a big goal, the necessary resources, and set them off. As long as feedback mechanisms are in place they'll get there. The specialists want routine and stability. They want to be part of a team where roles and responsibilities are clearly laid out. They want to be able to focus and specialize on a single problem and excel in a particular domain. BTW, this division, like most binaries, is not written in stone. Excellent results can be achieved by rotating commands over time. Specialists who claim to dislike command should sometimes be given command responsibilities simply to edge them out of their comfort zone and broaden their perspective. Sometimes commanders need to get to their hands dirty to grain a deeper tactical perspective. Avoiding a rigid hierarchy and command structure is how good organizations scale and adapt. The problem with the completely flat model is that it may serve commanders very well (who again, can thrive off chaos) but specialists will experience a lot anxiety and frustration.
BaronSamedi 8y ago
"Most aspects of systems development are fundamentally creative processes ..." I'm not sure this is accurate. The Space Shuttle systems software, likely among the highest quality software systems ever developed, does not appear to have been a creative process--at least not in the artistic sense of creative self-expression (thanks to a previous commenter for the link: https://www.fastcompany.com/28121/they-write-right-stuff https://www.fastcompany.com/28121/they-write-right-stuff). If the Shuttle example were representative of software development as a whole then we might posit that software quality is inversely proportional to creativity. But I don't think it is. Instead I would describe the creativity required as: improvisational problem-solving within the bounds of a known form. In warfare, for example, there are standard tactics (the form) for reacting to an ambush, however, every ambush is unique and the local commander must improvise within those tactics to solve the unique problems. Likewise in classical music, the symphony had a standard form in which a composer like Mozart could express creativity. Software development should work the same way. The problem is that we don't have a sufficient catalog of proven software designs (forms) to refer to when solving common problems. We end up solving the same problems over and over again in unique ways. This allows developers a lot of creativity but does it result in high quality software at a reasonable cost? I don't think it does. I lay a large part of the blame for this state of affairs on the culture of neophilia so prevalent among developers. In the culture of other professionals who make things, they seem to cultivate a tradition of what works, why don't software developers?

dnomad 8y ago

It's funny because I've always felt this is something the military gets right. (At least the Marines do.) The military understands quite well that most tasks cannot be planned or managed at all. It is never a matter of giving people scripts and having them execute scripts. The world is chaotic and unpredictable. It's also very hard for any one person to get anything done. Most work requires a team which introduces even more chaos, failure modes and unknown variables. Therefore the military introduces the concept of 'command'. Commanders are not there to micro-manage anybody. Good commanders understand quite quickly that they cannot control everything. Commanders are there to work with the chaos. Once you accept the concept of command the next step is the basic understanding that there are some people who are good commanders and others who are not just bad at it but they may actively dislike it. The commanders may indeed thrive off a certain amount of chaos and structurelessness may despise being "micro-managed." Give them a big goal, the necessary resources, and set them off. As long as feedback mechanisms are in place they'll get there. The specialists want routine and stability. They want to be part of a team where roles and responsibilities are clearly laid out. They want to be able to focus and specialize on a single problem and excel in a particular domain. BTW, this division, like most binaries, is not written in stone. Excellent results can be achieved by rotating commands over time. Specialists who claim to dislike command should sometimes be given command responsibilities simply to edge them out of their comfort zone and broaden their perspective. Sometimes commanders need to get to their hands dirty to grain a deeper tactical perspective. Avoiding a rigid hierarchy and command structure is how good organizations scale and adapt. The problem with the completely flat model is that it may serve commanders very well (who again, can thrive off chaos) but specialists will experience a lot anxiety and frustration.

BaronSamedi 8y ago

"Most aspects of systems development are fundamentally creative processes ..." I'm not sure this is accurate. The Space Shuttle systems software, likely among the highest quality software systems ever developed, does not appear to have been a creative process--at least not in the artistic sense of creative self-expression (thanks to a previous commenter for the link: https://www.fastcompany.com/28121/they-write-right-stuff https://www.fastcompany.com/28121/they-write-right-stuff). If the Shuttle example were representative of software development as a whole then we might posit that software quality is inversely proportional to creativity. But I don't think it is. Instead I would describe the creativity required as: improvisational problem-solving within the bounds of a known form. In warfare, for example, there are standard tactics (the form) for reacting to an ambush, however, every ambush is unique and the local commander must improvise within those tactics to solve the unique problems. Likewise in classical music, the symphony had a standard form in which a composer like Mozart could express creativity. Software development should work the same way. The problem is that we don't have a sufficient catalog of proven software designs (forms) to refer to when solving common problems. We end up solving the same problems over and over again in unique ways. This allows developers a lot of creativity but does it result in high quality software at a reasonable cost? I don't think it does. I lay a large part of the blame for this state of affairs on the culture of neophilia so prevalent among developers. In the culture of other professionals who make things, they seem to cultivate a tradition of what works, why don't software developers?