Tiering projects

Introduction

In software development organizations, especially those managing multiple projects or repositories, it's essential to understand how to prioritize and organize work. Tiering projects provides a framework for making strategic decisions about where to invest engineering effort, how to manage technical debt, and where to focus quality improvements.

There are multiple approaches to tiering projects, each offering different perspectives on prioritization: dependency order, downstream impact, value, and development experience. These approaches are complementary and can be used together to create a comprehensive understanding of your project portfolio.

Tiering by Dependency Order

Dependency order tiering organizes projects based on their position in the dependency graph. Projects are classified from lowest-level (no dependencies on internal projects) to highest-level (depends on many internal projects).

Characteristics

• Tier 0 (Foundation): Projects with no internal dependencies, only external libraries
• Tier 1 (Core): Projects that depend only on Tier 0 projects
• Tier N: Projects that depend on Tier N-1 (or lower) projects
• Top Tier: Applications and executables that consume the entire stack

Benefits

• Clearly identifies foundational components that require higher stability
• Helps prevent circular dependencies and maintain clean architecture
• Makes build order and deployment dependencies explicit
• Identifies which projects need stronger versioning and compatibility guarantees

Application

Lower-tier projects typically require stricter breaking change policies, more comprehensive testing, and careful versioning since changes ripple upward through the dependency chain. Higher-tier projects have more flexibility for rapid iteration.

Tiering by Downstream Impact

Downstream impact tiering categorizes projects based on how many other projects depend on them. This is the inverse perspective of dependency order, focusing on the blast radius of changes.

Characteristics

• High Impact: Projects consumed by many downstream projects
• Medium Impact: Projects consumed by several downstream projects
• Low Impact: Projects consumed by few or no downstream projects

Benefits

• Identifies where bugs or breaking changes will have the widest effect
• Helps prioritize where to invest in quality, testing, and documentation
• Highlights projects that need stronger API design and backward compatibility
• Informs risk assessment for planned changes

Application

High-impact projects deserve greater scrutiny in code reviews, more extensive automated testing, and careful consideration of API evolution. They may also be candidates for formal deprecation policies and migration guides when changes are necessary. Low-impact projects can tolerate more experimentation and rapid iteration.

Tiering by Value

Value-based tiering classifies projects according to their business or organizational value. This approach is less technical and more strategic, focusing on the return on investment for engineering effort.

Characteristics

• Strategic: Projects critical to core business capabilities or competitive advantage
• Important: Projects that support key functionality but aren't differentiators
• Utility: Projects that provide supporting functionality or convenience
• Experimental: Projects exploring new capabilities or technologies

Benefits

• Aligns technical decisions with business priorities
• Helps allocate scarce resources (senior developers, security reviews, etc.)
• Identifies candidates for sunsetting or open sourcing
• Provides context for making trade-offs between quality and speed

Application

Strategic projects warrant ongoing investment in modernization, performance optimization, and feature development. Utility projects might be candidates for replacement with third-party solutions or community-maintained alternatives. Experimental projects need clear success criteria and exit strategies.

Tiering by Development Experience and Build Support

Development experience and build support tiering recognizes that different projects require different levels of developer tooling, build infrastructure, and support systems. This perspective focuses on the operational aspects of maintaining and evolving projects.

Characteristics

• Premium Support: Projects with dedicated build pipelines, comprehensive local development tooling, automated testing infrastructure, and dedicated support teams
• Standard Support: Projects with standard CI/CD pipelines, documented setup procedures, and shared team support
• Basic Support: Projects with minimal build automation, basic documentation, and community-based support
• Self-Service: Projects where developers are expected to figure out setup and builds independently

Benefits

• Optimizes resource allocation for build infrastructure and tooling investments
• Sets clear expectations for developers about available support and tooling
• Identifies projects that may need developer experience improvements to attract contributors
• Helps prioritize investments in build system modernization and automation
• Reduces onboarding friction by making support levels explicit

Application

Premium support projects might include features like one-click local development setup, pre-commit hooks, comprehensive build validation, automated dependency updates, and dedicated Slack channels or support rotations. Standard support projects have documented README files, CI/CD for main branches, and team-based support. Basic and self-service projects rely more heavily on developer initiative and may accept longer feedback cycles.

Considerations for Build Infrastructure

• Build agents: Premium tiers might use dedicated, high-performance build agents while basic tiers share general-purpose agents
• Caching strategies: Higher tiers benefit from aggressive caching and incremental builds to speed up development cycles
• Local environment support: Premium tiers may include containerized development environments, dev containers, or infrastructure-as-code for local setups
• Monitoring and alerting: Higher tiers warrant build health dashboards and proactive alerting for failures
• Artifact management: Premium tiers might publish to multiple registries with symbol servers and debug packages

Developer Experience Indicators

• Time to first build: How long from cloning to successfully building the project
• Build feedback time: How quickly developers get CI/CD results
• Documentation quality: Completeness of setup guides, architecture docs, and troubleshooting resources
• Tooling maturity: Availability of IDE extensions, code generators, test runners, and debugging tools
• Support responsiveness: Expected time to get help with build or development issues

Strategic Use of Tiering: Centralizing Build Infrastructure

Beyond classification, tiering can be used architecturally to dramatically reduce maintenance overhead across large project portfolios. By creating higher-tier repositories that consolidate build workflows, reusable actions, and tooling scripts, organizations can achieve massive efficiency gains.

