Sigu Magwa · Kisumu, Kenya

Technology Strategist & Software Engineer

I help organisations turn technology into a competitive advantage.

I come in, find where the technology, the processes and the people are holding the business back, agree with you on what should change, then build the system that carries that decision.

Strategist by perspective. Engineer by practice.

Start a conversation Download CV

Sigu Magwa speaking on stage at a conference

Worked with teams at

The problem

The business grows. The systems stay where they were.

At first nobody calls it a technology problem. Work starts taking longer than it should. People spend the day on the phone following up. One or two staff become the bottleneck without meaning to. When they travel, everything waits for them. Underneath, you find the same pattern almost every time.

Processes that worked when you were ten people were never redesigned for eighty.
Data is sitting in three or four systems that do not talk to each other.
Somebody has become the integration layer, moving figures between systems by hand.
The engineering team is busy from morning to evening, yet the business is not moving faster.
Nobody in the room can explain, end to end, the technology the business runs on.
The expensive decisions, rebuild or replace, build or buy, are made on a hunch.

By the time it reaches the budget, it has stopped being a technical question. It is now a decision about where the business puts its money and its people for the next three years. That is the one I am called in to answer.

The aim is a business that runs on systems, not on two or three people holding everything together.

Where I sit

Strategy without implementation is just a recommendation

I sit with leadership to understand the business problem, turn it into a technology strategy, make the architecture decisions that follow from it, then work with the engineers until the thing is running. You are not left with a roadmap and a handshake. You get somebody who knows what it takes for that roadmap to survive contact with a real codebase.

01 Strategy

What the business needs technology to do next. What to build, what to buy and what to stop paying for.

02 Architecture

The structure that makes that strategy possible. Also the trade-offs it ties you to for years to come.

03 Execution

Working software, left with a team that can keep changing it long after I have gone.

Method

How I work

Diagnose

Follow the work as it actually moves through the business, not as the manual says. That is where the real bottleneck shows itself.

Decide

Name the choice the business is actually making. Rebuild or replace, integrate or leave it alone. Then design the architecture that follows.

Build

Join the systems so data moves on its own, then automate the rule-based work: approvals, reconciliation, reports.

Transfer

Hand over so your own team can run it and extend it without calling me.

Outcomes

What changes

Reconciliation

Reconciliation that used to swallow a whole afternoon now runs on its own.

Approvals

Approvals that used to sit in somebody's inbox for three days now move the moment the rules are met.

Reporting

Reports that were assembled by hand every month are simply there when you need them.

10+ Years building and leading technology work
4 International technology companies
30+ Engineers hired and mentored
60s to 3s Critical operation, rebuilt

Selected work

Problems I was brought in to solve

Each one written as the business problem, the decision it came down to and what changed after.

Featured case study

Running a volunteer literacy programme on Elixir

Eight years of a Phoenix system tracking volunteer teachers across clusters of Kenyan schools. Attendance comes from tablets in the field where the network is poor, pay is worked out and approved from that attendance, then it goes out over M-Pesa. Every change carries the name of whoever made it.

Eight years of payroll Still running every month, still shipping
Failures that name themselves 6,600 sync failures triaged in one pass. Three were code bugs
Scopes that fail closed An unresolvable scope returns no rows, never all of them

Read the case study

Featured case study

Digitising the paper ledger of village savings groups

A chama of fifteen to thirty neighbours, three ledger books and a treasurer working out compound interest by hand. A Phoenix LiveView platform gives them one shared record everybody can check: savings, loans, penalties, welfare and the end-of-cycle share-out. The money arithmetic sits in a pure module. The loan ledger is made immutable by the database itself.

Immutable by trigger The database itself refuses to edit a loan event. Corrections are appends
Provable arithmetic Money maths isolated as pure functions and property-tested
Auditing by default Attached through telemetry, not instrumented call sites

Read the case study

Featured case study

Fixing a water utility's customer database and the processes that broke it

A water company billing from records that no longer matched what was on the ground. Around 14,000 anomalies checked against field survey data. The ones that could be resolved were corrected through the utility's own change control. Then five departmental procedures were rewritten, so the same anomalies stopped being created in the first place.

~14,000 Anomalies reviewed
~6,600 Records corrected
95% Spatial accuracy on actionable records
5 units Procedures rewritten

