Should developers get involved in engaging with customers?

And what we can all learn from Mort the mouse lemur

Read time ~ 4 minutes. TLDR; yes, they should.

After my last blog, the area that got the most attention was around whether to put our creators (be it developers, engineers or designers) in front of customers. This prospect might seem frightening to both our developers and commercial teams, but let me explain through a laboured analogy. Bare with me.

I love to watch the film ‘Madagascar’ with my young son. In it, there’s a scene where the castaway animals from the New York Zoo (including our protagonist “Alex the Lion”) land in Madagascar and happen upon a petrified bunch of Lemurs, led by King Julien. How does King Julien know that these new giant animals are not “fierce savages”? Well, he takes the most cute and lovable mouse lemur called ‘Mort’ and dropkicks him in front of the animals to see if Alex the Lion eats him.

So at this point, Mort is our developer, Alex the Lion is our customer, and King Julien is someone who wants to see what happens. Usually me. Sounds pretty brutal right? Just to give you an idea of how commercial teams (certainly in the business-to-business product world) envisage this interaction going, here is Mort in this situation:

If the story ended here then this would be a horrifying way to engage with our customers. However, Gloria the Hippo soon scoops Mort up into his arms and assures him that everything’s OK. Alex befriends him too, although he’s a Lion so he’s still a bit scary. After a while, they’re all best of friends and sailing together in boats crewed by penguins and monkey powered biplanes </analogy>.


Surely it stands to reason that if we as creators take the risk to build up a rapport with the people we’re designing for, it allows us to understand their pain points and motivations which are the reason we’re building their products in the first place. Understanding our customers’ pain points gives us that intrinsic drive that pushes us so much further than carrot / stick models, knowing that our work is actually helping human beings make their lives easier. Taking that initial first step is crucial in fuelling that drive.

Commercial teams need not worry – your customers and users will respect you for trying to understand them and treat them as humans. Your products will be better because your creators haven’t got pre-biases on what they’re thinking, and will have asked some interesting questions. And yes they might not know everything about your field and look a bit bewildered, but if they never get the opportunity, they will never get better or create that empathy.


It is not the sole responsibility of developers to understand their customers and the user journey. A good Product Owner should be the primary contact with customers and users. However, they should be facilitating this interaction with the development team so that they get the best possible product.

In great organisations, especially those business-to-consumer models, there is a whole team dedicated to user/customer experience and product design that will integrate and facilitate these activities with all teams. If you don’t have this, to get started you should at least get in touch with some of the fantastic agencies dedicated to customer experience that the region has to offer – I can put you in touch with a few if you like 😉

And finally, four easy things developers can do in the short term

1. Start conducting usability tests if you don’t already. There are reams of literature on good test strategies including in “Don’t make me think”, however if you’re looking for a cheap hit here are some basic rules.

2. Find an easy going customer to practise on. Maybe a Gloria the Hippo, rather than an Alex the Lion. That latest bug that was filed? Call the customer to see what the problem was. If you’re nervous like Mort, you can always lead up to interactions through email, then phonecall, then face-to-face, but always remember there is immensely more value to be had gauging body language and tone of voice (Albert Mehrabian’s views are well documented – and cited – on importance of non-verbal cues)

3. Talk to your commercial teams about how best they can facilitate customer-developer interactions. They might have just never thought of the idea before.

4. Volunteer for customer visits. Commercial / product teams seem worried that developers will embarrass the company by not knowing anything about their domain or staying quiet. I’ve outlined above how this seems counter-intuitive.

And that’s it. Thanks for reading, as always interested to know who’s reading this, what you do and any comments you have on this or any more of my content. Thanks beautiful human for reading.

July 2020 Edit : I just felt that my wonderful experience of taking part in a Design Sprint last year should be noted as an excellent way to get closer to the customer. Whilst developers might not end up talking to the customer, it’s an intensely customer focused 5-day workshop that uses design thinking to produce a prototype of your idea directly to the customer at the end. Empathise, test assumptions quickly, and get that feel-good feeling after slogging a great idea out for a week.

Zero Day Blog – Five Themes in Humanising Software Development

