From Hope-Based to Systems-Based: How I Eliminated Monthly Fires and Doubled Revenue as Director of Operations

A 3-year operational transformation story: from reactive chaos to predictable calm.

The Challenge: When “Hope” Is Your Operating System

By October 2022, I had spent years at Solspace. I started as a developer, grew into technical leadership, and managed teams across dozens of client projects. But when I stepped into the newly created Director of Operations role, I discovered that the company’s operations ran on what I came to call hope-based planning.

Here’s what that looked like in practice:

• No unified client delivery structure. Some projects had project managers. Others didn’t. Some had backup developers. Most didn’t. Developers worked in silos, often never speaking to each other. There was no standard for how client work should flow from sales to delivery.

• No forecasting of any kind. Development capacity? Estimated by gut feel. Revenue projections? Based on optimism. Resource planning? Non-existent. The company hoped developers would be available when needed. They hoped projects would finish on time. They hoped clients would be happy.

• No marketing or sales discipline. The CEO wrote a blog post every two months when inspiration struck. No cadence. No LinkedIn presence. No website improvements. No outbound sales. No systematic lead generation. The company hoped referrals would keep coming.

• No operational visibility. Nobody could answer basic questions: How many hours does each developer actually work per week? Where are the bottlenecks? What’s our capacity for new work?

• Monthly fires. Roughly once a month, something broke badly enough that the founder had to drop everything and fight the fire. Production incidents. Scope explosions. Developer burnout. Client escalations. Emergency coverage gaps.

The result was predictable: chaos disguised as normalcy.

Solspace was a technically competent agency managing 50+ clients with talented developers. But operationally, it was held together by individual heroics, not systems. When I asked how decisions were made, the answer was usually some version of “we figure it out as we go.”

This is the reality many web agencies live with. They know something is wrong. They feel the chaos. But they don’t know how to fix it because they’ve never seen it work any other way.

Year One: Unlocking Productivity No One Knew Existed

The First Discovery: Developer Utilization Was Terrible

My first priority was simple: understand what was actually happening.

I pulled every hour logged in Basecamp (our project management tool at the time). I built spreadsheets. I started meeting with each developer weekly to understand their preferred working hours and what their historical patterns showed. And I found something striking: developers were dramatically underutilized.

Here’s what the data showed before I started:

• Average developer hours per week: 19.65 hours
• Most consistent developer: working full-time only 61.3% of weeks
• Total team capacity: ~98 hours per week across 5 developers

For context, a full-time developer should be working 30–35 billable hours per week. The team was averaging barely over half that.

This wasn’t because developers were lazy. It was because the system was designed to keep them underutilized.

The underutilization was intentional: management kept developers at lower capacity to make them easier to manage (busy developers create more issues to solve) and to maintain emergency capacity. With no backup architecture in place, the company needed developers available for fires.

But this created a vicious cycle:

• Unclear requirements meant developers waited for clarification
• No project managers meant developers handled client communication, scope questions, and coordination themselves
• No backup coverage meant work stalled when someone was sick or on vacation
• Tool fragmentation meant developers wasted time context-switching across Basecamp, email, Slack, and random spreadsheets

The productivity wasn’t hidden inside the developers. It was buried in operational friction and a deliberately conservative capacity model designed to prevent problems that proper systems would have solved.

The Solution: Structure, Not Pressure

I didn’t push developers to work more hours. I removed the friction that prevented them from working effectively.

Step 1: Unified Project Structure

Every client engagement got the same structure:

• Project Manager to handle client communication and scope management
• Lead Developer to own technical decisions and delivery
• Backup Developer to ensure continuity during absences

This simple change had cascading effects: developers stopped spending significant time on client emails and scope negotiations; requirements got clarified before development started; work continued even when someone was unavailable; clients got consistent communication.

Step 2: Migration from Basecamp to JIRA

Solspace had used Basecamp for 10 years. Every project was an isolated island. No visibility across engagements. No standardized workflows. No way to forecast capacity.