Read the case study

Other engagements

Pulpo WMS

Jenkins · Docker · CI/CD

When a warehouse operation became the constraint on throughput

One operation in a big warehouse management system was taking over a minute. Every pick and put-away in that building was waiting on it. This was not slow code needing a tune-up. The implementation and the infrastructure under it had put a ceiling on what that warehouse could move in a shift, so I redesigned the operation instead of working around it, sorted out the bottleneck underneath, then moved the team onto CI/CD with Jenkins and Docker. The operation went from over a minute to three seconds. The other projects got a better developer experience out of it as well.

Fly.io

Ruby on Rails · Elixir · Phoenix

Changing the foundation without stopping delivery

An established Ruby on Rails codebase had to move onto a new framework without delivery stalling while it happened. The codebase was not failing. It was simply the wrong shape for the concurrency the product was growing into. That gap only widens with time, so the call was to migrate rather than rewrite from scratch, shipping features the whole way. I moved the codebase into Phoenix, wrote new features and services and reviewed code for a fully asynchronous team spread across time zones, working from written specifications rather than meetings. The platform now sits on a framework built for high-concurrency work, delivered by a team that hardly ever had to be in a call together.

Frame.io

Elixir · monolith architecture

When onboarding is the hidden cost of a monolith

A big, established monolith where new engineers took long to become productive. Hiring was not turning into delivery, yet the cost was not in the code. It was in the knowledge around the code, living in people's heads, so every new engineer paid the same price by interrupting a senior colleague. I treated documentation and readable code as part of the delivery itself: built new back-end features and services, wrote code somebody would still understand six months later and maintained the living documentation that made onboarding easier. The result is a codebase and an onboarding path a new engineer can join without relying on who knows what.

Podii

Elixir · Phoenix · AWS · mobile

Building the delivery capacity the strategy needed

Clients in several industries needed systems built. The delivery capacity to do it was not there. The shortage was never talent, because Kenya has the engineers. What was missing was a path that takes a business problem all the way to a system somebody can run, so I started Podii and built that capability instead of brokering it, keeping strategy and delivery under one roof. We sit with the client and agree on the problem before agreeing on what to build. We work in short cycles so they see working software early. Then we hire and mentor the engineers who deliver it. From two people, Podii has grown into a consultancy delivering for clients in several industries, with more than 30 engineers hired and mentored along the way.

Also contracted with Adobe, building and maintaining back-end services for the Creative Cloud team. See the full career history.

References

What people say

“His projects always come in under budget and with good quality. He points out things I have coded imperfectly that he can improve. I whole heartedly recommend Sigu Magwa and Podii for Elixir development.”

Bruce Tate President, Groxio

“Sigu is a pure pleasure to work with. I would highly recommend him to any company looking for a smart, capable developer with excellent teamwork skills.”

Catherine Aronson Director, Platform Engineering, Adobe

“I appreciated his ability to simplify complex ideas and his problem solving skills. He is an independent mind, a coach and values his teammates’ ideas.”

Lucy Muhonja Software Engineer, Microsoft

“As a boss and mentor, he encourages autonomy but is always available to provide guidance with utmost patience.”

Pollet Obuya Full-stack Developer, xMoney

How the work starts

How I help

Three ways the work usually starts. Most begin with one of these and grow into the next.

Technology strategy

You have to decide where technology takes the business next. Whichever way you go, it is expensive.

Technology assessments
Architecture reviews
Technology roadmaps
Build versus buy
Digital transformation strategy
Technical due diligence

Systems transformation

Your processes and systems have become the thing slowing growth instead of the thing carrying it.

Legacy modernisation
Systems integration
Process automation
Architecture redesign
Data flows and reporting
Operational systems

Engineering leadership

You already have engineers. What is missing is technical direction they can act on.

Engineering organisation design
Technical leadership
Architecture
Hiring
Mentorship
Engineering processes

Who this is for

Who I work with

Organisations whose technology has stopped keeping up with the business.

Growing companies where the systems have become the bottleneck.
Organisations buried in manual work.
Companies whose engineering team is not delivering what it should.
Businesses replacing old systems that were never meant to work together.
Organisations going through digital transformation.
Leaders who need an experienced technical partner, not a full-time CTO.

You might need me when