“At the risk of generalising, we are an industry of proud and noble nerds.”

So this is my first blog. I want to keep them quite informal and light-hearted, so try not to take what is essentially my opinion too seriously.  

If you’ve read the home page or my bio, you’ll see that I’m interested in addressing the human aspect of product development, particularly in the software sector.

At the risk of generalising, we are an industry of proud and noble nerds. We generally value technology, data and facts over human interactions. It’s easy for us to concentrate on the technology first, rather than the people it helps. This directly contradicts two of the four key points in the Agile Manifesto:

  • Individuals and interactions over processes and tools
  • Customer collaboration over contract negotiation

“People first” (whether it’s customers or employees) is an ethos I’ve worked hard to ingrain in me throughout my career as a developer and a manager, and I hope that I can share some of that with a wider audience and hopefully learn something from you too (please do critique and comment in the section below).

So whether you’re reading this as a developer, engineer, manager or recruiter, here are five topics I hope to blog more about in the future that I hope you will resonate with.

1. The Recruitment Process

Gosh, I could write a lot here. The candidate experience is massively important and directly affects your credibility as a manager and a company. Don’t leave candidates hanging. Don’t use one candidate against another as a way of assessing whether one of them is good enough (that includes waiting to see what the next candidate is like before you’ve decided the current candidate is any good). Have a solid metric or bar and if the candidate meets it, hire them soon. Read how Amazon / AWS do it here.

Lastly, if you’re going to use recruiters, which you should do in our industry and region, use a very small number of trusted recruiters who are going to give your candidates the time and experience they deserve.

2. Networking

Boy, developers really don’t like talking to other people do they? I’m still on the fence myself. However I do know that when AI, blockchain and [insert buzzword] take over all our jobs, our networks and relationships are the only thing we have left.  

I would not have the fantastic team that I have without investing the time to network, being active on social media and generally being interested in people. Example mediums I have to thank for recruiting people: 

  • LinkedIn 
  • Recruitment fair (didn’t have a stand, just turned up and chatted) 
  • University expo 
  • Local meetup 
  • Beer festival (and no, I did not hire them because they drank beer. More on this story some other time…) 

Persuading developers to go to networking events, meetups or conferences in my experience is pretty hard, but I’m confident of the benefit it will bring everyone in the long run. 

3. Customer Experience

Again loads more to come on this I hope, but starting with customer problems and articulating them through interaction rather than starting with technology is something we as engineers can always get better at. There’s a few decent books about UX and customer obsession in my about section, and I plan to talk about some of the things my colleagues are trying out here. 

4. Motivation through empowerment and intrinsic drive

I once interviewed a candidate who was clearly so frustrated with his current company, I asked him what they said when he brought his unhappiness up with them. The company’s response was “well there’s no barbed wire on the door”. Christ. Regardless of what that particular individual’s circumstances were, with that attitude you’re going to eventually end up with a second rate delivery that sucks, morale that sucks, employees that suck as a result, and you’re generally going to suck. 

It is no longer acceptable to use the carrot / stick model with creative teams as Daniel Pink puts it so succinctly in his book ‘Drive’. Design engineers like software developers mostly have an intrinsic interest in what they do in delivering beautiful, creative solutions, and industry needs to tap into this to get the absolute best out of our engineers. 

“Just because we’re creative, doesn’t mean we all want to work in an open plan bean-bag filled unicorn shed”

5. Other quirks, trials and tribulations of working with software engineers as human beings 

If you’re after a humorous but incredibly generalised tutorial on talking to software engineers, try this. As much as I’ve generalised here, we’re all still individual complex human beings with different needs. Just because we’re creative, doesn’t mean we all want to work in an open plan bean-bag filled unicorn shed. Engineers need places for deep work, an uninterrupted time boxed creative thinking session to maximise productivity (although if that’s not your bag, check out Microsoft’s research on Microproductivity). 

So that’s about it. Hopefully more (shorter content) to come. If you have any questions or any topics you’re interested in, let me know. Even if you just leave a like, it will spur me on into creating more content.

Thanks beautiful human for reading.