I led the migration to JIRA with unified project structures shared across all client engagements, custom workflows that matched how work actually flowed, automated reminders that kept work moving without manual nagging, and custom capacity tracking (first in Excel, then built as a custom tool) that made workload visible at a glance.

Step 3: Breaking Down Silos

Before, developers rarely spoke to each other. Everyone had their own clients, their own tools, their own approaches.

I broke this down systematically: intentionally mixed developers on new projects to force cross-pollination of knowledge and working styles; paired developers who had never worked together as backup pairs, creating new knowledge pathways across the team; led documentation initiatives in Confluence where developers captured project-specific knowledge and edge cases for team visibility; pushed activity in the Slack dev channel to create ongoing technical discussions and knowledge sharing; weekly developer standups (async in Slack) to maintain visibility across projects; cross-project code reviews to spread knowledge and enforce quality standards; unified best practices for common platforms (Craft CMS, integrations, deployments).

This was deliberate risk-taking. Mixing developers who hadn’t worked together created short-term friction. But it paid off: knowledge spread, redundancy increased, and the team became genuinely collaborative instead of siloed.

Step 4: Workload Regulation

I tracked every developer’s actual capacity and built sustainable schedules. No more boom-bust cycles. No more last-minute heroics.

The Results: Doubling Revenue Without Hiring

By the end of my first year, the numbers told a clear story.

The ad-hoc to retainer conversion was critical. Many clients operated on ad-hoc contracts but requested retainer-level service. I pushed to convert them to formal retainers, creating predictable incoming workload and allowing consistent weekly hours for the same developers. Combined with unified project structures, backup coverage, and the end of siloed work, developers could finally work efficiently instead of waiting on clarification or juggling reactive tasks.

This didn’t happen by accident. It happened because we could finally forecast capacity, commit to realistic retainer scopes, and deliver predictably month after month.

The team transformation was equally important.

Year Two: Building the Anti-Fire Systems

Doubling revenue was great. But preventing fires? That required deeper structural changes.

In year two, I shifted from fixing immediate problems to designing systems that prevented problems from happening in the first place.

The Operational Loop: From Reactive to Proactive

Most agencies operate reactively: something breaks, they fix it, they move on. The same problems keep recurring because no one asks why.

I implemented what I call the Operational Loop, a systematic approach to operational decision-making:

1. Gather Data — Before acting, collect information from multiple sources: project statuses, forecasts, developer workloads, client contracts, risk patterns, historical issues.
2. Gather Feedback — Check perspectives from project managers, developers, designers, sometimes clients. You cannot solve issues you do not fully understand.
3. Gather Industry Standards — Identify best practices around workload planning, forecasting, project structuring, client communication frameworks.
4. Fit Everything Into a Coherent System — Cross-analysis: “How does this change affect other projects?” “What is the long-term implication?” “What downstream issues could arise?”
5. Review and Revise — Before acting, ensure the decision fits the broader operational ecosystem.
6. Act With Precision — Only then: update JIRA, adjust workloads, refine forecasting, write documentation, communicate changes.
7. Gather Feedback Again — Test the change. Ask: “Is this solving the problem reliably?”
8. Repeat the Loop — Operations is iterative. Repeat until stability is achieved.

This loop is why fires disappeared. Issues got caught and resolved before they became fires.

The Pulse: Making Capacity Visible

You can’t manage what you can’t see. And before The Pulse, Solspace couldn’t see its capacity.

I built The Pulse, a custom capacity visibility tool that modeled: all active client retainers; developer allocations across projects; each developer’s sustainable weekly availability; distribution of hours across the organization.

The Pulse answered questions nobody could answer before: Can we take on this new retainer? Which developers have capacity this month? Are we approaching burnout on any engagement? What happens if someone goes on vacation?

Capacity planning shifted from “hope we have bandwidth” to “here’s exactly what we can commit to.”

