SRE for Scale-Ups: How to Build a Reliability Engineering Practice Without a Google-Sized Team.

What is SRE? Site Reliability Engineering (SRE) is the practice of applying software engineering principles to operations and infrastructure to build and maintain reliable, scalable systems. Coined at Google in 2003, SRE replaces ad-hoc ops work with measurable reliability targets (SLOs), structured error budgets, and systematic automation. It is a discipline, not a headcount. Any team can adopt it.

Most scale-ups hit the same reliability wall. The DevOps setup that shipped product fast at ten engineers starts generating cascading alerts at sixty. A prospective enterprise customer asks about your SLA before signing. And engineering leaders search for SRE guidance only to find Google’s 500-page book, Netflix’s chaos engineering posts, and Spotify’s squad model, all built for organizations with thousands of engineers. The question every CTO at a 50- to 500-person company actually needs answered is: how do we build a reliability practice that works at our scale right now?

This guide answers that question. It covers the SRE building blocks that deliver the most leverage at the scale-up stage; how to staff and tool the practice on a realistic budget; the content gaps that most SRE guides skip; and the five anti-patterns that derail scale-up SRE programs before they gain traction.

Key Takeaways:

• SRE is a set of practices, not a headcount. Two engineers with the right framework outperform a ten-person team without one.
• SLOs and error budgets are the highest-leverage starting point: they immediately align engineering decisions with business impact.
• The DORA four-key metrics are the industry-standard baseline for measuring SRE maturity before investing in dedicated infrastructure.
• Most scale-ups with fewer than 150 engineers should use an embedded or specialist-augmentation model rather than a Google-style dedicated SRE silo.

Why Scale-Ups Need SRE (And Why DevOps Alone Isn’t Enough)

Startups tolerate downtime because their users tolerate it. Large enterprises have platform teams, incident playbooks, and reliability budgets. Scale-ups sit between the two: user expectations have crossed into enterprise territory, but the engineering organization has not yet built the infrastructure to match.

Between Series A and Series C, most engineering teams experience the same set of reliability inflection points: deployment frequency increases, the number of services expands, and real customer contracts with uptime commitments appear. The architecture that served the startup well becomes a reliability liability. DevOps provides speed and automation, but it does not provide a structured mechanism to make the velocity-versus-reliability trade-off explicit. That is exactly what SRE adds.

The financial case is not abstract. Gartner research has pegged average unplanned downtime costs at over $5,600 per minute for enterprise-class systems. The Google SRE Book notes that 40 to 90 percent of total software system costs are incurred after deployment: in maintenance, incidents, and reliability work. For scale-ups closing enterprise deals, reliability is no longer a technical concern. It is a revenue concern.

The SRE practices described in this guide, taken together, typically reduce change failure rates by 30 to 50 percent and mean time to restore (MTTR) by 40 to 70 percent for teams that apply them consistently. That translates directly to fewer incident-driven revenue losses, faster feature delivery, and lower on-call burnout, all without needing a dedicated SRE function to get started.

The table below benchmarks typical scale-up reliability metrics against DORA 2024 research categories. Most scale-ups begin in the Low to Medium performance band; the gap to elite performance is real, and closing it is precisely what a structured SRE practice is designed to do.

Engineering stage	Team size	Typical change failure rate	Median MTTR	Deploy frequency	Toil / reactive time
Early scale-up	15–50 engineers	20–30%	4–10 hours	Weekly–monthly	40–55% of eng capacity
Growth stage	50–150 engineers	12–20%	1.5–4 hours	Weekly	28–42% of eng capacity
Late scale-up	150–300 engineers	8–15%	30 min–2 hours	Daily	20–32% of eng capacity
Pre-enterprise	300–500 engineers	5–10%	15–60 min	Daily–multiple/day	15–25% of eng capacity
DORA 2024 Elite	Any	<5%	<1 hour	Multiple/day	<20% of eng capacity

The “toil/reactive time” column, meaning the share of engineering capacity consumed by repetitive operational work, on-call response, and unplanned firefighting, does not appear in standard DORA reporting. It is the metric most strongly correlated with SRE program ROI: every 10-point reduction in toil directly translates into engineering capacity for reliability and feature work. Scale-ups entering the growth stage typically spend 35 to 45 percent of engineering capacity on reactive work, well above Google’s 50 percent toil cap guideline for SRE teams. Reducing that number is the fastest path to both better reliability and higher developer velocity.

