Network structure – 11 lessons learned

Posted on Leave a commentPosted in management

1. Autonomous & multifunctional teams

Having all necessary skills in one place allows you to have hyper performing teams able to handle complex tasks. This can be achieved if such environment is created for teams:

  • Ability to make decisions on a timely manner and with maximum return on value
  • Technical and organizational autonomy to deliver on demand
  • Focus on clearly defined area to avoid context switch
  • Possibility to acquire all required skillset to enable autonomy and reduce dependencies
  • Service oriented approach which brings value both internal and external

2. Value/Service delivery oriented teams

Main benefit of such setup is reduction of functional/component (which typically are valuable only in combination) dependencies because teams are forced to exchange valuable services with each other.

Important to keep in mind that it is still a system of mutually dependent elements. It means that it is crucial to operate with respect to the capacity of the teams that you are dependent on. Negative effect of sub-optimization is amplified by fast pace of autonomous network elements.

It requires to adjust behavior, and instead of putting all effort on performing local optimizations to advocate and strive for solving identified bottleneck in the whole structure.

One sample could be hiring. Instead of hiring into your area, hire where bottleneck is or even form a new missing entity. Such actions will optimize whole value delivery

3. Common target

Whole activity of a network must be aligned to a common target. If there is no common goal defined network structure will perform only slightly better comparing to conventional organization (where each function optimizes it’s behavior according their KPIs). Positive effect is driven by focus on value delivery for identified users.

Even if you do not utilize all benefits of network structure you at least will achieve following:

  • Clear cost structure: teams are organized around value delivery and 100% focused on a single purpose
  • Clear communication map: easy to understand who is covering which areas
  • Easier to notice not covered areas, dependencies and

You can make a decision on a strategic level in <10 minutes for a scale of 400 people by just looking at a couple of pages in confluence (or other team collaboration solution) without diving into complex excel files and diagrams.

4. Strive on being a team

It is important to take personal responsibility for every leader of network element and make an effort to act as a team. Team typically shares following characteristics as minimum (if compared to a group):

  • aligned goal,
  • optimizing the whole,
  • supporting

5. Fire fast

The only way to save the box of apples is to throw away rotten ones. By “rotten” in this context I mean:

  • not acting upon achieved agreements,
  • acting according own agenda,
  • not adapting behavior according raised expectations,
  • not learning.

6 Constraints

No system cannot operate without constraints. It is needed to eliminate entropy and to keep the focus of the whole. The most important constraint is common target.

Other constraints play key role in establishing stability because they set rules for communication between elements.

Includes, but not limited to: organizational level artifacts and deliverables, KPIs and/or Service Level Objectives, agreements, dependencies, set of internal services. Each element must expose following artifacts publicly available:

  • Purpose aligned with common target
  • List of stakeholders (clients and dependencies)
  • Service/Product catalog
  • Team structure
  • Roadmap
  • Business KPIs
  • SLOs and Non functional requirements
  • High-level architecture

7. Quality

Quality must never be opinion based. It must be measurable and agreed set of clearly defined metrics that are communicated to stakeholders, publicly visible and tracked in real-time.

There always must be a professional included in a team who understands what quality assurance as discipline means and knows all set of practices that can and should be applied at the right moment of product/team evolution.

Typical mistake is to measure quality with # of bugs. If your team relies mainly (or sometimes only) on this metric, it means there is no agreed quality definition in the team.

Things mentioned are important and beneficial for conventional structure, but vital for network structure because of service oriented approach.

8. Internal services/platforms are critical

It is critical to establish and properly staff internal service/platform teams as soon as possible. It will increase speed and efficiency of the rest of organization. Such internal services cannot be avoided and must be used across company.

It can be useful (time to market, lack of experience and etc.) to use 3d party vendors or build custom solution as a temporary decision while internal service is being developed.

9. “API”

This is foundation of network structure. Contexts must be separated by programming interfaces. It gives possibility to:

  • have autonomous teams,
  • control dependencies with other teams,
  • react faster to market needs due to proper technical decomposition,
  • apply the best technologies and tools for specific challenge,
  • reduce unnecessary communication and coordination (the most important!) among teams,
  • easily add more teams with increasing returns,
  • keep innovating and reduce unknown side effects due to smaller codebase.

10. Chaos in da house

Assumptions that things do not change and can be finalized are wrong. It applies both for work structure and technical solution.