The Consolidation Pattern

In this pattern, top-tier repositories exist specifically to provide shared build infrastructure that lower-tier projects consume. Instead of each project maintaining its own build toolchain, workflow definitions, and scripts, they reference centralized, versioned build infrastructure from upstream repositories.

The Maintenance Mathematics

Consider an organization with 100 repositories, each depending on 10 different build-related packages or tools (build engines, linters, formatters, test frameworks, etc.):

• Without consolidation: Each of the 100 repositories must update all 10 packages independently. Total updates required: 100 repositories × 10 packages = 1,000 updates
• With consolidation: One top-tier repository maintains the 10 packages. Each of the 100 lower-tier repositories updates their reference to the consolidated infrastructure once per release cycle. Total updates required: 10 packages (in consolidation repo) + 100 repository references = 110 updates

This represents a 90% reduction in maintenance effort (from 1,000 to 110 updates). The savings compound with monthly or quarterly release cycles and as the number of repositories or tooling dependencies grows.

Implementation Examples

• Consolidated workflow repository: A top-tier repo containing reusable GitHub Actions workflows, Azure DevOps pipeline templates, or Jenkins shared libraries. Lower-tier projects reference these via workflow includes or template imports.
• Build script packages: PowerShell modules, npm packages, or NuGet packages containing common build scripts (versioning, artifact publishing, code signing). Projects reference a specific version and only update when upgrading to a new release of the consolidated tooling.
• Docker base images: Top-tier repositories maintain standardized build environment images with all required tooling pre-installed. Lower-tier projects use these images, inheriting all toolchain updates automatically or on-demand.
• Composite actions: Reusable GitHub Action composites or Azure DevOps task groups that encapsulate multi-step build operations. Updates to the composite propagate to all consumers.

Release and Update Strategy

• Versioned releases: The consolidated infrastructure repository publishes semantic-versioned releases (e.g., monthly or quarterly)
• Controlled adoption: Lower-tier projects can choose when to adopt new infrastructure versions, allowing testing and validation
• Automated notifications: Dependabot, Renovate, or similar tools can automatically create PRs in downstream repos when new infrastructure versions are available
• Breaking change management: Major version bumps signal breaking changes, allowing projects to plan migrations deliberately

Benefits Beyond Maintenance Reduction

• Consistency: All projects use the same build patterns, making it easier for developers to move between projects
• Best practices propagation: Security improvements, performance optimizations, and bug fixes in build infrastructure automatically benefit all consumers
• Easier compliance: Centralized control makes it simpler to enforce organizational policies (code signing, security scanning, artifact retention)
• Knowledge centralization: Build expertise is concentrated in one place rather than scattered across hundreds of repositories
• Onboarding acceleration: New projects can adopt proven build infrastructure immediately rather than reinventing solutions

Challenges and Mitigations

• Challenge: Single point of failure if consolidated infrastructure has bugs
  Mitigation: Thorough testing of infrastructure changes, canary deployments to subset of projects
• Challenge: One size doesn't fit all project types
  Mitigation: Provide multiple workflow templates or configurable parameters for different scenarios
• Challenge: Upgrade coordination across many projects
  Mitigation: Automation tools for bulk updates, clear communication of changes, gradual rollout windows
• Challenge: Governance and ownership of shared infrastructure
  Mitigation: Clear ownership model, RFC process for major changes, representatives from consuming teams

Combining Tiering Approaches

The most effective project management strategies use all tiering approaches together. A project that is both high-impact and strategic demands different treatment than a low-impact utility project, even if they're at similar dependency tiers. Similarly, development experience requirements should align with the project's importance and usage patterns.

Example Combinations

• Low dependency tier + High impact + Strategic + Premium support: Foundation libraries that are business-critical. Require exceptional quality standards, comprehensive testing, careful evolution, and excellent developer experience with fast build times and comprehensive tooling.
• High dependency tier + Low impact + Utility + Basic support: Internal tools or applications used by small teams. Can iterate rapidly with minimal process and self-service build infrastructure.
• Medium tier + Medium impact + Experimental + Standard support: New features or capabilities being piloted. Balance innovation with stability of dependencies, with sufficient build automation to validate ideas quickly.
• Low tier + High impact + Important + Premium support: Shared infrastructure components. Need robust build pipelines, excellent documentation, and responsive support to prevent blocking multiple teams.

Practical Recommendations

• Document your tiers: Make tier classifications visible in README files, architecture diagrams, or project metadata
• Automate detection: Use dependency analysis tools to programmatically determine dependency and impact tiers
• Review regularly: Project tiers change over time as business needs and architecture evolve
• Set tier-specific policies: Define different requirements for testing, code review, deployment, and versioning based on tiers
• Align build support with tier: Match your build infrastructure investment to the project's dependency position, impact, and value
• Measure developer experience: Track metrics like time-to-first-build and build feedback time to validate support tier assignments
• Communicate tiers: Ensure team members understand how tiers affect their work and decision-making

Conclusion

Tiering projects provides a structured approach to managing complexity in multi-project organizations. By understanding projects through the lenses of dependency order, downstream impact, value, and development experience, teams can make more informed decisions about where to invest effort, how to manage risk, and how to balance quality with velocity. The key is to use these approaches complementarily, recognizing that different situations call for different prioritization perspectives. Aligning build support and developer experience with a project's technical and strategic importance creates a coherent system that helps teams work effectively at scale.