People are not our most valuable resource – a response

Pawel Brodzinski recently wrote a post entitled ‘People are not our most valuable resource’ the point being that people aren’t resources at all , they’re people and should be treated as such.

 

“Every time I hear this cliché about people being most valuable resource I wonder: how the heck can you say people are most valuable when you treat them as resource? As commodity. As something which can be replaced with another identical um… resource. If you say that, you basically deny that people in your organization are important.”

I’m in agreement with Pawel on this point, but I’d go further. Not only is a statement like ‘People are our most valuable resource’ degrading and counter productive, even if you restate it as ‘Nothing is more important than our people’ it’s still incorrect. The real value had nothing to do with people and everything to do with teams.

The key thing that a team provides is a means to align the goals of its members. These goals need not be for the greater good of humanity, in fact they’re generally much more mundane. It really doesn’t matter who wins the world cup* or whether project omega will ship by next Tuesday, all that matters is that the team succeeds in its common goal. A group all pulling in the same direction is orders of magnitude more effective than that same group working as individuals – a business cannot be successful without effective teams.

The trouble is the word ‘team’ is massively over used, it’s a buzzword that has become so ubiquitous we don’t even notice it. The tendency to assemble a group of disparate people and label them as a ‘team’ devalues the concept. One area where this is especially true is that of ‘The Management Team’, generally comprised of middle management peers from various disciplines this group often have very little in common in terms of shared goals and identity.

And here lies the problem, if management is unused to working in a team themselves, then the value of a team is less visible. Furthermore, since it is generally individuals, not the team as a whole, who complete the component tasks the team effect is not obvious from afar.

I don’t think you’ll find an organisation that is anti team, simply that it’s hard prioritise the tasks necessary to encourage team formation when the value of teams is poorly understood. It’s easy to measure the cost of co-location but much harder to measure the benefit to the co-located team, hence the true value of the team is passed over.

Not only are ‘people are not our most valuable resource’, people aren’t our most valuable anything just on their own, it’s all about teams.

[In this post I’ve purposely avoided the subject of how to form a team. It turns out that it’s quite tricky, I’d recommend Peopleware as a good place to start.]

* Except if it’s England of course.

 

 

Hell is for Heroes

Last December I attended the London XPDay, the session I enjoyed most was run by Chris Matts on the subject of Heroes in the context of software development teams.

What makes a Hero?

Chris put forward the idea of the ‘Hero’, an unofficial role assumed by an experienced developer critical to the project. There are positive aspects to the role, this is person turned to in the moment of crisis when something must be fixed ‘right now’, they are the person with the deepest knowledge of the system and an indispensable contributor to the project.  As with many things, however, this strength can also be a weakness. The feeling of being indispensable is very powerful and freely sharing knowledge and collaborating with other less experienced/capable team mates only undermines this feeling. If the Hero is no longer the only person who can fix the problem, surely that makes them less important?

In extreme cases the presence of the Hero becomes toxic, reluctance to collaborate is unpleasant, but active obstruction and obfuscation is something else. At this point the team/project has some serious problems. On the one hand it is doomed to failure without the Hero, on the other-hand, the ability of the group to act as a team evaporates and progress on the project is brought to all but a standstill.

What to do when a Hero goes bad?

We spoke for about an hour on the subject and while there were one or two examples that partially dealt with the problem, ranging from ‘move them to another project’ through to ‘fire them’ (!), no-one in attendance was able to provide a truly positive example of recovering from such a scenario.

I am fortunate in never having worked with anyone quite as extreme as the examples presented in the session, but where I have seen glimpses of this behaviour my sense is that overwhelmingly, the behaviour is the product of environment rather than necessarily any failing on the part of the individual.

The participants in the session, seemed to be made up of managers/coaches rather than out and out developers, which may explain why much of the discussion seemed to presuppose that the fault lay solely with the Hero.

Common environmental factors that I have observed include:-

  • Perceived ambiguity over who has technical responsibility for a system
  • Poor performance feedback and/or poorly communicated career development
  • Lack of trust/respect amongst team mates
  • Seemingly overwhelming operational issues
  • Compensation schemes pitting team mates against one another

It is the manager not the Hero who has most influence over these points. So I think that before answering the question ‘What to do when your Hero goes bad?’, a better question, as a manager is ‘What have I done wrong to allow my Hero to go bad?’.

Focus on Teams

Unhelpfully, as with all management problems, the best way to solve the problem is not to have it in the first place. Placing greater emphasis on the performance of the team rather than on the individual can help here. Any action that benefits the whole team is recognised and celebrated so the Hero need not lose prestige by supporting those around him. In fact the Hero’s standing increases since he is now multiplying his own capability through increasing the skills of the team. As a side effect, since the team is now more capable the Hero has more time to spend on the truly difficult problems, which in time, he will pass onto the rest of the team.

