Why Your Developers Should Meet With The Customer
What comes to mind when you think about asking your leading developer to join a meeting with the customer? “I hope she won’t say that this feature is impossible”, “I hope he won’t be rude”, “Are we risking that he can ruin our relationship in a 30 min meeting”. Well, let me share a personal story with you.
The first time I was requested to meet our customer, I was a young team lead of a small development team. The customer was an insurance company located in a different country, so I had to travel, and I didn’t understand how I, a developer, could be relevant to them.
What I couldn’t even imagine is what an impact they would have on me.
I remember entering an open-space room full of officers making calls and using our screens, the UI that my team created. It was overwhelming.
In the time that has passed, I’ve led several teams and groups of developers, and I always like to take this event as an example with me.
At this point you might be thinking — nice story, but my developers are already complaining about having too many meetings. Besides, wouldn’t they get confused with such unfiltered information? To put it in simple words — what do I gain from sending my developers to see our customers?
What’s in it for me?
Maybe you’re right? I mean, that is what product managers are for, isn’t it?
So yes, I don’t think that it’s the developers’ job to gather requirements or break down business requirements. But I do believe that you can gain in a few ways, by exposing your developers to the customer. And here is how…
Coding
When I started to write code, I couldn’t care less about who was going to be on the other side. Our modules were created according to the business verticals, and I couldn’t understand why. When you start thinking like the customer, your functionality becomes much more customer-oriented, and most likely better suits the business needs (and look, I’ve even managed not to mention micro-services!).
Impact
It’s an amazing feeling for your developer to see their work being used by real clients. You can see that in the difference between FE and BE. The engagement and commitment that you will gain when your developer understands that, is huge.
Focus
Prioritization is and still will be the product role, but it is much easier to explain the motivation behind specific choices when your developer is part of the process. When a developer is part of planning and triage meetings, or even presents in the room when things break, they will much better understand what is important and what can wait another sprint.
Shorten the cycle
In some cases, you need a technical point of view. It can even be a meeting to discuss some requirements, where if your developer was in the room they could have told you that it should be done in an asynchronous way, or that this functionality will cause performance issues. You can always take it up with the dev team later, but why not shorten the cycle?
Some practice
The way to achieve this interaction is easier than you might think. I like to split meetings into three categories — Pre-Dev, On-going and Post-Dev.
- Pre-Dev
Includes all planning meetings, sharing ideas, etc. I like to ask developers to join discussions about new features and opportunities with the customers. - On-going
These are triage meetings, dailies that involve customers or even team events and 1:1 personal conversations. In my group, we established periodic meetings with the account managers, who act as the customers’ representative when we sync on our accomplishments and share ideas. - Post-Dev
Involves handling crises and major bugs that have caught the customer’s attention, but also celebrating a milestone, going live with a big feature, and such.
Your developer can and should be invited to each of these meetings. In some they can contribute from their knowledge, and in others they will gain value in return. In some cases it might require traveling and sometimes it could be done remotely. As long as it involves communication with customers, it will be good.
A few words of caution
You might want to prepare your developer before the meeting, especially if it is the first time that they are meeting customers.
If there are sensitive topics, perhaps you want to raise them in advance, keep in mind that customers might come from different cultures and that your developer is less familiar with these nuances.
Try to describe the relevant roles, what the purpose of the meeting is, what they should bring to the table and when. You may be surprised by the human understanding a developer can cultivate.
One more point worth mentioning, is that you should make sure that customers don’t take advantage of this direct access to the development resource. It is very easy for the customer, who has the developer’s personal phone number, to send them a message asking to check something or to fix some urgent bug. It happened to my developers many times in the past, and it can become a great time consumer.
You have to make sure that all important communication still goes through the relevant stakeholders and processes in your company, and that escalations are always done in the predefined and agreed manner.
Just do it
Engaging your developers to go and meet the customer might require some effort.
Show them what they will gain and how this can contribute to the company as well. Explain to them that this is an experience that they cannot learn in the university and will require them to get out of their comfort zone, but they will learn so much while doing so.
Initiate this process in your team and who knows? Maybe your developers can be ambassadors to their colleagues as well.
