Technology Decision Delegation

In order for a technology organization to deliver products in support of a company’s mission, decisions about which technology to use and how to use it must be made regularly. Creating a strategy for making these decisions is a problem for many organizations.

For small organizations, decisions are often made by seeking consensus through group discussion. As organizations grow, new strategies have to be adopted. One common, though flawed, strategy is for those early members to retain decision-making authority for the entire organization. This strategy creates a decision-making bottleneck for the company which leads to a variety of undesirable behaviors.

The engineering team at Pluralsight is comprised of skilled and experienced professionals. We value intentionality and explicitness in our communication and decision making. As an organiztion, we embrace the principle of subsidiarity.

Subsidiarity

Matters ought to be handled by the smallest, lowest, or least-centralized competent authority.

This means that the technology leadership team provides a central vision and direction, and we expect our colleagues to behave as competent professionals who are capable of making good technical decisions for the organization as they execute on the vision.

One of the techniques we use to share our vision is a Technology Radar which categorizes technology decisions and provides guidance in making decisions that have a systemic impact. We evolve our tech radar over time using the RAPID decision making framework.

The Technology Radar is not all-inclusive however. For this reason, we have explored other ways to honor our principles while providing the clarity about decision making necessary for teams to execute effectively. What we found is the 7 Levels of Delegation framework in the Managing for Happiness book by Jurgen Appelo.

This framework breaks down decisions into 7 categories based on how central vs distributed the decisions are. As we apply it to our technology decisions, the levels look like this:

In order to train our internal heuristics about which decisions should be made at each level, we went through an exercise with each of our development teams in which we categorized many types of technology decisions they make. We have compiled an incomplete, but representative, list of these and present them here so that everyone can understand who has decision making authority, how those decisions ought to be made, and who is ultimately responsible for the outcome of the decisions.

Architecture Team Decisions

Tell

The architecture team makes a decision for the product development teams and may explain the motivation. Opening a discussion about the decision is neither desired nor assumed.

• Deciding that all production code must be reviewed by 2 or more people.

Sell

The architecture team makes a decision for the organization then tries to convince the members of the product development teams that it is the right choice and will help them feel involved.

• Selecting and defining the architecture for the system of Pluralsight products.
• Defining a menu of messaging patterns for use between Bounded Contexts.
• Selecting a messaging platform or message broker for communication between Bounded Contexts.

Consult

The architecture team will ask for input first, which will be considered before making a decision that respects the product teams’ opinions.

• Updating the menu of approved programming languages for production code.
• Updating the menu of data stores.
• Selecting the order in which system level technical debt is addressed.
• Adding a previously unused service provided by AWS into the menu.

Agree

The architecture team will enter into a discussion with the product development team(s) and reach a decision as a group.

• Selecting a paid shared library.
• Selecting a free 3rd party service.
• Selecting a paid 3rd party service.
• Deciding when and how to split a Bounded Context.
• Deciding when and how to combine Bounded Contexts.
• Deciding to publish a new Customer-facing API.
• Integrating Bounded Contexts at the database layer.

Advise

The product development team will request the advice of the architecture team prior to making a decision.

• Selecting a messaging pattern from the existing menu for a specific integration between Bounded Contexts.
• Defining the boundary between Bounded Contexts.
• Deciding when and how to split a team.
• Deciding when and how to combine teams.
• Deciding to publish a new message.
• Deciding to publish a new System-facing API.

Inquire

The product development team will make a decision and inform the architecture team what was decided and may be asked to share the process and information that lead to this choice.

• Defining the architecture for a single Bounded Context.
• Selecting a method of integrating components within a Bounded Context.
• Specify the shape or contents of a message body.
• Selecting a programming language for production code from the menu.
• Selecting a data store from the menu.
• Deciding to create and publish a shared library.
• Deciding to subscribe to a new message.
• Deciding to consume a new System-facing API.
• Selecting a tech lead.
• Integrating Bounded Contexts at the UI layer (for example with Web Components).

Delegate

The product development team will make the decision and no notification, presentation, nor documentation is required by the architecture team.

• Defining the architecture for a single application.
• Defining the architecture for a single web site or web API.
• Defining the architecture for a single service or daemon.
• Selecting a messaging library to integrate with the messaging bus/broker.
• Selecting a feature to build.
• Selecting an open source shared library (from nuget/npm/etc).
• Selecting a code editor or IDE.
• Deciding which practice to use for reviewing production code.
• Starting or stopping a development practice.
• Introducing a client-side JavaScript library.
• Selecting and enforcing a source code formatting or naming convention.
• Addressing technical debt within a Bounded Context.
• Selecting a testing tool or framework.
• Designing a domain model for a Bounded Context.
• Designing a domain model for an application.
• Designing a database schema.
• Deciding to publish a new Bounded-Context-facing API.

Operations Team Decisions

Tell

The operations team makes a decision for the product development teams and may explain the motivation. Opening a discussion about the decision is neither desired nor assumed.

• Selecting a hosting provider for production systems.
• Network/VPC location of production systems (data stores, services, execution hosts et al).
• Required use of MFA on particular systems.
• Required set of tags to utilize on cloud objects.
• Selecting a paid on-call/alerting service provider.

Sell

The operations team makes a decision for the organization then tries to convince the members of the product development teams that it is the right choice and will help them feel involved.

• Selecting mandatory items for the production implementation checklist.
• Selecting a version control hosting provider.
• Selecting a desired state configuration tool for provisioning and managing servers.
• Selecting a system log format, contents, and aggregation service.
• Updating the menu of operating systems approved for production applications.

Consult

The operations team will ask for input first, which will be considered before making a decision that respects the product teams’ opinions.

• Selecting a continuous integration/build service.
• Updating the menu of deployment tools.
• Updating the menu of data stores.
• Adding a previously unused service provided by AWS into the menu.

Agree

The operations team will enter into a discussion with the product development team(s) and reach a decision as a group.

• Backup strategies for each BC.

Advise

The product development team will request the advice of the operations team prior to making a decision.

• Monitoring strategy for product development owned hosts/services.
• Alerting strategy for product development owned hosts/services.

Inquire

The product development team will make a decision and inform the operations team what was decided and may be asked to share the process and information that lead to this choice.

• Selecting an application server operating system from the menu.
• Selecting a programming language for test code and configuring build agents to run it.
• Selecting a deployment tool from the menu.
• Cassandra schema modeling.

Delegate

The product development team will make the decision and no notification, documentation, nor documentation is required by the operations team.

• Determining application log format, contents, and aggregation service.
• Selecting a web application framework

Security Team Decisions

Tell

The security team makes a decision for the product development teams and may explain the motivation. Opening a discussion about the decision is neither desired nor assumed.

• Selecting security vulnerability scanning services and penetration testing providers.
• Actions to take during a breach or major security incident.

Sell

The security team makes a decision for the organization then tries to convince the members of the product development teams that it is the right choice and will help them feel involved.

• Selecting mandatory security items for the production implementation checklist.
• Selecting industry security standards the business will comply with (i.e. ISO 27001/2, PCI, CIS, NIST 800, etc.).

Consult

The security team will ask for input first, which will be considered before making a decision that respects the product teams’ opinions.

• Categorizing security risks and vulnerabilities.
• Cryptographic standards and strategies for sensitive data in-transit.
• Cryptographic standards and strategies for sensitive data at rest.

Agree

The security team will enter into a discussion with the product development team(s) and reach a decision as a group.

• Required annual security specific development training.
• Security monitoring strategy for BC hosts/services.
• Security alerting strategy for BC hosts/services.

Advise

The product development team will request the advice of the security team prior to making a decision.

• How to implement specific security standard controls.

Inquire

The product development team will make a decision and inform the security team what was decided and may be asked to share the process and information that lead to this choice.

• Determine technology specific configuration hardening techniques.
• Determine how to securely handle, process, and store authn/z tokens or credentials.

Delegate

The product development team will make the decision and no notification, documentation, nor documentation is required by the security team.

• Selecting a process to ensure secure coding practices are used in development.
• Selecting security tools or methods to review code before it’s committed to corporate repositories.

Execute with increased clarity

By putting in place a decision making framework, we are able to unleash the power of our development teams. There is no need for excessive meetings to make technology choices, and our teams don’t hide their choices with the intention of seeking forgiveness after the implementation is complete.