Riddler
Arcane
- Joined
- Jan 5, 2009
- Messages
- 2,388
IMO you need someone in charge of projects and hierarchy to keep track of who's doing what and how they are progressing. If someone's not pulling their weight, for whatever reason, there needs to be process to sort out any problems, I know it's probably problematic in creative endeavors as creative fluids might not flow on schedule, but how else can you keep the project running on time?
In my experience, clear hierarchy is necessary to keep it clear who is responsible for what and who reports to whom, of course it doesn't always work like it's planned as there might be personality clashes and whatnot.
As I said, some hierarchy is probably inevitable. The question is how high is the structure, and how do people in it conceive of their responsibilities. Of course situations where someone isn't working out -- not pulling their weight, causing social problems, whatever -- need to be sorted out, and it's maybe a little bit utopian to expect a comrades' court to take care of it.
In my opinion a software house should be organised a bit like a carpentry workshop. Making software -- and this applies to a game just as well as any other software -- is a craft after all. You've got your master craftsman who understands the whole process. You've got your journeymen who are at least competent, possibly extremely competent in one or more specific areas as well as having at least a partial understanding of the big picture. And you've got your apprentices who range from people who are just learning the craft to a majority who's capable of working productively under supervision, to a few that are already very good at some limited areas. The journeymen mentor the apprentices and the master participates in the work, teaches the most promising journeymen personally, and breaks any ties that emerge in the work.
And of course the master and journeymen agree about who takes charge of producing whichever order is being worked on, and how the journeymen and apprentices are assigned to each of the orders. But you don't really need an Assistant Sub-Manager Of Fishtail Joins with a team of Junior Fishtail Join Engineers working in his team, just somebody who's able to make a fishtail join, and some mechanism to make him available where fishtail joins are needed.
Of course the height of the organizational hierarchy needs to be closely managed so that people can operate without constantly seeking approval and operations devolve into inter-manager politics and constant need for more communication rather than being productive.
One common issue that I often see here is that many people, in particular within SW dev, have had bad experiences with hierarchies and thus tries to have as flat organisations as possible and often to pretty great success. The problem is that the case studies of when this really works well are based on two facts:
- The need of very competent, driven and self-motivated employees, something that is a pretty limited resource when everyone are screaming for more developers.
- The cases studies that the theories of flat organisations are based on are relatively small teams and companies (many cases start ups).
As a management consultant I see the lack of hierarchies as a much more common failure mode than hierarchies. This is not due to flat organisations being bad but because they are overused and not adapted to the realities of organisations that do need hierarchies.
Saying one or the other is better or worse is naïve, both are needed to varying degrees in different types of organisations.
In the end however it is rarely the organizational map that is the issue, it is the managers. Being a manager is very difficult and stressful and the method for selecting people for the role is often very flawed and even random (also promotion to incompetence) which leads to bad outcomes regardless of systems.
Most of the time when we come in to help an organisation straighten out their practices the organisation we propose is often based on (when we are doing a thoughrough job) eliminating or circumventing destructive managers or practices rather than implementing some "master organizational plan".
In the end, If the rot is at the very top (which it often is in startups that have been moderately successful) it's often difficult to do anything really productive.
Edit: organizational theories are kind of like diets. People have trouble taking a measured approach and end up with something too extreme which they can't maintain.
Last edited: