Analyzing the Manager’s Role in AEC Tech Teams
How can we drive better innovation in the AEC Industry? The answer is through specialized knowledge.
When you're developing technology for a specific industry as complex as the AEC (architecture, engineering, and construction), the Project Manager role can be complicated to nail right: they need to understand the industry (better even if you come from it, e.g., being an architect/engineer), understand the business with its problems and tools, and also the technology you're using to build those tools. It's a pretty complex mix of knowledge to get.
The traditional PM role
In tech, the PM role is usually focused on the overall product strategy and business goals and managing the execution. If it's a different person, the PO role focuses on translating that to actionable tasks for the developers.
My issue is: how do you do that with enough efficiency if you're primarily a middleman and don't understand what the devs need to do their tasks? How do you give them what they need and unblock them if you don't fundamentally understand what those needs are and don't understand the underlying tech?
At e-verse, we've been trying different solutions to this problem for three years across over sixty projects. Through making many mistakes along the way, I believe we've come much closer to understanding what a manager needs to carry out so many innovative projects in the industry.
The Product Engineer
Agile? Waterfall? Scrum? Mix them up and see where you land, understand the rules, and bend them to get what you need for your current team, skill sets, challenges, and company scale. Adapt, tinker, make mistakes, and change collaboratively. That is my philosophy: practice before theory.
I'm not fond of theories or names and prefer pragmatism over playing by the book. So, I use names to describe something more quickly, but these names are nothing more than a "sign" pointing at an underlying concept. In this case, the sign is "product engineer," pointing to an idea of a role that mixes product and engineering knowledge.
The Efficiency of a Unified Role
I think that is an outstanding balance: deeply understanding what we're doing, why we're doing it, and how we're doing it, enabling organizations of all sizes, especially tiny ones that can't afford a PM and a PO, plus a technical leader, to make decisions faster: the Product Engineer covers most of the other roles in a single person, avoiding all communication, middle management, and back-and-forth, making better quality decisions faster, working directly with the clients and the team.
The elimination of miscommunication and bureaucracy is enormous. In traditional settings, the PM and PO must constantly communicate and align their understanding of the project. This back-and-forth can lead to delays, misunderstandings, and misaligned priorities. Having a single person make decisions across multiple fronts drastically reduces these issues. That person's ownership of the project will also be much higher.
A Product Engineer, equipped with a comprehensive understanding of the project's business goals, user needs, and technical constraints, can make informed decisions quickly. This agility is particularly beneficial in the AEC industry, where timely decisions can make or break a project since the stakes are usually high. The PE's direct involvement in strategic planning and technical execution ensures that product development remains aligned with the overarching business objectives without losing sight of the technical feasibility.
Specialized Knowledge
One of my favorite entrepreneurs, Naval Ravikant, speaks of the power of specialized knowledge—expertise that combines multiple domains to create unique and valuable insights. The Product Engineer exemplifies this concept. The PE becomes an indispensable asset by merging product management, hands-on technical abilities, and industry-specific knowledge. Specialized knowledge, as such, is not easily automated or outsourced, and it's obtained mainly through having skin in the game, in this case, by being involved in technology products from different standpoints.
The concept of specialized knowledge is evident in the case of an architect who codes. This individual possesses a deep understanding of architectural principles and design, coupled with the ability to translate these insights into technical specifications and code while understanding why and where to apply them from a business standpoint. This dual expertise is an excellent case of specialized knowledge, enabling a seamless integration of two areas of expertise that aren't necessarily related (and whose combination few people understand). A great candidate for a Product Engineer!
An architect who codes can:
Understand and anticipate client needs with the precision of someone with firsthand experience in architecture, empathizing with the end users.
Translate architectural requirements into technical solutions, ensuring the end product aligns perfectly with its vision and functional needs.
Make swift, informed decisions on both design and technical fronts, reducing the need for extensive back-and-forth communication and accelerating project timelines.
Bridge the gap between creative and technical teams, fostering a more cohesive and collaborative work environment.
Final Thoughts
The AEC industry demands a nuanced approach to project management. The Product Engineer role offers a pragmatic solution that leverages deep industry and technical knowledge to drive innovation and efficiency. This role is precious for smaller organizations, as it consolidates multiple responsibilities, reducing overhead and fostering a collaborative, agile work environment.
By breaking down silos and streamlining decision-making, the Product Engineer ensures that technology development in the AEC industry is not only efficient but also innovative and responsive, even anticipative, to client needs. The PE role is a model for effective, integrated project management.
Embracing the concept of specialized knowledge may represent the future of agile, expert-driven project execution in the AEC and beyond, especially in the era of automation and AI since specialized knowledge is the kind of knowledge that is most hard for non-human systems to obtain.