HOW I SCALED GTM ENABLEMENT THROUGH AN ACQUISITION
Building the learning, systems, and support that helped Tegus teams onboard, ramp, and adapt through its acquisition by AlphaSense.
I joined Tegus as a Learning Experience Designer, originally focused on BDR enablement and onboarding.
My background wasn’t the traditional path into learning design. I studied biology, then taught myself a lot of the discipline through research, mentors, coffee chats, and actually doing the work. I learned instructional design principles, learning objectives, evaluation frameworks like Kirkpatrick, and eventually how all of that connects to product adoption and business performance.
At Tegus, I got to put a lot of that together. The immediate need was onboarding and enablement. There wasn’t a centralized learning system, information could be difficult to find, and new hires needed a clearer path from accepting an offer to actually being productive. My role quickly grew beyond designing learning experiences. I helped build the infrastructure behind them, supported reps directly, used performance data to improve what we were teaching, and eventually helped the GTM organization navigate a much bigger change: Tegus being acquired by AlphaSense.
BUILDING THE ENABLEMENT INFRASTRUCTURE
Highspot became one of my biggest areas of ownership, but the bigger job was figuring out what the enablement experience should actually be.
When I joined, Tegus was in the final stages of selecting Highspot. Once we moved forward, I helped take it from implementation to a working enablement system. That included the architecture, permissions, IT and SSO coordination, content organization, learning paths, reporting, ongoing maintenance, and the experience people actually saw when they logged in.
Different teams needed different things. A new BDR didn’t need the same experience as an experienced AE, CSM, or manager, so I built around those differences instead of treating enablement as one giant library of content.
I could also produce much of the learning myself. My background across instructional design, video, presentations, graphic design, and content production meant I could go from identifying a learning gap to actually building the thing that solved it without creating a separate production process every time. Highspot was the platform but the bigger thing I owned was the system around it.
I started thinking about the learning experience in three stages:
1. ONBOARD
Give someone the foundation: the company, product, customers, tools, processes, and what success in their role actually looks like.
2. RAMP
Move from knowing to doing. Practice calls, use the resources, get coached, learn from managers and peers, and start building toward productivity.
3. GROW
Keep learning as the product, market, messaging, and role change. Enablement shouldn’t end because someone finished onboarding.
Some of this could scale through Highspot, courses, playbooks, snippets, and reusable resources. Some of it couldn’t.
I also ran live training, office hours, and one-on-one call coaching. During periods when reps needed more support, I spent more time with them. If the fastest way to solve something was being on the floor, staying later for coaching, or opening up more time for questions, I did that. Once things stabilized, I could put more of that time back into the systems that made constant hands-on support less necessary.
I’ve carried that with me since. I don’t default to in-person, remote, synchronous, or asynchronous. I use whatever helps the learner do the work better.
what i owned
-
Highspot implementation, architecture, permissions, content organization, integrations, reporting, and ongoing administration.
-
Structured learning paths that helped new hires understand the company, product, customers, tools, processes, and their role.
-
Courses, presentations, videos, playbooks, snippets, live sessions, and resources built around what people actually needed to do.
-
Live training, office hours, call coaching, manager support, and hands-on help when a scalable resource wasn’t enough.
-
Updated learning, messaging, playbooks, and support as Tegus transitioned into AlphaSense.
-
Early use of AI and automation to speed up parts of the work while keeping security, privacy, and company information front of mind.
USING PERFORMANCE TO IMPROVE THE LEARNING
I never wanted course completion to be the definition of whether enablement was working. I looked across Highspot analytics, content usage, Salesforce performance, calls, manager feedback, and conversations with the reps themselves. The useful part was often figuring out the story between those signals.
For example, someone could have lower call activity and still be performing well. Instead of immediately treating that as a problem, I’d look at what else was working. Were their emails better? Were they handling objections differently? Were prospects engaging with the content they shared? Was there something one of our strongest reps was doing that we could teach everyone else?
That created a pretty simple loop: FIND THE GAP → STUDY WHAT WORKS → COACH IT → BUILD IT INTO ENABLEMENT → MEASURE AGAIN
Sometimes the answer was changing a course or playbook. Sometimes it was improving objection handling, creating a better snippet, changing a talk track, or giving managers something specific to reinforce. And sometimes the answer was just sitting down with someone and coaching them.
The goal wasn’t to make every rep sound or work exactly the same. It was to find repeatable things that worked and give everyone a better starting point.
THEN TEGUS JOINED ALPHASENSE
When Tegus was acquired by AlphaSense, one of my first priorities was learning the broader product myself. That’s something I’ve carried across pretty much every role I’ve had.
If I’m responsible for teaching or enabling people around a product, I need to understand the product first.
I spent time learning AlphaSense, understanding how Tegus fit into the broader platform, talking with product and leadership, and getting as much context as I could about what was changing before trying to teach it to someone else.
Then we translated that into what reps actually needed. We updated selling playbooks, call guidance, objection handling, snippets, and other resources as the story changed. We added more live sessions and office hours, and I spent more time coaching people individually when a course or document wasn’t going to answer the question. That mattered because the reps were having real conversations with prospects while they themselves were learning a new company, a broader product, and a changing GTM motion.
The scalable system was still there. We just added more hands-on support when the moment called for it.
MY FIRST REAL FORAY INTO AI AT WORK
This was also around the time AI started becoming part of how I worked.
Because we were operating in financial services, my introduction to professional AI use started with something important: privacy and security. I used tools like Microsoft Copilot and early generative AI to help with things like drafting, structuring learning, and speeding up parts of content creation. But I was careful about what information went into those systems. I wasn’t dumping proprietary GTM data or sensitive company information into a public model. That shaped how I still think about AI now. The question isn’t just, Can AI do this? It’s also: Should it? What data does it need? What’s sensitive? And where does a person still need to be involved?
I’ve gotten much more sophisticated with AI and automation since then, but a lot of those habits started here.
THE PART THAT’S HARDER TO MEASURE
There’s another part of enablement that’s harder to put into a dashboard: whether people actually trust you enough to change how they work.
I was coming into a growing company and changing systems, introducing new processes, reorganizing how people learned, and asking reps and managers to work differently. That can go badly if people feel like something is just being imposed on them.
A few months after joining, my colleagues nominated me for the Golden Tegu Award, a peer-recognition award for people who went above and beyond while exemplifying Tegus’s values.
I didn’t know I was being nominated. I found out when my name came up during the company meeting.
That recognition meant a lot because it came so early in my time there and from the people I was doing the work with. For me, it was a good signal that I wasn’t just shipping systems. I was earning enough trust for people to actually use them.
Peer-nominated for the Golden Tegu Award within my first few months at Tegus.
WHAT I TOOK WITH ME
Tegus was where a lot of the pieces came together for me. I was hired as a Learning Experience Designer, but the work quickly expanded across systems, sales enablement, content production, analytics, coaching, AI, and change management.
It reinforced something I’ve learned again and again since: know the product first. Once I understand the product, the customer, and the people using it, I can make much better decisions about what needs a course, what should be searchable, what a manager should coach, what AI can make faster, and when someone just needs another person sitting next to them helping them figure it out.
That’s still how I approach the work today.
