Mindstorm

It was a long journey of trying to understand what organisational structure is best for dynamic growth, experiments, agility and change. While trying to understand how it might work had tons of discussions inside my team and series of disconnected posts validating ideas gathered from various sources about principles and challenges:

• Value structure - showing benefits of different type of organisation in numbers
• Organizational design – problems  - explaining what type of problems are introduced with hierarchical growth and why functional departments are not good.
• Org. design: value structure Highlights from my presentation where i try to explain why do we need value oriented structure in the company
• Network structure - latest explanation why and how to turn into value structure
• Skillset and responsibility - how are they different?

But all these were kind of separate notes and most often feedback can summarized into this - “ok, seems reasonable. but what should I do? How my team should act from now on?”

Within our work group we made a decision to write down everything on paper and use it as a starting point for our continuous journey. We decided to call it - POD framework.

Some things to keep in mind. Framework doesn’t describe exact roles with units (product managers, developers, analysts, marketers or whoever is needed) or even how to implement it exactly. Framework sets boundaries and principles how growing organisation must work and what is needed for healthy growth and collaboration.

Will continue sharing main aspects of framework in a series of posts, but you can find a link to whole description at the end of the post. Feel free to comment. So, here we go…

Why?

There is a tendency to organize work around functions, especially during fast growth. Common argument - we need to increase efficiency by forming expert teams which focus on a single skill. It’s common mistake for fast growing organizations. Such way of work introduces too many dependencies as company grows and leads to increased level of formalization and control because in order to deliver solution you need a mix of people with various skills with 100% focus.

POD framework suggests to organize work around business offering and/or value creation by forming interdisciplinary units. PODs are autonomous and have full responsibility for delivering awesome customer (internal or external) experience.

This simple twist allows to reduce dependencies on a company level and manage operational dependencies among functions “inside” the POD. In addition it forces to transform typical functional units into teams who are experts in their field and must provide service for internal clients (e.g. API infrastructure, Load balancer as a service, Private cloud and etc.).
The interdisciplinary product development pods have members of all skills needed to complete particular tasks, which is obviously a great approach comparing to the siloed teams with management overhead on top. Typically component teams focus only on software development of their part, and leave other activities related to product development or self-service creation less attended (or not attendant at all): e.g. meeting your users, gathering feedback, adjusting to needs and etc.  

POD shifts your focus from activities related _only_ to software development towards user needs by extending software-development-only teams with additional skills required to deliver final solution for the identified user. Team’s composition can/should differ from POD to POD  i.e.: feature PODs can have people performing 2nd or 3d level client support.

All POD members are focused on meeting market and customer needs (by “market” and “customer” i both mean external or internal and use it for simplification), and not targeting its own goals which potentially can bring no value for the user.

The benefits are:

• rapid value delivery because of clear focus and multifunctional teams;
• reduced # of dependencies;
• partnership behaviour with other PODs;
• direct  communication and feedback from users.

Critical elements of this organization:

• Global company targets serve as alignment for all PODs;
• PODs follow and contribute to agreed common standards in the company which are typically owned by Service PODs: deployment, hiring, api first and etc.
• Scale out instead of Scale up. This thinking applies to all blocks: architecture, structure, process, …

p.s. Pod framework v 0.3 - https://docs.google.com/document/d/1abZlCX7oNQeW8VozW6ri70xqPp0xZikxe8emzqxZysQ/edit#heading=h.w2zmbnxsqc8w

Feedback is welcome. Feel free to add comments.