One of the things that agilists say is to get the team as close to the customer as possible, in order to build what they truly need and achieve the outcomes that the business desires. However, in the past 20+ years, all I’ve seen agile teams do is have the Product Owner (or product manager) be the only person talking with the customer. If there were UX members on the team, they would also be part of the discussion (however, there were a few organizations I was in where this wasn’t the case).

But what about the engineers? Nada. Zilch. Hardly anything – except for when there was a huge issue that jeopardized a very important client (aka, one who paid lots of money and was p*ssed), and something needed to be done ASAP.

My first job after graduating from college was as a Technical Support Engineer for Sun Microsystems (yes, way back when, before the web/internet as we know it today). I was exposed to all sorts of problems from our customers and had a first-hand view of how they were having difficulty using o

ur hardware and software products. What seemed obvious to engineers was not quite so apparent to people.

One thing that Sun did well, which was unique and opened my eyes to customer-centered organizations, was something I’ve never seen any other company do after all these years working in Silicon Valley. Each year, engineers were required to spend a one-week rotation in Tech Support, listening in on the conversations with Tech Support Engineers like me. There were strict rules, where only the tech support engineer could talk to the customer while the engineer remained silent.

The first time I had an engineer sit with me was funny (to me) because I could see the engineer getting frustrated. He kept passing me notes on what the customer could do to resolve the problem. I kept scribbling back that the steps weren’t clear or intuitive for the customer, or it wasn’t something a customer would do because it didn’t quite solve their need or problem, or the steps were so tedious that customers would invariably make mistakes that woul

d cause more problems, or that the documentation was incorrect and has not been corrected for some time now.

By the end of the week, I saw how the engineers would have a new perspective on how they might design and build their software. They also had much more respect for Tech Support folks like me, given how we had to be very patient at times with customers who could be angry at us because they were frustrated that the expensive hardware/software they bought wasn’t doing what it was supposed to be helping them with.

At some point in my career at Sun, I eventually became a software engineer, and I, too, had to do my required rotation. Even though I came from a Tech Support background, it was nice to do a rotation because I would see things in a new light just by hearing what customers were going through, and it helped me bring back information to my team that helped us build or improve our products. We sometimes get blinders working on something for so long. Doing something as simple as this – listening in to customer calls trying to solve their issues – would easily remove the blinders that have been built up.

So, my question to agile teams out there – have you ever thought of simple ways such as this to get closer to your customer so you can really understand – and solve – their problems and needs? My question to managers and executives is, why not allow your teams to do something as simple as this?