Dimension	Traditional IT Ops	DevOps	SRE
Primary goal	Stability; minimize change	Speed; continuous delivery	Reliability through engineering
Success metric	Uptime; change failure rate	Deployment frequency; lead time	SLO compliance; error budget
Toil attitude	Accepted as necessary	Reduced through automation	Capped at 50% of eng time
Reliability ownership	Operations team	Shared Dev and Ops	Shared via error budgets
Platform engineering fit	Operates separately	Complementary	SRE teams often build the platform

A note on SRE versus platform engineering, a distinction more competitors are now drawing: platform engineering builds the internal tooling and infrastructure that product teams use. SRE defines the reliability standards that tooling must meet and the practices that govern how reliability is measured and maintained. At the scale-up stage, one small team often does both, and that is fine. What matters is that both functions are explicitly owned.

The Three SRE Building Blocks That Matter Most at Scale

Google’s SRE book spans more than 500 pages. A scale-up team cannot implement all of it at once. The three practices below deliver the highest reliability leverage per unit of engineering investment for teams in the 20- to 300-engineer range.

1. SLOs and Error Budgets: Making the Reliability-Velocity Tradeoff Explicit

A Service Level Indicator (SLI) measures what users actually experience: availability, latency at the 95th or 99th percentile, error rate, or throughput. A Service Level Objective (SLO) is the target for that SLI: the threshold that, when crossed, signals a reliability problem requiring engineering attention. An error budget is the mathematical complement of the SLO: the allowable amount of unreliability in a measurement window.

The error budget mechanism solves the most persistent organizational problem in scale-up. Development teams push for fast releases. Operations push for stability. With an error budget, neither side needs to win that argument: the budget makes the tradeoff quantitative. When the budget is healthy, teams can ship faster. When it is consumed, teams prioritize reliability work. This replaces a recurring subjective argument with a shared, data-driven operational policy.

SLO calibration rule: set your SLO tighter than your SLA but looser than what your system currently achieves. If you currently deliver 99.8% availability, a 99.5% SLO gives engineering headroom for feature work without triggering reliability incidents. Starting at 99.9%, when you are delivering 99.8% means spending cycles chasing a target you barely miss rather than building business value.

Start with two or three services. Not every service needs an SLO immediately. Identify which services, if they failed, would most directly affect paying customers or contractual obligations. Define SLOs for those first, and add services each quarter. An SLO document needs only one page per service: the SLI being tracked, the target, the measurement window, and the error budget policy.

Worked Example: SLO and Error Budget for a Payment API

Abstract definitions become concrete fast with a real service. Below is a complete SLO and error budget setup for a payment processing API, the type of service where reliability failures have direct and immediate revenue consequences.

• Service: Payment Processing API   
• SLI: Successful transaction rate (percentage of payment requests that complete without error)   
• SLO: 99.5% over a rolling 28-day window   
• Error budget: 0.5% of 40,320 total minutes = 201 minutes (~3.4 hours) per cycle

With those parameters defined, the team tracks budget consumption weekly against a simple ledger:

Week	Event	Downtime consumed	Budget used (cumulative)	Budget remaining
Week 1	3 routine releases; latency degradation on one	14 min	7%	187 min (93%)
Week 2	Deployment rollback after config error	26 min	20%	161 min (80%)
Week 3	Database connection pool exhaustion, P1 incident	64 min	52%	97 min (48%)
Week 4	Product proposes major infrastructure migration	0 min	52% consumed	97 min (48%)

The week 4 decision: 97 minutes of budget remain with 7 days left. A routine feature release carries an estimated 10 to 15-minute blast risk: within budget, cleared to ship. The proposed infrastructure migration carries a 2 to 3-hour blast risk that exceeds the remaining budget by a factor of two. Decision: ship the feature release, defer the migration to the next 28-day cycle, and open a reliability investigation into the database incident to reduce the probability of recurrence before the next cycle begins. No argument required. The budget made the decision.

2. Toil Reduction: Protecting the Engineering Capacity That Makes Reliability Improve

