Inner Forces in Organization
Have you ever noticed that building a modern (software) organization has a lot of similarities to a mechanical engineering? That one constructing cars, buliding and pyramids. On a first glance the comparison may sound very strange - modern companies consist of people organized into units and departments. There are policies and goals bringing everything together. There is no place for the classical mechanics in this description.
But let's look deeper. An organization consists of people. As we all know, humans are very different - every one have own inspirations, personal goals, work practices, preferred ways of communicating and so on. Inevitably there would be various views on how to approach any given problem. Larger structures like organizational unit or department also has their own directions. Marketing may be interested in bringing on new clients while software engineering is busy with improving software performance. There are forces and tensions between parts in the organization! Like Jenga tower, the overall construction may be quite stable or very fallible. A conscious effort to structure the organization in a way that harness such interpersonal "physics" may greatly improve owerall performance and boost innovation.
I like to think that building a team (just a small bit in an organization) is similar to creating a river crossing. One person may just grab stones and throw them into the river until it is possible to cross it. Another will make some calculations and build a bridge. The latter approach requires more mental effort but in most cases yields better result (more people would be happy and the crossing would be useful for years). It is quite similar with people. Many companies just hire lot of developers (or other knowledge specialities) and throw them into an existing process hoping it will work. A good leader would look at individual strengths and build a process (tools, responsibilities and goals) around the people they have.
The anology is even more powerful. Many organizations has official rise and promotion policies. But quite too often they focus on the things easy to measure. If you have to quantify which stone is better for river crossing, how would you do it? Well, maybe just throw and see which one produces a larger splash? I don't think anyone would argue it is a criteria. The only problem is that it does not measure how the stone contributed to a crossing. A heavy boulder may even ruin the brittle emergin dam. Actually, it may be not the right thing to judge stones making a bridge individually! And still too many software organizations just measure abstract impact instead of value for achieving a goal.
And at the larger scale the mechanical analogy still works. A building may consist of structural elements, plumbing, ventilation and heating systems just like an organization is comprised from multilpe units with different functions. As long as there is much independence, you can't just desing one component without taking into consideration others.
So how do we build an organization or a team? And how would we substitute some existing structures. If we can't judge an individual by an impact, how else should the raise and promotion be allocated? What would be better insentives to move things forward? There are many good questions and not many answers. So let's explore things together. I have a personal theory which seems to work well (team is happy and the product seems to be better than industry average). But I only worked with just a handful of teams and wider indursty input in appreciated. It could be your own theory, some data on the ideas and methodologies or maybe just a personal feeling and experience from a workplace - everything matter.
I'll continue with more thoughts and explanation if there is an interest. And the very next topic would be a difference between "traditional" and "knowledge" organizations and management practices.
Комментарии
Отправить комментарий