Switching focus away from individuals and towards the team is a non trivial exercise, but if the agile movement has brought us anything it is methods to engender collaboration, trust and team level thinking.

How I Manage Technical Debt

debt pillIn the previous post, Technical Debt is Different, I talked about the need to treat management of technical debt as a separate class of problem to that of feature requests generated outside of the team.

As with any project above a certain size, team collaboration is key, and that means having a reliable method of prioritising technical debt that the whole team can buy into. This post will describe a method that I have been using over the past year that satisfies this need.

Identify

I was new to my current the project and wanted to get an idea from the team of the sorts of things that needed attention. I mentioned this just before lunch one day and by the time I got back from my sandwich I had an etherpad with over 100 hundred items. By the end of the afternoon, I discovered that etherpad really doesn’t deal with documents above a certain size.

It was clear that we needed to a way to reference and store these ideas, I had two main requirements.

  • It was easy to visualise the work items
  • An easy, non-contentious way to assign priority

The first step was to go through the list and group items into similar themes, this helped identify duplicate or overlapping items. At this stage some items were rewritten to ensure that they were suitably specific and well-bounded.

Prioritise

Now that we had a grouped list of tasks it was time to attempt to prioritise. As discussed in the previous post, prioritising refactoring tasks can be challenging and passions are likely to run high. I felt that rather than simply stack ranking all items, it was better to categorise them against a set of orthogonal metrics. This led to a much more reasoned (though no less committed) debate of the relative merits of different tasks.

Every item was classified according to:-

  • Size
  • Timeliness
  • Value

Size

The simplest metric, this is a very high level estimate of what sort of size the item was likely to be. Estimating the size helped highlight any differences in perceived scope, and in some cases items were broken down further at this point. Size estimation works best when estimates for tasks are relative to one another, however to seed the process we adopted the following rough convention.

  • Small – A week
  • Medium – 2 weeks
  • Large – 3 weeks for 2 people

Timeliness

Timeliness speaks of how the team feels about the task in terms of willingness to throw themselves into it. Items were assigned a timeliness value from four options.

  • ASAP – There is no reason not to do this task right now. Typical examples include obvious items that the team were all highly in favour of, or items that the team had been aware of for some time and feel that enough is enough.
  • Opportunity – An item that lends itself to being worked on while the team is already working in the area.
  • Medium term – An item that is thought of as a ‘wouldn’t it be nice some day’. The items are typically riskier than ASAP or Opportunity and the team need to really commit to it’s execution before embarking on the item.
  • Long term – Similar to medium and generally populated by reviewing the medium section and selecting items that are imposing or risky enough to postpone behind other medium tasks.

Value

How much will the team benefit from the change? Is it an area of the code base that it touched often? Perhaps it will noticeably speed development of certain types of features. It could be argued that Value is the only metric that matters, however Value needs to be considered in the context of risk (addressed through timeliness) and effort (addressed through size).

All items for a given Timeliness are measured relatively and given a score of ‘High’, ‘Medium’, ‘Low’. Low value items are rarely tackled, and even then, only if they happen to be in the Opportunity category.

Visualise

Once all items had been classified, it is time to visualise the work items. To do this we transferred the items to cards and stuck them to a pin board, with timeliness on the horizontal axis and value on the vertical axis (each card contained a reference to the task size). Now it was possible to view all items at once, and from this starting point much easier to make decisions over which items to take next.

Since the whole team had contributed to the process it was clear to individuals why, even though their own proposals were important, that there was greater value in working on other items first. Crucially, we also had a process to ensure that these mid-priority items were not going to be forgotten and trust that they would be attended to in due course.

Technical Debt Board

When a task is completed, we place a red tick against it to demonstrate progress, this helps build trust within the team that we really are working off our technical debt. Sometimes a specific piece of work, as a side effect, will lead to the team indirectly making progress against a technical debt item. When this happens we add a half tick, indicating that this card should be prioritised over other similarly important items so that we get it finished off completely.

Tiny Tasks

This system is effective in reducing the stress that comes with managing technical debt and provided a means for all the team to have a say in where the team spent their effort.  However, one area where it is weak is in managing very small, relatively low value tasks that can be completed in an hour or so. Examples might include removing unused code, reducing visibility on public fields, renaming confusingly named classes – in essence, things that you might expect to happen as part of general refactoring were you already working in the area.

To manage these small easy wins, the team maintains an etherpad of ‘Tiny Tasks’ and reviews new additions to the list on a weekly basis.  The rule is that if anyone considers a task to be anything other than trivial it is thrown out and considered as part of the process above. These tasks are then picked up by the developer acting as the maintainer during the week.

