The Accelerator as a Listening System

Innovation programs are usually evaluated by what they produce.

How many ventures launched? How quickly did they reach an MVP? How much funding did they attract? Which technologies made their way into the portfolio? These are reasonable questions. A program created to explore the future should eventually produce something the organization can point to.

At the CA Accelerator, we could spin up a new startup in under a month. Funding, hiring, problem validation, MVP definition, rough design and engineering estimates, and the beginnings of marketing and sales plans could all move within that window. Multiple ventures advanced from concept toward viable product directions, and several supported Series A–level outcomes.

Those results mattered.

The longer I worked inside the Accelerator, however, the more interested I became in another form of output. Each venture gave CA a reason to enter customer conversations the company’s established technology stack would not naturally have initiated. Containers, predictive operations, natural-language systems, automation, IoT, and new developer experiences opened different doors. They brought us into contact with emerging teams, unfamiliar buyers, and operational problems that sat beyond the gravitational field of the existing portfolio.

Before a venture became a product, it could become an instrument of perception.

The Accelerator expanded what CA could build. It also expanded what the company could notice.

---

The Gravity of an Existing Business

CA Technologies operated one of the world’s largest enterprise software portfolios, with deep commercial strength in mainframe and infrastructure systems. That success made exploration possible. It also shaped what the organization could easily recognize as valuable.

Established companies develop perceptual habits around the markets they serve. Their products determine which customers they meet, the customers determine which problems enter the organization, and those problems reinforce the categories the portfolio already knows how to address. Over time, the business becomes exceptionally capable inside its field of view while the boundary of that field becomes harder to see.

The narrowing need not indicate complacency; it can be a structural consequence of competence.

An accelerator creates a partially protected environment in which different questions can survive long enough to become legible. The emerging ventures at CA explored technologies and developer ecosystems that did not always resemble the business that had made the company successful. They needed autonomy from conventional planning cycles, existing revenue expectations, and the instinct to evaluate every proposition through the architecture of the current portfolio.

Autonomy alone was insufficient. An incubator can easily become a collection of enthusiastic teams moving quickly in unrelated directions, each rediscovering the same operational mistakes with admirable energy. The ventures needed enough connection to the enterprise to access its capabilities and enough separation to avoid inheriting its conclusions before the work had produced evidence.

The design problem lived in that boundary.

---

Speed Arrives Before the Sprint

When organizations want innovation to move faster, they often compress the visible activities: shorter workshops, optional research, an MVP defined by whatever fits the date, and implementation beginning before uncertainty has had a chance to become inconvenient.

The calendar improves because ambiguity has been omitted from the plan. It returns later as rework, organizational resistance, technical debt, or a product that arrived efficiently at the wrong market.

Our speed at CA came from preparation outside the individual venture.

The Accelerator had precomposed many of the capabilities a startup would otherwise spend months locating and negotiating. Funding, hiring, design, engineering, research, product strategy, marketing, and sales were available while a proposition was still malleable instead of waiting downstream for a founder to produce a finished idea.

The topology of the work changed. A technical constraint could shape the MVP before it became a commitment. Customer evidence could alter the proposition before marketing fossilized it into language. Commercial expertise could reveal that an elegant product had no credible route to a buyer. Design could expose that the proposed workflow solved a problem customers did not experience, or that a modest interaction revealed a larger opportunity than the original technology suggested.

Early friction prevented late reversal.

Velocity therefore appeared as a lagging indicator of a well-composed system. We moved faster because relevant forms of intelligence could reach the venture earlier, while the cost of revision remained low.

---

Designing the Venture, Not Decorating the MVP

UX was hands-on from the beginning. We worked with founders to determine whether the proposed problem deserved to be solved, who experienced it, what behavior surrounded it, and which portion of the idea could generate meaningful evidence.

The object under design was the venture’s emerging theory of reality.

Research tested whether the problem existed with the frequency and consequence the founder imagined. Product framing converted technical potential into a proposition someone could evaluate. Interaction design gave assumptions an experiential form. Prototypes created occasions for customers to reveal behavior that interviews alone could not reach. The MVP became an instrument for learning rather than the smallest collection of features a team could persuade itself to ship.

My agency experience resurfaced here. Years of scoping ambiguous client work had taught me how to translate a developing concept into approximate design and engineering hours, identify the capabilities required to produce it, and create a plausible statement of work before every detail was known.

