Morakinyo (Akin) Isaac-Olaniyi is Associate Director, Talent Development and Performance Management at IHS Towers. He has previously held senior HR and talent roles at Coca-Cola Hellenic, Subsea 7 and British American Tobacco. In this interview with ITPulse, he discusses workforce planning, headcount decisions, capacity modelling, outsourcing, operational efficiency and how HR can better connect people decisions to business performance.
You spent years working inside large organisations where people, operations and budgets had to work together. What first made you question the way businesses decide how many people they need?
What made me question it was seeing headcount conversations start with the number rather than with what the business was actually trying to achieve that year. One leader would say the team was stretched and needed more people, while another would say the budget required a reduction. Both could argue their positions passionately, but often nobody had first established the demand, the service level, the process or the productive capacity behind the work. That taught me that headcount is really an output, not a starting point. I am less interested in asking how many people we had last year than in asking what the operation needs to deliver, under what conditions, and how much well-designed human capacity that genuinely requires. Historical headcount and budget are useful inputs, but neither of them is a workforce model.
You have managed workforce planning across operations involving nearly 1000 employees, several hundred outsourced workers and more than 25,000 tower sites. When you look at an operation of that scale, where do you begin when deciding the right headcount?
I normally begin with the service and operating model, because at that scale a single ratio can hide a lot. I want to understand the customer or network outcome we are trying to deliver, the activities that create it, how often they occur, where they happen and what service, safety and quality standards apply. Then you start seeing the differences that averages miss: peak demand, travel time, shift coverage, planned versus unplanned work, skill requirements and critical-role cover. From there, I look at the process and the technology. Before adding people, I want to know what can be removed, simplified, automated or redistributed. Once the work is clear, I translate the remaining workload into productive hours, allowing realistically for leave, training, meetings and absence. The end result is not one magic enterprise ratio. It is a set of capacity assumptions that leaders can see, challenge and test.
Many organisations start workforce planning with a budget and then work backwards to determine what can be afforded. Why is that approach problematic, and what should come first?
The problem is that a budget tells you what you can afford, but it does not tell you what the work actually requires. If you start with the budget, you can easily end up cutting roles to fit a number without ever asking what that means for service, risk or workload. You can also keep roles for years simply because they are already sitting in the cost base, not because anyone has tested whether the work still needs to exist. I prefer to start with demand. What does the business actually need to deliver? Then I look at the work itself, how it should be designed and what capacity that requires. Cost absolutely matters, but I want it to come after we understand the operational requirement. Otherwise, the budget quietly makes the workforce decision for you. In practice, I would usually take leadership through a few scenarios: what full service delivery requires, what the available budget can support, and what gap exists between the two. Then everyone is making a conscious trade-off rather than pretending the number has no operational consequence.
How do you translate workload into the number of people an operation actually needs without relying on assumptions or historical headcount?
I start by getting the real volume of work and the time it takes to do it. That might be transactions, calls, tickets or site visits. I do not want a guess if we can measure it, and if the data is not available I am quite happy to go and time the work myself or pull what I can from the system. Then I account for the work that does not show up neatly in a transaction count, things like meetings, administration and scheduled maintenance. The next piece is realistic productive time. Contracted hours are not the same as hours available for productive work once you allow for leave, training, breaks and downtime, and that is where a lot of workforce plans go wrong. From there the maths is fairly straightforward: total workload hours divided by realistic productive hours per person. For field teams, travel time and site access constraints belong in the workload too because they consume real capacity. I still do not trust the model until I have checked it against what is happening on the ground. If someone asks me why the answer is 40 people rather than 35, every important input should be something I can point to and defend.
When an operations leader says, “My team is overwhelmed and we need more people”, what evidence would you need before approving ten additional positions?
Before approving anything, I would want to understand what ‘overwhelmed’ actually means in that team, because headcount is only one possible answer. I would look at workload trends over a reasonable period, not just a difficult week, and then look at where people’s time is going. Sometimes the issue is genuine growth in demand. Sometimes people are spending hours on manual work that should be automated, approvals that belong somewhere else, or rework created by an upstream problem. I would also check vacancies and attrition, because if approved roles are sitting empty the answer may be to fill them and understand why people are leaving rather than create ten more positions. Then I would put the workload against a capacity model and ask what happens if we do nothing. Are we missing SLAs? Is there a safety risk? Are complaints rising or are we burning people out? My answer to the leader would not be yes or no on day one. It would be, ‘Let’s build the case together.’ If the evidence says ten people, fine. If it says five, or zero and a process fix, that is the recommendation I would make.
Outsourcing is often presented as a way to control costs and improve flexibility. How should a business decide which roles belong within its permanent workforce and which can be outsourced?
I do not start with cost because the cheapest-looking option can become expensive very quickly if you outsource the wrong work. I start with what the role means to the business. If it sits close to competitive advantage, customer experience or a capability the organisation really needs to own, I am naturally more cautious about moving it outside. The same applies where performance depends on deep organisational knowledge or continuity that builds over time. On the other hand, outsourcing can make a lot of sense where demand is variable, the work is well defined and the business genuinely benefits from being able to scale capacity up and down. I also look closely at risk and oversight. If a role carries significant regulatory, safety, security or reputational consequences, the business may still own the outcome even when a vendor performs the work. Cost comes in after those questions, and even then I want the full cost, including management overhead, quality risk, transition cost and what it would take to bring the work back in-house. So for me, the practical rule is to outsource work that is variable, well defined and relatively low-risk to get wrong, while keeping closer control of work that is core, knowledge-heavy or carries consequences the organisation cannot simply contract away.
You have worked across regional operations where the same job can require different levels of capacity in different locations. How should geography and operating conditions influence workforce decisions?
Geography is a real demand driver, especially in field operations. Two people can have the same job title and completely different productive capacity simply because one covers a dense urban cluster while the other spends hours travelling between remote sites. I have used telemetry and trip data, actual GPS and travel-time information, to see that difference very clearly. Then you add access conditions, security requirements, terrain, road quality and site access windows, and suddenly a national average stops being very useful. Some locations also carry greater operational or safety risk, so they may need more cover even when their transaction volume is lower. What I prefer is to build one workload-to-capacity logic and then allow the local inputs to change by region or cluster. That gives you consistency in the method without pretending every location operates under the same conditions. I still validate it with the people on the ground because the data gives you the shape of the problem, but the field teams will usually tell you what the model has missed.
Workforce dimensioning can lead to restructuring and changes to spans and layers. How do you make sure the process is being used to improve how work gets done rather than simply to justify reducing headcount?
The practical rule is to outsource work that is variable, well defined and relatively low-risk to get wrong, while keeping closer control of work that is core, knowledge-heavy or carries consequences the organisation cannot simply contract away
I deliberately separate workforce design from a headcount-reduction target. The work has to come first: what needs to get done, how it should flow, where the bottlenecks are and where there is duplication. If I begin that exercise with a savings number sitting in front of me, it is very easy to start reverse-engineering the organisation to hit the target rather than designing what the operation actually needs. I treat spans and layers the same way. Too many layers can slow decisions and add cost, while spans that are too wide can leave managers unable to manage properly, so the question is whether the structure helps the work. I also like to show leadership more than one scenario and make the trade-offs visible. If a role is removed, I want to know where the work goes: whether it is automated, absorbed somewhere sensible or eliminated because it no longer adds value. If nobody can answer that, the design is not finished. Once a change is agreed, I manage it as a real change process, using structured methods such as ADKAR rather than treating restructuring as an announcement. The test I keep in mind is simple: if every workforce exercise I run somehow concludes that we need fewer people, I should probably be suspicious of my own process. Sometimes good design tells you that you actually need more capacity in the right places.
HR is often expected to become a strategic partner to the business. What must HR understand about an organisation’s operations before it can credibly advise leaders on people, productivity and structure?
HR has to understand how the business creates value and where that value can break down. That means knowing the customer promise, the revenue and cost drivers, the operational KPIs, service levels, technology, risk controls, work volumes and the capabilities the operation cannot afford to lose. Without that context, it is very easy for HR advice to fall back on generic benchmarks or policy language. I encourage HR partners to get close to the operation: walk the process, visit the sites, listen to frontline employees and understand the unit economics. Then, when a leader asks for more people, a restructuring or a new capability, HR can ask useful business questions. What demand changed? Where is the bottleneck? What work will stop? Which outcome should improve? For me, that is where strategic partnership becomes real, when HR can connect a people decision to the mechanism through which the business actually performs.
Morakinyo (Akin) Isaac-Olaniyi is an HR and Product leader with more than two decades of experience spanning talent, organisational development, workforce strategy and technology. After several years contributing HR domain expertise to Eazipay’s Product development and subsequently serving as fractional Head of Product, he became Chief Product Officer in October 2025. In that role, he is responsible for Product strategy, prioritisation, customer adoption and alignment across Product, Engineering and commercial teams. His approach to Product leadership draws heavily on his experience solving people and organisational problems across multinational and complex operating environments.