What ‘How your company treats exiting staff’ says about you

Nothing impacts your working life like company culture and yet culture is very difficult to assess. This problem keeps me up at night and I’ve written about it before in ‘Why work at your company?

The trouble is that in many cases, the company itself does not really know that much about its own culture and even if it did, expressing it in a sincere manner is challenging, in fact most companies don’t even try at all.

But how about this as a question to quickly determine a how a company feels about its staff?

“HR hoops aside, what happened the last time someone left your company?”

Seems pretty innocent, no? Every company can answer that question in a positive manner, but I think the variations speak volumes.

For instance, recently we said goodbye to junior (ish) developer, he’d been with the company 18 months and was leaving to pursue a childhood dream to work as an air traffic controller (actually true).

On his last day there was a leaving ceremony where a few words were said in the office and a leaving gift presented, immediately afterwards there was a trip to the pub for those wishing to see him off.

Nothing unusual so far.

But it was the whole office of eighty people that turned out – the parting gifts, while inexpensive, were completely personalised – in this case it was a ‘make your own picture book’ with each picture and audio presenting some sort of in joke – jokes understood by the whole group. In similar situations, gifts have included a ‘time of day’ vs ‘date’ commit plot for a notoriously nocturnal team member, a Wordle of IRC logs for an especially chatty colleague and even a framed 3ware card (his nemesis) for a long suffering sys admin.

The pub trip was not just his team or engineering, but had attendees from across the entire company, and at all levels of seniority. Numbers were high, especially given it was a Friday night.

It was a sad occasion, but in many ways felt like a celebration. ‘Great working with you, can’t wait to see what you do next’ – it’s one thing for your immediate work mates to say this, but how about a whole company?

What struck me was how normal this felt, this is completely standard practice for us. Why wouldn’t we act in this way? On reflection I think that this would be considered unusual at most organisations. Such sends off are not unheard of but usually reserved for especially treasured members of the team. This difference say something about our culture.

By comparison, at my friend’s organisation, a senior (much loved) member of staff of 20 years service cannot even expect their manager to drop into their leaving ceremony. Their reluctance to attend driven by fear of tacit endorsement. It’s the same set up, leaving ceremony followed by pub, but a completely different feel.

How a company treats its exiting employees, speaks volumes to remaining staff. The actions of individuals in response to the leaver, reflect the company’s culture. Since the leaver no longer has any direct value to the company, these actions speak honestly about how the company values people.

So ask yourself, how does your company treat exiting employees and what does it say about the culture? What message are you sending to remaining staff? It is not for management to mandate a leaving procedure, but it is for management to create an environment where people matter.

Identity and Narrative – Managing Change

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

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

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

How to appraise a developer (resources)

This post provides support and resources for the ‘How to appraise a developer’ series, If you haven’t read the series this post will make no sense whatsoever.

There are two main sections

Suggested Knowledge Areas

Knowledge Area Description
Coding The creation of software according to a specified design. The primary activity is creating code and configuration data to implement functionality using the selected languages, technologies, and environments.
Design The bridge between requirements and construction, design defines the structure and dynamic state of the system at many levels of abstraction and through many views.
Technology The use of tools, technology, methodologies, and techniques for software engineering.
Operations System installation, deployment, migration and investigation. Working safely with live systems.
Requirements Working with partners/commercial colleagues on an ongoing basis to translate their ideas into something that can be tackled in software.
Quality Activities performed associated with providing confidence that a software item conforms or will conform to technical requirements. Quality is related to testing but considers broader questions such as what strategies necessary to ensure systems work as expected.
Testing Practical means to verify behaviour of a component through unit testing, system/functional testing or manually. Testing is related to Quality but focusses on the practical aspects.
Documentation Activities associated with recording or expressing information about a how a system works.
User Interface Design Designing clear, discoverable user interfaces so that Partners are able to make full use of our systems.
Internal Relations Ability to communicate with and relate to those within the company.
Client Relations Ability to communicate with and relate to clients.
Supplier Relations Ability to communicate with and relate to technical suppliers.
Project Management Resource,task and process management, essentially making sure the right things get done.
Line Management Pastoral care, support and development – most commonly relating to direct reports.
Recruitment Includes CV assessment, interviewing, strategic direct recruitment.

Capability Examples

Below follows some examples to help with assessing a individual’s Capability level for a given Knowledge Area.

The examples are not exhaustive and should be added to over time, what’s more it is not necessary for the employee to satisfy all examples. The examples aim to answers questions like “What does a Practitioner in Design look like?”

Before diving into Knowledge Areas specific examples it’s worth considering the following broad guidelines that can be applied across all Knowledge Areas.

Introductory Rarely coaches others.
Looks to the team for support and guidance.
Practitioner Occasionally coaches others, usually those at Introductory level
Occasionally introduces new ideas and practices to the team.
Leadership Regularly coaches others, their own skills and expertise are amplified through the help that they provide.
Regularly introduces new ideas into the team with examples of where these ideas have been adopted.

Coding

Introductory Can complete simple 1 week (ish) well spec’d tasks/stories alone with some guidance from outside.
Can complete a medium complexity series of tasks/stories spanning a few weeks starting with a fairly loose spec, working along side a more experienced developer.
Practitioner Can complete a medium complexity series of tasks/stories spanning a few weeks starting with a fairly loose spec.
Proposes alternate and superior approaches to problems.
Leadership Takes the lead for large and complicated projects.
Takes the lead on high profile or time critical projects.

Design

