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.

One reply on “Zero Day Blog – Five Themes in Humanising Software Development”

  1. A comment made by Robert Martin at a conference last year resonated with me for a number of reasons “we don’t work with computers because we like people” on this very topic. Whilst a massive generalisation it’s true for many that the environment of interaction with predictable computers is a lot easier than unpredictable, complex people. The art form is getting the best out of people to deliver this highly organised 0’s and 1’s and accepting one size doesn’t fit all.

    Like

Comments are closed.

%d bloggers like this: