Why we spent six weeks enabling everyone at Ambrook to build their own AI workflows and automations — and what we learned.
This January was our busiest month ever — 4x the signups we’d had the year before, all showing up at once to set up their books, dig into the product, and brace for tax season.
To support our customer-facing teams, engineers spent time automating core Ambrook processes, building the foundation for connecting our disparate systems into a centralized place that an LLM could access. It’s also when our engineering team experienced what much of the world was experiencing: AI tools were getting better, to the point where we were seeing real improvements in how fast we could build and ship.
Through February and March, we saw some benefits to the infrastructure we put in place — automated follow-ups to meetings, tedious workflows condensed into a short prompt by a user, and in-product automations that helped us more easily serve customers. Even with these improvements, with the growth we were seeing, it was clear that even hiring wouldn’t be enough to keep up with demand. We needed a way to give each person the tools to make themselves more scalable. This wasn’t going to happen when folks were caught up in the day to day. Like any new set of tools, it would require dedicated time to test and learn how to use them.
After April 15th (Tax Day), we decided to pause non-critical work and run what we branded Momentum Month, a company-wide sprint where every individual — engineers and non-engineers — learned to identify, build, run, and evaluate their own AI workflows and automations.
The Setup
To prepare for the 6-week sprint, the two of us (Dan and Paige, leads of our Product and Ops teams, respectively) sat down with folks across every department at Ambrook. We asked them a series of questions to help us understand what we needed to automate and what tools we’d need to equip the team to do it. These questions included:
Tell me about your day.
How many hours of meetings do you have a week? Internal? External?
What have you done 10x in the last 2 weeks that took 5 minutes or more?
If we hired someone reporting to you to help you with your job, what would you delegate to them?
What kind of work regularly falls to the bottom of your list, even though it’s important?
If you could wave a magic wand and remove one painful or tedious part of your job, what would it be?
Last time you were OOO or on vacation, what broke?
If you were CEO, what would you tell the team to automate?
From these conversations, we decided on a few things:
We asked the team to remove all recurring meetings. We’d add back only the ones that felt mission-critical.
We asked each person to do the same exercise (if they weren’t one of the people we originally interviewed) so they had a prioritized list to work from.
We created a “platform” pod that was responsible for building the core infrastructure that would unlock individual workflows — improving core data systems, setting up the right MCPs, adjusting internal documentation that was distributed across multiple sources, and allowing Claude to work within the tools that teams used every day.
The Structure
A typical week had:
Tech Talk(s): a team member walking the team through a structural concept (agents, growth data architecture, automated triggers). Our final “tech talk” was hosted by our tech lead John, ruminating on how we stay human in the age of AI.
Pre-reads: short, opinionated pieces (e.g., Anthropic on building effective agents, Simon Willison on the lethal trifecta, an intro to skills and prompting)
Office hours with an engineer who could unblock you
An individual mapping exercise: a list of things that each person could automate from their own workflow.
We broke the content into 10 parts:
A selection of our Momentum Month slides.
We also restructured our team into small pods of 3-4 people. While we generally kept engineering pods and non-engineering pods separate, the latter we paired with a ”visiting engineer,” embedded as a TA rather than a builder. The visiting engineer’s job was to consult, share patterns, and surface structural blockers. They were explicitly not allowed to write the automations for their podmates.
We spent the first two weeks focused on individual automations, and the last four weeks connecting these to business goals, such as marketing funnel improvements or support efficiency, where teams were working on a set of skills together. In both cases, instead of engineers building for everyone, we had everyone building for themselves.
The Outcome
Before Momentum Month, we’d only seen individual-level workflow improvements. Users were using AI to draft, summarize, brainstorm, and code, each optimizing their workflows inside the confines of their own work. Claude skills were not shared or crossfunctional. As a result, the benefits weren’t compounding to keep up with the rate the company was growing.
Taking the time to make everyone a builder on top of shared infrastructure meant that:
Everyone on the team shipped a small feature or bug in the product. Our 75th percentile time-to-resolution for bugs dropped 35% — and teams across the company are empowered to file what they see.
Non-engineers authored skills pushed to our shared repo. Everyone can benefit from the repeatability they’ve created, and everyone can receive the feedback from their peers to make their skills better.
Every system became accessible to the organization, via an MCP or well-defined API that allows the team to avoid data entry across systems.
The conversation around AI can be framed as an identity crisis, a risk to our jobs, or worse. We choose to use AI as an opportunity to rethink how we’re building the company and the team. We built an instinct for where judgment and intuition are most valuable in each workflow, which AI cannot fully replace.
It also gave us new empathy for our customers, who like millions of other businesses are starting to adopt AI. Some of them are well ahead. Some haven’t started. But by working to help others on the team become more AI-fluent, it’s given the engineering and product team at Ambrook the perspective we need to thoughtfully introduce AI workflows in the product. For our customers to win, they’ll need to embrace how these tools can accelerate their business too.
What’s Next
This period was the reset we needed for everyone on the team to transform how we operate. To leverage what we’ve learned, we’re committing to:
Enabling our customers to become builders, too. We learned from how our teammates used these tools, and are committing to offering our customers the same opportunity. Building a community of Ambrook builders will help our customers win too.
Rethinking our team structure. We’re moving to smaller, high-agency “pods” of cross-functional teams tasked with a common goal. Engineers still have the right expertise to review code; operational teams can go deeper with the right customers. This helps us make the most of AI tools and move much faster to solve problems.
Building a true papercut-fixing engine. We’re starting a leaderboard for non-engineers filing tickets that get fixed. They’re the ones best positioned to document this friction, and we have the tools to more readily solve these — even with a small team.
Extending loops to handle more complex tasks. As new models are released and we continue to iterate on the product, we’ll have more work to do to speed up our idea-to-production pipeline even further.
Six weeks doesn’t make a team fluent in everything. But it has helped us understand the possibilities, and the investment it takes to make that happen. The compounding is just getting started.
If you want to compound with us, we’re hiring across all roles: ambrook.com/careers.
