Until recently, 4PSA has had a pretty standard organization, with function-based departments – Sales and Marketing, Software Development (with many teams), Technical Support, Administration, Human Resources etc. This worked decently for many years and that is why I still recommend it as the default organization for any company really focused on a single product.

Making sales communicate with engineering and so on is indeed a challenge. However, there are mechanisms to improve their communication. Good teams are capable of self-improvement at any time.

But It’s Not Perfect

Issues started to become more and more obvious when our engineering organization became more complex. Frankly, we do not like complexity that much. 😀 Therefore, the best idea we came up with was to attempt to simplify complexity.

We identified complexity and started hunting things that we were doing wrong (no relationship with the picture above :)).

A Lot Is Actually Less

Complexity was mostly triggered by the various needs arising in product development. We ended up doing lots of things:

• low-level stuff (like distributed databases, frameworks)
• end-user products (VoipNow)
• R&D on future stuff (our Apps, which include a JavaScript framework)
• cloud provisioning and monitoring etc.

While a lot eventually gets into an end-user product such as VoipNow, it takes a great deal of time for it to happen. That’s how we reached the stage where some people were working on technologies that remained pretty much unknown to the rest of the engineering group. Not only this is far from being ideal, but it’s also dangerous. I’ve seen teams willing to take the effort of reinventing the wheel, but time can be spent smarter.

Solving It, Step By Step

Reducing complexity is definitely a challenge. What matters even more is increasing the focus on the products, even if such products are internal. That’s why we first worked on the engineering level.

Step 1: Software Architecture

Changing the way we write software was the most important thing we did. This change, which was also demanded by the cloud reality, proved to be the biggest challenge – mostly due to the legacy software we had to support, but also to the old mentality most engineers are inevitably attracted to.

Basically, any project in 4PSA falls into one of the following categories:

• Stack – This includes all the helper libraries, frameworks, databases, testing tools etc. The stack is not public. There are some plans to open parts of it, but this would require a lot of resources that we currently do not have.
• Platform – This is a public product, open to developers on the API level. We treat other developers the same way we treat our developers.
• Apps – They are written by our developers, but they can also be written by third parties, based on the API we expose at Platform level. Naturally, they are public unless someone decides to write an App for internal use only.

Sounds too simple? It’s that simple actually, but we had to write a lot of stuff to make it possible. It was time-consuming, but it was worth it.

Step 2: Understand Important Functions

Sooner or later, all companies learn the hard way how ignorant people tend to be when somebody else’s work is at stake. For example, sales people are most times perceived as the ones that bring money to the company, marketing people as the ones that are good at bullshitting, developers as the geeks, so on and so forth. Getting people together helps them understand each other better, but this must happen very often, otherwise people tend to forget.

This is the reason behind our efforts of getting people to learn more about each other and understand how important their role is in the success of the product. We identified six important functions in our organization:

• Leadership – they build the strategy and guide through it
• Marketing – they spread the word about the product
• Sales and Customer Support – no matter if they do technical or non-technical stuff, they make our customers happy
• Product Development – they build the product, in our case it’s software engineering
• Infrastructure – they provide the support for the software to run in the cloud
• Team Support – they help everyone else in their work, for example HR, financing, accounting, administrative etc.

This is only the shortlist. Reaching this point was not easy as we had to make a lot of sacrifices. In the beginning, the list had 12 important functions. Reducing it to six really important roles that do not overlap was quite a challenge.

Step 3: Build The Product-Oriented Teams

Considering our software architecture and these functions, we reorganized the company into product-oriented teams. Instead of having function-based teams, we built them in such a way that each team had at least one baby to look after. Surely, this approach brings some overhead. For example, the sales and customer support function must be present in each team that builds something that is directly used by customers (or even by internal customers). Before reorganization, it was a separate team. On closer analysis however, this overhead doesn’t count much as sales guys tend to become specialized anyway – someone cannot truly master more than one product.

Sounds like fun? It’s more than you think. 🙂 In our next article, we will tell you how we are organized internally. In short, we’ll be introducing the product teams.