From a corporate perspective, the Startup world is chaotic, hard to understand, seemingly irrational and even irresponsible. Similar feelings come into play if just a unit inside a Company adopts Agile working principles, for example, an IT Unit adopting SCRUM as its project method.
It is here that the paradigm of Control & Predict meets the paradigm of Autonomy & Evolutionary Purpose. There are bound to be misunderstandings, crisis, conflicts, drama, and frustration in this interface between the traditional corporate world and the Start-up World.
Yet many Companies are rather inept dealing with this interface. A typical reaction is to assign a single point of contact (SPOC) by each supporting unit, such as IT, Logistics, Purchasing, Accounting or Legal to take care of any issue raised by the Startup. The well-meant message to the Startup is: “Do not worry. We will take care of your issues”. And so the trouble starts – boys and girls working for the startup usually:
- Don’t know which question to ask. There are there for a mission, but the intricacies of e.g., corporate IT, Legal finesse or accounting laws are not their area of expertise nor their primary concerns. All their focus is to get a product with a viable business proposition off the ground
- Don’t know how to formulate question, so that the experts in the supporting unit can understand it
- Are not sure who should ask a question. In such a fluid way of working as a Start-up environment demands, responsibility can hardly be pinpointed to single person
- Have other concerns. Yes, there might be this or that – for example – legal quirk with this or that decision, but this is often a secondary concern. Too many decisions need to be taken at a moments notice
- Change their questions fast. Even if a question is formulated, with all the experimentation going on, there is no guarantee that the question will not be outdated tomorrow
- Need answers real fast. A hierarchy, where there is an awareness that answers are nothing else than commitments, and commitments costs resources, needs a lot of time to come up with an answer. After all, the hierarchy is built for reliability and efficiency – not for speed and effectiveness
Giving these problems, the single point of contact model is doomed to fail.
So what is the alternative to the SPOC model? It is not waiting for issues to be raised by someone in the Startup but integrating some co-workers deep in the Startup. Thereby those co-workers, which might be described as liaison officers, agents or advisors, stay in the full context of the Start-up and are able:
- to scout for issues with all their knowledge
- to solve issues by directly addressing real or potential issues with their support unit
- to work relive the tensions between the Supporting Unit and the Start-up
The support unit has to dedicate the liaisons, which can be hard given that the liaisons will be the more effective, the more knowledgeable, the higher their social skills and the better their existing network is.
The Start-up has to accept an increase in their number of co-workers. If multiple supporting units do send liaisons, the number of persons to be integrated can be quite large. But Start-ups need to be close-knit teams where communication is plenty and relations are close and meaningful.
Therefore the liaisons should be integrated not into any single team of the start-up. In the open space facilities so typical of start-ups, the liaisons should have their own table. But they have the permission to change their desk to this or that team table from time to time, just like the situation demands it.
It is the liaison’s job to make themselves useful to the start-up, to seek meaningful work where the start-up team might not be able to identify it and be instrumental in solving it.
Conclusion: Time to move, HQ!
I think that going native is a very good option – after all, the agile way start-ups are working, with lots of experimentation and engagement, lights a way for the corporate world to change.
It is the corporate units that got to integrate into the new world of working- not vice versa.
“Going Native” allows this. It is challenging for the leadership of the support unit to be faced with this new way of working, that provides so much autonomy and decision making authority to the liaisons. But this is exactly what needs to be learned to survive in the digital age.
This is what I think. What do you think?
- Kotter, John “Accelerate” 2014 – gives a good hunch what it takes to lead a conventional, command and control organization (first “operating system”) and simultaneously a second agile one (second operating system)
Special thanks to Holger Balderhaar for making me rethink my position on Kotter’s 2nd Operating system.