So what does it all mean?

Generally it is easier if an individual has final say of the prioritisation of tasks, in the case of technical debt this is harder since the whole team should be involved. Therefore, a trusted method of highlighting and prioritising technical debt tasks is needed. By breaking down the prioritisation process into separate ‘Size’, ‘Timeliness’ and ‘Value’, it was possible to have more reasoned discussion over the relative merits of items. Visualising the items together at the end of the categorisation process enables the team to make better decisions over what to work on next and builds trust that items will not be simply forgotten. Very small items can still be prioritised if the team agrees that they really are trivial.

The Best Job in the World

“What the worst job you’ve had” sings Stevie Jackson on Belle and Sebastian’s Chickfactor. Now I appreciate that in this world many people find themselves with no choice but to accept work in awful conditions, but in the rosy context of a teenager growing up in the suburbs of London I’ve had some questionable jobs. I was happy to have them but if you ever wondered how shops that sell ice cubes in bags get those cubes into the bags, well it’s not as automated as you might think.

However the job that I really loved during that period was at large super market. My job was to make sure that all the shopping trolleys moved from the trolley drop offs dotted around the car park, back to the front of the shop, so that new customers had a trolley to hand.

On the face of it, this job was just like any other that I had had, it had little variety, was physically tiring and was hardly something I could use to  impress girls, and remember these were girls who were impressed by people who tore tickets at the cinema.

So why did I like it so much?

I think the best way to answer that is to draw upon Daniel Pink’s book Drive. He proposes that the three tenants of intrinsic motivation are:-

  • Autonomy
  • Purpose
  • Mastery
Let’s examine each in turn

Autonomy

No one cares about the trolley guy, unless there is a lack of trolleys, so you can pretty much do what you want. Iterating over a strategy as you please. It was sunny, I had my walkman on and had no one to answer to for the entire shift.

Mastery

Pushing 10-15 trollies in a chain is rarely a good idea, especially in with so many cars close by. But if that’s all you do, you get pretty good at it. You learn to control the leading trolley by gently arcing the chain and you learn how to judge the delay from starting a turn to the leading trolley responding.
At a more strategic level, you can greatly reduce you workload once you understand that some parts of the car park will be busier at certain times. In the mornings every one scrambles for the spaces closest to the entrance, in the afternoons people have areas that they always return to.

Purpose

It’s hardly saving the world, but it’s a job that had a clear benefit to shoppers. If you made sure people had trolleys, they had something to put their food in. Shopping for food in such a place is pretty hellish, it would be even worse without a basic necessity like a trolley.

So the question is, if it’s such a great job, why don’t I do now? Why isn’t this just a sentimental piece about a job that was actually pretty rubbish when it rained?

Well the thing is, as a sixteen year old, it satisfied my expectations. I could have earned more elsewhere but I felt reasonably well paid (for my age), and in terms of professional development, I really didn’t care, it wasn’t a long term career choice.

If I took the job now both of those points would cause problems, I have a mortgage to pay, and I expect my job to stretch and teach me things.

So the perfect job matches, at the very least, general expectations but also satisfies the individual’s need for autonomy, mastery and purpose.

Vitamins and pain killers

A while back there was a thread on Hacker News asking why there is no search functionality, Paul Graham responded with:-

What makes users happy is not features, but the quality of the submissions and comments. So I focus on the latter instead of the former …… This is a classic example of how one should give users what they want, not what they say they want. Lots of people say they want search, but I would be surprised if there was a single user who’d left HN because it lacked search. Whereas if I let the front page get filled up with crap, or the comment threads filled up with mean or stupid comments, people would start leaving pretty quickly….

The point being that the absence of some negative behaviour can be more valuable than the  presence of some positive behaviour. The more effective you are at removing negative behaviour the less people will notice your efforts since the pain point is hidden from them.

I think management is great example of this, sure there will be times where your actions are highly public and obvious to all, but you really earn your bread and butter by working furiously to maintain a state where your team can simply get things done. If anything, too many active interventions should be a warning sign that you are not picking up on things quickly enough.

How to appraise a developer (part 3) – A worked example

This post forms part of series, if you’ve not done so already you may want to take a look part 1

Last time round I promised to provide a worked example of how the scheme might work, this post will chart the early careers of two fresh out of university  programmers, Alice and Bob. Alice and Bob are both smart people but have very different skill sets, Alice is a hard core dev and really has no desire to go into management, Bob on the other hand is weaker in terms of pure programming but is better with people and organisation.

This example is a little artificial since, in order to show case the scheme, Alice and Bob are pretty much polar opposites. Real world examples will be much more subtle, though hopefully by demonstrating a toy example it will become clear how to apply the same ideas once real people are involved.