Inside the Accelerator, an estimate did more than support a budget. It tested whether the declared MVP was actually minimal, whether the current team could build it, where technical ambiguity was hiding, and which capability would become the limiting factor. The estimate converted a founder’s aspiration into a provisional allocation of time, people, and uncertainty that the larger group could inspect.

It made the idea discussable without pretending the discussion had made it certain.

---

The Bookshelf

Assembling those capabilities around a venture did not make them naturally interoperable.

Founders, engineers, designers, researchers, executives, and commercial leaders arrived with different professional dialects and different intuitions about what counted as progress. A validated idea might mean customer enthusiasm to one person, observable behavior to another, and a signed agreement to someone responsible for revenue.

Shared reading became part of the Accelerator’s connective tissue. Ash Maurya partnered with us, and every founder received a signed copy of his book. We accumulated a bookshelf of Lean literature: Lean Canvas, Lean UX, The Lean Startup—Lean everything. Had someone published Lean Lunch, we probably would have bought that too.

The library was not devotional, and we harbored no illusion that a sufficiently complete collection of canvases would cause a business to emerge spontaneously from the wall.

Its value was linguistic.

Hypothesis, assumption, experiment, evidence, validation, customer segment, problem–solution fit, and minimum viable product gave different disciplines a common way to interrogate a venture. A founder could articulate what they believed. Research could specify what evidence would alter that belief. Design could turn uncertainty into an observable interaction. Engineering could identify the smallest credible implementation. Commercial partners could examine whether the learning connected to a market.

Shared vocabulary reduced the overhead of translation. We spent less energy establishing what someone meant and more energy examining whether it was true.

People could think differently without becoming mutually unintelligible; uniform cognition was never the goal.

---

Reconfiguration as a Capability

Traditional product organizations compose stable teams around durable roadmaps. Accelerators operate under a different temporal logic. The problem, customer, product, and sometimes the venture itself may change before the team has developed a fixed identity.

Reconfiguration became one of the program’s most valuable capabilities.

Design and strategy support could move toward a venture facing acute uncertainty. Specialized technical knowledge could enter when an architectural question became decisive. Research could intensify before an expensive assumption crossed into implementation. Marketing and sales could shape the proposition while it was still forming instead of being asked to package it after the product existed.

When evidence contradicted a belief, we could change the composition of the conversation. A venture might narrow its market, revise the MVP, recruit a missing capability, pursue a different application of the technology, or stop before momentum became its only justification.

Shared frameworks made this movement coherent. People could enter a venture without reconstructing its entire intellectual history because assumptions, evidence, experiments, and decisions had a recognizable form. The surface supported mobility without demanding amnesia.

I came to see the Accelerator as a precomposed capability system rather than a collection of startups. The relevant expertise existed before any particular venture knew exactly when it would need it. Capabilities could enter consequential contact with a problem, alter its direction, and be recomposed elsewhere as the portfolio learned.

This form of scale leaves the ventures distinct while making the organization increasingly capable of discovering what each one needs to become.

---

The Conversation Before the Product

The emerging technologies created access to customers and categories the core business would not have reached on its own. Those conversations were potential commercial opportunities, but their strategic value began earlier.

They allowed CA to hear how customers were reorganizing work, which new roles were accumulating authority, where technical categories were forming, and which problems mattered before the established portfolio had developed language for them. A venture did not need to achieve scale before it increased the organization’s capacity to perceive the market.

That perceptual function receives far less attention than venture output.

Innovation programs are often framed as engines for producing future products. They can also operate as listening systems positioned outside the perceptual habits of the current business. Their ventures become probes. The customer conversations they generate return signals that ordinary account relationships, product roadmaps, and sales motions are structurally unlikely to detect.

That signal is useful only if the parent organization can hear it. A protected innovation program can become so isolated that its learning never crosses back into the institution. The same collaborative design required inside a venture is needed at the boundary surrounding the program: shared language, credible evidence, relationships capable of carrying unfamiliar information, and enough executive curiosity to let the future arrive in a form the current portfolio does not recognize.

The Accelerator gave CA a way to investigate possibilities beyond its established business without destabilizing the systems that still sustained it. Some ventures advanced. Some changed. Some generated learning more valuable than the proposition that produced it.

The durable outcome was organizational optionality. We helped startups move quickly, but speed was only the visible behavior of a system with a repeatable capacity to find, compose, and redirect the intelligence required to explore what the company could not yet see clearly. An accelerator should produce products while leaving the organization with a larger field of view.

---

This article is supporting content for Designing the Collaborative Surface. For my role, the operating model, and venture outcomes, read the professional case study: Precomposing Velocity at CA Technologies.