neilj

Why Work At Your Company?

May 222011

Recruitment is all about relationships and trust, whichever way you look at it common recruitment practices support neither. While there are countless articles focusing on how hard it is to hire good developers little is said about how to find good companies. Trust work both ways and in order to ‘fix’ recruitment both sides of trust equation must be balanced. Examining each in turn:-

Employer-> Candidate trust

Employers have low trust in external recruiters, low trust in CVs, and low trust that candidates can complete a Fizz Buzz question. This means that it’s not possible to invest sufficient time in individual applications, which in turn makes it less likely they’ll ever attract really good people.

Services like LinkedIn and Stack Overflow have made some gains in solving the employer-> candidate trust problem. In LinkedIn’s case they have scaled the ability to ‘ask around’ for recommendations and Stack Overflow provides a feel for someone’s knowledge. Neither is perfect and in truth the best they can do is give me confidence that the candidate is not a total waste of time.

Candidate -> Employer trust

The Candidate -> Employer problem is more interesting not least because it’s generally ignored. Unless you happen to be Google or Facebook candidate->employer trust is a major stumbling block. How can a candidate be sure that they are dealing with a good company? They can’t trust their agent to have a clue (or care) and they themselves will not be aware of a host of interesting companies. As such applications tend towards the bland and generic since candidates cannot afford to spend days tailoring individual introductions, this in turn fuels the employer perception that passionate interested candidates do not exist.

As an example, I work for a small B2B Telecoms company, our work is on the public eye, but our brand is not. Most developers will not be aware of us. Once hired, developers tend to want to stay with us, with working environment and the freedom to ‘get things done’ playing a big part in that. However as a company I have no easy way to express this. It’s not even a case of saying ‘Isn’t my company great!’ it’s much more about about describing the trade offs. Not everyone will appreciate the chaos, pace and variety of working at a small company, some will prefer the promise of a well defined career path, security and greater opportunity to specialise typicallly afforded by a larger organisation. It’s down to personal opinion.

Individual companies can solve this problem by publishing an engineering blog, sponsoring community events, getting people speaking at conferences and generally exposing their culture and values. It could be argued that companies willing to go to these lengths clearly value recruitment more highly than others and deserve the rewards. However, if there was someway that candidates could pull that information rather than have it pushed then that would be hugely valuable.

The closest example I can see is the Joel Test. To me the Joel Test is starting to show it’s age and could benefit from an update, the best it can say is ‘this company is less likely to be a horrific place to work’. Glass Door also addresses this in part, though practically speaking companies must be a of certain size before it becomes useful.

I’m not sure what the solution might be. Perhaps a curated job board/job fair is the way to go, the curator finds a way to characterise companies and makes sure it only backs good companies. This builds trust with candidates, and should mean that it attracts the top people, especially those for whom money is not the top driver. Companies are happy to pay decent rates because they know how good the candidate pool is, further more there is prestige in being associated with the agency.

The Challenge

So, world, here is my challenge to you. How can I, as a company, express my culture and values in a meaningful and standard way so that candidates can approach me with confidence.

'We only hire the best' - I don't believe you

May 072011

Ask anyone about hiring developers and the advice is always the same ‘only hire the best’. The principle reasons being that

On the face the face of it this seems like great advice, who wouldn’t want to hire the best? It turns out pretty much everybody.

For instance, how long are you willing to wait to fill the position? What if you are really really stretched? What if you’re so stretched that you worry for existing staff? What if hiring a specific individual will mean huge disparities in pay between equally productive staff? What if not making the hire is difference between keeping a key client or losing them? At some point every company has to draw a line and elect to hire ‘the best we’ve seen so far’.

The difference between the great companies and the rest is how to deal with this problem. Great organisations place recruitment at the centre of what they do. If hiring is genuinely everyone’s number one priority then hiring the best becomes more achievable. For starters you might even have half a chance of getting ‘the best’ into your interview room in the first place.

