Team GSD - Year 1 Reflection: Unlocking Operational Velocity

As I write this, it was a year ago this week that Team GSD - short for Get Sh!t Done - formally began.

Looking back… what a wild ride.

Over the last 12 months, we've gone from a brand-new team with a big mandate to a group that has shipped 14 automation and AI projects across 8 departments.

This post is a reflection on what we built, how we built it, what we learned, and where we're headed. If you're an engineering leader thinking about standing up an AI-enablement function inside your company, or you're an IC wondering what this kind of work actually looks like on the ground - this is for you.

TL;DR

• 14 projects. 8 departments. Year 1 was defined by significant reductions in manual work and faster execution across Customer Support, Finance, Commercial, and beyond.
• Four principles drove our success: start with problems not solutions, keep discovery lightweight, prototype early, and build platforms - not just projects.
• We built NOVA (our internal tooling & AI + Automation hub), deployed n8n org-wide, and launched LiteLLM as a centralized LLM gateway across Claude, OpenAI, and Gemini.
• Real Impact: The time required for Customer Support to wrap up calls decreased substantially, and the launch time for Commercial campaigns was dramatically reduced from ten days to just a few.
• If you're building something similar: Start with trust, hire for mindset, show don't tell, and measure optimizations from day one.

The Mission

Team GSD was created as a small, focused tiger team tasked with improving how departments work on a day-to-day basis. Our job: find the manual, tedious, repetitive tasks that are draining people's time, and rebuild those workflows using AI and modern automation so people can move faster with less friction.

Our official mission from our Team Charter: "To lead, support, and scale automation & AI-driven solutions that transform how work gets done at Fullscript."

What We Walked Into

It didn't take long for a few patterns to show up - and they were consistent across every department we touched:

• Heavy manual, repetitive work everywhere. Documentation, returns processing, data entry, campaign setup - hours of human time spent on tasks that didn't require human judgment.
• Fragmented systems and workflows. Teams were bouncing between disconnected tools with no central place to operate from.
• Limited ability to quantify the inefficiency. People knew things were slow, but nobody had a clear picture of how many hours were actually being lost.
• Teams coming prepared with clearly defined processes. In several cases, stakeholders brought well-documented workflows and clear visibility into where their processes were breaking down, making it easier to identify opportunities for automation.
• Teams showing up with solutions instead of problems. Stakeholders often came to us with "we need X built" instead of "here's the problem we're trying to solve."

And underneath all of it: the challenge of earning trust fast enough to move fast enough.

People First, AI Empowered

Let me be crystal clear about something: this is not about replacing people.

Fullscript is taking a deliberate, strategic approach here - People First, AI Empowered. This is a documented organizational value, not just a tagline. The idea is simple: AI is a thinking partner. It generates, analyzes, and accelerates. Humans design, review, and make decisions. The goal isn't to replace our teams - it's to amplify them.

We automate the parts of the job that are the most manual so people can focus on what really matters: helping people get better.

That's what Fullscript is here for - changing the standard of healthcare to whole person care. Everything we build ladders up to that mission.

What Actually Made This Work

Looking back on 12 months and 14 projects, a few core principles drove almost all of our success. I wish I could say we had these written on a wall from day one - honestly, we figured them out by running into walls and learning from what worked.

1. Start with Problems, Not Solutions

The business defines the what. Engineers own the how.

This sounds obvious, but it's the single most common failure mode I've seen. When we got stakeholders to articulate the problem clearly instead of prescribing a solution, everything downstream moved faster.

2. Lightweight, Repeatable Discovery

We established a baseline set of questions that every project starts with (I go deeper on these later in the post). The point is: enough clarity to move, not enough to slow us down. Get to a shared understanding fast, then let engineers prototype.

3. Prototype Early, Not Perfectly

We defaulted to proof-of-concepts, fast demos, and real user feedback over polished specs and long planning cycles. People don't adopt ideas - they adopt things they can see and react to.

We learned this the hard way. There were early projects where we spent weeks aligning through documents and meetings before building anything - and by the time we had something to show, the stakeholder's priorities had shifted. Now we get something in front of people within days, not weeks. Sometimes the business can't imagine the future until you put something real in front of them.

4. Build Platforms, Not Just Projects

Individual projects save hours. Platforms create compounding impact. This realization - and the shift from one-off deliverables to building a shared infrastructure layer - is what allowed us to scale beyond a tiger team.