Way of work. Network structure is dynamic as it consists of autonomous elements not fixed functions which can be changed/adjusted based on business needs.

Technical uncertainty. Capacity, stress and resilience tests are new practices that must be introduced and performed periodically. This is the only approach that will help to: ensure technical excellence, identify bottlenecks, visualize dependencies and ensure right level of automation in all teams.

11. Building an internal service/platforms is difficult

Because it requires to act differently (not typical for internal teams in conventional structure):

  • Identify users
  • Understand their problems
  • Build a solution for those problems (not ideal solution)
  • Deliver value as early as possible (typically pick to work on ideal solution)
  • Continuously work with users in gathering feedback, sharing knowledge, organizing meet-ups and etc. (the most difficult)

This is big behavioral shift from a conventional functional/component team that focuses only on development into a multifunctional team which spends a lot of time on pre and post development activities.

12. Resources that I was inspired by

Here is possible implementation of network structure – http://agilemindstorm.com/2016/03/16/network-structure-it-works/

It was inspired by following material:

Recent findings which show things are moving that direction:

Why team don’t work

Posted on Leave a commentPosted in management

Very good article about Teams performance by J. Richard Hackman

http://econ.au.dk/fileadmin/Economics_Business/Currently/Events/PhDFinance/Kauttu_Why-Teams-Dont-Work-by-J.-Richard-Hackman.pdf

Mistakes Managers Make

  1. Use a Team for Work That Is Better Done by Individuals
  2. Call the Performing Unit a Team but Really Manage Members as Individuals
  3. Fall Off the Authority Balance Beam
  4. Dismantle Existing Organizational Structures So That Teams Will Be Fully “Empowered”to Accomplish the Work
  5. Specify Challenging Team Objectives, but Skimp on Organizational Supports
  6. Assume That Members Already Have All the Skills They Need to Work Well as a Team

How teams are often formed:

There are two different strategies that managers use to implement work teams without upsetting the corporate applecart.

One is to try to capture the benefits of teamwork by relying mainly on rhetoric and training. Members are told that they are now in teams, team leaders are appointed, and everyone is sent off to get training in good team processes. It is easy to implement teams this way—neither organizational structures nor managers’ own behaviors need change. But such teams are more ephemeral than real, and mere changes in appearances rarely yield measurable improvements in organizational outcomes.

The second strategy is to form real teams—intact, performing units whose members share responsibility for some product or service—but to lay them atop existing organizational structures and systems. The rationale, as one manager told me, is to see how well they perform before making other organizational changes that could be hard to reverse.

This is exactly why network structure is suggested as preferred approach for complex and ambiguous tasks:

  • Teams oriented approach
  • Organizational structure must reflect value delivery, not work composition

Constraints On Effective Product Development

Posted on Leave a commentPosted in management

Organising yourself as a network of multi-dependent teams helps to solve following constraints and increase effectiveness of product development

Functional Teams

People from different functional areas must be a part of the same team to eliminate all possible “cross departments” activities

Toyota have long eliminated this constraint through their Obeya concept, and unique matrix structure.

Capacity of Bottlenecks

Often certain teams in the company can become a bottleneck as lots of others start to depend on them. Providing options for teams in different stages of development gives needed flexibility and possibility to act according the situation.

Delayed Decision Making 

Building structure around function silos and skills forces you to increase additional layers of coordination or start more projects which automatically leads to more communication points and less efficiency. additionally temporary nature of projects breaks ownership mindset. Organising around value forces you to:

  • think long term as there is no end, but continuous value delivery
  • focus on relevant problems, especially if options are given to others and they can abandon your service
  • build in ownership and quality as things will not be passed to someone else

 

What other constraints you face? Do you find these common?

Resources

  • http://www.organizeforcomplexity.com
  • https://medium.com/@flowchainsensei/constraints-on-effective-product-development-3b2684f5d1e2#.puz0ysspx
  • http://agilemindstorm.com/2016/03/16/network-structure-it-works/

#75 out of 100

Posted on Leave a commentPosted in management

Although i am not acting as Agile coach or trainer but surprisingly listed here – 100 Top Agile Blogs in 2015TOP 100

Happy and proud to be among great people of agile community. It will definitely encourage me to continue sharing my ideas and thoughts about how to organize work in a company to keep Agile mindset even when you grow from 20 to 600.

Posts that worth taking a look at:

Thank you for reading.

Network structure – it works

Posted on Leave 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.