Identity and Narrative - Managing Change

Feb 052012

People hate change, and the reason they hate change is that they really hate change, and that change is hated because they really hate change…….

I’d love to know who said this

All teams are subjected to continuous environmental change, but it tends to be gradual and hard to perceive at a week by week level. I want to talk about the sharp, often unexpected step changes and go into some strategies to guide a team through the worst.

Before diving in, I want to introduce a model for characterising teams. There are two attributes that I consider critical in determining a team’s ability to function.

  • Identity – Who the team perceive themselves to be, what they value.
  • Narrative – Why the team exists, what value they bring.

I’m unaware of anyone else talking specifically in these terms but similar thinking appears in Daniel Pink’s ideas of Autonomy, Mastery (both mapping to Identity) and Purpose (narrative) as well as echoes in the higher levels of Maslow’s hierarchy of needs.

Ordinarily, definition of identity and narrative is straight forward. The team will arrive at their own identity over time, while the narrative, for the most part, comes from the commercial arm of the company. In times of change there are no such guarantees. I’ll look at each in turn.

Identity

As an individual, our identity is in part context specific and a function of those around us. The same is true for teams. This means that when the environment changes quickly, it can be difficult for a team to define itself. Definition means identifying the skills and attributes that set it apart and most importantly what it values when compared to those around it.

A manager can help speed this process. They have a birds eye view, they know how their team have defined themselves in the past and have more opportunities to interact with the broader business. The manager ought to be able to spot and highlight specific points that will go and form part of the team’s new, long term identity.

Additionally during upheaval it is for the manager to contextualise the actions and focus of other teams/departments. It’s all too easy to enter into a spiral where ‘everyone apart from us is an idiot’. A team needs to understand how they are different, but they also need to collaborate and work effectively with those around them.

Narrative

Narrative is interesting in that it should be easy to identify. The business is willing to invest in the team for some purpose and that purpose ought to be the team’s narrative.

During times of upheaval this is not a given, and it could take months for a clear narrative to emerge, as the dust settles and the business redetermines the best way for the team to add value.

But waiting months for the new vision is not an option. Put bluntly, if the business cannot provide a compelling narrative quickly then the team manager must arrive at one. Once again it is time to make use of the manager’s elevated view of the organisation to sift through the confusion and draw out something tangible that resonates.

Conclusion

All teams need a sense of identity and a sense of narrative in order to be productive. During times of significant change both of these characteristics come into question. It is up to the team’s manager to act as the catalyst, as the team aims to arrive at new definitions.

What being in a band taught me about management

Jan 162011

The only way to learn to manage is to do it;
and the only way to do it, is to do in front of people;
and the only way to do it front of people, is make a bunch of mistakes in a very public forum;
and the only saving grace is that, as an inexperienced manager, it’s really not clear quite how many mistakes are being made.

Me, ranting, in a pub, in West London

This, of course, is of small consolation to the manager’s team.

So the question is, how do we train people for team management without causing pain and suffering to the team? I don’t think there’s a simple answer, but it definitely helped me to have a chance to learn something outside of my professional life.

Back in the days when I had silly hair and green shoes, I used to play guitar in a band. Much like software teams, the problems a band faces are as much social as they are technical. A band needs someone to draw the group together, drive things forward and turn a bunch of dreamy-eyed losers into a bunch of dreamy-eyed losers who, you know, might get a gig. I’d love to think that I was in the band for my guitar excellence, but in truth my job was to keep things together. Sadly the Lonely Crowd never quite made it beyond the indie dives of London town, but it taught me a huge amount that I would later apply in managing teams of software developers.

Trust is key

Without trust it’s not possible for the group to work effectively. I’m not talking about trusting someone with a winning lottery ticket, more that I know I can rely on that person in the context of the project. Once the trust is gone the band is gone, it’s not coming back. Similarly, as a manager, my effectiveness is directly related to the trust within the team.

No need to motivate, just don’t demotivate

Generally, people who form bands are motivated passionate people, no-ones’s getting paid to be there, and even those more interested in impressing girls/boys than music, need to make sure the band is as good as it can be. The easier it is for the group to concentrate on turning ideas into songs and turning songs into set lists, the more satisfying the whole thing will be. So don’t worry about motivation, focus on removing obstacles and dealing with cranky promoters.

Provide a vision

Often the line between creative spark and creative fleurgh is very thin. Someone has to provide a vision for the group to work towards. In my case this meant coming to the band with rough song ideas, I’d bleed over these things in my bedroom, secretly very proud of my work, only for the rest of the guys to mutate it into something excellent. The point is that without that first step nothing would have happened. Remember that the aim is not to be the best musician, it’s to make the best musicians better.

Roles and responsibilities

A band has distinct roles, when people talk about the Beatles they rarely start with George Harrison, but his considered rhythm guitar parts made it possible for Lennon and McCartney to steal the show, similarly Bill and Ted were never going to get anywhere on their own. The point is that everyone needs to understand where they fit and exactly what they bring to the group, if the drummer is thinking like a lead guitarist, the band will sound awful no matter what.

Feedback

Without good feedback the music will suffer, either through a lack of innovation or through a lack of quality control. The key is finding a way to express your thoughts, good or bad, without it being taken personally. Thinking managerially, the aim should be that the whole group can provide good feedback. Doing so effectively requires a high level of trust within the group as well as a sense of when to intervene if the criticism becomes destructive.

Limit work in progress

Getting a song to a performable state is massive step. It brings the group together and feels like progress. It’s better to have three presentable songs than nine nearly finished ‘things’, not least because it then provides a means for feedback from outside of the group.

Manage internal tensions

Where passionate people collaborate there will always be differences in opinion. Impassioned debate is healthy and a sign that band mates care about the project, but sometimes things get out of hand and it’s necessary for a third party to mediate. Generally it comes down to a breakdown in communication and trust, problems are often best fixed away from the rehearsal room and after the event once all concerned have had a chance to calm down.

So what are you saying Neil, before a new manager starts out they should spend three years in Spinal Tap? Hardly, but training for people management is a tricky subject. At some point it’s necessary to dive in with a real team, accept that mistakes will be made and aim to learn very quickly indeed. The thing is there are plenty of opportunities to gain an introduction outside of work, for me it was guitar wrangling, I’d love to hear what other people have found helpful.

The Best Job in the World

Sep 252010

“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

Sep 132010

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

Sep 112010

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).

Older Entries
© 2011 Neil Johnson Suffusion theme by Sayontan Sinha