5. Lean Heavily on AI to Build AI

We didn't just build AI solutions for other teams; we used AI to accelerate our own development. By leveraging agentic coding and our internal autonomous agent, Nitro, we were able to move from concept to production-ready tools in a fraction of the time a traditional development cycle would require. We are proving that the future of engineering is about moving up a level of abstraction.

The Results: Driving Massive Efficiency Gains

I'm proud to say that in our first 12 months, Team GSD has delivered 14 completed projects across 8 departments. While we’re still developing how we measure long-term impact, the changes in how teams operate are already clear.

By removing the "manual tax" from our workflows, we have enabled teams across Customer Support, Commercial, Finance, Quality, Catalog, and Partner Management to operate with a level of velocity that was previously impossible. This represents real capacity that no longer needs to be spent on documentation, repetitive admin, and manual processes - capacity our people can now spend actually doing what they do best.

Spotlight: Optimizations That Tell the Story

Customer Support: Zero-Touch Wrap-up

This project is the best example of what iterative, responsible AI deployment looks like in practice. Phase 1 was AI-powered call summaries and topic tagging. We built the system, deployed it, monitored it, and iterated until we achieved 95% accuracy through human-in-the-loop validation.

At that point, we had the confidence to flip the switch to Phase 2: Auto-Submit. Call summaries and ticket categories now auto-submit to our CRM the moment a call ends, significantly optimizing wrap-up time. This allows our agents to stay fully present on calls instead of being distracted by manual note-taking. They're helping people - not filling out forms or documenting.

Commercial: Growth Plays Campaign Builder

Historically, launching a new marketing campaign was a manual marathon. The Commercial team drastically reduced campaign launch times, streamlining their curation from over a week to just a couple days. In February alone, 15 campaigns were generated using the tool. This isn't incremental improvement - it's a fundamentally different way of operating.

Beyond the Headliners

• Product Description Enhancements (Quality): We built an AI-powered compliance engine that rewrote over 18,000 product descriptions. This mitigated compliance risk across our entire catalog ahead of a major migration - a task that would have been insurmountable manually.
• VoC Automation (Customer Support): This is more of an evolution story - GSD introduced automated sorting and processing components through n8n, which were integrated into the team’s existing workflow, significantly reducing manual effort.
• Product Data Cleanse (Catalog): We used an n8n workflow to automate the update of missing data fields for over 16,000 products. This is a perfect example of enabling a non-engineering team to get a massive, tedious job done with better data quality as a bonus.

Building the Team (and Betting on the Right Mindset)

When I was told I'd have the opportunity to lead GSD, I was electrified.

But I also knew the mission wasn't "build some bots." It was: take a new set of technologies that are evolving weekly, apply them responsibly, and make real operational impact across the company.

So I focused on building the right team early. I identified two engineers who weren't just strong technologists - they had the mindset and commitment to their craft that made me confident I could throw almost any problem at them, and they'd be able to learn the domain, understand the pain, prototype fast, and drive real solutions to completion with stakeholders who don't live in engineering.

The best part? Both of them were hesitant at first - unsure if they were the right fit. I made sure they understood: this is a rare opportunity. Not just to learn the AI and automation space, but to work directly with stakeholders across the business and materially improve how their teams operate.

They're now thriving, and they've delivered immense value across the business.

The Real Challenge: Trust and Change Management

Once I had my initial team established, it was time to figure out: how do we actually deliver solutions that get adopted?

Because when you walk into a department and tell them you're here to "disrupt how they work," two things happen immediately:

1. You hit resistance - especially when an "outsider" is involved.
2. You hit change management realities - even great tools fail if people don't trust them or don't use them.

So we made a deliberate call early: start by building rapport and trust - then move fast.

We didn't get this right on day one. Early on, we moved too fast with one department - jumped straight into prototyping before we'd built enough context or relationship. The work was technically solid, but adoption stalled because the team didn't feel ownership over the solution. That experience is what taught us to slow down at the start so we could speed up later.

I began meeting with department stakeholders bi-weekly. Not just for status updates, but to align on goals, understand what "success" looks like in their world, establish a working rhythm, and set expectations on what engineering needs to be successful.

That foundation of trust is what unlocked everything else.

Requirements Gathering Doesn't Have to Be Painful

