The balance of people and product

TLDR; favour people.

dilbert.com

So a combination of finishing my new favourite book “The Infinite Game” by Simon Sinek, a change in career and some pretty heavy family events has led me to reflect a lot on this question. 

To clarify, when leaders favour people over products, they make a conscious decision to sacrifice the speed of product development in favour of supporting the team that are working on it. When leaders make decisions that favour products over people, they make decisions they have deemed to be for the good of the product, project or bottom line sometimes to the detriment of the team. Sinek also refers to this as “will over resources”. In the infinite game of business, he provides evidence (both anecdotal and empirical) that companies who make more of the decisions that invest in trust and psychological safety over profit stand the test of time. The DORA 2019 State of DevOps report (a benchmark guide for high performing software teams) suggests that elite performers in our industry have a culture of psychological safety as a building block for high software delivery performance. To build exceptional products, it requires an exceptional investment in people.

As he explains it so beautifully in this video, Sinek suggests that even if we can tip the balance of our priorities 51/49 in favour of people (will over resources), the rewards are obvious.

Many leaders have a bias towards people higher than this, not that I have any way to quantify it. This brings its own problems (lack of exposure to at C-level, perceived slower project delivery etc.) which I have personally encountered. This is not a strategy I recommend if you want to climb the corporate ladder quickly, but it is one that I recommend if you want to make a positive difference to people’s lives (and, as it happens, also delivers great products and brings in revenue to the business).

“If employees don’t feel cared for, they are statistically and significantly more likely to leave”

A study by Gallup that pops up time and again (first referenced in “First, Break All the Rules” – 1999, Buckingham & Coffman) asks over one million employees around the world to agree or disagree with the following statement : “My supervisor, or someone at work, seems to care about me as a person”. This Gallup defines as the The Fifth Element of Great Managing. The study finds that those teams that answered this question in the bottom quartile (that is, the teams that answered ‘no’ most often) had a 37% higher turnover rate than those in the top. If employees don’t feel cared for, they are statistically and significantly more likely to leave. For more reading, this post does a better job of explaining it than me.

In Summary

  • Psychological safety is the number one building block for creating elite performing teams in software delivery according to DORA
  • If employees don’t feel cared for, they are statistically and significantly more likely to leave

My personal argument for people over products like this: Investing in teams is like investing in a savings account. You use the capital in the account to ‘buy’ delivery of a high quality product. You cannot call on reserves when you have not invested, and you will pay for it later if you take out a loan to do so. 

Building rapport with humans and creating a culture of psychological safety requires heavy investment, and is hard work. However, Sinek reminds us that to favour ‘will’ over ‘resources’ and to build trusting teams is key to playing the infinite game of business, and ultimately delivers the best possible product for our customers.

A call to action for software companies – talk to each other!

“At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly”

Agile Principles

So states the agile principle, but considering we’re all supposed to be finding new ways of improving, it sure is darn hard to talk to other teams about it.

Firstly, let me say networking events continue to be a fantastic source of knowledge transfer for our industry. In our region in Teesside for instance there’s Refresh Teesside and the Hainton meetups, but people tend to have their guard up at these events. The conversation leans towards the ‘this is what we’re doing right’ rather than ‘this is where we’re struggling’. I always find the latter conversation extracts more value, and I feel way more secure talking about this in my environment of work with the people and tools available.

I’ve been on a personal mission the last few years to try and invite developers from other companies to come on site to have a look around at our tools and processes, in exchange for an optional reciprocal tour. Both sides gain insights, understand where their strengths & weaknesses are and hopefully take something back into their retrospectives to make them more rounded teams. Reciprocation has been a challenge at best.

So taking a leaf out of the call centre handbook, I thought I’d share a script to counteract the most common reasons why companies are reluctant to share…

1. We’re too busy / don’t call us we’ll call you

Number one reason we get. I have a simple flowchart that helps in this situation:

Whilst it’s a bit tongue-in-cheek, the situation always reminds me of the following ‘too busy to improve’ graphic that hangs pride of place in our physics office:

2. All my stuff is secret

OK, so let’s sign an NDA. And let’s not look at your super secret project. In fact, let’s not have a look at any projects at all. We’re really just interested in how we can be better developers and improve our delivery, and we’d love to help you out too if we can.

3. Are you scoping me / my team out for a job with you?

Nope. No strings attached, no hidden agenda, we just want to be better, and if we can we want to help you be better too.

4. Do you want a job here?

Probably not. I’ve knowingly arranged for my team to go to companies where they’re interested in hiring them, on the understanding that they’ll come back with some valuable insights on where we can improve our processes (I could probably do a whole other post on why it’s not a good thing if you’re a manager and this scares you!).

So please do seize these opportunities to improve (drop me a line on LinkedIn if you want to arrange a no-strings-attached meetup!) and ask this question of yourself : “Am I the hairy guy with the square wheels?”

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>.

Kay…

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.

Caveats

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.