Toil is operational work that is manual, repetitive, automatable, and scales proportionally with service scale: recurring manual deployments; the same alert pattern resolved the same way every week; manual database cleanups; ticket-driven processes that could be self-served. Google’s SRE practice caps toil at 50 percent of SRE team time. Above that threshold, teams enter a maintenance mode where reliability stagnates rather than compounds.

For scale-ups, measuring toil is often more valuable than fixing it immediately. Quantify how much time repetitive operational work consumes before investing in automation. This measurement builds the business case for reliability investment and is directly connected to how accumulated technical debt reduces engineering capacity over time: both forms of operational drag compound in ways that become increasingly expensive to address reactively.

Toil reduction also unlocks the shift-left reliability model used by high-performing engineering organizations. When SRE engineers are not consumed by repetitive operational tasks, they can embed reliability checks earlier in the development lifecycle: SLO-based quality gates in the CI/CD pipeline, automated load testing before production, and runbook generation as part of service creation rather than after the first incident.

3. Incident Management and Postmortem Culture

Incident management is the practice of responding to system failures in a structured, coordinated way. The critical shift for scale-ups is from hero culture to process culture. In hero culture, incidents are resolved by whoever is most senior and available, creating single points of failure and producing no institutional learning. In process culture, incidents follow a defined protocol, ownership is shared through on-call rotation, and every significant incident produces a postmortem reviewed and acted upon.

The DORA 2024 State of DevOps Report identifies psychological safety as a significant predictor of both reliability performance and engineering team well-being. Blameless postmortems are the primary mechanism for building that safety: a document that explains what happened, why it happened, and what systemic change would prevent recurrence, without attributing failure to individual error.

On-call health is an underrated reliability investment. An on-call rotation that routes all alerts to the same two engineers at all hours, with no runbooks and no handoff protocol, is engineer burnout on a schedule. A functional rotation includes documented runbooks for the most common alert types, defined response-time expectations, and compensation policies that signal that on-call is a professional responsibility, not a background expectation.

Your SRE Roadmap by Engineering Stage

Most organizations wait until after a reliability crisis to invest in SRE practices, a pattern that consistently produces higher recovery costs than proactive investment. The table below maps the highest-leverage SRE priorities to each engineering stage, so teams can identify where to start regardless of where they currently sit on the maturity curve. If your change failure rate exceeds 10 percent, your MTTR is measured in hours, or engineers are spending more than 40 percent of their time on reactive work, the investment is overdue.

Stage	Team size	First 90 days	Days 90–180	Skip for now
Early scale-up	15–50	SLOs for top 2 revenue-critical services; basic on-call rotation; DORA baseline measurement	Error budget policy; first 10 runbooks; blameless postmortem template	Dedicated SRE hire; chaos engineering; platform team
Growth stage	50–150	Expand SLO coverage; toil register; shift-left quality gates in CI/CD	Full observability stack (logs, metrics, traces); alert audit and pruning	Google-style SRE handover model; over-engineered tooling stack
Late scale-up	150–300	Reliability owner per product squad; shared observability platform	SLO-based engineering OKRs; quarterly Game Day chaos exercises	Retrofitting SLOs across all services simultaneously
Pre-enterprise	300–500	First dedicated SRE or platform engineer; formal error budget reviews	Automated toil reduction; incident response automation for P2/P3	Building an SRE org before practices are embedded across product teams

Two structural notes on using this table: first, the “Skip for now” column matters as much as the priority columns. The most common SRE failure mode at the scale-up stage is over-investing in tooling and org structure before the foundational practices are operational. Second, the stages are defined by engineering complexity more than headcount. A 60-engineer team with ten microservices and three product squads faces late-scale-up reliability challenges regardless of size.

SRE Staffing Models for Scale-Ups

Google’s SRE model (dedicated reliability teams that manage services after handover from development) requires roughly one SRE per eight developers. At 60 engineers, this is inaccessible. Four staffing models are viable at the scale-up stage, each with distinct tradeoffs.

Model	How it works	Best fit	Key risk
Embedded SRE	SRE responsibilities distributed across all engineers within each product team	Under 100 engineers; strong DevOps culture	Reliability work deprioritized under feature pressure
Platform team	Small team builds shared SLO framework, tooling, and runbooks used by all product teams	100–300 engineers; multiple product teams	Platform-product friction; tooling over-engineering
Specialist augmentation	External SRE specialists work alongside internal engineers to build the practice	Rapid scaling; SRE skills gap; limited hiring budget	Knowledge transfer requires active continuity management
Hybrid	One or two internal SRE leads own standards and tooling; product teams own reliability execution	150–500 engineers; transitioning from embedded model	Internal SREs become bottlenecks if not staffed to capacity

