Before IBM, I was a Cavalry Scout in the Georgia Army National Guard.
Our job was reconnaissance and security. Simply put, we gathered information about the terrain and the enemy so commanders knew what they were sending people into.
Every scout trains the same way. One Station Unit Training (OSUT) combines basic soldiering and the scout trade into one continuous 22-week program.
First, 10 weeks of the fundamentals: rifle marksmanship, land navigation, first aid, and basic communications. Then, 12 weeks of the craft: reconnaissance, vehicle operations, crew-served weapons, calling for fire, and reading terrain.
By the end, each of us could work every position in the squad and understood how they fit together.
Once we graduated and were assigned to our units, the mission set the roles. Mounted, one scout drove while another manned the gun. On foot, one took point, one carried the radio, one shouldered the M240B.
We were all trained to do every aspect of a scout’s job.
On a mission, your squad counted on you to do one.
That’s the part that feels familiar in an IBM AI FDE pod.
My OSUT platoon at Fort Benning. That’s me in the red square.
Same team, different responsibilities
A pod is the team working in the client’s environment to take an AI use case into production and help their people run it.
One FDE stays accountable for seeing the entire engagement through. The pod does the work together. IBM’s architecture, platform and product specialists can step in when the work needs them.
We come into FDE work with different backgrounds and strengths. But we all need a working understanding of four things: finding the right problem, building the system, earning trust, and keeping the engagement moving.
On each engagement, we put those strengths to work and agree who leads each one. Knowing the other jobs helps us back each other up without dropping our own.
In my pod, I lean toward the Engagement Lead role, drawing on my years in technical pre-sales at IBM. I spend a lot of time getting to the problem beneath the request, connecting technical and business teams, and making sure what we build gets used.
Nonetheless, I still need to understand what we’re building.
If an integration changes what we can deliver, I work through the tradeoffs with the engineers and explain them to the client.
Four essential skills sets, not necessarily four people.
Take the fictional claims-routing assistant from my first article. The client wants AI to send claims to the right team. Here’s how I think about the work we need to cover:
Finding the right problem:
The problem-finder leads discovery and sits with the claims team to understand where work gets stuck. Are claims going to the wrong queue, or do people lack the information to act on them? We need that answer before we decide what to build.
Building the system:
The builder leads the development work alongside the client’s engineers to connect the system, test it on real cases and make sure failures get caught and handled. They also help prepare the client’s team to run it.
Earning trust:
The governance lead brings in the client’s security and model-risk reviewers early and makes sure the build meets their requirements. Can we explain a routing decision? Who can override it? What evidence do we need before it goes live?
Keeping the engagement moving:
And finally, (my personal specialty) the engagement lead, keeps the sponsor involved, gets decisions made and checks whether the claims team actually uses the result. If the tool doesn’t add value to a process people already hate, the pod still has work to do.
Those responsibilities overlap. We work through them together, but each needs an owner the rest of the team can count on.
The work overlaps. And each responsibility has an owner.
Do your job
I like the line Bill Belichick made famous: “Do your job.”
On a football team, everyone needs to understand the play and carry out their assignment.
That’s how championships get won, missions get accomplished, and AI use cases make it to production. Everyone understands how the jobs fit together. Everyone gives relentless effort to the one that’s theirs.
In my pod, if I’m responsible for getting a decision from the sponsor, the team counts on me to get it. If I’m stuck, they need to know while there’s still time to do something about it.
And things change. A broken integration might reveal that we misunderstood the workflow. The builder needs help from whoever led discovery, and I need a decision on scope.
Understanding how our individual assignments connect helps us catch problems early and adapt together.
Everyone knows the play. Everyone runs their assignment.
First, agree on the problem
Before any of those assignments matter, we need to agree with the client on what we’re trying to accomplish. Whose work should improve? What’s getting in their way? How will we know we made it better?
Otherwise, we can all do our jobs well and still build the wrong damn thing.
That’s why commanders send scouts out first.
Finding the right problem is an AI FDE’s reconnaissance.
Next up: Five Phases of an FDE Engagement.
Disclosure: I work at IBM as an AI Forward Deployed Engineer. I write here in my personal capacity, and the views are my own. This is my interpretation of the role, not an official IBM publication. The example above is fictional and contains no client-confidential information.