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.
(5) QA would then test the implementation and there was usually back and forth between QA, professional services, content and the account team and customer.
(6) Professional services would hand the finished solution off to the account team.
(7) The Account team would hand over the solution to the customer.
(8) The Customer’s new implementation gets passed into the Support process.
The problems we experienced were similar problems I see with clients:
- time and effort wasted during hand-offs
- fighting between silos (professional services and the account team wants the implementation out the door but those pesky testers are getting in the way)
- scheduling confusion
- overloaded professional services team (too much work flowing through them, support interruptions, some technical pre-sales work)
- senior management fighting about priorities and direction as the react to how the work is getting done
I was leading the Professional services team and we were using Kanban (although we didn’t know that was the word at the time) to flow the work through our system. Actually to be more accurate, and to provide a nice buzzword, we were using Scrumban since we did stand-ups and retrospectives but weren’t working in sprints. In fairness we did what made sense and none of us knew what Agile was at the time so we’d throw out stuff that didn’t work and do more of the stuff that was working.
We provided lead times and cycle times to the account team and our biggest gripe was being the whipping-boy group. Any between-the-org-chart work by default came to me since I was one of the original 3 people.
Oddly enough our WORK was EXACTLY the same as it was before however our system had grown so utterly complex it was difficult to get that work done. Hindsight is 20/20 and here’s an example of designing a scalable work system to support the work being done:
Since the work didn’t change, the system didn’t need to change as drastically as it did and we could have created multiple cross-functional teams to handle the work. The only difference between the first stage and this one is the extra hop when interfacing with product development which seems like it’d be a good idea so we don’t end up with legacy ninja boys all over the place.
Would this have worked? Maybe. The point is with all the hub-bub around scaling and if Agile’s good enough to scale, what is getting lost in the shuffle is understanding the actual work that is being done. Organizational leaders fall into the trap of building structures they are familiar with, what they did at their last job or what is thought to be the typical way to scale (read: functional departments and hierarchy).
If that worked they wouldn’t need ‘Agile’ to get the work done. If you’re considering adopting Agile, take the time to understand the type of work you’re doing and build a system to support that work. That’s like diet Agile. All the benefits and none of the wasted calories associated with wondering whether or not you’re Agile enough.