Of the rhetorical questions posed above, in all cases the impact can minimised (though not eradicated) so long as management understands and anticipates the challenges in recruitment. For example “What if hiring them will mean huge disparities in pay between equally productive staff?” A company that intends to hire the best understands the value of keeping the best. So compensation of existing staff, especially longer serving staff relying on annual raises to ensure market parity, must be at an appropriate level. Doing so can be hugely expensive when multiplied over all employees and this cost comes directly from the bottom line. Companies that put recruitment at the core are willing to make the investment. Yishan Wong’s writing on this subject is brilliant.

If hiring really is everyone’s number one priority then there is a trade off to make, something has been deprioritised or sacrificed to make room. As a result hiring is much more than a partitionable activity, it is a statement of corporate identity. Proclamations like “we only hire the best” are meaningless without an understanding of the trade offs and sacrifices made.

People are not our most valuable resource - a response

Apr 252011
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

Feb 222011
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.

In Praise of Continuous Deployment

Feb 132011
It doesn’t matter if you get there, every step along the way is an improvement.
Me, praising Continuous Deployment



Ever since coming across the idea on Eric Ries’s blog I’ve always been a big fan of Continuous Deployment. For those unfamiliar with the term, it means writing your code, testing frameworks and monitoring systems in such a way that it is possible to completely automate the process of going from source control commit to deployment to a live system without posing a quality melt down. This means teams can find themselves deploying 50 times a day as a matter of course.

Yeah

It’s not without it’s critics, and a lot of people see this as one way ticket to putting out poorly tested buggy code. I think that those folk completely miss the point and that in many scenarios in fact the opposite is true. The thing I really like though, is that, whether or you ever get to the point of automatically deploying every commit to live, every step that you might take to get there is hugely positive.

So, really, what would have to happen in order to employ a Continuous Deployment regime?

18 months ago my then team started to take this idea more seriously, I thought it would be interesting to give an overview of the steps taken towards Continuous Deployment, and since we’re certainly not there yet, what we plan to do in the future.

We started from a point where we would release to live environment every few weeks. Deployments, including pre and post deploy testing could take two people half a day sometimes more. I should also say that we are dealing with machine to machine SaaS systems where the expectation is that the service is always available.

Reduce manual deployment load

Our first efforts aimed to reduce the human load on deployment through automation. Fear meant that we still needed to ssh into every node to restart but every other step was taken care of. This meant that it eventually became common place to deploy multiple times a week across multiple platforms.

Improve system test coverage

Once a deploy was live we were still spending considerable time on behaviour verification. To address this we worked to improve our system and load testing capability. Doing so meant that we had more time to manually verify deploy specific behaviour, safe in the knowledge that the general behaviour was covered by the tester.

Improve system monitoring

This approach also requires a high level of trust in system monitoring. We have our own in house monitoring system whose capabilities we expanded during this period. In particular, we improved our expression language to better state what constituted erroneous behaviour and we also worked on better long term trend analysis, taking inspiration from this paper . It’s no surprise to me that it came out of IMVU who have been practicing Continuous Deployment for a long time.

Reduce deploy size

Since the act of deployment was now much less expensive we looked to reduce the number of changes that went out in each deploy. At first this felt false, after all if the user can’t use the feature in it’s entirety, what’s the point? We soon realised that smaller chunks were easier to verify and sped us up over time. We took an approach that I’ve since heard referred to as ‘experiments’ so that new functionality could be deployed live but was hidden from regular users. It meant that we could demo new functionality in production, without disrupting the business as usual service.

Embrace lean inspired methodology

Breaking down deploys into a few day’s worth of work also improved our lead time meaning that we could more responsive in the event of a change of plan. It was during this period that we switched from time boxing to Kanban. This is interesting since Continuous Deployment is often championed by the lean startup movement.

The future

More recently, actively pursuing Continuous Deployment has taken a back seat, but the next logical steps could be to further flesh out the system test coverage and then look to completely automate deployment to the staging environment (modulo database changes).

However, it doesn’t really matter what we do next, if it takes us a step closer to theoretically being able to deploy continuously it will undoubtedly improve our existing lead time and responsiveness.

This post contains a number of Continuous Deployment resources, but a few further articles I found to be interesting follow include:-

Older Entries Newer Entries
© 2011 Neil Johnson Suffusion theme by Sayontan Sinha