Network structure - confirmation bias

Posted on Leave a commentPosted in management, quick thoughts

I’ve recently read the book about Black Swan theory. If you are going to read comments about this book you will find it very controversial. But i would recommend to read it anyway as it suggest slightly different view on complexity and our desire to rationalize everything (especially when it’s already happened).

I want to share notes from the book about the _complexity_ and how it maps to POD framework (or any other network organisation) we are starting to apply in a company.

Even though it might look like a confirmation bias why network structure is much better than hierarchical structure. But f*** it, i treat it as thinking tool and mental exercise.

When organisation grows bigger the complexity increases and as the result more risks become hidden and one of the main ideas is to bring them on the surface.

Definition of Complexity from the book:

What is a complex system? It’s a system where elements are strongly related in time (element depends on its own historical transformations), horizontally (elements are mutually dependent) and in diagonal (A depends on a history of B)

For me it’s a perfect definition of a product development team that works on a complex solution with many offerings. So here are some suggestions on how to manage risks (or make them visible).


Book: Management shouldn’t get bonuses based on short-term targets (1 year). All decisions must be evaluated from a long-term perspective.

Network structure: when you organize yourself around value creation you must think in a long-term perspective because you need to evaluate following things: who will use it? is it a big group? do they really need that? when do they need that? who are competitors? and etc.

Avoid optimization

Book: It leads to narrow specialization and system becomes too much dependant on exact planning and you cannot predict/foresee all options. It leads to more hidden risks within the system.

Network structure: each cell in a network structure has the authority and right level of autonomy to solve problems in their own way to avoid centralization when it’s not needed.

Prediction of distant events

Book: It’s impossible to predict distant events (and their impact) in a complex system. Most predictions are based on historical failures, but it doesn’t explain the nature of next one as we don’t know all inputs and dependency (planning tends to simplify things).

Network structure: i don’t like planning. i believe that right level of transparency instead of strategic planning solves the problem much better. Better to have right information at any moment in the future in order to make right decisions than try to predict decisions based on information you have now.

Weak things

Book: Weak things must break while they are small as it reduces the impact of the event.

Network structure: cells are created around value and it must be “closed” if it doesn’t prove it works otherwise it must split as outgrows certain size or tries to solve very diverse set of problems, which results in a huge loss of focus, slow value delivery, possible queues and etc.

That’s it.

p.s. If interested you can read a bit more about the theory and the author please visit Wikipedia.

Black Swan Theory -

Nassim Nicholas Taleb -

Network structure - first Q&A

Posted on 1 CommentPosted in management

2011.06.27_organizational_charts-600x584Previous 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.

Link to a v0.2 document. Feel free to comment.

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

  1. 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.
  1. 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, Scrum, 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.

Network structure

Posted on 6 CommentsPosted in management

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:

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…


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 -

Feedback is welcome. Feel free to add comments.

5 steps for any meeting

Posted on Leave a commentPosted in management, quick thoughts

This works with one precondition - If it’s not going to be a one way presentation and you want to have constructive discussion, don’t make it obligatory, invite only those who wants to contribute. There are different ways to achieve that and approach must fit your company culture.

  • Set the stage of the meeting
    • Ask people to say several words. It can be names, how the feel or anything else. This simple trick involves people into a conversation. Or it can be just a simple question at the start of the meeting
    • When people don’t speak early in a meeting, they may not contribute later at all and may not buy into team’s insights and decisions
    • Set working agreements upfront
  • Gather data
    • Without common picture, individuals tend to verify their own opinions and believes.
    • “F word” - feelings. It’s not easy to talk about feelings for engineers, but questions can be put in different way, e.g. When were you excited/mad/sad?
  • Get insights
    • Ask why. Looks at causes and effects. Think together how to change/improve.
  • Decide what to do
    • Pick best action that brings most value with least effort
    • Avoid do nothing retrospectives
  • Close
    • Decide what and how to document and formulate next steps

p.s. this model proved itself working perfectly once again when we were setting up “POD framework”

Group size

Posted on Leave a commentPosted in management

Should we consider this when forming a team?

The size of social groups of people in pre-industrial societies, especially hunters/gatherers. They found several common sizes:

  1. An “inner circle” of about three to five very close friends or family members
  2. A “sympathy group” of 12 to 15 close friends who care about each other’s fate
  3. A “hunting group” of 30 to 50 colleagues who cooperate to accomplish a task
  4. A “clan” of 150 people who maintain stable interpersonal relationships
  5. A “tribe” of about 500 to 2,500 people who speak the same