Kloia employee handbook

Organization Examples

Ihtiyaca Gore Organization Yapilari

Elif Structure Design Example

https://docs.google.com/presentation/d/1_FZwLylF58iVzvhUmgXvw_mq8MlKQZT3/edit#slide=id.gd929230b39_0_144 (opens in a new tab)

Key Concepts For Our Organizational Design

Conway's Law:

Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.

Slowification, Amplification and Simplication:

Team Topologies:

1.Slowification

We slow things down and tackle problems in that environment. Slowification can be thought as the "bullet time" special effect in The Matrix where the main character slows or pauses time entirely, allowing them to dodge bullets. We slowify by decelerating out performance environment (e.g., slowing down the car in hazardous conditions) or finding slower-moving conditions in which we can build skill and understanding (e.g., the conditions in a driving school or Apollo 11 program simulation rooms).

2.Simplification

incrementalization-modularization-linearization

2a.Incrementalization: Incrementalization is iteratively designing, developing, testing and delivering in small increments instead of waterfall approach. So in our case we can apply this to our reorganization efforts.

Pilot Module: We can start out by defining a pilot module. Instead of attempting to restructure the entire DevOps division at once, we identify one bounded context/domain that can serve as a pilot for the new modular structure.
Sequential Transitions: We slowly transition teams sequentially Rather than transitioning all teams simultaneously to the new structure, we do it in phases.
Implement Structural Changes Iteratively: We just don't try to implement the full ideal end-state structure in one go but break it down into iterations. For example, we could start by just defining the domain boundaries and interaction models first. Then add stream-aligned teams in the second iteration, followed by establishing enabler/platform teams supporting them.

We identify bounded contexts/domains and revisit the potential domains we have like Cloud Transformation Services, Managed Cloud Services, SRE/Monitoring & Observability and Software Development etc. We validate and refine these bounded contexts through workshops like event storms and we run analysis of our existing team structure and responsibilities to map out core domain activities and deliverables.
We define domain boundaries and key capabilities/activities that fall within this domain. We look for areas where the domains may have interdependencies, shared models, or integration points and then explicitly map out these relationships between the domains.
We establish Interaction Models For the identified interdependencies. Will there be shared services used across domains? Are there clear supplier-consumer relationships between domains? Are there anticipated physical integration points?

Example steps for defining domain boundaries and interaction models

1.Identify Core Areas/Domains Based on the services we provide, for example the potential core domains can be:

Cloud Transformation (helping companies move to AWS cloud)
Managed Cloud Services (providing managed AWS services)
SRE/Monitoring (monitoring and observability for customer systems)
Software Development (building microservices/apps for customers)

The divisions above are not based on technical definitions but business domains which we create value stream for the clients. This is an important distinction!

2.Define Boundaries for each domain for example, for the Cloud Transformation domain:

Key activities: Migration planning, deployment, cutover, etc.
Core deliverables: Successful cloud migrations for customers
Language/models: Cloud migration strategies, landing zones, etc.

3.Map Domain Connections There will be connections between domains, like:

Cloud Transformation and Managed Services domains both utilize the SRE/Monitoring capabilities
Software Development relies on Managed Services for hosting

4.Establish Interaction Models Determine how domains will work together, like:

Cloud Transformation team requests SRE/Monitoring team for post-migration monitoring
Software Dev team deploys apps to environments provided by Managed Services

5.Assign Domain Owners Designate leaders for each domain, like a "Cloud Transformation Owner (Lead)", "SRE/Monitoring Owner (Lead)", etc.

6.Share Model Across Teams Review the identified domains, boundaries, connections, and owners with all teams to align.

2b.Modularization: With the center-out method, headquarters collect much information as they can get and push it to local operations. They delegate authority to local leaders to generate solution that work for ther uniuq situation. Then the center gaters local lessons learned and synthesizes them into sharable, collective wisdom. Center-out leadership increase the number of partitions of the whole system but decrease the complexity of the problem that needs to be solved. Moreover, each partition creates more, smaller coherent units therefore many more participants can be engaged simultaneously.

2c.Linearization: Linearization partitions problem-solving within sequential workflows by using four elements of Sequentialization, Standardization, Stabilization and Self-synchronization. This approach can be applied when defining domain boundaries and interaction models during our reorganization.

Here's how we can implement linearization:

Identify End-to-End Value Streams: For each core domain we have identified (Cloud Transformation, Managed Services, etc.), map out the full end-to-end value stream of activities required to deliver value to the customer in that domain.

Example: For Cloud Transformation, the value stream could be - Initiate Migration Project > Migration Planning & Design > Build Landing Zone > Application Migration > Cutover > Cloud Operations

Look for Handoffs and Interdependencies Within each value stream: identify points where work gets handed off between teams or depends on other domains/teams. These are the points of potential waste, delays, and lack of end-to-end accountability. Example: The Application Migration step likely requires handoffs between the Migration team and the Managed Services team provisioning the target environment.

Linearize Wherever Possible: The goal is to linearize the value stream by bringing the end-to-end activities and capabilities into a single, autonomous team as much as possible. This eliminates handoffs and allows for full life-cycle ownership. Example: You could have a "Cloud Migration Stream Team" that handles the entire value stream - from initial planning through to landing zone build, app migration, and cutover to cloud operations.

Establish Clear Responsibilities: Where we cannot fully linearize due to required Domain or Platform dependencies, we clearly define the interaction models and hand-off responsibilities between the teams involved.

Example: The Migration Stream Team may still depend on the SRE/Monitoring team for ongoing reliability practices post-migration. But responsibilities are clear.

Enable with Platforms/Enabler Teams: Any foundational capabilities or services required by the stream teams should be provided through Platform teams following the enabler-stream delegation model.

Example: A Cloud Platform team could provide self-service infrastructure and app deployment capabilities used by the Migration Stream teams.

By linearizing value streams into end-to-end teams wherever possible during the reorganization, we minimize handoffs, increase accountability, and put the customer experience first within each domain area.

Principles

Domain Driven Design: Designing teams and divisions around business domains not technical definitions
End-to-end ownership: Every service must be fully owned by a team with sufficient cognitive capacity to build and operate it. "Build it, run it, own it".
Reduce handoffs: Establishing multi-product teams organized around business-aligned domains versus old legacy systems
Limit cognitive load:: Limit the size of software, services, and products to the cognitive load that the teams can handle.
Agile System Design and Incrementalization: Iteratively designing, developing, testing and delivering in small increments
Loosely coupled architecture: A loosely coupled architecture is a software application development model wherein multiple components are connected with one another but are not heavily dependent on each other. Together, these components create a general network or system, despite each service being an independent entity created to perform a single task.

Minimize cognitive loads

A simple and quick way to assess cognitive load is to ask the team, in a non-judgmental way: “Do you feel like you’re effective and able to respond in a timely fashion to the work you are asked to do?” When measuring cognitive load, what we really care about is the domain complexity—how complex is the problem that we’re trying to solve with software?

Domain Complexity

A domain is a more largely applicable concept than software size. For example, running and evolving a toolchain to support continuous delivery typically requires a fair amount of tool integration and testing. Some automation code will be needed, but orders of magnitude less than the code needed for building a customer-facing application. Domains help us think across the board and use common heuristics. While there is no formula for cognitive load, we can assess the number and relative complexity (internal to the organization) of domains for which a given team is responsible.

Team Topologies Approach

Because those decisions are often made on an individual team basis, they lack consideration for important organization-wide factors, like technical and cultural maturity, organization size, scale of the software, engineering disciple, or inter-team dependencies. The result is team structures optimized for problems that are temporary or limited in scope, rather than adaptive to new problems over time.

Stream-Aligned Teams: A stream-aligned team is a team aligned to a single, valuable stream of work; this might be a single product or service, a single set of features, a single user journey, or a single user persona. The team is empowered to build and delivered customer or user value as quickly, safely, and independently as possible, without requiring hand-offs to other teams to perform the work.

Enabling Teams: An enabling team is composed of specialists in a given technical (or product) domain, and they help bridge this capability gap. Such teams cross-cut to the stream-aligned teams and have the required bandwidth to research, try out options, and make informed decisions on adequate tooling, practices, frameworks, and any of the ecosystem choices around the application stack.

Complicated-subsystem Teams: A complicated-subsystem team is responsible for building and maintaining a part of the system that depends heavily on specialist knowledge, to the extent that most team members must be specialists in that area of knowledge in order to understand and make changes to the subsystem.

Platform Teams: The purpose of a platform team is to enable stream-aligned teams to deliver work with substantial autonomy. The stream-aligned team maintains full ownership of building, running, and fixing their application in production. The platform team provides internal services to reduce the cognitive load that would be required from stream-aligned teams to develop these underlying services.

How To Apply This Methodology

1. Identify Streams: We start by identifying the different streams or value streams within kloia. A stream represents a workflow or set of activities we deliver value to customers. For example in our case some streams can be identified as Transformation, Cloud Migration and SRE Enablement.

2. Create Team Types: Based on the streams, we create different team types. Example:

2a. Stream-aligned Team: Dedicated teams responsible for a specific stream, e.g., Cloud Migration Team, Integration Team.

2b. Enabling Team: Teams that provide specialized skills or services to stream-aligned teams, e.g., Security Team, Quality Assurance Team etc.

2c. Complicated Subsystem Team: Teams responsible for complex components or subsystems used across multiple streams, e.g., AWS Platform Team, DevOps Platform Tooling team, CI/CD Team Platform Team.

2d. Platform Team: Teams responsible for maintaining and evolving the core platforms or services used by other teams, e.g., DevOps Platform Team.

3. Define Team Responsibilities: We clearly define the responsibilities and areas of ownership for each team type. This will help reduce overlaps, ensure clear accountability, and foster collaboration between teams.

4. Establish Team Interactions: We define how different team types should interact and collaborate with each other. For example, stream-aligned teams might "consume" services from enabling teams or platform teams, while complicated subsystem teams might provide consultancy to stream-aligned teams.

Align Teams with Streams: Align our existing departments or teams with the identified streams and team types. This might involve restructuring or reorganizing some teams to better align with the Team Topologies principles.

Implement Team Topologies Patterns: Incorporate other Team Topologies patterns, such as team cognitive load measures, team anti-patterns, and team interaction modes, to optimize team structures and collaboration further.

Foster Collaboration and Communication: Establish mechanisms for effective collaboration and communication between teams, such as regular cross-team meetings, shared backlogs, and communication channels.

Continuous Improvement: Regularly review and adapt our organizational structure based on feedback, changing business needs, and evolving best practices.

Let's Discuss

What do you think about our new approach designing the kloia organization structure around business domains?
Do you think center out is the best method for distributing operations?
How do you feel about new team types defined with team topologies approach?
How can we apply lean management and continuous delivery methods more effectively in our workflows?
HOw can we apply loosely coupled architecture better within the organization?

Reference

Books:

Articles:

By Kloians 3.People of Kloia