The embedded model is the most common entry point. It works when engineering culture already treats reliability as a shared responsibility, but it requires protecting 10 to 20 percent of sprint capacity for reliability and toil-reduction work; otherwise, that work will be consistently deferred in favor of features.

The specialist augmentation model is increasingly relevant for scale-ups facing a skills gap rather than a capacity gap. SRE skills, including distributed systems expertise, observability engineering, and chaos engineering, are among the most in-demand roles in engineering. Filling that gap through direct hiring is expensive and slow. Engineering talent for SRE roles can be sourced more flexibly through specialist augmentation. Nearshore engineering partnerships can provide SRE expertise flexibly, allowing scale-ups to build the practice faster than internal hiring allows while preserving the option to hire dedicated SREs once the role is clearly defined.

SRE Tooling on a Scale-Up Budget

Implementing SRE does not require enterprise-scale tooling investment. The following table maps core SRE functions to options viable at scale-up budgets, with a recommended starting point for each.

SRE function	Open-source options	Managed / cloud-native	Scale-up starting point
Metrics and alerting	Prometheus, Alertmanager	Datadog, New Relic, Dynatrace	Cloud-native metrics plus Prometheus for custom SLIs
Logging	Loki, Elasticsearch, Fluentd	Datadog Logs, Splunk, CloudWatch	Cloud-native log aggregation (CloudWatch or GCP Logging)
Distributed tracing	Jaeger, Zipkin, OpenTelemetry	Honeycomb, Datadog APM	OpenTelemetry SDK with cloud-native tracing backend
Incident management	Alertmanager, open-source oncall	PagerDuty, Opsgenie, Incident.io	PagerDuty or Opsgenie; Slack-native incident channels
SLO tracking	Sloth (Prometheus-based)	Nobl9, Datadog SLOs	Grafana SLO dashboards initially; dedicated tooling at scale

A sequencing principle worth following: instrument first, alert second, visualize third. Many teams install dashboards before properly instrumenting their services, producing elegant charts about irrelevant metrics. Instrumentation, meaning ensuring the SLIs you care about are measured at the code level, is the prerequisite for everything else. Integrating observability into the development lifecycle from the start is far less expensive than retrofitting it into existing services later.

On cloud-native architectures, the observability infrastructure is available natively from most cloud providers at low cost. The investment is in adoption discipline, not tooling licensing. For teams on legacy or mixed infrastructure, the observability retrofit cost is usually the dominant SRE investment, making the case for infrastructure modernization measurable.

Five SRE Anti-Patterns That Stall Scale-Up Programs

1. Copying Google’s Org Chart

Google’s SRE model is a consequence of its scale, not a cause of its reliability. A dedicated SRE silo of 60 engineers lacks the scale to provide leverage and creates a specialized function that the rest of the organization does not know how to engage. Start with practices, not org design.

2. SLOs Without Business Context

SLOs set entirely within engineering often target the wrong things. A 99.9% availability SLO on an overnight batch job is not the same investment as a 99.9% SLO on a payment processing API. Business context, specifically the revenue impact of failure and contractual commitments, should drive SLO selection. And SLOs set without stakeholder buy-in will be ignored when they conflict with feature priorities.

3. Alert Fatigue From Over-Alerting

Configuring alerts for every possible metric trains on-call engineers to ignore their paging systems. SRE alerting philosophy: alerts must be actionable and represent conditions requiring human intervention within a defined time frame. Informational conditions belong in dashboards and logs, not on-call channels. Pruning alert rules regularly is toil-reduction work that directly improves engineer’s quality of life.

4. Skipping Postmortem Culture

Postmortems are consistently the SRE practice most deferred under time pressure. When incidents are resolved, the instinct is to move to the next sprint. This creates organizations that solve the same problems repeatedly and accumulate undocumented reliability debt. A one-page postmortem completed within 24 hours of any significant incident, answering what triggered it, what slowed response, and what single change would most reduce recurrence, is more valuable than a comprehensive template that is rarely used.

5. Treating Reliability as a Phase

