Organization chart

Organization chart

Vasiliy Ivanov Jun 07, 2017

I knew the "organization chart" definition even before the company was created, but I realized its true value only after the company surpassed the mark of 60 employees. Before that I had time to talk to each employee during a week, I knew what was happening in the projects, and personally took part in solving the emerging problems.

After some time, I got my mind set on that my working day started at 9-10 a.m., and ended at 10-11 p.m. At the same time, far from everything that had been planned was done. At this stage, we began to formalize processes and relationships. The problem to solve was simple - every employee should know who he was working with, who was his team lead, whom to contact for any issues. As a result, in addition to describing the technical and administrative processes, we have built the organization chart.

The current organization chart represents its fourth iteration. We always notice mistakes and make changes, striving for one goal - the company productivity. I'd like to clarify one thing: there is no organization chart that would satisfy most organizations, as this chart is highly dependent on the type of organization's activities, technologies, employees and, even, location (country).

Required properties of the organization chart, which I considered for KeepSolid:

  • Relations of subordination and cooperation. The classical structure is drawn in the form of a pyramid from the first person of the company to the subordinates and so on. The first issue that we noticed was the sequence "project manager > technical leader > technical specialists". The project leader and technical leader are people from two different divisions, which are often combined into one branch of the hierarchy, which leads either to the decline of the project technical level (product quality, technology choice, team development), or the project management (terms, relations between people, compliance with requirements, selection and retention of staff, etc.). Even worse, when the technical team has two managers: technical and administrative. In this case, it generally becomes unclear for the team whom they should address issues to, and the most shifty ones also begin to take advantage of it. In our case, the optimal solution was the following: we created both a technical branch and an administrative one that would not have a relationship of subordination, but cooperation only. Thus, we got an organization chart in which technical specialists were subordinated to technical managers, and administrative specialists - to administrative managers.

  • The product and responsibilities of the employee. Each position has the specified functions to be performed and the result of the work expected from the person in the selected position. Such clauses clarify for employees the reason for their being in the office and the adequacy for their position/salary.
  • Each leader is recommended to have no more than 8 subordinate people.

We made the organization chart and...? No, we did not just save the picture on the computer's hard drive, but put it in a prominent place. It's very important that every member of the company can refer to it when needed. It is worth mentioning that this document cannot be executed just once for the whole company life (if the company, of course, evolves) and requires modifications when new items or activity areas appear. I already see the following changes that we have to do: the current organization chart suits us for the management of one office. The opening of new offices in other regions will require the allocation of some employees to a separate management unit, and the structures of each office must be linked to one leader in each office.