Microsoft Press 2010
Microsoft SharePoint 2010 Plain & Simple
With Chris Beckett
ISBN 978-0-7356-4228-7
The problem
Most AI projects don’t fail for technical reasons.
Johnathan Lightfoot
- Technician
- Architect
- Executive
- Builder
- Teacher
I have spent decades learning how technology succeeds and fails inside real organizations. I now apply those lessons to AI automation, systems thinking, and teaching others how to build well.
- Three decades in technology
- U.S. Navy veteran
- Technology executive
- n8n Ambassador, Ghana
- Published Microsoft author
Practice
01 Practice
I start every engagement in the same place: what has to be true when this is finished. Not which platform, not which model — what the organization must be able to do that it cannot do today. The technology is chosen last, because it is the least interesting decision.
I do not start with the tool. I start with the outcome.
Three decades of watching systems succeed and fail taught me that the hard part is never the installation. It is the people who have to use the thing on a Tuesday, the data that is messier than the demo, the exception nobody scoped, the budget, the security review, the politics. A design that has not survived contact with any of that is a proposal, not a system.
This is why I give automations the authority they need and not a step more. Agents prepare; people decide where the consequences are real; approved workflows act. Bounding authority is not timidity about the technology — it is what makes the technology safe enough to trust with something that matters.
An automation is not successful because it runs. It is successful because the organization can trust it.
The measure I care about is whether the organization is stronger after the system arrives than it was before — more capable, not more dependent. That is also why I teach. A system I leave behind should outlive my involvement in it.
The Long Gallery
02 The Long Gallery
Five eras. Open one to see what it taught me.
01
Operations & Technical Support
Learning that technology exists to support a mission.
What it taught me
What this era taught me
Systems are not abstractions when people depend on them. Reliability, communication, procedure and accountability come before novelty.
- Operations Specialist, rising to OS2 United States Navy · Nine years · USS Guadalcanal (LPH-7) · NCTAMS London · USS Mahan
02
Systems & Infrastructure
Moving from individual problems to interconnected systems.
What it taught me
What this era taught me
A system looks very different to the person who has to keep it running than to the person who designed it. Maintainability is not a courtesy — it is the job.
Desktop environments, infrastructure, enterprise systems, troubleshooting, deployment, operations and user support.
- Systems, infrastructure & technical operations
03
Enterprise Architecture & Consulting
Connecting technology to business requirements.
What it taught me
What this era taught me
Clients rarely need the technology they ask for. They need the outcome they believe that technology will produce. The work is discovering the difference.
Enterprise, government, defense, education and other regulated environments — SharePoint, collaboration platforms, CRM, application development, systems integration and compliance-aware delivery.
- Owner / Technology Consultant TechForce LLC · 2016 — 2020 · Client sites / Remote
- Technology leadership & systems roles Enterprise, government and regulated environments
04
Leadership & Strategy
Becoming responsible for organizations, teams, adoption and outcomes — not merely systems.
What it taught me
What this era taught me
The hard part of enterprise technology is rarely installing the software. It is aligning people, process, incentives, data and systems well enough for the change to last.
- Vice President, Application Development Tower Education Technologies · 2018 — 2019 · Education technology
05
AI Automation, Building & Teaching
Returning to hands-on creation with three decades of accumulated context.
What it taught me
What this era taught me
AI changes what can be built and how quickly. It does not repeal the lessons of architecture, operations, governance, testing or human behaviour.
- President / AI Automation Architect Symbiont, Inc. · 2020 — Present · Silver Spring, Maryland / Remote
- Founder / Automation Architect / Educator Bulletproof Automations · 2026 — Present
- Founder / Product Builder CLN Publishing & independent technology initiatives · 2023 — Present
01 05
Selected Works
03 Selected Works
Curated, not collected. Open one for the lesson it left; the full exhibit answers all four questions.
01
Johnathan OS
A private operational command center where agents prepare, a human decides, and only approved workflows act.
What I learned
Agents prepare. Johnathan decides. Approved workflows act.
What I learned
Constraint is a design decision, not a limitation. An agent should have the authority it needs to be useful — not unlimited authority simply because the technology permits it.
Private repository
02
ScriptureFlow
A developer-focused Bible data platform giving applications and automations structured, predictable scripture access.
What I learned
What I learned
A platform earns adoption through predictability, not features. The most valuable thing an API can offer other builders is the confidence that it will behave the same way tomorrow.
Private repository
03
Bulletproof Automation Lab
A secure self-hosted automation stack a small team can actually run without a platform vendor.
What I learned
What I learned
Self-hosting is not a cost decision, it is an operational commitment. The honest question is not whether you can stand it up, but whether you can keep it running.
Private repository
04
Every Tongue
An AI assistant for drafting and checking scripture study material in low-resource languages.
What I learned
What I learned
Aim AI at a problem narrow enough to evaluate. A constrained tool whose output can be checked is worth more than a general one whose output cannot.
Python Updated July 2026
05
Bulletproof Automations Training
n8n Foundations — teaching automation as an engineering discipline rather than a library of copied templates.
What I learned
What I learned
Teaching exposes gaps that building alone can hide. If I cannot explain why a system works, I probably do not understand it as well as I think I do.
HTML Updated July 2026
01 05
Teaching & Community
04 Teaching & Community
I do not only build systems. I build the people who will build the next ones.
I teach automation as a working discipline.
The method is outcome-first: determine the result that must be achieved, then work backward to the workflow, the tools, the controls and the skills required. The emphasis is on understanding why a workflow works rather than reproducing an example that happens to run — because a student who cannot explain a workflow is not ready to maintain it.
01 03
01
Teach
Direct instruction — cohorts, curriculum, workshops.
4 entries
- n8n Foundations — Beginner Cohort Getting Started · Triggers and Data · Connecting Apps · Working with APIs · Logic & Branching · Error Handling · AI-Powered Automation · Capstone.
- Workbooks, instructor guides and a portfolio system Every learner leaves each week with proof of work: an exported workflow, screenshots, and notes a non-technical person can follow.
- AI Security Foundation exam preparation Working knowledge of AI risk management and the NIST AI RMF that survives the exam room.
- Adjunct Professor Howard Community College. Formal teaching alongside a career of training users, teams, clients and practitioners.
02
Enable
Tools and resources that let other people build without him.
5 entries
- n8n Ambassador — Ghana A growing local community of automation builders with somewhere to start and someone to ask.
- API learning materials Able to use the data in their own work without writing the integration from scratch.
- Self-hosting and automation QA methodology Able to run, upgrade, back up and restore a platform they own.
- Community technology built for handover A system the community runs itself, rather than a dependency on its builder.
- Portfolio-building guidance Work that is genuinely their own and stands up to being asked about.
03
Share
Public thinking.
3 entries
- Published Microsoft author The earliest evidence of a recurring theme: taking complex technology and making it usable by ordinary practitioners.
- Video Perspective from someone who has watched technology succeed and fail for three decades.
- Field Notes The lessons of the career arc, written for someone about to face the same thing.
01 03
Microsoft Press 2011
Microsoft SharePoint Foundation 2010 Inside Out
Contributor, with Errin O’Connor · Penelope Coventry · Troy Lanphier · Michael Doyle · Thomas Resing
ISBN 978-0-7356-2724-6
Microsoft Press 2013
Microsoft SharePoint 2013 Plain & Simple
With Michelle Lopez · Scott Metker
ISBN 978-0-7356-6700-6
01 03
The systems I have seen do real damage were not badly built. They were correctly built and given more room than anyone had thought carefully about.
Field note — Why AI Implementations Fail
I keep some time for people earlier in their careers. If that is you, write to me. johnathan@bulletproofautomations.com