Scrum hasn’t much to say about organizational design. And rightfully so – if there is any area that has no universally applicable template, org design is it.
B2B startups – that is, companies whose customers are other businesses – have an especially hard time with organizational design. Their customers are hundreds or even thousands of times larger than they are. And yet, many B2B start-ups design their organizations to match that of their much larger customers. The logic appears sound: aligning internal structures with those of your large clients seems like a good way to understand and meet their needs more effectively.
But the reality is that your customers are buying from you because you are small and nimble. You are able to solve their problem sooner more effectively than they could internally, and that is extremely valuable to them.
Furthermore, attempting to match the scale and complexity of larger clients’ organizational structures can strain the resources of a nascent startup. There is a real risk of burning out employees, who now need to expend energy on untangling needless bureaucratic knots. This type of organizational design throws a giant wet blanket on the entrepreneurial spirit of what should be your most enthusiastic, resourceful employees.
I once worked with a small company whose main customers were large North American cable and telco companies.
They had:
- PMO Department (1 person)
- BA Department (1 person)
- UX Department (2 people)
- QA Department (2 people).
- Engineering Department (5 people)
Each department sat in their own separate area of the office. You could almost physically see the waterfall of projects travelling from one area of the office to the next.
They created BRDs that were very similar in form to what their customers were producing for their own internal Projects. The bulk of communication between each “department” was done through a series of templated documents, and whenever something went wrong, the blame would be placed on a ‘missed requirement’.
By mirroring their major customer’s org chart, they were severely limiting the effectiveness of their own internal collaboration. They would work for months on a project, only for the client to reject the latest release because it wasn’t what they thought they were asking for. Projects that were accepted were often late and required extensive rework after the initial release.
As they began to break down their internal silos, and move to something resembling an agile organization (with a cross functional team, go figure), they started bringing people from their customers’ organizations to the Sprint Reviews.
They were getting real time feedback on what they were building, while they were building it.
Developers would speak directly with people from the client’s organization, instead of playing broken telephone with the Account Executive.
Quality improved.
Releases became more frequent.
The client loved it.
The client even began applying some of these principles in their own internal projects.
Resist the urge to mirror your clients’ organizational structures. Embrace a structure that encourages agility throughout your organization, and provide that value to your larger customers – because they can’t do it themselves.