In our last blog we spoke about bottleneck management: when managers become victims of their own success and employees drift away into a shadow organization. We had to rethink again and ask ourselves: How do we deal with the overextension of our top manager? In a top-down fashion and by recruiting more traffic police or by building a roundabout so that the (organizational) traffic can self-regulate?
Know-how in the company – distributing the best brains
We soon had to ask ourselves this question in a very specific situation: for our company it was very important that resources were invested in new software. With this in mind we recruited both our best internal and outstanding external programmers. And as a result the project ran very smoothly. But we quickly noticed something: that we now lacked the expertise to further develop our existing software. We were left with no other choice than to send a few of these best brains back to their old team. But it was clear to us that this move would be met with resistance. The new software was more prestigious and working on it presented topical challenges for our programmers and was a real career highlight. So how would they react to being redeployed to their old team?
Voluntarily transferred: when employees become heroes
We felt there were two options: We could simply reach a decision and order the employees in question to return to the old project. Or we could resolve the problem in keeping with our self-determined business culture. And because it is this culture that defines our identity as a company, we opted to go down this path. We turned to our employees, made clear to them the challenge for our company and asked them to voluntarily join the project team to which they felt they could make the biggest contribution. The result: the very employees that we felt could make the best contribution to further developing the old software voluntarily opted for this project. For us this was a very important experience that supports our firm views on responsible employees. For their colleagues these programmers became “workplace heroes” because they safeguarded our existing software. Had we presented them with faits accomplis, however, they would in all likelihood have been dissatisfied and in a worst case scenario their performances would have significantly deteriorated.
Subsequently we repeated the principle of project-dependent and independent team training and introduced so-called swarming in some areas of the company. But we could no longer tap into our initial great success. Although we knew by now that it is important to have at least some rules in agile structures too. However, we had underestimated just how important and paid too little attention to the drafting of these rules. For example, we gave our employees firm deadlines by which the teams should be rearranged. The problem with this was that anything not finished by then didn’t get done. In addition, the responsibilities and to-dos for the next swarming period were unclear. Rather than achieving self-regulation we had brought traffic to a standstill. Taking into account all our experiences in our company’s various phases of development since it was founded, one thing was clear: every company always needs agility and management – and in combination. For our managers this means that they must be very flexible: providing management where it is necessary and wanted but also leaving scope for initiative and introducing carefully considered rules to facilitate agility. It was based on this realization that we developed the operating system for companies. We are excited to see how our company is developing on this basis and will continue to report on our successes, mistakes and lessons.
Do you think our company will achieve the next phase in its growth with an employee-focused operating system? What challenges do you think Haufe-umantis could still face in the future? What are the potential stumbling blocks for our operating system?
Photo Credit: Pixabay