About 10 years ago, I was an experienced .NET engineer. I knew my stack well, I was good at my job, and I had never needed to think much about integration platforms or messaging queues.
Then I was introduced to a MuleSoft integration project.
I knew almost nothing about MuleSoft, RabbitMQ, Enterprise Messaging, or the architecture behind them. I was learning from scratch while working on a live project with a real team and real deadlines.
Two years later, I was playing an senior role on that project. I had written an article about integrating Cosmos DB with MuleSoft, and I had worked directly with MuleSoft engineers to troubleshoot and fix issues in their platform. I learned all of this while the project was moving, not in a sandbox or training environment, but through real production work.
One moment from that time still makes me smile. A colleague contacted MuleSoft support with the same Cosmos DB integration question, and their support team sent him my article. They had no idea that the author was sitting on the same team.
Looking back, I don’t think that progression was luck. I had developed a way of learning that I had been using, without naming it, since my Master’s degree. Over the years, I kept applying the same pattern whenever I had to move into a new technology area.
I now think of that pattern as the S.E.E.D. Framework.
Why I’m Writing This Now
I have repeated this pattern many times in my career: learning a client’s proprietary compiler so my team was no longer dependent on someone else; removing a Tibco middleware layer by working directly with the source SDK; learning Documentum’s query language (DQL) to build an integration others preferred not to touch; moving from .NET into MuleSoft architecture; and, more recently, moving from AI/ML fundamentals to helping lead the adoption of AI coding tools across 80+ engineers in my organization. We also measured the productivity impact, which came out to roughly the equivalent of three additional engineers per year.
Over time, people have asked me some version of the same question: “How do you get comfortable with a new technology so quickly, and how do you get to the point where others start coming to you for help?”
For a long time, I didn’t have a clear answer. Writing this framework helped me put one together.
The S.E.E.D. Framework
S — Scan
Decide what is worth your attention
When a new technology starts getting attention, I don’t immediately jump in. There is always something new, and not every technology deserves the same investment of time. I usually ask myself three questions:
Layer 1 — Infrastructure or application? If the change is mostly at the infrastructure level, such as GPU architecture, networking hardware, or data center technology, I stay informed but usually don’t go deep. That isn’t where I add the most value. If it changes how software is built, how developers work, or how applications are designed, I pay much closer attention.
Layer 2 — Can I try it today? If there is a trial, free tier, open-source version, or local installation, I prefer to use it myself. Reading about a technology helps, but I learn much faster once I can actually work with it.
Layer 3 — Can it multiply what my team does? As a leader, this has become an important part of the filter. With Cursor, for example, I wasn’t only asking, “Will this make me faster?” I was asking, “What could this mean for 80 engineers?” Scan is really about choosing where to spend your learning time.
E — Explore
Understand the ecosystem before going deep
A common mistake when learning a new technology is to start with one tool and go deep immediately. You can become comfortable with the tool without really understanding the system around it.
I prefer to build a map first.
When I entered the MuleSoft world, I listed the major pieces around it: RabbitMQ, MuleSoft connectors, SQL databases, deployment strategies, CI/CD pipelines, and the underlying Java layer. I wasn’t trying to master everything at once. I wanted to understand what existed, how the pieces related to one another, and where I needed to go deeper.
Then I learned in sequence. I started with concepts: How does messaging work? What is a queue? What is a topic? Why do we need a dead-letter queue? Next came the mechanics: install RabbitMQ locally, send a message, and watch how it moves. Only then did I focus on integration: how MuleSoft connects to RabbitMQ and databases, and how the full application gets deployed.
That distinction has stayed with me. Learning a tool is useful, but understanding the system is more durable. Tools change; many of the underlying patterns do not.
For me, Explore is about building that mental map before specializing in one part of it.
E — Excel at the Edges
Go beyond the documented path
This is where learning starts turning into real expertise.
Once I understand the standard path and can build the normal use cases, I keep going. I look for the places where the documentation becomes thin, the usual solution stops working, or the team is blocked.
I ran into exactly that situation with MuleSoft. I needed to integrate with Cosmos DB, but at the time I couldn’t find a connector, useful documentation, a community article, or a Stack Overflow answer that solved the problem.
Instead of changing the requirement, I built reusable flows for the operations we needed. After I got it working, I wrote an article about the approach because I knew someone else would eventually run into the same problem.
I had similar experiences with other connectors. When I found platform issues, I reported them and worked directly with MuleSoft’s engineering team to understand and resolve them. That changed the nature of the work for me. I was no longer only consuming the platform; I was contributing back to the people building it.
That is what I mean by excelling at the edges. It is the point where you move beyond following the documented path and start solving problems that do not yet have a clear answer.
Those are also the problems that tend to build credibility, because the solution is useful beyond your own immediate task.
There is another part of this stage that has become just as important to me: removing dependencies that everyone has started treating as permanent.
Many stalled projects have a dependency somewhere in the middle: a team waiting on a client, a middleware layer nobody owns, or a proprietary system that everyone treats as a black box. My instinct is usually to understand the dependency and see whether it really has to exist.
Early in my career, I worked on a learning management system where our team depended on the client to write stored procedures. Their backend used a proprietary compiler that translated a specialized language into SQL for multiple databases. Nobody on our side knew it, so we waited whenever we needed a change. I decided to learn the compiler myself. Once I could work with it, that dependency was no longer blocking the team.
On another project in legal services, a Tibco middleware layer sat between our application and an Autonomy search engine. The assumption was that Tibco was required. I wasn’t convinced, so I learned the Autonomy .NET SDK, built a proof of concept, and showed that we could integrate directly. The result was a simpler architecture with fewer moving parts and less dependency on a system we did not control.
The same pattern came up with Documentum. Instead of treating its proprietary query language and SDK as a black box, I learned them and built the integration directly.
In all of these cases, I followed a similar approach: build a small proof of concept, validate the idea, show it to the team, and then decide whether to implement it. The POC matters because it turns an opinion into something people can see and evaluate.
For me, this is the practical meaning of Excel at the Edges: go toward the constraint, understand it, and learn enough to remove it when that is the right engineering choice.
Sometimes that work stays inside the team. Sometimes it becomes an article, a reusable solution, or a conversation with the vendor. Either way, it leaves the next person with a better starting point.
The Excel phase is about going beyond what is already documented and solving the problems that are limiting the team.
D — Distribute
Teaching completes the learning cycle
I have always felt that I understand something better once I can explain it clearly to someone else.
That habit started before my professional career. During my Master’s program, some of my roommates and classmates would ask for help with computer science subjects. I would read the material, work through it until it made sense to me, and then explain it back to them. Teaching forced me to organize what I had learned.
I have carried that habit into every major technology transition since.
With MuleSoft, distribution meant writing blog posts, including the Cosmos DB article that eventually found its way into MuleSoft support. With AI and Cursor, it meant lunch-and-learn sessions for 80+ engineers, live coding, practical examples, and a framework for measuring time saved. We used the data to build a productivity report that I later shared with leadership.
Distribution is not only about publishing, though. It is also about helping people grow. In 1-on-1s, I have used technology transitions to talk with engineers about where their careers could go next. Two engineers on my team who started as general-purpose developers are now working as Gen AI engineers. That outcome matters to me as much as the technology adoption itself.
This is why I see Distribute as the final stage. Individual knowledge becomes much more valuable when it turns into capability across a team.
What This Looks Like End to End: The Cursor Story
A recent example shows how the four stages work together.
Scan: AI coding tools caught my attention because they were changing the way developers build software. Cursor was easy to try, so I started using it rather than only reading about it.
Explore: I looked beyond my own coding tasks and mapped where it could help across the engineering lifecycle: coding, debugging, testing, code review, and documentation. I also spent time understanding the LLM concepts behind the tool so I could explain both its strengths and its limitations.
Excel at the edges: I turned a simple lunch-and-learn into 100% team adoption of AI tools, using feedback surveys to guide the rollout and a measurement framework to track results. The measured productivity gains equaled roughly three additional engineers per year.
Distribute: We ran lunch-and-learn sessions with live coding for 80+ engineers, continued the conversations in 1-on-1s, and used the adoption effort to help engineers think about AI-focused career paths. The results also gave leadership useful data for broader adoption decisions.
That is the S.E.E.D. cycle in practice: start by noticing the right signal, understand the system, push into the hard problems, and then share what you learned.
Why This Matters Now
AI is changing software engineering quickly. I don’t think every new AI tool will matter, but I do think the broader shift will change how teams build, test, operate, and maintain software.
For engineers and engineering leaders, that makes the ability to learn deliberately more important. Scan the landscape instead of chasing every trend. Explore enough to understand the system. Go deeper where the real constraints are. Then distribute what works so the team benefits, not just the individual.
You don’t need to know everything. You do need a repeatable way to learn what matters.
That is what S.E.E.D. has become for me. It isn’t a talent or a shortcut. It is a practice I have built over time.
Where I’ve Landed
Today, I am a Senior Manager, Staff Software Engineering, with more than 20 years of experience across .NET, MuleSoft, Azure, databases, and now AI/ML. I work in an insurance industry, where technology changes need to be approached with both speed and discipline.
I am sharing this framework because it helped me make sense of a pattern I have followed for years. I also suspect many engineers and leaders already do some version of this without giving it a name.
If S.E.E.D. resonates with you, or if you use a different approach when learning a new technology, I’d be interested to hear about it.
I’m especially interested in how engineering leaders are helping their teams navigate the current AI transition: what is working, what is not, and where teams are still getting stuck.
And, in the spirit of the D in S.E.E.D., if this is useful to someone else on your team, feel free to share it.