5 Steps To Building An Infrastructure Company that Operates Without you
From Founder-Led to Process-Led: Structure and Empower Middle Management
If you really want to scale your infrastructure portfolio, you must attract capital at scale, to attract capital at scale, you must resource for the future you want.
Since November 12, 2025, on Notes on Project Development, I have systematically been discussing resourcing for the future you want,
I have systematically explored the necessity of separating a dedicated internal Project Development and Financing Office (PDFO). Detailing the roles that will focus on building your pipeline and take them from concepts into bankable projects and raise capital.
I described the evolution of a company through 4 stages of maturity and the types of investors companies at each phase could attract.
I went on to cover the necessary evolution of the C-Suite, where the CEO moves from “Chief Everything Officers” to appointing other strategic leaders, then I briefly mentioned the need for middle management and standard operating procedures.
I then tackled the governance upgrade, establishing that companies with Key Man Risk couldn’t unlock institutional capital at scale and a functional board was essential. Covering how a company could begin with an Advisory Board as practice before setting up a Board of directors with fiduciary duties.
This note will expand on setting up and strengthening the shock absorbing layer of your organisation - the middle management.
Companies transitioning from start up to growth phase will start to require more execution oversight. To do this, the institution requires an operating structure that is fit for purpose.
Enter middle management, the primary anchor for processes, tools, procedures and resources that deliver the value promised, repeatedly and at scale.
Why you must decentralize.
You Need Capable Shock absorbers
In the startup phase, centralization was a survival mechanism. Speed was currency. But in the growth phase, centralization becomes a liability, when too many decisions rest on person’s shoulders, there are challenges when issues arise with that person.
If those in the C-Suite are doing your job of maintaining a clear vision, charting strategic direction, maintaining the administrative side of having an effective board and governing a growing institution then they can no longer have the time and energy to chase every single thing down.
Middle management who are often unfairly maligned as introducing bureaucracy, become the shock absorbers between executive strategy and tactical execution.
Investors looking at your institution want to see an effective organizational chart, which must include this layer.
They want to know that if there are people to delegate to, people to execute at necessary levels of detail, people to also provide structure close to the ground.
They need to know that of the CEO and CFO are away for any reason like illness, or a fundraising road show, the assets that have already been built will continue to run smoothly.
That the engineering team knows how to approve a design change and the finance team knows how to process a drawdown request without operations grinding to a halt.
Scaling requires Specialized Competencies
As infrastructure companies scale, the jack-of-all-trades generalist model becomes a liability.
Early employees wearing multiple hats cannot maintain the depth of expertise required for increasingly complex technical, financial, and compliance demands.
To achieve functional excellence, organizations must transition to specialized roles managed by a capable middle management layer.
These functional experts possess the specific skills required to translate high-level executive strategy into tactical realities.
By decentralizing functional authority to these middle managers, the C-Suite is freed to focus on long-term vision, while the organization gains the specialized operational capacity necessary to deliver complex projects efficiently, ensuring that specific functional standards are met without burdening the leadership.
Building the Middle Management Layer
First Map the internal value chain – Identify Core and Support
To map your value chain effectively, you must distinguish between activities that directly generate value for the customer – Core and those that provide the resources to allow that value creation to happen – Support.
Core Processes (The “Value” Activities)
Core processes are the primary tasks of the organization, the things the company has been set up to do. These are the series of steps and activities that physically create the product, market it, deliver it to the buyer, and provide post-sale support. Create and deliver the value that the customer pays for.
For an infrastructure developer and operator, the core process generally flows through these distinct phases
Origination: Identifying the market need, customer base, the project concept.
Development: Taking the project through feasibility, design, and permitting and financing.
Construction: The physical creation of the asset.
Operations: Managing the asset to established service levels in exchange for fees.
If your company also produces the products it uses in completing projects, then manufacturing is considered a core process.
Primarily the Commercial(or Business Development), Project development and the Operations teams of an Infrastructure Company perform the steps in these stages.
If your company stop doing these things, there is no revenue, no project, and no business, no growth. These are processes that directly touch the customers of your services.
Support Processes (The “Enable” Activities)
Support processes exist to obtain, replenish, and manage the resources needed to perform the primary tasks. They are the internal functions that support the Core.
But they do not directly create the output the customer pays for. These processes are covered in these functions:
Finance and Accounts
Maintenance
Procurement
IT support
Human Resources
Customer Service
HSE & Security
Legal
Why You Must Map Core Processes First
The core processes are the internal customers of the support processes and until you have understood the needs of the core you cannot really have effective support processes.
o The Logic: You cannot design an effective HR recruitment process (Support) until you have mapped and identified exactly what skills e.g., financial modeling or civil engineering are required for core stages
o The Risk: If you map Support first, you create “functional silos” where HR or Finance optimize their own internal efficiency rather than optimizing the speed and quality of the team that creates new business or generates revenues
Doing things this way allows the owners of Core Processes have the authority to define what they need from Support functions.
o The Logic: The requirements for IT, Legal, and HR must be derived from the operational realities of the project and Asset lifecycle.
o The Risk: If Support processes are mapped and fixed first, they become constraints. The organization becomes inwardly focused on rules rather than outwardly focused on project execution.
Second Identify Transition and Handoffs Points Between Functions/People
The greatest risks in your value chain lie at the Transition Points. These are the points where responsibility shifts from one functional team to another. Bottlenecks are found here, process quality drops happen here when upstream activities are not delivered or received correctly.
Collaboration is important at these points to maintain traction and prevent stalling or project failure.
What documents are involved, how are they sent? Who on the team approves their sending? What signals show that the baton is formally passed from function to function. When passed what must them be done to kick of the next steps?
Even within phases of the core processes there are many hand over points either with core execution functions or with support functions.
It is very important that these transitions are known and identified to ease definition of processes, systems and tools and design of structure of an organisation that is effective in meeting the organisations needs.
Third Choose Your Organisational Structure Design – Functional or Matrix
Option 1: The Functional Organization:
The Functional Organization is the traditional hierarchy. It groups employees by specialty, Engineering, Finance, Legal, Operations, Procurement
For example this structure, a Civil Engineer reports to the Head of Engineering, and a Financial Analyst reports to the CFO.
How it works on a project: Workflows vertically, not horizontally
For example, when a project requires engineering, the request goes through the up to the Head of Engineering, who assigns the work to a subordinate. Once the engineering work is done, it is effectively “thrown over the fence” to the next department (e.g., Finance or Procurement or Operations).
Pros:
Technical Excellence: It fosters deep expertise. Engineers work with engineers, allowing for knowledge sharing and standardization of best practices.
Clear Career Paths: Employees have a clear “home” and a defined path for promotion within their discipline.
Budget Control: Functional managers maintain absolute control over their budgets and resources.
Cons:
No Single Accountability: There is no single individual directly responsible for the total project. Responsibility is fragmented across department heads.
Slow Response: Issues that cross functional lines (e.g., an engineering change impacting the financial model) must travel up one chain of command and down another to be resolved.
The “Silo” Effect: Departments optimize for their own goals, not the company’s goals. The legal team might draft a “perfect” contract that is commercially unviable, or engineering might design a solution that finance cannot fund.
The challenge at transition points is felt keenly in this structure.
Option 2: The Matrix Organization
The Matrix Organization attempts to combine the technical strengths of the functional structure with the project focus of a dedicated team. It superimposes a horizontal project structure over the vertical functional hierarchy.
How it works on a project: Workflows vertically and horizontally.
Employees have two bosses: a Functional Manager (e.g., Head of Engineering) and then a Project Manager (PM).
The Project Manager controls the “What” and “When” (Project objectives, schedule, budget).
The Functional Manager controls the “How” and “Who” (Technical standards, staffing assignments, methodology).
Pros:
Resource Efficiency: This is critical for sharing scarce, expensive resources (like a Senior Financial Analyst or ESG Specialist) across multiple projects. They are not “locked” into one project effectively sitting idle during quiet periods.
Project Focus: There is a single point of responsibility (the Project Manager) for project success, ensuring integration across disciplines.
Retention: When a project ends, the employee still has a “home” in their functional department, reducing anxiety and turnover compared to project-only structures.
Cons:
The “Two Boss” Problem: This is the greatest weakness. Employees can be caught in a tug-of-war between the PM (who wants speed) and the Functional Manager (who wants technical perfection or cost containment).
Conflict: It requires high levels of communication. Without clear rules, resource allocation becomes a constant negotiation (or argument) between PMs and Functional Managers.
Overhead: It requires more administrative effort to manage the dual reporting lines.
Which One Works for You?
Infrastructure development and financing is fundamentally project driven.
Origination of sites, Development and financing of sites, Construction of Sites all requires a strong collaborative effort of many functional experts.
However, Operations and maintenance may thrive under a more functional expertise.
For the Origination, Development and Construction and Handover, my recommendation is that you set up a Matrix Organisation.
In a functional structure, projects fall behind schedule because no one has the authority to integrate the disparate pieces (legal, technical, financial) into a cohesive whole.
Having Project Managers with significant authority over the quality and the flow of work becomes vital to execution success.
The Functional Managers (Heads of Department) are still required, as support centres, ensuring their staff are trained and following quality standards, even when daily direction for each project comes from the Project Manager.
Why this fits the growth phase:
Scaling the Pipeline: It allows your core specialists work on 3-4 projects simultaneously. Your ESG specialist can manage the ESIA for Project A while scoping Project B.
Maintaining Standards: Your functional heads ensure that as you scale, the quality of engineering or financial modelling remains consistent across all projects, mitigating the chaos or poor standards that plagues rapid growth.
Flexibility: You can assign staff full-time to a critical project for a month, then dial them back to part-time, maximizing utilization.
Rules of the Matrix
To avoid the “Two Boss” chaos, Uncertainty about project ownership, a sense of disconnect for cross functional project managers, a matrix must implement the following:
Anchor The Project Managers: Project Managers still require a functional home of their own with an authority that helps them be assigned/allocated. They also require standards methodology and standards for how projects are run. A Project Management Unit, with a head project manager could serve this role.
Conflict Resolution Protocol: Accept that conflict is inevitable in a Matrix. Establish a protocol where conflicts about resources (e.g., “I need the analyst now!”) are resolved by the resource needs of the portfolio, not the loudest voice.
Align Performance Management: You must update KPIs and performance management to recognise and reward both functional excellence and project delivery. If staff are only evaluated by Functional Managers on departmental tasks, project work suffers. Project Managers must also appraise staff assigned too. Formalize this dual-input review process to ensure employees prioritize project goals alongside technical standards.
Fourth Define the Authority Delegation Clearly
Now that you have a clear process, identified the functions involved, defined an organisational structure that is suitable for execution and project delivery, next is to define what level of authority to delegate and to who.
There are two major types
1. Decision Authority: Who is the deciding voice on the quality of input, resources, outputs of execution?
Who confirms a Contractor Selection, before final sign off?
Who confirms the Site should be developed?
Who confirms the technical design?
Who confirms the choice of technology?
2. Financial Authority: Who gets to authorise expenses based with a specific financial threshold? An illustrative example here, NOT a recommendation or best practice.
Site Supervisor: Can approve expenses up to N50,000.
Project Manager: Can approve up to N500,000.
Head of Engineering: Can approve up to N2,000,000.
COO: Can Approve up to N5,000,000
CEO/Board: Approves anything above.
Fifth Draft and Maintain Standardize Operating Procedures
Structure and Delegation require documentation. You cannot delegate if the “how-to” is only in your head. You must document everything from how to format a budget to how to ground a generator.
This allows your middle managers to enforce standards without you being present.
The how of executing processes defined in exact detail through the SOPs.
Relying on tribal knowledge becomes a critical vulnerability. Institutional memory must migrate from the heads of specific individuals into the institution itself.
How do we procure materials? How do we onboard a new hire? How do we report a safety incident?
SOPs ensure consistency and scalability. They allow you to train new employees without you personally mentoring each one.
Then ultimately these middle managers then become process owners and custodians of these SOPs.
SOPs cannot be static documents. Middle managers must implement a cycle of continuous improvement, periodically reviewing and updating procedures to reflect new technologies, regulatory changes, or lessons learned from past projects.
They must ensure version control is strictly managed so that the team never works from outdated specifications. Finally, the existence of maintained SOPs is a primary bankability signal.
When institutional investors conduct corporate due diligence, they look for these documents as proof that the company is a protected, predictable, and professional structure capable of deploying capital at scale. An organized back office with updated process manuals proves that the business is a machine independent of its CEO and ready for institutional capital at scale.
Bringing it all home
A strong board governs effectively only when there is a well managed organization to report on.
A CEO’s vision is realized only when specialist teams can collaborate to execute it.
Building up effective Middle management is a vital part of building an organisation that can scale.
From value chain to SOPs—is the practical implementation manual for that viability. It systematizes growth, turning strategic intent into repeatable, investor-grade execution.
As you implement this, you are not just solving for today’s bottlenecks; you are architecting the platform that will support your next phase of projects, your next round of capital, and your transition from a growing company to an enduring institution.
It proves your company can function—and thrive—independent of its founders. When due diligence begins, these documented systems demonstrate a command of operational risk that is non-negotiable for institutional partners.
Your future pipeline and the capital required to build it may not depend on your next great idea, but on the strength of the team that will execute it.
This is work that you can start now, because this the part of resourcing for the future you want that is most in your control as a Founder and CEO of an infrastructure company.