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:

Good and Bad tech leads

Posted on 1 CommentPosted in quick thoughts

Bad tech leads take the high-profile tasks for themselves and are motivated by being able to take credit for doing the work. They optimize locally, keeping team members working on projects that benefit the team at the expense of the engineering organization at large.

Good tech leads listen and encourage debate. When the team is unable to resolve a debate, they describe a process or framework of thinking that would help them resolve it. They don’t enter discussions with foregone conclusions, and always allow themselves to be persuaded by great ideas.

Leave developers alone

Posted on Leave a commentPosted in management

If you are working in a product development company most probably you are doing something wrong if start changes and improvements in a technology departments/teams. Little by little i start to understand that.

Leave developers alone, let them do the work they love and focus instead on the flow and other challenges which require attention and might be missed:

  • Understand and communicate the essence of the product
  • Identify business value and stakeholders’ needs and make sure this is delivered regularly
  • Clarify, negotiate and communicate the important priorities and dates
  • Balance the needs
  • Work effectively with development team(s)
  • Identify, track and address things blocking progress
  • Gather and spread information

Developers can help with all these activities, but most probably they don’t love this type of work. That is why they are not managing the product and don’t want to act as Product Owner or Product Manager.

Value structure

Posted on Leave a commentPosted in management

Forget old company structure – it doesn’t support growth! By the way did you notice that clients, customers or users are never represented in organizational structure? It is like company exists for itself, but not for the clients…

Inspired by Niels Pflaeging ideas was writing some posts about what type of change we are introducing in my company. Any change is not an easy thing to do as different people need different arguments. Analogy with Scrum framework helps to explain these ideas to those practicing Scrum. I must say this comparison is so obvious that you get buy-in instantly.

But there are other people in the company. I found this article about product lines which basically is orientation towards value but has this smell of control and hierarchy. But even with control mindset and orientation towards value creation brings such benefits:

  • Improved productivity by as much as 10x
  • Increased quality by as much as 10x
  • Decreased cost by as much as 60%
  • Decreased labor needs by as much as 87%
  • Decreased time to market (to field, to launch) by as much as 98%
  • Ability to move into new markets in months, not years

Have no idea how precise are these numbers and how they were collected, but i think this can help to sell it to top management. What do you think?

p.s. posts that i mentioned above:

  • Org. design: value structure Highlights from my presentation where i try to explain why do we need value oriented structure in the company

Hints by Niccolo Machiavelli: outsource

Posted on Leave a commentPosted in management

….Army that defends the country can be of three types: own, allied, hired or mixed. Allied and hired armies are useless and dangerous as you can’t use them as solid foundation, such armies can be as dangerous as enemy during a war – they will use your resources during a peacetime, but will not sacrifice their lives in times of danger.

Allied armies are dangerous as stronger partner will use the victory for their benefit, not yours….

keepcalm_zed
Of course it’s not about war, but about building strong and successful company. Even though i made several points for myself keeping in mind context of a fast growing company working on a complex product.

  • Keep unique and core knowledge or experience inside the company
  • Spend effort on educating and training your team
  • “Hide” core functionality behind APIs
  • Outsource repetitive, mechanic, support or experimental activities that your team is not interested in. Give your team time to focus on core things and building API