The Forward-Deployed Anthropologist

Long before “forward-deployed designers,” I spent two weeks watching enterprise sales reps. Here’s what I learned.

At 9 a.m., notebook in hand, I settled in with Steve at his cubicle. As an enterprise sales rep, he was naturally warm and personable, but it was still weird for both of us to sit crammed shoulder-to-shoulder in his cube.

He powered up his laptop and set a hardbound notebook on the desk, next to his phone and calculator. He plugged in the Blackberry first. Then he opened Yahoo! Finance — configured, I learned, with the stock tickers for his current customers. Company email came last.

He only opened CRM when an opportunity needed updating for a pipeline call or pipeline reporting. He tracked his phone conversations in the notebook and kept information about his contacts in the Notes field in Outlook. CRM was the system of record, but it held almost none of the information that made him good at his job.

Why I went and observed

I’d been re-orged again, but I was still responsible for the SMI, the Sales & Marketing Intranet. I was concerned that I knew nothing about salespeople nor what their work was like. How was I going to shape the direction of SMI without that basic understanding? I wanted to learn what I’d need to do the job well. So rather than guess, I secured support to observe (or shadow) some of the reps our team was responsible for enabling.

Right now there is a lot of chatter about forward-deployed engineers. As that idea spreads, there is also some conversation about forward-deployed designers. In his recent article, Jakob Nielsen argues the ideal profile is an anthropologist. That’s exactly what this work was — observing high-value employees and finding ways to streamline their work. This was twenty years ago (before UX was a well-known discipline), and it was my first non-academic project as a workplace anthropologist.

The reps were good-humored about the whole thing; in Boston they started calling themselves my “specimens.” So I observed, and here is a bit about what I learned.

70% of their office time went to admin

One misconception about ethnographic research is that it’s slow and expensive. It does take time to do it well, but the trade-off is that the sample size can be quite small, and the data is rich. “Thick description,” as described by Clifford Geertz. I spent ten days in the Philadelphia suburbs and then Boston, watching five Large Enterprise AEs for two days each. It turned out to be a worthwhile investment of time and energy.

These reps came into the office roughly two days a week, and I shadowed them on those days. They traveled into the office for admin work, using the time to navigate SAP’s bureaucracy and systems, and to handle what couldn’t be done over the phone — reviewing legacy contracts (which were still on paper at the time), meeting with the finance team for help with pricing. Roughly 70% of their in-office time went to that type of work. All the while they were chomping at the bit to get back in front of customers.

A colorful calendar for the week of April 6-10, 2009, displaying the daily schedule of an enterprise sales representative, highlighting various activities like customer calls, meetings, and administrative work.

This research was also my first real look at how a rep uses CRM. As central as it was for SAP management and sales ops, it barely featured in the rep’s day.

I noticed that none of the reps ever mentioned commissions. That seemed strange to me, knowing that most reps dreamed of “the seven-figure W-2.” I finally got up the courage to ask a couple of reps how they tracked their compensation. That was how I learned how complex the commissions process was, and why it drove so many calls to finance.

Twelve needs nobody had named

By the end, I’d distilled my findings into twelve unmet needs, none of which a rep would have named in an interview. These were manual steps, or workarounds reps had built to get through the parts of the job the systems didn’t help with — things unlikely to come up in a survey or interview, but visible through observation with the right time and patience.

Those unmet needs became a roadmap, and in the years that followed, most of them were addressed through process changes, templates, and/or bespoke internal solutions. Two of the most impactful findings were in the contracts and commissions area. The legacy contracts they kept pulling up and evaluating manually became Contract Management, and the commissions process became a Commissions Workflow solution. Each is a case study of its own, for another day.

Leadership later credited our team with a 20% lift in sales productivity, in part from programs that began with these findings. Many of our efforts came from these insights, which couldn’t have been surfaced any other way.

Twenty years on, the same gap

Sales productivity is a perennial problem. When I left SAP in 2011, I was still getting calls about the damn pie chart I used to report the findings. People wanted the study, the context, and the findings years after the fact. Twenty years on, reps today spend only about 28–30% of the week actively selling; the reality of sales rep productivity is now widely known.

Sales enablement and CRM have been a throughline in my work ever since. In the software development group at ZS, my team and I studied pharma reps and built the systems that support them — B2B sales has similar pain points, regardless of industry. That work is in the market now under the ZAIDYN brand. You can read more about that work here (Field Insights) and here (Dynamic Targeting).

Forward-deployed engineers need forward-deployed designers

A forward-deployed engineer (FDE) is supposed to embed with the people doing the work and build based on what they see. The concept is not new — social scientists have been working in the business setting this way since the 1920s, and observing human behavior long before that. But engineers focus on systems and perhaps processes — they don’t necessarily observe people. That creates risk. If the work isn’t well understood, all you’ve done is automate the wrong thing, faster.

Achieving that level of understanding is harder than it seems. It isn’t just observation; it’s the analysis and synthesis that turn what you see into what matters. Some of that expertise comes from knowing how enterprises, and sales teams, really work. That’s what a designer or a social scientist can do to make an FDE’s outputs stronger.

So before you point your best engineers at the problem, ask yourself whether anyone truly understands how the work is getting done, and what that’s telling you about how automation can help.