Following his contribution to Accenture’s Work.com industry publication and his election as a Fellow of the Institute of Management Consultants Nigeria, the Nigerian Salesforce specialist discusses the decisions behind dependable enterprise systems.

In June 2020, Accenture’s Australia and New Zealand Salesforce Business Group published Outmanoeuvre Uncertainty: Return to Work with Work.com, an industry point of view examining how organizations could coordinate workplace operations during the COVID-19 crisis.

Nigerian Salesforce specialist Olaniyi Badmus contributed to the publication while working as a Senior Salesforce Consultant and Manager at Accenture.

Three months later, the Institute of Management Consultants Nigeria elected him as a Fellow. Together, the publication and professional recognition provided a timely basis for this interview.

Badmus entered technology in 2004 and has since worked across the United Kingdom, Nigeria, New Zealand, and Australia. His assignments have covered telecommunications, healthcare, logistics, financial services, consulting, and pharmaceutical distribution.

A technology correspondent covering enterprise software contacted him because his record combined frontline support, regulated systems, integration, platform management, applied research, and the workplace challenges confronting organizations in 2020.

In this interview, Badmus discusses his career and responds to five practical industry scenarios designed to test how enterprise principles operate under real pressure.

What did this year reveal about the difference between owning technology and being operationally prepared?

Organisations might own capable platforms and still lack readiness. Preparation depends on governance, trained users, reliable data, defined decision rights, and tested processes. During a disruption, weaknesses become visible quickly because teams must change operations while maintaining security and service continuity.

The lesson is to design resilience before an emergency. Leaders should know which systems support critical processes, who owns each decision, how data moves, and what teams will do when a platform or integration fails. Real-life scenario one.

A company wants employees back onsite within two weeks and plans to collect health declarations through Salesforce. What would you do first?

I would begin by defining the legitimate purpose, minimum information required, authorized users, retention period, and legal or policy obligations. The team should involve privacy, security, human resources, operations, and employee representatives before configuration begins.

I would separate sensitive information from general workforce records, apply role-based access, enable audit history, validate data, and document deletion rules. The organization should explain the process to employees in clear language. A rushed form without governance creates privacy, trust, and data-quality risks.

Real-life scenario two. A major Salesforce release fails on Friday evening, hours before a national campaign. What is your response?

The first decision is whether to fix forward or restore the last stable version. That choice depends on impact, available time, test evidence, and rollback readiness.

I would activate the incident process, assign technical and business leads, preserve logs, and stop uncoordinated changes. The team should restore essential service, communicate factual updates, and record each decision.

After stabilization, it should conduct a root-cause review covering code, configuration, dependencies, testing, approvals, and deployment controls. The purpose is learning and prevention, not blame.

Real-life scenario three. An audit finds that hundreds of healthcare users hold broader Salesforce access than their jobs require. How would you address it?

I would treat the finding as an active control weakness. The team should identify exposed objects and fields, determine whether inappropriate access occurred, preserve evidence, and notify the responsible security and compliance leaders.

Next, I would map access to job functions, remove unnecessary permissions through a controlled change, test critical workflows, and establish periodic access reviews. Profiles and permission sets need named owners. New access should require approval, and role changes should trigger prompt review. Security is an operating process, not a one-time configuration.

Real-life scenario four. A senior executive demands a rapid integration, but the technical team identifies data and security risks. How should a Salesforce leader respond?

The leader should translate the technical concerns into business consequences. Instead of saying the integration is unsafe, explain which data is exposed, what could fail, how customers or operations might be affected, and which controls are missing. I would present options with time, risk, and cost implications.

One option might deliver a restricted first phase using limited data and monitoring. Another might delay release until essential controls are complete. The executive owns the business decision, but the technical leader must make risk visible and document the agreed position.

Real-life scenario five. An organization launches a technically sound CRM, yet employees continue using spreadsheets. What went wrong?

The program likely treated deployment as completion. Adoption begins with process design and user involvement. Teams need to understand how the system supports their work, where responsibilities change, and how leadership will respond to practical concerns.

I would study why users avoid the platform through interviews, usage data, support records, and workflow observation. The solution might require training, simplified screens, better automation, clearer ownership, or corrected data. Leaders should measure adoption by meaningful behavior and outcomes, not login counts.

How did your early career prepare you to answer these operational questions?

At Telefonica O2, I learned incident management, user support, administration, reporting, and data quality. Hadmor Nigeria strengthened my ability to translate business requirements into technical specifications. Fujitsu New Zealand developed my experience with severe incidents and platform administration.

At Health New Zealand, formerly HealthAlliance, I worked across Salesforce, Microsoft Dynamics CRM, clinical applications, data warehouses, integrations, and delivery pipelines. New Zealand Post Group, Pepperstone, and Accenture expanded my responsibilities across enterprise delivery, testing, integration, security, and stakeholder coordination.

Why has DevOps become central to your Salesforce work and research?

Salesforce environments change constantly. Without version control, peer review, testing, deployment records, and recovery procedures, teams create avoidable risk. DevOps provides a disciplined path from requirement to production while preserving accountability.

My 2020 research compares Copado, Flosum, and Salesforce DX across enterprise contexts. Tool selection should follow operating requirements. Organizations need to assess team structure, automation, security, audit needs, release volume, and existing development practices. No product substitutes for a coherent delivery model.

What does your election as a Fellow of the Institute of Management Consultants Nigeria mean to you?

The fellowship recognizes my outstanding contributions across consulting, technology delivery, research, and platform leadership. It connects international experience with a Nigerian professional community and reinforces my duty to maintain standards, share knowledge, and support other professionals.

What advice would you give Nigerian technology professionals pursuing international careers?

Build depth in a defined field, but understand the business surrounding it. Learn to communicate risk, document decisions, work across disciplines, and support users. Qualifications provide structure, while practical experience develops judgment.

Nigerian professionals should preserve evidence of their contributions and approach international opportunities with preparation and confidence. Consistent delivery builds credibility across industries and countries.

Across these scenarios, what separates a capable technical specialist from a trusted enterprise adviser?

A capable specialist understands the platform. A trusted adviser understands consequences. The adviser asks who is affected, which obligations apply, what evidence supports the decision, and how the organization will operate if the plan fails.

Technical leaders must listen, challenge assumptions respectfully, and avoid presenting certainty where evidence is incomplete. They should make recommendations that executives can evaluate, with dependencies, tradeoffs, ownership, and measures of success.

They must also remain close to delivery. Advice loses value when it ignores how administrators, developers, service teams, and users work. I expect leaders to verify that controls function, data remains usable, support teams are prepared, and promised outcomes appear after launch.

Trust develops when people see consistent judgment under pressure. It is strengthened by reporting, early escalation, documentation, and a willingness to correct mistakes. In enterprise technology, credibility is not created by titles or technical vocabulary. It is earned through decisions that protect the organization while enabling responsible change.

What principle should enterprise leaders carry beyond 2020?

Technology resilience depends on decisions made before pressure arrives. Organizations should invest in architecture, governance, integration, security, training, and recovery planning as normal operating disciplines. The objective is not to predict every disruption. It is to build systems and teams capable of responding with reliable information, clear accountability, controlled change, and sustained service.