Tag: agile

Network structure - it works

Posted on asdasd asdasdLeave a commentPosted in management

It was a long journey of trying to understand what organisational structure is best for dynamic growth, experiments, agility and change.

Simple conclusion that i came up for myself - it works! And it is the best way to grow up to an organization to a scale of 600 people at least. Reasons behind are simple - it allows you to scale fast naturally and have built-in flexibility in the structure to a constant change. Obviously there are challenges which you have to overcome.

TOP 7 Challenges

  1. Flexible structure is not possible if you want to keep technical foundation monolithic. Devops and Service Oriented Architecture is a must use practices otherwise organization will not be able to adjust to changing business demand fast enough
  2. Easy to fallback to local optimizations and thinking that structure is something permanent
    • POD Leads and Keepers start to maintain status quo rather than to advocate the change as structure must be adjusted according new findings, growing number of people, speed of delivery and many other things that pop up during the journey
    • Extreme sense of ownership can lead to certain local optimizations instead of seeking global improvement
  3. It’s very important to define common artifacts for PODs as soon as possible so everybody knows what to expect and how to work. You can start from something simple first and grow it naturally according the needs
  4. Pod sponsor role is extremely critical in order to achieve alignment and solve challenges outside the scope of the POD or priority conflicts
    • Especially for service pods which are often understaffed and business value is indirect, but high expectations are formed by the community
    • Pod sponsor is an important contributor to network orchestration
  5. Transparency is key, especially regarding speed of delivery and commitments
  6. Behavior and mindset is much more important than experience as new structure depends a lot on readiness to change and constant learning
  7. Change and adoption core group must be full-time activity and include decision makers (often C-level)
    • Plays leading role in network orchestration
    • Solves operational challenges together with leaders

But what you get instead:

  • you know value creation chain of your company and make dependencies visible
  • people are committed and motivated as they are the owners of what they do and decision making is delegated to them
  • problems are transparent to everyone who is looking for information and you can act upon them

Updated document with our experience - POD framework v.03, comparing to previous version you will find:

  • Description of deliverables and artifacts that can be used as a starting point of your journey
  • Better description of roles to handle expectations
  • Description of how roles work should together
  • Challenges that you must prepare for

If you have experience organizing work as a network of autonomous teams, I would love to hear your insights, ideas and experience.

Question on errors and randomness?

Posted on asdasd asdasdLeave a commentPosted in management

Is it possible to build an organisation which benefits from uncertainty, errors and randomness?

reality

  • How small should be the teams? 
  • What should be minimum process?
  • What is the level of centralisation/decentralisation?
  • How often achieved agreements must be reviewed?
  • What behaviour is needed?
  • What is the ratio between explicit and self-discipline?
  • What is the level of autonomy?
  • Can growth be the target?
  • Should it reflect value delivery?
  • Should org. look different depending on the context?
  • Should unstable be new stable?

Those are curse words for any member in a company. Often companies are designed as if for any non-repetitive task it is exactly known what is going to happen and what is the most efficient way to do that.

The “science” in the science of …

Posted on asdasd asdasdLeave a commentPosted in management

Often notice that people tend to be “black and white” when talking about practices in any field, let it be management, design, development or whatever… e.g. go completely scientific and measure everything and be very structured or become completely ad-hoc and reactive.

contrast

Of course it’s an option to work in a binary way, but in my opinion it is not necessarily the best way to go while facing complex problem. You must have various “tools” in your toolbox and be creative in applying them depending on a situation or context.

As a confirmation for myself I’ve stumbled upon an article  recently which covers exactly the same topic - http://www.jnd.org/dn.mss/the_science_in_the.html

So, can design be a science? Sometimes yes, sometimes no. Can it be empirically based, evidence driven? Yes. Will it have to reply on intuition and the creativity of individual designers? Sometimes, yes.

Network structure

Posted on asdasd asdasd6 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…

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.