Lennox Omondi

What Lennox teaches

Much of Lennox’s teaching comes from having experienced software from both sides.

He has been the developer receiving a requirement and being expected to deliver it. He has also been the person responsible for the team, the budget, the client relationship, the quality of what gets shipped and what happens when a product decision turns out to be wrong.

He wants students to understand both perspectives.

Product Thinking

Lennox teaches students to start with the problem rather than immediately reaching for code.

Students begin by understanding who will use the product and what those people are trying to accomplish. They examine the assumptions behind a proposed feature before deciding whether it is likely to help. They also consider what the company can afford to build now, what can wait and how they will judge whether their work has solved the problem.

Students learn that professional software development involves making and questioning decisions, not simply implementing tickets.

Database Design

Students learn how real product requirements become data structures.

The focus goes beyond creating tables and relationships. Lennox teaches students to think about data integrity, access, security, scalability, maintainability and what happens as a product grows beyond its first version.

A database decision that feels convenient today can become expensive to undo later. Students are expected to understand those trade-offs.

Product Analytics

Shipping is the beginning of another part of the engineering process.

Lennox teaches students to follow what happens after people start using a product. They look at which features people use, where they struggle and where they drop off. Patterns in that data help them understand whether the product is doing what it was built to do.

Students learn to use that evidence to question assumptions and decide what should be improved next.

The goal is to produce developers who can participate intelligently in conversations about the direction of a product, rather than disappearing once the code has been deployed.

Business Etiquette

Lennox has worked with developers, founders, clients and international teams long enough to know that technical ability alone does not make someone dependable.

In Business Etiquette, students learn how their everyday behaviour affects the people relying on their work. They practise communicating clearly, agreeing on expectations and honouring commitments. When a problem threatens those commitments, they are expected to raise it early and keep others informed.

Documenting decisions and giving useful updates help colleagues understand where the work stands. Students also learn to receive feedback and take responsibility when something goes wrong.

It also means understanding that your behaviour builds a reputation over time.

For Lennox, these are not optional soft skills. They are part of being a professional engineer.

From developer to entrepreneur

Lennox started his professional career as a developer and gradually took responsibility for larger parts of the software delivery process.

At Africa’s Pocket, his work expanded from full-stack development into DevOps, technical planning, code review, developer support, recruitment, external technology partnerships and mentoring.

He also worked on the Africa’s Pocket learning platform, contributing to systems around course management, enrolments, payments and interactions between learners and course creators.

Eventually, Lennox became interested not only in building software, but in the systems required to consistently deliver good software.

That led to Reduzer Technologies.

Building Reduzer Technologies

Lennox founded Reduzer Technologies in 2022.

Reduzer works with growing companies that need to build or expand software products without taking on all the complexity of assembling and managing a product engineering team themselves.

The company provides managed software delivery, bringing together developers, delivery management, quality assurance and engineering oversight while helping clients reduce the risk, time and cost associated with scaling a software team.

Running that company changed the way Lennox looked at engineering.

A technical decision could affect a client's budget. A missed commitment could damage trust. Poor communication could create delays across several people. An architecture decision could make a product harder to scale months later. A developer who understood the product could sometimes create far more value than one who simply completed exactly what was written in a ticket.

Those are experiences Lennox now deliberately brings into his teaching.

Why he teaches

Lennox’s relationship with education began long before Reduzer School.

He first learned web development through free online resources while using the internet available at a cybercafé. He later went through formal software-development training himself before building his career in the industry.

That journey made education deeply personal to him.

His experience as a learner shaped what he expects of Reduzer School. Students have a responsibility to put in the work, and the school must give them the teaching, feedback and environment they need to learn. It must also take responsibility for how well it prepares them for professional work.

Lennox has written publicly about that responsibility and about his concern with training institutions selling career aspirations without being equally accountable for whether students develop the capability needed to pursue them.

Reduzer School is one attempt to build the kind of training environment he believes should exist.

What he wants students to leave with

Lennox wants students to leave Reduzer able to build an application and understand the company that depends on it. He wants them to be comfortable sitting with a founder or product team, understanding what they are trying to achieve and contributing to the solution.

In their own work, that means making deliberate database decisions and following a product after deployment to learn how people use it. They should be able to explain and defend their technical choices, while remaining willing to change their minds when the evidence calls for it.

He also wants them to recognise how their work affects people beyond the engineering team. Communicating early when something goes wrong gives those people time to respond, especially when a commitment is at risk.

As they gain experience, he hopes they will be ready to take responsibility for more of the work around them. What begins with a feature may grow into responsibility for a product or a team, and perhaps one day a company of their own.

That is the perspective Lennox brings into the classroom.