Resources are people, too

I am not a number- my life is my own

Resources are people too – and it’s companies that know this that get recognised as great places to work

I was on a call recently where I got told that one of the people starting on a project was “a great resource”. Not a great guy, or a really good analyst, but a great resource. To my mind, that encapsulated how businesses, particularly large corporates, have come to regard those guys and gals that actually get the work done for them and why people still consider things like offshoring to be anything other than a false economy.

I’ve been thinking about this post for a few days and it suddenly seemed quite timely when I saw a recent tweet from Matt Barcomb that said, “Can we stop generally calling people resources……and start calling them biochemically fueled water/carbon units? LOL”. Facetious? Yes. Bang on? Yes.

Strategic decisions are being driven purely from the balance sheet, which means that knowledge is usually the casualty; putting a price on knowledge is difficult. So it comes down to roles, headcount and associated costs, because these things can be easily measured. That leads to redundancies and marginalisation of experience in favour of ‘cheap’ offshore/outsourced labour. Documentation becomes king and, as stated in Barry Evans’ great book Agile Exposed, “essential IT becomes more of a liability to the people who, in the name of cost cutting, gave away the essential control that skilled in-house programmers would have provided them with”

Personally, I think part of it comes down to fear: a lot of businesses don’t want to think they need to rely on people, because what’s going to happen if you get hit by a bus? Relying the less emotive ‘resource’ is much simpler. I rely on the wheels on my car; if one gets a flat, I replace it with another and I know I can get one from any number of garages and chances are it will be equally effective and reliable. Turning to a close friend or relative for advice or reassurance can be the most quick and effective panacea in times of need. Try swapping that out like-for-like. Bring that comparison back into the world of IT and try swapping out a conversation with a developer about a specific requirement for a 60-page document on a teleconference.

In The Tipping Point by Malcom Gladwell, there is a chapter called “The Law of the Few”, where he talks about Paul Revere‘s famous ride across America with the message ‘The British are coming’ and how that journey fired the communities through which he rode so vigorously that, by the time the British arrived, they were heavily defeated by the organised resistance they met. He also goes onto talk about the fact that this was not just down to the sensational news that Revere was carrying, because he compares the negligible effect that the same message had when another revolutionary, William Dawes, set off in a different direction, covering the same distance and communities as Revere. The conclusion being that “Revere’s news tipped and Dawes’s didn’t because of the differences between the two men“. He preceded this by stating that the success of any social epidemic depends on the social ‘gifts’ of the people involved.

Warren Buffett and Simon Cowell

These are people, whether you like it or not…

Like it or not, personality and social traits are a big part of the package. If they weren’t, people wouldn’t still bother with interviews to see if you’ll ‘fit in with the team’. If people want the best in investment, they look to Warren Buffet. If they want the best in music industry knowledge, then love him or hate him, they’ll look to Simon Cowell. Headhunters exist because if people want the best for their business, they go looking for people, not just a role profile.

The best project I’ve worked on was led by a guy who had some of the greatest man-management skills I’ve ever seen, knew how important team spirit was, but still retained the ability to manage his senior stakeholders effectively. The worst projects I’ve ever been on involve those people that are only interested in managing upwards, which basically means the people doing the work are dragged from pillar to post, with poor direction, ever-changing priorities and very little recognition for what they do.

In that first project, the timescales were ridiculous for delivering the scope required; because of the respect engendered in his team, people committed the extra weekend hours and late nights to delivery without being asked. We had a shared understanding and commitment to each other and we delivered. Repeatedly.

In an example of the worst project moments, when challenged on the priority of producing a piece of documentation over the delivery of a piece of code vital to meeting project objectives the project manager said “everything’s a priority”. Completely straight-faced as well. The need to manage upwards and appear on top of everything was the greatest priority, which was to the detriment of the people working for him.

People are loyal, by-and-large. Build a team around respect and knowledge and there is less likelihood people will jump ship to the next best thing at the next opportunity, because they’ll already be part of it. Companies seem scared to train people for fear they’ll go to a rival. That’s just low self-esteem on a corporate scale, which is why command-and-control systems are still a massive part of working life and methods like Agile are still treated like the black sheep of the family. Or people want to adopt it, but want to wrap it in stifling layers of governance.

People are your business. Treat them as such and maybe your next employee engagement survey won’t stink as much.

2 thoughts on “Resources are people, too

  1. Another great blog Nick. When asked over the years why I left HBoS, one of my stock responses was… in the time I was at HBoS I seemingly transitioned from being a ‘colleague’, to an ’employee’, to being an ‘ID’. It was something which relentlessly irked me. Working as I do now, in a small business (20 of us, flexing with contractors coming in and out), you’re valued as a member of both your project team, and almost more importantly as a member of the company team. As such, we all pull in the same direction in taking the company forward. This inspires commitment to quality not restricted to projects, but in the wider operation of the business.

    • Hi Rich, thanks for your comments and great to hear from you as always!

      You’re spot on and HBOS/LBG is a great example. I remember speaking to someone last year that described it as a cultural change from a community feel to that of a ‘big City company’.

      With the massive rise of social media and the explosion in app development, companies are doing far more with far less, but they can do it because the emphasis is on creativity and innovation, which allows people to flourish and strong relationships to be built. It’s the virtue of trust versus contract that Agile extols; the emphasis on conversation and collaboration.

      One of my recent projects could probably have done far more with far less, but rather than focus on the people they already had and what ideas they could bring to it, management only looked at numbers and resource requirements, the end result being ‘throw more resource at it’. Which meant more people; more reporting than delivery in order to keep track of what all those people were doing and ultimately, failure. When it turns into a pure numbers game, it’s a disaster waiting to happen.

      Don’t get me wrong, good use of data is hugely important in making decisions and that data will be numbers and other factors (although the term ‘Big Data’ is really starting to get on my nerves!) Stepping back from the emotional element may allow a degree of clarity to be established. But it comes back to my point: how do you accurately measure knowledge? Knowledge is power [slaps self for slightly trite saying] so companies should look to harness the power that their people have instead of spending as much time and money as possible mitigating the risk that they might leave by producing all the documentation under the sun.

      What nearly made me spit out my drink a while back was a PM that said ‘code is not documentation!!’, which brought back a rush of memories about how well commented code is one of the best sources of documentation you’ll get, because it’s how the system is actually working. Not how it was thought to work originally, but what it actually does now. So instead of using that documentation, an analyst has to disappear into a hole and produce other reams of documentation, most of which is probably never read and where an SME will undoubtedly say, ‘speak to one of the development team to find out how the code works now’.

      Documents don’t deliver projects: people do. It sounds like your current experience is one that we should all be aspiring to and I hope it continues on in the same vein.


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