The Accelerator did not merely make individual startups faster. It made the organization better at repeatedly creating startups.
Innovation Inside a Successful Legacy
CA Technologies operated one of the largest enterprise software portfolios in the world, with substantial commercial strength in mainframe and infrastructure systems. That success created a peculiar strategic constraint. The company had the resources and technical capability to explore what came next, but its established products, customers, revenue models, and decision structures naturally exerted gravity on anything new.
Emerging opportunities did not necessarily resemble the business that had made CA successful. Venture teams were exploring containers while the category was still forming, predictive DevOps, natural-language processing, operational analytics, developer tooling, machine learning, automation, IoT systems, and configuration models that questioned whether YAML should remain part of the experience at all.
The technologies differed, but the organizational problem remained consistent. How could a mature enterprise evaluate unfamiliar markets and build credible new products without either forcing them prematurely into the legacy portfolio or insulating them so completely that they never developed a path back into the business?
The CA Accelerator became a parallel system for answering that question.
It gave early ventures enough autonomy to explore propositions that would have struggled inside conventional product-planning cycles. Yet autonomy alone does not produce learning. An incubator can easily become a collection of enthusiastic teams moving quickly in unrelated directions, each rediscovering the same mistakes with admirable energy.
The emerging technologies also gave CA permission to enter customer conversations its established portfolio would not naturally have initiated. A company known for a particular generation of enterprise infrastructure tends to encounter customers through the problems that infrastructure already knows how to name. Containers, predictive operations, natural-language systems, automation, and new developer experiences opened different doors. They brought us into contact with teams, buyers, and operational concerns that sat beyond the gravitational field of the existing stack.
Those conversations became instruments of strategic perception as well as potential sales opportunities. They allowed CA to hear how customers were reorganizing their work, where new technical categories were forming, and which problems might matter before the core portfolio had developed language for them. The Accelerator expanded what the company could build and, equally important, what it could notice.
The more consequential design challenge was to make venture creation itself repeatable.
Speed Is Usually a Lagging Indicator
We could spin up a new startup in under a month. In that period, a venture could move through initial funding, staffing, problem validation, MVP definition, rough design and engineering estimates, and the beginnings of credible marketing and sales plans.
That speed sounds like the product of urgency. It was actually the product of preparation.
When organizations attempt to accelerate work, they often compress the visible activities while leaving the surrounding dependencies untouched. Teams hold a shorter workshop, reduce research, declare an MVP, and begin building. The calendar improves because uncertainty has been omitted from the plan, not because it has been resolved. Speed appears early and debt appears later.
Our velocity came from a different source. The Accelerator had precomposed many of the capabilities a new venture would otherwise spend months locating, negotiating, and sequencing. Funding, hiring, design, engineering, research, product strategy, marketing, and sales did not wait as downstream services for a founder to produce a finished proposition. They were available to influence the venture while its assumptions were still malleable.
This widened the collaborative surface at the moment when change was least expensive.
A technical constraint could shape the MVP before it became a commitment. Customer evidence could change the proposition before marketing fossilized it into language. Early commercial thinking could reveal that an elegant product had no credible path to a buyer. Design could expose that the proposed workflow solved a problem users did not actually experience—or that a modest interaction change revealed a much larger opportunity.
Velocity emerged because the organization could resolve consequential questions earlier, not because it learned to ask fewer of them.
UX Inside the Formation of the Venture
UX was hands-on from the beginning. We did not arrive after a founder had defined the product and ask how its interface should work. We worked directly with founders to determine whether the proposed problem deserved to be solved, who experienced it, what existing behavior surrounded it, and which portion of the idea could become a meaningful experiment.
That required moving fluidly among research, product framing, interaction design, organizational composition, and commercial plausibility. We were designing the MVP and, through it, the venture’s emerging theory of reality.
We helped teams distinguish an interesting technology from a viable product proposition. We translated raw technical potential into user value, system boundaries, and testable assumptions. We designed prototypes to produce evidence rather than merely enthusiasm. We identified which capabilities the team possessed, which it lacked, and which uncertainties deserved attention before code made them expensive.
My agency experience resurfaced in an unexpectedly useful way. Years of scoping ambiguous client work had taught me how to translate an emerging concept into approximate design and engineering hours, identify the specialists necessary to produce it, and construct a plausible statement of work before every detail was known.
At CA, those estimating mechanics became a venture-design instrument. A rough estimate 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. A founder’s aspiration became a provisional allocation of people, time, and uncertainty that the larger group could inspect.
The estimate made the idea discussable.
A Shared Language for Learning
Putting multiple capabilities around a venture did not automatically make them interoperable. Founders, engineers, designers, researchers, executives, and commercial leaders arrived with different professional dialects and different intuitions about what counted as progress.
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. Nobody needed to subscribe to a methodology with equal fervor, and we harbored no illusion that a sufficiently complete collection of canvases would cause a business to emerge spontaneously from the wall.
The value was vernacular.
Terms such as hypothesis, assumption, experiment, evidence, validation, customer segment, problem–solution fit, and minimum viable product gave people from different disciplines a common way to interrogate a venture. A founder could describe what they believed. Research could specify what evidence would alter that belief. Design could turn the uncertainty into an observable interaction. Engineering could identify the smallest credible implementation. Commercial partners could examine whether the proposed learning connected to a market.
Shared vocabulary reduced the cognitive overhead of translating among professional languages. We could spend less time establishing what someone meant by “validation” and more time examining whether the evidence deserved the name.
The purpose was not to make everyone think alike. It was to let different forms of thinking remain mutually intelligible while they revised one another.
Capability as a Reconfigurable System
Traditional product organizations tend to compose stable teams around durable roadmaps. An accelerator operates under a different temporal logic. The problem, market, product, and sometimes the venture itself may change before the team has developed a fixed identity.
That made reconfiguration one of our most valuable capabilities.
Design and strategy support could move toward the venture facing the greatest 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 perspectives could appear early enough to shape the proposition rather than being asked to package it after the product existed.
When evidence contradicted an assumption, we did not need to preserve the original composition of the conversation out of organizational habit. We could alter it. A venture could pivot, revise its MVP, narrow its market, recruit a missing capability, or stop before momentum became its only justification.
I came to see the Accelerator as a precomposed capability system rather than a collection of startups.
The relevant capabilities were available before any particular venture knew exactly when it would need them. They could be brought into consequential contact with a problem, released when their contribution had been metabolized, and recomposed elsewhere as the portfolio learned.
The shared frameworks made that 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.
Different Ventures, Recurrent Questions
The portfolio covered markedly different domains. Some teams explored predictive health and operational signal inside CI/CD environments. Others examined natural-language processing for customer insight, AI-assisted collaboration, developer configuration, network monitoring, or sensor-driven automation.
The same design questions recurred beneath those differences:
- What signal does this system detect, and what noise might it amplify?
- What does the person using it need to understand before acting?
- Where does prediction end and unsupported certainty begin?
- Which decision can be automated, and where must human judgment re-enter?
- What evidence would cause the venture to revise or abandon its current direction?
- What is the smallest implementation capable of producing that evidence credibly?
Those questions gave UX a role beyond interface production. Design became infrastructure for learning across the portfolio.
Reusable research practices, prototype approaches, workshop structures, usability checkpoints, and feedback systems reduced the amount of operational invention each new venture required. The products themselves remained specific to their users and domains; a predictive operations tool and an NLP-assisted insight platform had no reason to look or behave alike simply because they shared an incubator.
We standardized enough of the learning machinery that teams could preserve their attention for the distinctions that made their ventures valuable.
Productive Contact at Portfolio Scale
At Autodesk, the collaborative surface helped a team perceive one inherited system vertically. At Dremio, it helped designers cross a formidable domain boundary through consequential contribution. At CA Technologies, the philosophy operated at another scale: the surface had to support multiple ventures simultaneously and repeatedly.
The capability vectors were not limited to design disciplines. Founders saw opportunity and carried conviction. Engineers perceived feasibility and technical leverage. Researchers saw the difference between stated interest and observable behavior. Designers converted ambiguity into interactions that could be experienced and tested. Business leaders understood strategic fit and organizational sponsorship. Marketing and sales saw category language, buyers, channels, and the distance between curiosity and purchase.
When those capabilities remained sequential, uncertainty moved downstream and became more expensive. When they entered productive contact early, each venture could acquire a more complete model of itself while revision remained possible.
That contact also distributed ownership. People support what they help create, but the effect is deeper than buy-in. Someone who has influenced a decision understands more of its causality. Even when their preferred answer does not survive, they can see how their contribution altered the result and why the venture arrived where it did.
The final product could become a synthesis instead of a compromise assembled from fragments: an outcome no participant could trace exclusively to themselves because contact with the others had materially improved it.
Outcome
The Accelerator became a functional system for repeatedly exploring and shaping new product directions inside a legacy enterprise.
We could move a venture from proposition toward a staffed, funded, researched, scoped, and commercially legible MVP in under a month. Multiple ventures advanced from concept to viable product direction, with several supporting Series A–level outcomes. Emerging technologies that would have been difficult to evaluate inside the core portfolio gained enough space to be tested without being exempted from evidence.
The organization improved its ability to distinguish technologies worth watching from problems worth solving. Founders gained a clearer path through validation and MVP definition. Design and engineering estimates made ambition operationally legible. Reusable methods reduced ramp-up friction, while the broader capability surface allowed ventures to pivot without rebuilding their entire support system.
Workshops, prototypes, canvases, and books on the shelf were mechanisms. The results appeared in the ventures and in the organization’s growing capacity to create them.
The result was organizational optionality: CA Technologies gained a way to investigate futures beyond its established portfolio without destabilizing the business that still sustained it. New ventures created access to customers, conversations, and categories that the legacy technology stack would not have reached on its own. Even before a product achieved scale, the venture could increase the organization’s capacity to perceive where the market was moving.
What This Case Taught Me
CA clarified that speed and rigor are not natural adversaries. Poorly designed organizations trade one for the other because they treat collaboration as a sequence of handoffs. Each discipline receives a partially hardened decision, interprets it through local constraints, and passes the resulting compromise downstream.
A well-designed collaborative surface changes the topology. It brings relevant capabilities into contact while the work can still absorb them. Early friction prevents late reversal. Shared language makes reconfiguration possible. Estimation exposes hidden assumptions. Participation creates both stronger synthesis and a more durable understanding of why the result became what it became.
In the vocabulary of my design philosophy:
Collaborative Surfaces × Capability Vectors = Productive Contact
At CA Technologies, productive contact became a repeatable organizational capacity. Startups moved faster because the system could repeatedly find, compose, and redirect the intelligence required to create them.
That is what scale looks like in ambiguous work: not making every venture identical, but making the organization increasingly capable of learning what each one needs to become.