Building the Future of Tech: My Perspective on Leadership and Innovation

By Samini Ojo, Project manager and coach

From a leadership perspective, the strategic advantages of building an in-house, end-to-end technical team versus relying on specialised contractors or low-code/no-code platforms are clear to me. My philosophy is to align the team structure with the business’s long-term strategic assets, goals and finances.

The primary advantage of an in-house team is the development of deep, institutional knowledge. This team becomes the custodian of core intellectual property. They possess an understanding of the project’s history, its nuances, and its architectural trajectory. This enables unparalleled agility; the team can pivot quickly, respond to market changes, and iterate on complex features without the friction of external handoffs. That long-term ownership is crucial for sustainable innovation and maintenance.

Specialised contractors, however, remain a powerful strategic tool for acceleration and augmentation. I leverage them for well-defined, non-core projects where the scope is clear, allowing the in-house team to remain focused on strategic initiatives. They are also invaluable for augmenting the team with specialised skills for a specific period, without incurring the long-term overhead.

Low-code and no-code platforms, in my view, are excellent for market validation. Their strength lies in rapidly building Minimum Viable Products (MVPs) or internal tools to test a hypothesis with minimal engineering investment. However, I see them as a means to an end, as they often introduce significant limitations in scalability, customisation, and control, which can hinder a product’s long-term growth. Ultimately, the optimal approach is often a hybrid model, using each option as a deliberate tool to achieve specific business goals.

I see AI-assisted development as the next paradigm shift in software engineering, comparable to the move from assembly language to high-level programming. Over the next five years, the landscape will change in three key ways. First, the role of the engineer will evolve, with the focus shifting from writing boilerplate code to high-level architecture, complex problem-solving, and system design. AI will act as a co-pilot and force multiplier, handling implementation details and enabling a single developer to achieve the output of what would currently take a small team, leading to productivity gains of five to ten times.

Second, the speed of innovation will increase significantly, as AI will assist across the entire development lifecycle—from code generation and automated testing to bug detection and deployment—shrinking the time from idea to production and allowing organisations to deliver more value to customers faster. Third, team structures will adapt, with smaller, more highly leveraged teams tackling larger and more ambitious projects, placing greater emphasis on engineering quality and strategic thinking rather than team size.

To capitalise on these shifts, I would position any organisation by proactively investing in tooling and training to integrate best-in-class AI tools and upskill the team, adapting processes such as code reviews and QA to complement an AI-assisted model, and fostering a culture of experimentation where engineers are encouraged to leverage AI not only for faster coding but also to solve previously intractable problems. The real winners will be organisations that deeply integrate AI into their unique processes and business domains.

In my own leadership journey, I have seen how strategic decisions can change the trajectory of a business. In a previous role, our startup was scaling a complex, distributed application. As we grew, our biggest threat became system fragility. When issues occurred, it was a time-consuming, all-hands-on-deck effort to diagnose the root cause, leading to extended downtime and eroding customer trust.

My pivotal decision was to champion and lead the implementation of a comprehensive observability strategy, moving us from a reactive to a proactive operational model. I chose to standardise on OpenTelemetry because of its vendor-agnostic nature, ensuring we would not be locked into a single provider in the future. We instrumented our services to provide detailed logs, metrics, distributed traces and infrastructure monitoring. This provided us with a unified view of our system’s health. The result was immediate: our Mean Time to Resolution for critical incidents decreased by over 70%. We could identify and resolve potential issues before they impacted most of our users. That reliability became a key selling point, protecting revenue and rebuilding long-term customer trust.

When it comes to choosing a technology stack for a new, mission-critical application, my framework is pragmatic and defensible. I avoid chasing trends and instead focus on aligning technology choices with business trajectory. The process begins with problem-domain fit, then considers scalability and operational profile, ecosystem maturity and talent availability, and total cost of ownership. To lead this process, I believe in structured discussions with engineers, architects, and product leads to make shared decisions that balance immediate business value with long-term scalability.

Looking at the horizon, I am particularly excited about two emerging technologies: open-source Large Language Models (LLMs) and serverless databases. Open-source LLMs give businesses the power to fine-tune and control specialised models in-house, creating a competitive advantage without total dependence on third-party APIs. Meanwhile, serverless databases promise true elasticity, global distribution, and cost efficiency, enabling engineers to focus on business logic rather than operations.

High-pressure environments with aggressive deadlines are inevitable, but I believe quality and security must never be sacrificed. My approach balances speed with sustainability through disciplined scoping, automated guardrails, and a culture of accountability. Pragmatism over perfectionism is key: focus on robust cores, iterate quickly, and maintain trust through security.

The most common strategic mistakes I have observed are extremes: either moving fast and accumulating technical debt, or over-engineering for scale that does not yet exist. My advice is to adopt an evolutionary architecture and a sustainable pace, keeping it simple while scaling strategically.

For aspiring tech talent—engineers, product managers, or designers—my advice rests on three pillars. Think in decades but work in weeks. Cultivate your reputation, because integrity and reliability are your most valuable assets. And above all, embrace continuous learning as a core discipline, because today’s cutting-edge tool may become tomorrow’s legacy system.

The gap between engineering and business functions can only be bridged through empathy and shared goals. I emphasise business outcomes over jargon, involve engineers early in discovery, and maintain regular cross-functional forums to ensure alignment. Ultimately, engineers should see themselves not just as coders, but as business problem-solvers.

Finally, I believe strongly that technology must be built on ethical foundations. Privacy, transparency, and anticipating unintended consequences are responsibilities that cannot be ignored. To embed these principles, leaders must establish ethical review processes, hire people with strong moral compasses, and be willing to make tough calls—even delaying a launch—when standards are not met.

In the end, leadership in technology is not only about solving technical problems. It is about vision, responsibility, and the courage to align innovation with human values.