The Architecture, Engineering, and Construction (AEC) industry is a battlefield of colossal challenges: mind-bending project complexity, deadlines that make you question reality, and fees so tight they squeak. And yet, we keep hearing: “We need more innovation!” But what do we do? We hop from one shiny piece of tech to the next, forgetting that small improvements can significantly enhance our operations.
Computational teams challenges
Despite tech becoming more accessible and its adoption accelerating, there is still a significant gap in adopting computational processes and grasping how computational teams can supercharge design and delivery phases. Although computational designers have the potential to bridge gaps between deliverable teams and more specialised product squads, they are often misunderstood and not always recognised. For over two decades, we’ve discussed computational processes and thinking in the AEC space, but adoption remains a struggle, thanks to some persistent roadblocks.
Measurable outcomes: Without concrete ways to measure impact, it’s difficult for these teams to demonstrate their value and justify costs. As Peter Drucker famously said, “You can’t manage what you can’t measure.”
Business strategy misalignment: Computational teams often float like satellites, disconnected from the overall business strategy. This misalignment means their work doesn’t always sync with the organisation’s goals.
Short-term focus: Due to the brief phases of projects, there is often pressure to produce quick results and move on to the next project without extracting lessons learned and possible standardization from the processes. This short-term mindset hampers the ability to develop long-term strategies and improvements.
Resistance to change: Cultural barriers pose significant obstacles to the successful implementation of computational design. These challenges require a culture shift, challenging the status quo of traditional design processes. Without proper change management and leadership support, achieving this cultural transformation can be difficult.
Knowledge gap: There is often a knowledge gap between digital teams and other departments or leadership, particularly in understanding how technology is developed and digital products are built. This gap can lead to miscommunication and underutilisation of computational design capabilities.
Limited accessibility: For computational design to be truly empowered, it needs to be accessible and usable by everyone in the organisation. If the tools and processes are too complex or siloed, it can limit widespread adoption and impact.
Workflow integration: Companies may struggle with the lack of integration with existing workflows. Integrating computational design tools into established processes can create friction between traditional and new methods, making it difficult to achieve seamless adoption.
Insufficient infrastructure: These teams may lack the necessary tools, capabilities, and environments to test and implement their solutions effectively. This includes appropriate software and supportive infrastructure. Misaligned requirements between computational folks and IT often don’t help.
Talent retention: Companies may struggle to retain top computational design talent if they don’t provide opportunities for growth, learning, and working on cutting-edge projects. Talented individuals often seek environments where they can continually learn and apply advanced techniques, and without these opportunities, they may look elsewhere.
The Product Team Topology
Computational people/teams are critical assets for driving digital strategies and fostering innovation within organisations, directly impacting project outcomes and value. By leveraging specialised, automated teams working globally, organisations can develop tools and continuously re-evaluate processes for each project. These teams deliver on multiple projects and build software that fits perfectly within the internal market and, potentially, the external market.
Those teams need to be elevated into functional teams with specific objectives, and they can be identified as follows:
Platform Team
Platform teams provide foundational services and tools that other teams use to deliver their work autonomously and efficiently. They might develop and maintain a suite of digital tools and services, such as cloud-based collaboration platforms, data analytics tools, or project management software. These platforms enable product teams to focus on their tasks without worrying about the underlying infrastructure.
Product Team
Product teams are responsible for researching, developing, and implementing digital tools and processes. They are cross-functional teams with members from many different functional areas. They have shared goals and commitments, and they generally self-manage. Consider the example of product development teams comprised of developers, computational designers, product managers, and analysts; sometimes, they also include members from marketing and business development. These teams work on specific workflows, such as particular projects, products, or services. They might handle the digital aspects of a specific construction project or focus on segments like building information modelling (BIM) or digital twin technology. By being close to the end-users or clients, they deliver value quickly and independently, maintain better stakeholder relationships, and enable faster iterations of outcoming feedback to the other teams, ensuring continuous improvement of tools and processes aligned with a broader vision and strategy. They also support other teams by helping them overcome obstacles and fill capability gaps, acting as informed advisors and providing guidance on best practices, frameworks, and technologies.
When building a software solution, many companies burn capital because they make numerous assumptions. While assumptions are often inescapable, the key lies in managing them effectively. By integrating product teams into projects from the start, assumptions can be identified and addressed early on, converting them into actionable knowledge. This approach ensures that solutions are relevant and cost-effective, both for internal teams and the external market. While AEC enterprises often make the mistake of treating technology development as purely technical, service-first approach involves using humans to speed up the Observe, Orient, Decide, and Act, (OODA) loop, a decision-making framework developed by military strategist John Boyd. By applying the OODA loop, digital teams can quickly gather and analyse information, make informed decisions, and implement solutions. This strengthens the connection between design and delivery phases, improves knowledge transfer, raises technology awareness, and encourages internal collaboration.
Enterprises must move beyond merely talking about digitalisation and focus on empowering and creating integrated product teams. Without a proper strategy, hiring disconnected individuals will waste the potential of digital services and hinder the development of effective software and innovative processes.
Product Team Model
The industry mantra of faster, cheaper, and better creates a demanding environment. Real innovation demands that product teams hit the brakes, dissect, and rebuild our processes for peak efficiency. These teams are key resources in questioning existing methods and exploring new possibilities, fostering a can-do mindset that propels projects forward and leads to extraordinary results. This mindset is the foundation for successful construction projects that go beyond the ordinary, requiring a commitment to change how product teams operate and continuously improve.

To guarantee your teams don’t crash and burn, start by hammering out a business model that screams technical excellence and is packed with top-tier talent. Incorporating agile methodologies is also crucial. Structure your team and processes to ramp up productivity without bleeding money, and fostering collaboration through shared digital workspaces, organizations can maximize efficiency and innovation.
A key aspect often overlooked is the funding model. Traditional project-based organizations typically rely on executive leadership to allocate budgets based on a prioritization schedule of big-ticket items stacked up against historical overhead expenditures. This outdated practice often results in management struggling to manage an imprecise and failing budget.
In contrast, successful product teams focus on funding capacity and outcomes, not throwing money at vague, grandiose plans. Instead of an annual budgeting exercise where business leaders seek large sums of money for grand ideas that take all year to deliver, product teams should make stream priorities clear, show continuous value delivery, as detailed in the article “Funding Model: The Seven Domains of Transformation” from IT Revolution.
I firmly believe that with the right people and the right skills, a strong product team can succeed regardless of organisational design. I have seen enough teams over the years achieve the impossible, even in the most bureaucratic of organisations, to know that a motivated group of empowered and skilled cross-functional professionals can overcome any obstacle. Strong product teams are adept at navigating challenges, and inevitably, organisational design will be one of those challenges, where an intrapreneurial mindset can be invaluable. Such a mindset helps teams maneuver through the business context, identify opportunities, overcome bureaucratic hurdles, and push innovative ideas forward. By embracing this mindset and approach, organisations can truly unlock the potential of their digital teams and drive extraordinary innovation.
A huge thank you to Amar and Ben for their invaluable support.