A dashboard needs a destination.
I now ask what happens after an insight appears. Who owns it? What decision follows? Where is the evidence? How will we know whether the action helped? An impressive screen can still leave the actual work untouched.
Learning / MIT coursework / AI leadership and adoption
The AI can work.
Will people use it?
My MIT coursework on AI leadership and adoption gave me a more demanding way to think about the applications I’m building. Getting a model to produce an answer is one problem. Getting that answer into work people understand, trust, and take responsibility for is another.
Personal reflection · Coursework and capstone revisions reviewed October 2, 2026
The path through the work.
This is my own synthesis of the learning journey, rather than the course’s official module sequence. Open each step for the lesson and a small way to apply it.
01Start with the problem
My first task was to define a leadership challenge and a useful outcome. That forces a harder question than choosing a model: what should improve, for whom, and how would I know? If the existing process is unnecessary, making it faster with AI is a strange use of everyone’s time.
Try it: Write down the outcome, the current baseline, and one reason AI might be the wrong tool.
02Understand how the organization actually works
The assignments pushed me to examine people, process, information, and technology together. A solution can look convincing on paper while ignoring the handoff where work stalls or the person who holds the missing context. I learned to treat readiness as something to investigate, rather than a score that gives permission to proceed.
Try it: Map one workflow with the people who do it. Mark the missing information, disputed assumptions, and real bottleneck.
03Give AI a bounded job
The design work made me more specific about what AI contributes and what remains a human decision. Producing an observation is different from recommending an action; recommending is different from executing. Those distinctions belong in the design before the system is trusted with consequential work.
Try it: Choose one task. Specify its inputs, evidence, output, failure cases, and the person who can reject it.
04Organize people and decision rights
A useful insight still needs somebody to act on it. My capstone revisions made the connection between analysis and accountable action much more explicit. Cross-functional participation helps bring expertise into the work, but it does not replace a named decision owner or a clear way to resolve disagreement.
Try it: For each important output, name who reviews it, who decides, who acts, and how the result comes back.
05Earn trust through leadership behavior
Culture is part of the system. People pay attention to how new information will be used, especially when it could become surveillance or a new way to assign blame. The coach’s feedback pushed me to move beyond identifying resistance and describe concrete boundaries, opportunities to challenge outputs, and consistent leadership behavior.
Try it: Explain the permitted data uses and the limits. Ask affected people what would make the system useful, and what would make them avoid it.
06Turn the plan into a learning loop
The final exercise was synthesis: connect the problem, design, operating model, leadership, governance, and culture into one practical proposal. Feedback also exposed a weakness in my risk discussion. Listing risks was not enough; I needed signals that reveal a problem, a response, and conditions for pausing or rolling back.
Try it: Run a small pilot. Review outcomes, errors, overrides, unresolved actions, and user feedback. Decide what evidence would justify expanding, changing, or stopping it.
What changed in my thinking.
Speed needs an adoption plan.
I tend to move quickly from an idea to a build. The leadership work made me pay more attention to communication, participation, and the conditions that let others take ownership. Shipping code and changing how people work require different evidence.
Feedback should alter the design.
The capstone process involved drafting, receiving feedback, revising, and tightening the final plan. The most useful comments exposed where I had named a concern without explaining how I would handle it. That is a good test for any proposal I make.
Authority has to be earned.
I want early systems to make their evidence visible and remain easy to challenge. More authority should follow demonstrated reliability and clear accountability. A pause or rollback is part of operating a system responsibly.
Capstone / process reflection
From separate assignments to one plan.
The final strategic-plan exercise asked me to bring earlier work together into a proposal stakeholders could understand and act on. I worked through the challenge, solution, team structure, leadership approach, governance, cultural barriers, and adoption actions, then revised the connections between them.
This page shares the general method and my learning. The company context, project design, internal data, and submission documents remain private. It does not report a grade, certificate, or independently verified business result, and it is not an MIT-endorsed guide.
Learning continues in the builds.
I’m applying these questions to personal agents, voice interaction, private data tools, and a game for my family. A browser test can show that a button works. It cannot tell me whether the experience is worth somebody’s time.