Your team keeps building a workaround for the same problem.
Serious money still moves on a spreadsheet.
Nobody can explain how information moves through the organisation.
Engineering is busy the whole quarter but the business is not any faster.
Each system works on its own. Together they do not.
You are about to spend serious money on technology but you are not sure what to build.

Am I hiring you or hiring Podii?

Work with me

Strategy, architecture and technical leadership

You deal with me directly. Assessments, roadmaps, architecture decisions and the technical direction your own team then carries.

Work with Podii

End-to-end technology delivery

When the work needs a full delivery team, I bring in the engineers to build and run the system through Podii, the consultancy I founded.

Open source

Cybersecurity work built in the open

Built together with sFractal, where I lead the Podii team on it and write code on the codebases myself.

OpenC2 in Elixir

OpenC2 is an OASIS standard that lets one security system give commands to another without a human in between. We wrote the Elixir library for it, plus a dashboard that publishes commands to a subscribed device over MQTT so you can change the broker, change the command and watch what lands.

openc2 · open-c2-producer

Technology
Elixir · Phoenix · LiveView · MQTT · OpenC2

Digital twins for IoT security demos

Blinky is a Raspberry Pi with LEDs, the usual hello world of IoT. Twinkly is its twin in the cloud, where LiveView graphics stand in for the LEDs. So an IoT security talk can be demonstrated live, to a room or to a conference stream, without carrying hardware to the venue.

TwinklyMaHa · TwinklyHaHa · Blinky_haha_new

Technology
Elixir · Phoenix LiveView · MQTT · Raspberry Pi

Software bill of materials

A dashboard reporting the state of a software bill of materials proof of concept. The same discipline runs through the other applications here. Each one generates an SBOM of its own dependencies as part of the build, not as an afterthought.

SbomPoc-sFractal

Technology
Elixir · Phoenix · PostgreSQL · Docker · SBOM

A game that teaches cybersecurity

A falling-blocks game, extended from Grox.io's quadblocks, where clearing lines earns you loot boxes and getting a security question right keeps you in the game. We take it to security conferences, where people sign up and compete while learning the material.

quizquadaminos

Technology
Elixir · Phoenix LiveView · OAuth

How these actually work

Thinking

Talks, podcasts and writing

On building software under pressure, on observability and on growing a technology community here at home. Every talk below has a full write-up with the date, the venue and what I actually said.

Writing

Why the database refuses to let me fix a mistake

A chama's loan ledger is append only. That rule does not live in the Elixir. It lives in a Postgres trigger that rejects every update and every delete, mine included. What that bought and what it cost.

Read it

Talks

Keynote · ElixirConf EU 2020 Building an emergency software Building software in an emergency, what the developers were up against, plus why bringing in the community and testing all through mattered. Read the full write-up

Code BEAM Europe 2023 Building and growing the community Growing a technology community in Kenya through learning together and building together, plus what it takes to keep the members coming back. Read the full write-up

GigCity Elixir 2023 Observability in software applications What a 2007 plane crash and its black boxes teach us about instrumenting software so that you can find out what actually happened. Read the full write-up

More talks

Standing on the shoulders of giants ElixirConf Africa 2022
From your workstation to the client RubyConf Kenya 2019
Understanding Elixir GenServers Elixir Meetup #25

Podcasts

Beam Radio · Episode 52 Live from New York (almost)

Elixir Wizards · S7E8 The Elixir community in Kenya

Impact Masters · Episode 23 The long version

All talks and podcasts More on the blog

About

About me

For over a decade I have been designing, building and scaling systems in agriculture, finance, logistics, utilities and public service. Most of that work sits right where the business decision meets the architecture. I have contracted with teams at Adobe, Fly.io, Frame.io and Pulpo. I founded Podii, where I still make the architecture decisions and write code myself.

I co-founded ElixirConf Africa and Elixir Kenya. After more than a decade building and leading technology teams, I am now doing an Executive MBA at Strathmore Business School to sharpen the business side of the same work.

Read the full story

Facing a technology decision you cannot afford to get wrong?

Tell me how the work runs today and where it keeps getting stuck. We start by agreeing on what the real constraint is.

Thank you, that has been sent.

I read everything myself and I normally get back to you within two working days.

The contact form needs JavaScript. You can also reach me on LinkedIn.

Download CV