Previous post (Network Structure – Why?) raised some questions among people i distributed this draft to. Basically it was about how exactly it could work in a real world? Some people also indicated that you need to have lots of leaders in order this would work… I guess it’s true.

It’s too many POD roles for me

When POD is starting all roles can be merged in a single person (in various situations there might be a need to get resources to kick it off or set initial plan for early value delivery and etc.).

And when value is proven (customers and stakeholders understand and support it) it most probably will start growing as the result it might be difficult for one person to have all required skills and perform all necessary activities (product management, transparency, communication with others, hiring, technical excellence, education and etc.)

So POD is just a cross-functional software development team, isn’t it?

No, not at all. These are not cross-functional software development teams – these are cross-functional value delivery (or product development) teams. As you know product development is much broader activity than software development and involves other practices that must be implemented and skills that might be missing in development team only. POD is responsible for meeting consumers needs and make sure their experience is awesome.

If it’s platform POD technical “sales” skills are needed to explain how deliverables should be used by other developers or PODs. If it’s closer to market and delivers directly to end users – people involved in marketing and sales and client support should be involved on a daily basis.

How cooperation among PODs will work and why?

Motivation to cooperate depends on business model – what company is doing

In Adform case it’s the same product we are working on and all PODs are mutually dependent and are more valuable together rather than competing alone in a niche market.

In a project based companies where PODs might work on very different types of projects or business domains. Reason for collaboration might be completely different (e.g. knowledge sharing on same technology and etc.)

Who is responsible for metrics and measurement?

Public metrics and measurement are key part of Transparency. POD Lead depending on his pod context must define, track, adjust them and make decisions based on them. Why POD Lead?

Because he has an intent to create something or solve a problem or improve clients lives and etc and he kicks off pod (you cannot kick off something if you don’t believe into that.) and must want and know about the progress first of all.

POD Keeper seems to be just an SM

It depends on a POD size. In a small team (< 5) SM can perfectly perform this role. When POD grows roles responsibilities might change and become broader.

e.g. following analogy comes to my mind that might explain:

POD Lead – CEO (knows what to do); POD Keeper – CTO (knows how to do that).

Normally a lead will try to find someone who will help him to build something as it’s very difficult to alone.

Freedom, Command and Control, Scum, Kanban are tools that wise people will choose at the right moment of POD evolution.

Who “closes” the POD?

POD Lead, Keeper and Sponsor based on metrics and deliverables must be able to make a decision when it’s not reasonable to spend effort here.

Share this:

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

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 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 around functions when organisation grows, but POD framework suggests to organize around the consumer forming interdisciplinary product development units. PODs are responsible and autonomous to deliver on metrics indicative of awesome customer experiences.

The interdisciplinary product development units have members of all skills needed to complete particular tasks, which is obviously a great approach comparing to the component teams. Normally component teams focus only on software development, and leave other parts of product development (pre-development and post-development stages) less attended.

POD shifts focus from software development only. Focus on market and customer needs extend development teams with additional skills needed to deliver value to the identified client (differs from POD to POD i.e.: feature PODs can have client support <add more if needed> people).

All POD members are focused on meeting market and customer needs (external or internal), and not reaching its own goals that do not always relate to end-user value.

The benefits of it are rapid value delivery due to clear understanding of what and why is valuable and for whom, reduced dependencies, partnership behaviour and increased product quality due to dedicated focus and straightforward communication and feedback. Communication between PODs is based on partnership and value delivery for Company (e.g. Adform).

Share this:

Cost pressure and growth pressure can be harmful in the same way. Both these things have a tendency to push you towards efficiency and centralization. Avoid that. It kills innovation. Decentralize. Main question is how to do it, but not if it needs to be done.

We are trying to do it in our way. Why and How can be found in a presentation – https://prezi.com/5fznv3zxvnlt/network-structure/