Requirements gathering has a reputation for being a slog. But it doesn't have to be - as long as you have a baseline framework that gets you to a shared understanding quickly.

From my perspective as a former TPM, every project should start with these basics:

1. What's the problem statement we're solving?
2. Who are the key stakeholders?
3. What does the current process look like today?
4. What domains does this project touch?
5. What teams need to be involved because of those domains?
6. Are we touching financials or logistics?
7. Do we need a go-to-market strategy?
8. How are we measuring success - quantifiably?

Once you have that, you can drill into the more granular business requirements and actually knock it out of the park.

But here's the trick: you still have to enable engineers to prototype fast.

So the real art is balancing enough requirements to reduce risk, while not over-engineering the discovery process, and leaving room for rapid iteration. If you get that baseline info, you're starting on second base instead of stepping into the batter's box.

The best part about an established framework is that it adapts. Customer Support and Finance are completely different departments, but both can be set up for success by understanding what type of information engineers need in order to move quickly and get something in front of them. That baseline understanding is what empowers the department to begin ideating and envisioning potential opportunities to streamline. It certainly makes it a lot easier when you're an engineer being met with the information you need instead of having to get blood from a stone.

The Snowball Moment: NOVA

Once we turned the corner with a department, it snowballed quickly - in the best way.

We learned that the most scalable thing we can do is empower our technologists to get context, then rapid prototype from idea → demo → aligned path forward.

And in the last three months, we've taken a major step in that direction: we built NOVA.

NOVA is our new internal web application - a single, intelligent platform designed to unify the fragmented and disconnected tools and processes across departments. It's the foundational hub where departments will do more of their work over time as AI and automation capabilities expand.

NOVA is in production today with our Commercial team as its first tenants, and we're actively building tools within it for Legal and Customer Support.

This Isn't Just a Team-Level Initiative

It's worth noting: this work has full organizational support from the top. Our CTO has been a champion of this direction, openly sharing with the engineering org that leveraging expertise with language models to build software is likely the future of our profession - and creating dedicated time and space for the entire team to experiment with agentic coding. That kind of top-down alignment is what makes a team like GSD possible - it's not a rogue experiment, it's a strategic commitment.

How Any Team Can Adopt This Approach

If you're thinking about standing up an AI-enablement function at your organization - or you're already running one and looking for a framework - here's what we learned in Year 1:

1. Start with trust, not technology.

Meet your stakeholders where they are. Build rapport before you build anything. The best tool in the world is useless if no one trusts the team that built it.

2. Establish a lightweight requirements framework.

Don't over-engineer discovery. Get the eight baseline questions answered, then let engineers prototype fast. You can refine later - the goal is to get something tangible in front of stakeholders quickly.

3. Hire for mindset, not just skill.

You need engineers who are comfortable with ambiguity, who can learn domains quickly, and who can interface with non-technical stakeholders. Pure technologists who also have the soft skills to build cross-functional relationships - that's the combination.

4. Show, don't tell.

Resistant stakeholders won't be convinced by a slide deck. Build a proof-of-concept and put it in front of them. Let them react to something real.

5. Build capabilities, not just tools.

The goal isn't to make departments dependent on your team forever. Build it, prove it, and hand it off.

6. Invest in the platform layer.

Individual projects save hours. A platform layer (LLM gateway, automation platform, internal tooling hub) creates a compounding effect that scales exponentially as more departments onboard.

7. Measure everything quantifiably.

If you can't put a number on the impact, it's hard to justify the investment. Hours saved, manual steps reduced, time-to-market improvements - pick your metrics and track them from day one.

What's Next

With the acceleration we've seen recently - especially around agentic coding - I couldn't be more excited for what's ahead.

This is a truly unprecedented time at Fullscript, and I couldn't be more confident in the team we've built to not only meet our goals, but exceed them.

I'm already looking forward to writing another "Year in Reflection" post in early 2027… because I honestly can't imagine how much progress we're going to make this year compared to last.

The future is bright. It's time for technologists to be bold.

There's no better time to be a developer - building is easier than ever, and the AI disruption is still at the tip of the iceberg.

AI doesn't create impact. Systems that embed AI into real workflows do.

We didn't just build tools. We changed how work gets done.

And we're still early.

I'm strapped in for the ride. Let's see where it takes us.

- Christopher Folmar, Engineering Manager, Team GSD @ Fullscript