Day 1

Our story begins as Bob and Alice join FantastiCo as graduate programmers. At this stage it is only necessary to identify the Core Knowledge Areas for their respective roles.

Alice

Alice is working on FantastiCo’s core platform, she has no customer facing responsibilities and while she works within a larger team, has no responsibilities outside of the code that she produces.

Bob

Bob will be writing plugins to unleash the awesome power of the FantastiCo’s core platform, the plugins are typically developed with a lot of client interaction and while Bob will not be expected to deal with clients on day one, once he gets up to speed this will become a significant part of his job. At this point his Core Knowledge Areas are the same as Alice’s but also include the ‘Client Comms’ Knowledge area.

6 Months

Alice

Alice is progressing well and coming along as expected, she has made less progress in areas such as Quality and Design though at this stage this is really just a reflection that her role is not yet providing the necessary opportunities.

Bob

Bob is clearly a good communicator but there are concerns that he doesn’t spend enough time testing his code. Like Alice, Bob has not made very much progress in Design and Quality but at this stage this is not a concern.

18 Months

Alice

Alice is demonstrating considerable technical skill and this is reflected in a strong performance in Construction and Technology. She is starting to approach the criteria for progressing up to Software Developer ii. The best way to do this is look at moving Operations or Design up to full Practitioner. It is also worth noting that Alice is starting to develop Project Management skills despite this not forming part of her Core Knowledge Areas

Bob

Bob continues to develop well in communications and while not as strong at Construction he is close to reaching Practitioner status. He is still not making progress against Testing and Quality which is starting to limit his effectiveness. In order to be promoted to Software Developer ii he needs at least three Core Knowledge Areas at Practitioner and the remaining Core areas at least Introductory. He’s getting close but he needs to start taking more care in ensuring that his code does what he says it does. Like Alice, Bob is also making progress against Project Management.

2 Years

Alice

Based on the proposed Ladder Levels, Alice is now at the stage where she can be considered for promotion to Software Developer ii. Her manager is very a happy for this to happen and Alice is promoted.

Bob

Bob has shown improvement against Quality and Testing, but still does not have the practical skills to adequately test his code, ultimately this limits Bob’s overall effectiveness and blocks him being considered for promotion to Software Developer ii.

2.5 Years

Alice

Now that Alice is becoming increasingly able she is taken on more responsibility for Project Management, while she does not have formal project management responsibilities it is now an important part of her role and has been added to her Core Knowledge Areas.

Bob

Following his previous review Bob has worked hard to improve his testing skills and he is now ready for promotion to Software Developer ii. Bob has joined the mentoring scheme and this is reflected in his progress against Line Management.

4 Years

Alice

Alice is now a highly respected developer and is starting to approach the point we’re she can be considered for promotion to Software Developer iii. Note that despite the fact that she has started interviewing, Recruitment is not a core part of Alice’s role.

Bob

Bob has recently shifted roles and is the Technical Project Manager of a small team. As such his Core Knowledge Areas have changed, in Bob’s case it is appropriate to remove Construction and Testing. Note, Bob’s role has changed but he still remains at the same ladder level of ii, having said that his new role means that he has greater responsibility than he did as a Software Developer ii and is compensated accordingly.

5 Years

Alice

Alice has been promoted to Software developer iii but has also shifted roles to Tech Lead , her project manager considers her input into the personal development of team as an important part of her role and Line Management is now a Core Knowledge area, despite there being no expectation that Alice will progress past Introductory. The shift to Tech Lead brings with it greater responsibility and this is reflected in her compensation, it is important to note that Alice could have stayed as an individual contributor without this negatively affecting her ladder level.

Bob

Now as an experienced Project Manager, Bob has reached Technical Project Manager iii status. He has become rusty development wise and his score against these areas has deteriorated since Construction and Testing are no longer Core Knowledge Areas, this is not a problem.

Walk Through Conclusion

After 5 years Bob and Alice consider themselves to be peers despite following very different paths and having very different skills sets. Alice worked consistently well through out the period whereas Bob was initially held back by his skills in Testing and Quality.

Series Conclusion

The scheme’s original aims were to

  • Provide junior and mid range staff something to aim at and work to.
  • Provide senior staff who do not wish to enter management an alternate career path without the fear of adversely affecting their seniority or salary.
  • Be flexible enough to account for nuances in the role of individuals

I think the scheme as it stands makes some real progress against these goals but there is still plenty to be done. Future work might include improving the examples section, refining the Knowledge Areas and tuning the criteria for ladder levels.

This is the last post in the series, I’d be very interested to hear of the experiences of others trying to solve a similar problem, please feel free to get in touch via comments or if you would prefer via email (neil at this domain).