The most damaging anti-pattern is framing SRE as a project that will be completed before returning to “real” engineering work. Reliability is not a one-time infrastructure investment; it is an ongoing engineering discipline. Engineering teams that build an SRE practice, declare it complete, and stop actively managing it, see reliability regress as the system and team evolve. This is connected to the broader pattern of deferred technical modernization; both compound in ways that become increasingly expensive to address.

SRE Maturity: A Five-Level Framework for Scale-Ups

The following model maps the current state to the next steps across five dimensions. Most scale-ups that have not formally adopted SRE sit at Level 1 or 2, with pockets of Level 3 where individual engineers have pushed for structure. The target for a first-year SRE initiative is Level 3 across all dimensions.

Dimension	L1, Reactive	L2, Defined	L3, Measured	L4, Proactive	L5, Optimizing
Incident response	Ad-hoc, hero-driven	Documented process, on-call rotation	Severity framework, SLA tracking	Postmortems drive engineering OKRs	Automated remediation for P2/P3
SLOs and error budgets	None defined	SLOs for 1–2 services	SLOs tracked, error budgets visible	Error budgets gate releases	SLOs cover full service portfolio
Observability	Logs only; no tracing	Metrics and alerts on key services	Tracing, service dependency maps	SLI dashboards per service	Continuous burn-rate alerting
Toil management	Toil not measured	Toil identified informally	Toil register maintained quarterly	Toil reduction OKRs per team	Toil below 30% of eng capacity
Reliability culture	Blame-driven response	Blameless postmortems attempted	Postmortems consistently completed	Reliability reviewed by leadership	Reliability embedded in product roadmap

A dedicated SRE hire is warranted when the organization consistently operates at Level 3 across all five dimensions and the embedded model is creating capacity constraints. Hiring before the foundational practices are in place means the new hire spends their time building the framework rather than improving it, which is better addressed through specialist augmentation while the foundations are established.

The DORA 2024 Research Platform provides a free capability assessment that maps your organization’s current state against the four key metrics and generates capability-specific improvement recommendations: a practical first step before any SRE investment decision.

SRE and AI-Assisted Development: What Changes in 2026

The 2024 DORA report’s most important reliability finding was that AI adoption significantly increases individual developer productivity but negatively affects team-level software delivery stability and throughput. More code generated more quickly requires more testing, more observability coverage, and more incident-response capacity to absorb reliably.

This makes SRE investment and AI-assisted development adoption directly complementary rather than competing priorities. The SLO-and-error-budget framework provides the feedback loop that makes AI-accelerated development safe to operate: when AI-generated code increases the chance of failure rate, the error budget signals it quantitatively before it becomes a customer-facing incident.

The agentic AI systems now entering production add a further dimension of reliability. Agentic systems can take real-world actions (creating, modifying, or deleting data), and their failure modes include correctness errors and cascading automated decisions, not just availability failures. The SRE practices described in this guide apply directly, but the SLIs need to extend beyond uptime to include correctness and blast radius containment.

Frequently Asked Questions

1. What is the difference between SRE and DevOps?

DevOps breaks down the silos between development and operations to enable faster, more collaborative software delivery. SRE extends DevOps with a structured measurement layer: SLIs, SLOs, error budgets, and toil tracking. SRE answers the question DevOps leaves open: how reliable does “reliable” need to be, and who decides? For most scale-ups, SRE is implemented as an extension of an existing DevOps practice, not a replacement. The Atlassian guide to SRE principles provides a detailed operational comparison.

2. Does my scale-up need a dedicated SRE engineer?

Not to start. The most valuable SRE practices, including defining SLOs, implementing error budgets, postmortem culture, and toil tracking, can be adopted by existing teams without dedicated headcount. A dedicated SRE hire is warranted once the foundational practices are in place, the team is consistently operating at Level 3 on the maturity model above, and the embedded model is creating measurable capacity constraints. Most scale-ups with fewer than 150 engineers are better served by the embedded or specialist-augmentation model.

3. What is an error budget and why does it matter for scale-ups?

An error budget is the amount of unreliability your SLO allows. If your availability SLO is 99.5% over 30 days, your error budget is 0.5% of that window, roughly 3.6 hours. The mechanism matters because it converts the reliability-versus-velocity argument from a recurring subjective disagreement into a shared, quantitative operational policy: when the budget is healthy, ship faster; when it is consumed, prioritize reliability work. For scale-ups where this argument consumes significant leadership energy, the error budget is the most direct structural fix.

