Understand How the Work Evolves

Growing organizations can fall into the trap of thinking scaling is easy.  Simply add functional departments to break the work into compartments, flow it through the system and voila, infinite scaling!  I’m often perplexed about how the structures I see in organizations are similar regardless of the type of work they are doing.

There’s usually a development team, test team, release team, product team, implementation/support team etc and these groups are usually silo’d each with their own hierarchy.   Perhaps fodder for another post, I find that these structures and hierarchy often mimic manufacturing.  Put some requirements in one end and out pops the toaster from the other end.

You can avoid scaling problems, or at least minimize them, by understanding how the work evolves as you grow.

Many years ago I worked for a 3-person start-up company.  Life was simple then.  Worked flowed from the customer to us, we did the work and then we showed the customer.

One customer was closely followed by the addition of 3 other customers and the organization grew.  As a result, the work system changed even though the actual work didn’t:

Communication and work was flowing in an ad hoc fashion throughout the organization.  The first customer was fine as they were dealing with one of the founders who wrote the platform so we locked him in a room and called him Frankenstein code ninja guy.

There wasn’t much thought into creating this structure, as it was a start-up, people just naturally silo’d themselves and did what we could to handle the work.   In a nutshell, customers and prospects would generally contact whoever they knew at the company to get work done.  The result was a great deal of chaos, no real planning or strategy and instead more of a ‘lord of the flies’ culture emerged.

One box missing from the diagram is the Operations group.  They (well, he…it was one guy) were the gatekeeper and eventually took hold over all production deployments so there was one more hand-off in the chain.

By this time the company had about 20 employees and then we were acquired.  Things got interesting then.

Follow the orange lines, if you can, needless to say communication and flow of work became very complicated.  As an example, the yellow line represents a common type of work request and each number represents a step in the process.  This example is a customer  requesting a new implementation of the product.  I am speaking abstractly about the product because the product doesn’t matter.    By this time the company had about 250 people working for them.

You’ll notice legacy ninja guy is still all by himself.  Nobody wanted to touch that codebase.

(1) The customer would contact the account team with the request.

(2) The account team would engage professional services for feasibility and timelines.  There was usually some back and forth between these groups and the customer.

(3) The professional services team would engage content creation and the development team if there were any product customizations required.

(4) The content team would produce the content and hand it over to QA while the professional services team was finishing the implementation and loading the content.

Page 1 of 2 | Next page