Introductory Suggests sensible designs for small stand alone pieces of work.
Practitioner Can be relied upon to reliably produce sensible designs for loosely spec’d medium size projects.
Is sensitive to trades offs between flexibility at the cost of complexity.
Understands the need for maintainable extensible design work.
Leadership Takes the lead for the team’s most difficult design work.
Their work often has system wide architectural implications.
Can point to a number of projects where their design has stood the test of time.

Technology

Introductory Is aware of the technologies used by the team and has some idea of the reasons why one might be more appropriate than another.
Is not expected to make technology decisions, but should have opinions on what technologies they might use for their own tasks.
Has some experience of the technologies used by their immediate team.
Practitioner Has a good level of experience of all technologies that the immediate team make use of.
Has had exposure to technologies not actively used by the immediate team
Can reach decisions about library choice for some supporting technology, should we use JMock, EasyMock or Moquito as a Mocking framework?
Leadership Can make broad reaching project level technolgy decisions – what are the implications of upgrading to MySQL 5, is it sensible to do so?

Operations

Introductory Can spot obvious problems and make sensible first stabs at resolution.
Knows when to escalate a problem within the team.
Can provide basic support to those outside of the team e.g. A first line support team
Can perform system redeploys, noticing obvious problems, however needs the support of team to fall back on.
Practitioner Confident in the use of investigative tools, events logs also Wireshark or Jprofiler to diagnose and fix problems.
Is capable of deploying systems in isolation.
Leadership Handles the teams’s most complex operational issues, potentially diagnosing bugs in libraries that the team relies upon.
The person turned to for the ‘oh bugger’ moment.

Quality

Introductory Understands the rationale behind dedicating time to quality be this unit testing, pair programming, integration testing or otherwise.
Practitioner Regularly suggests ways in which improve the overall quality of the team’s work.
Encourages all members of the team to adopt practices to improve quality.
Leadership Considers the team’s long term strategy.
Can point to series of effective changes that they have instigated to improve quality.

Testing

Introductory Understands the importance of unit and integration testing.
Adheres to the team’s testing expectations
Is capable of writing tests where the code lends itself to testing, struggles in more complicated scenarios.
Practitioner Is capable of writing unit tests in all cases where it is sane to do so, making use of additional libraries over and above JUnit where appropriate.
Has a good understanding over what to test for, and writes tests in away that reduces maintenance load over refactoring.
Through system level testing can build a trusted series regression tests.
Where appropriate can devise manual test to reliable verify the behaviour of the system
Leadership Handles or advises on the team’s most complicated testing challenges, suggesting edge cases and reviewing testing strategies.

Requirements

Introductory Can spot subtle ambiguities in projects on which they are working and asks for clarification.
Practitioner Can work with parties outside of the team to nail down exactly what is wanted, offering advice where the requester is unsure or unclear.
Leadership Is trusted with requirements capture for the team’s largest projects.
Is able to identify alternate approaches to delivering large blocks of functionality.

Documentation

Introductory Where prompted can write clear descriptions of system behaviour.
With guidance can pitch documentation for the intended audience.
Uses code comments to explain how the code works
Practitioner Understands when and where to document
Does not over document
Code comments often explains why rather than what the code does
Leadership Notices where documentation is missing in a structural sense, creating new wiki/web pages as appropriate
Through good doc design, encourages continual maintenance since doc is often used.
Looks for ways to doc in an automated fashion

UI Design

Introductory Adheres to the team UI style
Considers the impact of their UI decisions
Can propose sensible ideas for simple UIs
Practitioner Proposes sane workable designs for complicated UIs
Leadership Takes the lead for the most complex UI challenges faced by the team.

Supplier Relations

Introductory Can raise well bounded faults.
Can express themselves clearly to suppliers
Typically chooses to communicate asynchronously over email (or similar)
Practitioner Chooses a suitable communication means though is confident to use a real time method.
Can follow up and present a clear argument where the supplier does not agree with our assessment of a fault.
Leadership Draws upon a network of contacts to circumvent bottle necks to achieve their goal quickly.
Through excellent interactions improves our relationships.
Understands when and how to raise matter through commercial channels

Internal Relations

Introductory Can express themselves clearly at a team level.
Practitioner Pitches their communication to a suitable level taking into account their audience and the context.
Has dealings with multiple departments within the company
Leadership Talk confidently to senior members of the company in different departments/countries.
Handles difficult or sensitive issues on behalf of their team.

Client Relations

Introductory Typically chooses to communicate asynchronously
Understand the difference between internal discussion and client facing communication.
Practitioner Understands that some information is sensitive and should not always be given to clients.
Can get to bottom of what clients are *really* asking for.
Can say ‘no’ in a constructive way
Chooses a suitable communication means though is confident to use a real time method.
Leadership Handles sensitive issues with large clients.

Line Management

Introductory Mentors junior members of the team
Assigned to help new members of the team to get up to speed
Practitioner Has formalised Line Management responsibilities
Leadership Line manages other managers.
Introduces new ideas to other line managers
Track record of handling sensitive or difficult line management issues

Project Management

Introductory Can keep track of non trivial lumps of functionality, perhaps they are not the only person working on the project.
Can provide sensible estimates and commitments for non trivial blocks of functionality.
Practitioner Has formalised project management responsibilities. Manages team projects on behalf of the team.
Leadership Manages multiple teams, provides advice and guidance for other PMs
A track record of successfully delivered blocks of functionality.

Recruitment

Introductory Assesses CVs
Can interview along side a more experienced recruiter
Practitioner Able to interview 1st rounds solo
Provides advice on CV review
Implements and develops direct recruitment projects
Leadership Develops interview/ CV assessment system
Instigates new direct recruitment initiatives
Meets with agents
Experienced final round interviewer