4. What DORA metrics should a scale-up track to measure SRE progress?

The two DORA metrics most directly relevant to SRE maturity are change failure rate (the percentage of deployments that cause incidents) and mean time to restore (how quickly you recover). Elite performers achieve a change failure rate below 5% and MTTR under one hour. Most scale-ups begin the SRE journey at a 10 to 15% change failure rate and multi-hour MTTR. Closing that gap is the concrete output of a well-executed SRE program.

5. How do SRE practices apply to AI-assisted development?

DORA 2024 found that AI coding tool adoption increases individual productivity but negatively affects delivery stability and team-level throughput. SRE practices, specifically SLO measurement and error budget tracking, provide the feedback loop that makes AI-accelerated development safe to operate: error budget consumption makes the reliability impact of AI-generated code visible quantitatively before it becomes a customer-facing problem. Teams that invest in SRE foundations before scaling AI-assisted development velocity are best positioned to capture productivity benefits without incurring reliability costs.

6. What is the ROI of building an SRE practice?

The return on SRE investment compounds across several dimensions: fewer incidents mean lower direct revenue loss and support costs; faster MTTR reduces the customer-impact window of each incident; lower change failure rates enable higher deployment frequency, which DORA research links directly to higher organizational performance; and reduced on-call toil lowers engineering attrition costs. Teams that progress from Level 2 to Level 3 on the maturity model above typically see reductions in change failure rate of 30 to 50% and MTTR of 40 to 70% within 12 months. The investment to reach Level 3 is primarily in engineering time, not tooling budget.

Conclusion

Somewhere right now, a scale-up engineering team is in an all-hands incident bridge, debugging a production failure with no runbooks, no owner, and a CEO asking for an ETA on a Slack channel that nobody is watching. The root cause, when they find it four hours later, will be something that has happened before. There will be no postmortem. The same failure will happen again.

That team is not understaffed or underfunded. It is unstructured. The difference between that team and a high-performing one is not headcount, it is the presence or absence of a small set of engineering disciplines that compound over time: explicit reliability targets, an error budget that makes the velocity-versus-reliability tradeoff a data-driven decision rather than a recurring argument, an on-call rotation that distributes load fairly and generates institutional learning, and a postmortem culture that converts failures into durable improvements.

SRE is not a transformation program. It is not a platform initiative. It is not something that requires a budget cycle or executive sponsorship to begin. It requires two things: the decision to treat reliability as a first-class engineering concern, and the discipline to measure it. The DORA research is unambiguous on what follows from that decision: lower change failure rates, shorter recovery times, higher deployment frequency, and engineering teams that spend their time building rather than firefighting.

Scale-ups that build SRE practices during their growth phase do not just reduce incidents. They build the kind of engineering organization that enterprise customers trust, that retains engineers who want to work on well-run systems, and that can absorb AI-accelerated development velocity without accumulating the reliability debt that comes with it. The ones who wait eventually build the same organization, after the incident makes the cost of waiting impossible to ignore.

Start before the crisis. Start with one SLO for one critical service, measured weekly and reviewed at your next engineering all-hands. That is enough to begin.

Build Your SRE Practice With Coderio

Coderio’s engineering teams work with scale-ups to design and implement SRE foundations: SLO frameworks, observability infrastructure, on-call rotation design, and incident response processes for teams between 20 and 500 engineers. We can augment your existing team with SRE expertise or build the reliability infrastructure alongside your product development. Talk to our engineering team to assess where your reliability practice stands today.

Related Reading

• AI Technical Debt: What It Is, Why It Compounds, and How to Control It: Reliability debt and AI technical debt share the same compounding mechanism
• AI-Native Engineering Teams: 10 Practices That Separate the Best: SRE practices are a core component of what separates AI-native teams from teams that are merely AI-assisted
• Signs You Need to Replace Your Legacy Systems: Legacy architecture characteristics that raise the cost of SRE investment
• Monolith vs Microservices: Stop Breaking Things Apart: Architectural decisions that directly affect SRE complexity and on-call blast radius
• Technical Debt Strategies for Business Leaders: Technical debt reduction and toil reduction are complementary reliability investments