Mashing up software thinking and People & Culture

There’s this game that I love to play called “the mashup game”.

Basically you take two unrelated things and mash them up together to give you something new.  So for example if I mash up a daffodil with a cat; then I might get a cat that when it does its business in the garden, a daffodil will grow 🙂

This is a great game to play with your kids or over a glass of wine of an evening; however it also has big implications in business.

Every organisation has areas of excellence and specialty, for example an ad agency will have creative know how, a manufacturing firm will know all about precision, or a project mangement company will be experts at organising many moving parts and deadlines.

As People and Culture professionals working within these companies, its vital that we “mash up” what we do with what we can learn from various functional experts within the company.  At Vend, I get a lot of inspiration from my marketing, business analytics and engineering colleagues.

All of this has led to me, unwittingly really, developing a software or agile thinking approach to doing People and Culture stuff.  I wanted to share how I do this so you might take some inspiration, especially if you don’t have engineering peeps in your organisation to model.  Please note that I am no expert at agile thinking and I’m sure the agile purists will find lots of holes in my reasoning – so if you’re an agile purist – stop reading now 🙂

Iterative thinking and MVP

There’s this picture in the ladies bathroom at Vend – it has a panel at the top with a tick, and a panel at the bottom with a cross.

In the top panel it denotes an MVP (minimum viable product) which in this case is a skateboard; then it has the next iteration, which is a scooter, then the next iteration which is a motorbike and then finally the last iteration which is a car.

The bottom panel – the undesirable one, marked with a cross – shows stage 1 of the car which is the wheels and axle; then onto stage 2, which is adding the chassis, then stage 3, adding the motor and body, and then finally stage 4, adding the doors and windows, a fully functioning car.

When you’re building software, you want to create your MVP, test it, learn, refine and then get your next iteration out the door.  You want iterative thinking.  This way you can constantly check in, ensuring that you’re on the right track.  The stakes in building a beautiful product step by step without testing it along the way are huge – in terms of lost time, dollars and missed opportunities.

We can do this same type of thinking in People and Culture – instead of working on a project for months with no testing, figure out what your MVP is and get it out there, test it, learn (which may mean making a big mistake), review and change if necessary.  Then rinse and repeat.

Fail Fast

Very closely aligned to iterating is that failing fast is a good thing.  Basically test what you’re working on regularly and be prepared for it to fail.  Be prepared to try another approach, to reevalute what the problem is, to go back to the drawing board.  It helps of course if you can figure out what success looks like at each stage so that you can objectively check in to ensure you’re on the right path.  I don’t need to tell you that biases exist so if you can have a predefined measure of success and be honest when assessing against it, you can get your ego out of it, and make the call.

Use Data (but don’t forget your intuition)

At Vend we have a love affair with data.  And because we’re a SAAS company we have data coming out of our ears.  So we use data to make decisions.  Of course some data is easier to capture, analyse and interpret than others; and in general People and Culture data is a lot harder to use than sales data, marketing data, customer data, etc.  But it can be done.

Of course we all know about the main data points – engagement surveys, regrettable turnover, length of service, sick leave, internal promotions, L&D spend, etc.  But for each project you’re working on, you can probably find other data as well.  So for example in the leadership programme at Vend, we track participation and satisfaction rates, as well as certain markers within the engagement survey.

All this talk about data is one thing, but also remember to touch base with your intuition.  If data and intuition are on a spectrum, then as People and Culture Professionals we need to be able to move up and down that spectrum at any given time, and remember that sometimes the data will send us in the wrong direction; and sometimes our intuition does fail us.  So its a balancing act of both things.

Retrospectives and Post Mortems

Within software, retrospectives are very common.  They might happen once per sprint, once per month and also once per year, etc.  A retrospective is basically a time to look back over what has gone well and what hasn’t in that period of time.  Often it is based around a couple of questions, being: What did we do? What went well?  What didn’t go well?  Its a chance to check in with your objectives for that time and see how you went meeting them.  If necessary you can tweak the system so that you increase the chances of hitting your goals for the next period.  Oftentimes questions will be asked like “What should we stop doing? What should we start doing? What should we do more of? What should we do less of?”

A post mortem is held when something goes wrong.  Its aim is to get to the bottom of the issue.  A really easy way to do this is by asking the “Five Whys”.  Essentially whatever has gone wrong, you ask Why? And then to the answer of the first Why you ask another Why, and so on and so forth.  If you find something in there that is a big issue, then put it to one side and do five whys on that one thing after you’ve finished the first exercise.  This is a great way to get to the fundamental systemic things that may be causing problems.

Also note that a post mortem in a software company is normally held very quickly after the problem has surfaced, so haste is important.

Lean Process

At Vend we love lean process.  We don’t like bureaucracy and try to ensure that we don’t inadvertently sprout one.  Of course this can be challenging within People and Culture, because some of what we do is compliance, and as such, there are processes that need to be in place.

And I have found it to be true in my career, that often People and Culture people loooove process, even sometimes if it’s to the detriment of company culture and overall efficiency.  So ask yourself before you’re about to email out a 20 box checklist, or get overly prescriptive on job interviews, 1:1s or anything else, how is this process helping the business succeed?  And notice there the focus on the business.  As People and Culture people we are there to help the business succeed and help its people thrive.  If what you’re about to do is simply to feather your own nest, or make you feel like you’re doing a great P&C job even if the business don’t need it, then stop at once, and go back to the thinking about MVP.

These are some of the things that I have learnt from doing People & Culture in a software environment.  I’d love to hear from people who do People & Culture stuff in other industries and what you have learnt from your functional experts that you bring into your work.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s