Emergency Coverage Framework

Monthly fires often happened for two reasons: someone was unavailable and no one could cover, and projects lacked execution standards. I designed emergency coverage into the system from the start and established unified technical standards.

Key principles:

• Coverage is designed, not reserved. Emergency capacity exists because retainer hours are paced intentionally, not because hours are held back unused.
• Every retainer has redundancy. Primary developer plus backup developer who knows the codebase.
• Even weekly distribution. Retainer hours spread across the month, so capacity remains available for emergencies late in the month.
• PTO planned 4 weeks ahead. Time off gets reflected in The Pulse so work can be reallocated early.

Execution standards as fire prevention: we began enforcing the most critical standards across all projects—CDN layer for traffic protection, automated backups, production deployment checklists, monitoring and alerting. These standards, combined with backup coverage, dramatically reduced production fires.

The framework included detailed playbooks for handling production incidents, covering absences (vacation, sick leave, holidays), escalation paths and response priorities, and workload rebalancing when emergencies occur.

Result: Emergencies became manageable events, not chaos.

Production Deployment Playbook

Production incidents were a major source of fires. I created the Production Deployment Playbook to ensure safe, predictable releases: risk classification (low/medium/high) for every deployment; pre-deployment planning including rollback strategies; QA requirements aligned with deployment risk; designer validation before client sees staging; client approval before production deployment; timing guidelines to avoid peak hours and holidays; infrastructure standards (backups, CDN, caching, monitoring).

The playbook wasn’t bureaucracy. It was a decision framework: “Given this risk level, here’s what we need to do to stay safe.”

Rolling Forecasting: 4–12 Weeks Ahead

I established rolling capacity forecasting looking 4–12 weeks into the future. Every week, I updated: developer availability (accounting for PTO, holidays, capacity changes); client retainer needs and project timelines; emerging risks (scope creep, requirement ambiguity, delivery delays); resource gaps requiring hiring or contractor support.

Small weekly adjustments prevented monthly surprises.

The result of all these systems? Monthly fires essentially disappeared.

Year Three: Company-Wide Transformation

By year three, the client operations infrastructure was solid. Fires were rare. Delivery was predictable. Developer utilization was high and sustainable.

But the company had bigger structural problems: no real sales function, no marketing discipline, no cross-functional alignment between product development and client work.

While I had served as EOS Integrator throughout my Director of Operations tenure, year three gave me the bandwidth to focus more deeply on company-wide operational transformation rather than firefighting client delivery.

Implementing EOS (Entrepreneurial Operating System)

I led the implementation of EOS company-wide: quarterly planning sessions to set rocks (strategic priorities); weekly leadership meetings to maintain accountability; scorecards to track performance across departments; clear organizational structure with defined roles and responsibilities; issues list discipline to surface and resolve problems systematically.

EOS provided the framework. But I had to make it work in practice: translating the CEO’s vision into executable operational plans; ensuring leadership actually followed through on commitments; detecting cross-department friction early; maintaining operational visibility for the founder.

Building Growth and Cross-Functional Coordination

When I started, Solspace had no sales or marketing discipline and departments operated in silos. Sales made commitments without checking capacity, and there was no financial forecasting.

I pushed to establish structured growth activities, iterating through three growth director hires over 1.5 years. I personally created Growth Engine v0.1 (defining roadmap, activities, and cadence), led Solspace’s first outbound sales initiative, built Python prospecting tools, and configured HubSpot integrated with JIRA.

The bigger transformation was creating cross-functional coordination across Client Ops, Product Development, Sales, Growth, and Finance through: weekly capacity planning across all departments; forecasting that included product development in resource allocation; sales proposal reviews to validate feasibility before commitments; quarterly resource planning aligning growth ambitions with operational reality.

Product integration breakthrough: Product development had always been isolated with a single dedicated developer. I introduced shared developers between product and service work, coordinated through The Pulse. This achieved two goals simultaneously: backup coverage for product work and knowledge sharing across the product/service divide.

Scaling the Team Strategically

By mid-year three, we had expanded the development team by 60%, from 5 to 8 developers. Every hire was strategic. Combined with improved individual developer consistency, this expansion gave Solspace the capacity to support faster feature delivery, handle larger product launches, and reduce bottlenecks during peak seasons.

The Framework: Why This Actually Works

The operational transformation at Solspace wasn’t about working harder. It was about working systematically.

These principles aren’t theoretical. They’re how Solspace went from monthly fires to operational calm.

The Results: What Actually Changed

• Team performance: Every developer improved or maintained their productivity. Consistency improved across the board—the lead developer went from working full-time 61% of weeks to 78% of weeks. This happened through removing friction, not pressure.

• Revenue stability: When I started, retainer work was 69% of revenue and fluctuated wildly. After converting ad-hoc clients to formal retainers and implementing systematic forecasting, retainer revenue jumped to 86% and held above 75% in 15 of the next 18 months. Predictable cash flow replaced monthly volatility.

• Operational calm: The real victory was eliminating monthly fires. The productivity gains were structural, not temporary.

• Client impact: Breaking down silos improved delivery predictability, knowledge sharing, and communication. The result was happier clients and more sales to existing clients.

These improvements reinforced each other. Most importantly, three years later, the systems are still running.

What This Means For Your Agency

If you’re reading this and thinking “that sounds like my agency,” you’re not alone.

Most web agencies operate on hope-based planning: hope developers will be available; hope projects will finish on time; hope clients will be happy; hope fires won’t happen this month.

But hope is not a strategy.

The good news: You don’t need to suffer through 9 years of incremental learning like I did. The systems I built at Solspace are repeatable patterns that work for agencies managing 10 clients or 100.

The transformation I’ve described demonstrates the core systems every agency needs: capacity visibility tools, unified project structures, rolling forecasts, emergency coverage design, production safety playbooks, and cross-functional coordination. Each of these was built iteratively at Solspace and can be adapted to your agency’s specific context.

The Operations + AI Opportunity

Operational transformation creates the foundation for AI automation. Once we had clean data, unified structures, and predictable workflows at Solspace, we could start automating: developer workload alerts and rebalancing recommendations; client communication patterns and escalation triggers; capacity forecasting with predictive models; automated JIRA workflows and reminder systems; sales pipeline analysis and proposal validation.

You can’t automate chaos. But once you have systematic operations, AI becomes a force multiplier.

This is exactly what I do now at IB Solutions: transform your operations from hope-based to systems-based; build the intelligent systems that remove workflow friction; automate the predictable patterns to free your team for high-value work.

How This Could Work For You

If you’re a web agency owner or operations leader dealing with: monthly fires that pull leadership into reactive mode; unpredictable developer utilization and delivery timelines; retainer scopes that consistently overrun; no clear visibility into capacity or forecasting; sales commitments that exceed operational reality; knowledge silos where only one person understands each client; hope-based planning across the organization—then you’re living the exact situation I inherited at Solspace in 2022.

The difference is: you don’t need to spend 3 years figuring this out yourself.

I offer two services that directly address these challenges:

• Fractional Web Development Agency Operations Director — Exactly what I did at Solspace, but fractional. I map how work flows, define practical operating models, align tools with reality, set up reporting for project health and utilization, and coach teams on sustainable execution. Typical outcomes: clear operating model from sales to delivery, reduced chaos, tools that match how you actually work, and fewer emergencies.

• Company Operations & Website AI Solutions — Once operations are systematic, we can build intelligent systems that multiply capacity: AI-powered capacity planning, automated client communication, intelligent forecasting, production deployment automation, and cross-functional coordination dashboards. This is where operations meets AI.

Related solutions:

• Development and Deployment Pipeline
• System Monitoring
• Task Management Automation
• Solution Discovery & Scoping
• Website Core & Stability

Related technologies: