Team Organization

I have been working for Inventive Designers for about 11 months now, and I’ve already gone through two internal re-organizations. Not the kind of ‘re-structuring’ that involves people getting fired, but the kind where teams are re-organized to optimize the working of the company.

It is important to note that our technical department is divided into two parts, being “Development” that works on the product and “Serviced” that works on implementing the product at customers, and doing small customer modifications. At the time I started working there were three different development teams:

  • “Core Infra”: responsible for our own infrastructure and the infrastructure backend of our program.
  • “End User”: responsible for the rest of the program.
  • “Communication Center”: responsible for an extension to the program.

Though it could be argued that “Communication Center” was not a full team in it’s own right, as it existed of consultants who also had to work on customer projects. This made the team very fluid, and spread over many different things that were not involved with the actual responsibility.

Changes in team structure are common at Inventive Designers, as I was told that not long before I started working there, they changed the teams as well to come up with the structure mentioned above. But I will focus on the changes that occurred since I started working there, their purpose and effect.

Things were not organized optimally, and this was noted by our Chief Technical Officer (CTO) who announced a big re-organizations at a staff meeting. The changes should allow the company to become more agile, have a clearer road map and understand of what we are doing.

The changes included:

  • Disbanding “Core-Infra”, the current members were assigned to another team or got a new function.
  • Assigning a Product Owner and Product Architect.
  • A few people moving from one team to another.

The new team structure was never really evaluated to see if it had the desired outcome. I don’t even know if anybody (except maybe the CTO) knew what the desired outcome was, and how we could measure it.

But based on my own experience, I would say that nothing much changed in the way everything worked, except that the Product Owner has done some a good job at clarifying the vision of the product. if the goal however also included the teams to become more productive, or more scalable for future growth (which I think it did), then that failed.

Recently we had another re-organization of the development teams, about 6 months after the previous one. This time however, the idea of the new structure was not solely invented by our CTO but it involved the Team Leads of the two teams as well.

The idea behind the new team structure was to have clear ownership of features for each team, enabling teams to focus on a clear set of features. To accomplish this some changes were made:

  • Two new teams were introduced.
  • Some people were moved to different teams.

It strikes me to see that our current two Team Leads, would remain and become the Team Leads of the four teams. Another remark that I have is that most teams have a clear, small set of features except the original “End User” team (of which I am a member). The responsibility of my team are simply everything that remains, which I think is still too much to have a coherent team that is up-to-date with the current code.

Though I like the idea behind the change, and I couldn’t agree more that we really needed it, the haste in which the new structure was introduced makes me septic to the effect it will have. Nothing was prepared yet to enable the teams of taking ownership, our code base is just one big pile and so are our tests. How can teams take clear ownership with this? How can we separate the teams if our code and tests are not?

It is a bit early to make any type of conclusion, but at the moment I don’t see any big changes. It is typical for the company to want to do something, but not think it through and prepare well before doing it. Instead we do things half, expecting to get all the benefit, only to call it a failure because things didn’t get better.

I believe this second team re-organization will not have the expected result, not because having multiple teams with a clear set of responsibilities won’t work, but because the teams will have a hard time guarding the responsibilities, and we will end up with a lot of inter-team communication about code and tests due to the fact that they are not suitable for such a structure.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.