I build learning and knowledge operations infrastructure for organisations delivering real impact at scale: from operational SOPs and staff onboarding to technical curriculum and stakeholder-facing guides.
I specialise in the space where knowledge capture meets learning design, helping organisations that operate at scale turn tacit expertise into structured, accessible assets that frontline staff can actually use.
My background spans technical curriculum engineering, corporate training for NGO partners, and operational documentation. I've designed for learners with variable digital access, tight resource constraints, and high operational stakes. Contexts where a poorly designed onboarding guide or an unclear SOP has real consequences.
I'm particularly drawn to organisations building knowledge infrastructure from the ground up, where there is an opportunity to design systems that will compound in value over time, not just produce one-off training events.
SOPs, playbooks, onboarding guides, and process documentation designed for operational clarity and consistent execution, not just compliance.
Structured learning programmes grounded in adult learning principles, from needs analysis and sequencing through to assessment and iteration.
Learning scripts, storyboards, and video-based course design for field-based and asynchronous delivery contexts.
Turning learner feedback and performance data into clear insights that improve programme quality and support continuous improvement.
Guides, resource hubs, and Centre of Excellence content designed for external partners, communities, and institutional stakeholders.
QA frameworks, delivery checklists, and standard operating structures that make programmes consistent, scalable, and auditable.
Designed and managed a master event tracker and operational SOP for a high-profile community fundraiser. Covered multi-stakeholder coordination, venue logistics, procurement timelines, and day-of delivery. Demonstrates knowledge capture and project management applied to a time-critical, zero-margin-for-error operational context.
A foundational technology programme designed for underserved youth with variable device access and limited prior digital exposure. Programme success drove a multi-year contract renewal and expanded client investment, demonstrating impact in resource-constrained, community-facing delivery contexts.
End-to-end curriculum architecture for a beginner technical programme. Includes needs analysis, learning outcome design, cognitive-load reduction strategy, assessment design, and two full iteration cycles informed by learner performance data and instructor feedback.
Understand the learner population, operational environment, resource constraints, and success metrics before touching a design tool. What does good look like for the people who will use this?
Translate needs into architecture: learning outcomes, knowledge flows, SOP logic, or content scaffolding. Every design decision has a pedagogical or operational rationale.
Produce the artefact (curriculum, guide, video script, playbook) and validate it with instructors, subject matter experts, or pilot users before full deployment.
Capture delivery standards, build facilitator resources, and establish feedback loops so the programme or system improves over time without starting from scratch.
"Stella is one of the most consistent people in the team. She goes above and beyond and produces quality work for both B2B clients and B2C products. The Foundations of Software Engineering programme, which she designed, collected feedback on, and iterated, is a standout piece of work."
Head of Product EdTech Company"Stella's contributions to the Digital Literacy programme were marked by continued excellence. Her consistent efforts contributed to the programme receiving excellent stakeholder feedback, which led to the contract being both renewed and expanded, a significant achievement that speaks to her ability to deliver and maintain strong partner relationships."
Director of Corporate Training EdTech Company"Stella combines thoughtful learning design with strong operational awareness. She understands how to balance pedagogy, stakeholder needs, and real-world constraints. Her work significantly improved the structure, quality, and scalability of our learning initiatives."
Director of Product EdTech CompanyLead curriculum engineering and product ownership across Data Science, Data Analytics, High School Bootcamp, and corporate training programmes. Design SOPs, pacing guides, QA frameworks, and facilitator resources. Manage 3+ concurrent programme portfolios. Shipped curriculum for 450+ learners; achieved 50+ NPS across flagship programmes.
Designed and standardised training materials for data courses, creating facilitator guides that established a delivery benchmark for future instructors. Facilitated community workshops using adult learning principles; achieved 9.3/10 satisfaction across sessions.
Facilitated cross-cultural learning for 35+ students across varied proficiency levels. Designed lesson plans aligned with language benchmarks; 80% of students met their target goals by programme end.
Structured product thinking including stakeholder mapping, programme lifecycle management, and prioritisation frameworks, applied directly to curriculum product ownership at Moringa.
Advanced study in instructional design, digital pedagogy, e-learning development, and educational research, applied directly to curriculum engineering practice.
I'm particularly interested in roles and collaborations where knowledge systems, operational learning, and mission-driven impact converge. If that sounds like your organisation, I'd welcome a conversation.
A foundational technology programme designed for high school students with variable device access, minimal prior digital exposure, and limited prior technical familiarity, delivered in partnership with an Italian NGO. Programme success led to multi-year contract renewal and expanded client investment.
Underserved high school learners in this programme faced layered barriers that most curriculum designs do not account for: limited or no access to personal devices outside school, variable connectivity, low confidence with digital tools, and curricula historically designed for learners with far more prior exposure.
The NGO's goal was not just to deliver a technology programme. It was to build something that would increase digital confidence, open pathways to STEM careers, and be deliverable consistently at low marginal cost. The curriculum needed to be replicable across cohorts without requiring highly specialised facilitators.
Before designing a single lesson, I mapped what "success" looked like through the learner's eyes: increased confidence using digital tools, understanding of what a career in technology could involve, and at least one tangible thing they had built. Content sequencing followed from that definition, not from a standard technology syllabus.
With learners at widely varying starting points in the same room, rigid linear progression breaks down quickly. I designed modular activities with clear extension paths, so a learner who completed the core task quickly could extend into a challenge, while learners who needed more time were not left behind or made to feel that way.
Abstract programming concepts are particularly hard to retain when they have no immediate visible application. Every concept introduced in this programme was paired with a small project or visible output within the same session, so learners could see what their code did before moving on.
That last point, capturing the tacit knowledge that makes programmes work and making it accessible to future facilitators, is a design priority I carry into every engagement: the difference between a programme and a system.
End-to-end curriculum engineering for a beginner technical programme at a Kenyan edtech school. Two full iteration cycles informed by learner performance data and instructor feedback. Recognised internally as a standout piece of programme design.
Beginner software engineering programmes fail at a predictable set of moments. Week one, when cognitive load is highest and the tooling environment is an obstacle before the learning has even begun. And again in the middle of the programme, when learners have enough knowledge to feel lost but not enough to debug their own confusion.
The existing programme had high early dropout and feedback indicating learners felt "thrown in at the deep end." My brief was to redesign the curriculum architecture to reduce that early failure pattern without simplifying the programme to the point of being unrepresentative of what real software engineering involves.
The first week is redesigned to be narrower in content scope and much richer in environment setup support, conceptual framing, and low-stakes practice. Learners who spend Week 1 feeling competent are statistically more likely to persist through Week 3 difficulty spikes, a pattern documented in self-determination theory and confirmed by our own cohort data.
Beginners learn syntax fastest when it is introduced alongside a clear mental model of what is happening, not as an abstract rule to memorise. Every new concept in this curriculum is introduced with an analogy or visual before the first line of code is written.
Weekly hands-on labs were designed as diagnostic instruments, not just evaluative ones. The rubric for each lab explicitly mapped errors to likely misconceptions, so facilitators could use assessment results to adjust pacing and support, not just to assign marks.
After the first cohort completed the programme, I ran a structured feedback analysis: interview data from instructors, completion rates by week, and learner self-assessment scores. Three clear patterns emerged:
Version 2 restructured Week 4 to lead with a practical problem, added a facilitator guide with the analogies instructors had found most effective, and revised the capstone rubric to include example "strong response" indicators for each criterion.
The most valuable design insight from this project was about facilitator knowledge. A significant portion of what makes a curriculum work lives not in the written materials but in the judgment calls instructors make in the room: which analogy to use, when to slow down, how to respond when a learner is stuck. That knowledge is fragile. It walks out the door when an instructor leaves and does not transfer to new cohorts automatically.
Building the facilitator guide as a living document, one explicitly designed to capture and update those judgment calls, is now a standard part of how I approach curriculum engineering. It is a knowledge operations problem as much as a learning design problem.
A high-profile fundraising event run by Global Shapers Nairobi required tight coordination across sponsors, venue partners, caterers, volunteers, and media. I designed the master operations tracker and the stakeholder SOP that kept delivery on track across a six-week run-up and a zero-margin event day.
Dining in the Dark is a sensory dining experience where guests eat blindfolded, guided by visually impaired hosts. For Global Shapers Nairobi, the event served two purposes: raising funds for a community cause and building awareness of disability inclusion in public life. It required everything to work: the wrong meal served to the wrong guest in the wrong order in a pitch-dark room is not a minor inconvenience.
The coordination challenge was significant. We had external sponsors with deliverable commitments, a venue partner with specific setup requirements, a catering team who needed precise timelines, visually impaired facilitators who needed thorough orientation, media coverage to manage, and a volunteer team with varying experience. All of this needed to come together on a single evening with no real room for improvisation.
The core tool I built was a master event operations tracker that served as the single source of truth across the planning period. Rather than managing coordination through Slack threads and email chains, everything lived in one document that the full organising team could read and update.
External partners (sponsors and the venue) needed a clear reference document that told them exactly what we needed from them, by when, in what format, and who to contact when things changed. A generic event brief was not sufficient. I designed a short SOP-style document for each external stakeholder that made their specific obligations explicit and gave them the escalation path if they ran into problems.
This reduced the number of last-minute clarification calls significantly and meant that when a sponsor did need to change a deliverable close to the event, the escalation path was already known. No one was trying to find the right person to call at T-minus two days.
This project sits outside my formal L&D work but it is directly relevant to knowledge operations roles. The skills involved are the same: capturing tacit coordination knowledge into structured, usable documents; designing for a diverse stakeholder group with different information needs; making dependencies visible before they become problems; and producing tools that outlast the individual event and become institutional assets.
An operational SOP for a field supervisor and a stakeholder pack for an event sponsor are different documents for different audiences. The design thinking behind them is the same.