Friday, September 28, 2018

On the destruction of a software team

A couple of posts ago, I tried to describe my experience of how a high performing software team might typically be formed and how the small startup approaches this differently to the larger organisation.  The irony is often that the larger organisation, turning at the speed of a super-tanker, is often desperate to capture the same feel, culture and belonging that small startups have, but without sacrificing their rigid 9-level organisation hierarchy, job roles and pay grades - and therein lies a problem.


As organisations scale, people are often put into role and pay 'boxes' so that they can be 'measured', 'managed' and 'appraised'.  Don't get me wrong, sometimes, this stuff is needed, but my experience is that the HR function of an organisation ends up being the driver of 'normalization' rather than an assistance or helper function to help tackle particular problems.

I'm pretty sure that when I was growing up, companies had 'personnel' departments rather than 'Human Resources'.  I've read explanations of the difference between the dated 'personnel' term and the more modern HR function.  Obviously these make HR sound much more impressive, citing faster decision making, strategic use of people as an asset of the organisation and grouping by function.  My issues with all of this are as follows:

1. I would prefer to be regarded as a person rather than a human resource.  In building decent software teams, I previously explained how small teams look for the right person to add to a team, bringing a collection of finely tuned complimentary skills and approaches that add maturity, balance and perspective to the team.  Adding '3 more human resources' - to me - sounds like a recipe for disaster.

2. A company regarding me as a 'strategic asset' is also not flattering. The only people frequently referred to as an 'asset' are the guys sent to kill Jason Bourne in the movies bearing his name. Asset also implies ownership, and while I'm happy to exchange a fair days work for a fair days pay, this betrothed relationship idea is nonsense - in fact, it is backwards. No one wants to work for a company that treats their employees like they own them.  Companies should be striving to create an environment where their employees feel a sense of belonging. That loyalty is not bought with a salary, it is earned with trust, empowerment and respect - the traits purveyed by someone blessed with leadership skills.

3. In the information age, our supermarkets have been using information not to categorise their potential customers into groups, but to treat them as individuals whom they can target individually based on individual preferences and habits - albeit to maximise their appeal and sales.  If your supermarket is willing to treat you more personally than your employer, what does that say about the attitude of your employer?

So what happens when you treat your software team as a pool of assets? Well, in my experience, the team dissolves quicker than a sugar cube in a hot cup of tea.

At one time, I was leading a small, but beautifully formed software team. The HR department moaned at me because it took me so long to find the right person each time I had a vacancy in the team. However, I was always looking for a person, not filling a role.  My team was great - well regarded throughout the business, and we'd been through many successful project 'battles' together and come out of each, stronger than when we started.

But the company was growing, and a bunch of managers were brought in to form an ironically named 'leadership team'.  Before lunch, a couple of levels of management had appeared between me and the senior people that I respected.  My new line manager was running the "Go big or go home" playbook mentioned in one of my previous posts, and I feared this would not go down well with my guys.  Our new 'leader' did not' 'go first' or 'eat last'.  He measured, criticised, re-structured and changed just about everything he could see.  Within 3 weeks, I received the first letter. A solid foundation of my team had decided to retire early.  She'd loved the many years we'd worked together since the early days, but things were changing, and now seemed a good a time as any.

A couple of weeks later, the next letter. Again, someone I respected hugely - a newer member of the team. She was the rudder of the team, meticulous in detail and had helped plan out our product roadmap for the next 2 years.  It was a project that we were all excited about.  Something we'd been itching to do for some time, something really good for customers and the future of the business. Something driven by a team that knew the product and customers inside out, something that we felt real ownership of - something that we would never deliver as a team.

In a small team, the loss of one team member is tough, and is felt by everyone.  It upsets that delicate balance in a way that is uncomfortable, but can be recovered from if there is collective will and a strong progressive vision. When the vision has died and 2 people leave, it's like losing the wing off a 747 - the most likely outcome is a plummeting spiral and the breakup of something majestic.

A few more weeks pass and my lead developer hands me a letter. This is a guy that loves to code - a real workhorse of the team, and someone who I'd worked alongside for the better part of 10 years, sharing a love of code and Pink Floyd, bike rides and curries. Even I could see the writing was on the wall.

After 12 weeks, 5 amazing members of my team had left for pastures new. This was sad in the extreme, but more shocking was the fact that upper management were not pondering the question of how we had managed to lose 30+ years of experience in such a short space of time. The worst had happened, and our new 'leader' was running out of options.  Go big or go home.  Within a few more weeks, our project was being off-shored to a new team on another continent.  Apparently, management liked the promise of the ability to easily 'spin up a new team at the drop of a hat' - because that's how you deal with software projects - you throw human resource at it in quantity - and see where it takes you.

On the whole, good people (the ones you want in your team) are smart, and smart people are smart enough to have confidence in their own abilities. If their current employer is happy to treat them as a resource in pool of human resources, then they will be happy to exercise their right to seek out an employer who sees them as a person - a person with a very particular set of skills...

No comments: