Yesterday, I wrote about varied aspects of looking for work, but concentrating on Equal Opportunities and Job Requirements specifications. Today I’ll look at some other systems that are at work in the job market right now.

When writing on such broad topics, it’s difficult to disassociate oneself from one’s own experience of the marketplace. Unless you have hard facts and figures… and I regret that I do not.

At the moment, I’m expecting this post to be a bit more of a ramble around the issues that I see in that marketplace (IT employment, especially in The City of London and surrounds)… and I expect some of the factors to appear to contradict one another. Still, maybe we’ll see some interesting things on our little stroll.

The Google Aura

If you’ve ever read anything written by a member of Google staff you may well have heard them (politely) rant about what a wonderful place it is to work. I’m sure it is! Google has many fantastic practices, and lots of money to throw at products that may never see the light of day… which is not a bitter snipe… it’s pretty much fact as far as it goes. Steve Yegge is a blogger who I’ve read a bit of… his post Good Agile, Bad Agile gives him the opportunity to let off steam a little about his loves for the environment… but here’s a snippet:

There is nothing like it on the face of this earth. I could talk for hours, days about how amazing it is to work at Google, and I wouldn’t be done. And they’re not done either. Every week it seems like there’s a new perk, a new benefit, a new improvement, a new survey asking us all if there’s any possible way in which life at Google could be better.

Broadly speaking, Google seems aims to hire the very best. Or, as this other post suggests, Google aims to turn away the less-bright of those people who flock to it looking for work (see the heading “Google’s Not Recruiting”).

But it seems to me that, whatever Google’s broad policies are, there is room or individual personality and preference to come in to play. In a recent trawl of their UK jobs site, I found a ‘Technical Writer’ role that required a ‘Bachelor’s degree or higher’ whereas the ‘Information technology Manager – London’ had: ‘ …with a strong preference for a Computer Science or related degree to be considered’.

You could argue this point both ways; perhaps that technical writer is going to have to document some immensely technical stuff (I’m referring to advanced algorithms or mathematical notations or…) whereas the attitude might be that, whilst preferable, a manager does not have to have a degree to be an excellent leader. But maybe you’ll understand me that I would estimate that on average a technical writer should not need to be quite so technical as the developers whose work they document… and what use would a Biology degree be in this instance anyway?

But Google employees are human too! In another post, Steve talks about learning Javascript from O’Reilly books. How normal! How ‘average’. I mean specifically; he did not mention some arcane script that no-one ever understands to learn from, he chose a book like you or I might. Google didn’t send him on a course (maybe they would have if he’d asked, who knows) – they probably assumed that he could do it.

This suggests that Google believes that excellence is transferable. Take a person skilled in one language, they’ll be skilled in another. And, based on the ‘average’ job specification on their jobs site, it seems like they feel a degree is a good indicator of that.

The Graduate Training Programme

When I last worked in the City, for an Asset Management company, my team was one which took part in the new graduate training programme. Graduates would work on short assignments with different teams throughout the IT department in a rota, and then move on to another team. It only started about a year before I left, so we only integrated two different graduates during my time there. Overall, I have to say that from the team perspective it probably was a good thing. Being a team dedicated to ensuring the overnight batch ran ok, we shared a call-out rota.

Although we aimed to get our graduates onto that rota, at least for a short time, to do that we had to train them in a lot of technical aspects of the work. During that period, they helped us out with some non-technical stuff, and probably also helped us in the sense that being somewhat less involved in the nitty-gritty of the batch they kept us grounded, and helped by being unstressed when there’d been a few call outs the night before.

They were also a useful tool to get people across the department talking to each other… or at least having a greater understanding of what other teams did and how.

But overall now, I struggle to remember what the aim was for all these graduates to do after their training programme had ended. Perhaps it was just a vague aim to keep the people long term. The company will probably have spent millions on them – in simple terms of us and other departments training them in areas that they may never have used again. But whichever way I hope that it worked out for the graduates.

But once again, we see that the company took the view that a graduate can be trained and be useful in any department.

As an aside, and referring back to the discussion yesterday, what are the equal opportunities impacts of having a graduate programme? Do they have to have just graduated? Can they be of any age?

The Average Job – The CSS Effect

It may not have applied in the past, but my understanding of the ‘average’ job is that it will change. In fact, anytime I’ve been employed (as opposed to self-employed) over the last 10 years I would say that I have done substantially less of what was on the job requirements, and substantially more on other roles and opportunities that just ‘cropped up’. I became a team-leader like that, I was chosen to investigate and analyse testing (QA) and configuration management tools like that. I documented things that had never been documented before because no-one had thought to or made time for it. I’ve never looked for jobs that involved travel, but have worked in Edinburgh and Glasgow (OK they’re not too far away from London) and Tokyo for short stretches, because the need arose for it. I nearly went to the Philipines with a colleague, but in the end, only one person was required and he had first dibs.

Sometimes my employer paid for me to be trained in new technologies, but probably more often they relied on my having learnt something myself out of personal interest, or maybe just giving me some time to read the bloody manual.

And that I must admit is a bit of a frustration for me. I reckon I could do many jobs in IT well or very well, but until I get my foot in the door I have to admit my CV is not the best to ‘prove’ to anyone that I am a good bet.

Anyway, back to the average job. If you are employed for any length of time in IT, the environment in which you work will probably change around you. And I’m not talking scenery and workplace, I’m talking systems, colleagues, computers, and the skills that you need to do the job.

If you were a web developer a few years back, you’ll have been through developments in browsers, in html, dhtml, xhtml, css, php, mysql and so on. And how many times did your employer (if you are not self-employed) decide that the best thing to do was to send you on a course to learn it?

Let’s consider Cascading Style Sheets (CSS). I believe that CSS was probably learnt on-the-fly by the vast majority of people who use it. Yes, there are true experts and evangelists like Jeffrey Zeldman and Eric Meyer, but I would suspect that most CSS users have learnt through persistence, tenacity, and occasionally flying by the seat of their pants. I can’t see that there could be any other way when one considers issues like ‘box model hacks’ and so on. Someone had to learn the hard way… someone else came up with a work-around. Seat – Pants – Flying.

So is CSS a core skill requirement for a web-developer job… or is it (if my assertions are correct) a learnable skill, the basics of which should come quite easily to web developers. Is it a skill you need to be an ‘expert’ in, or one that should be ‘preferable to have’ or ‘should have familiarity with’?

Whatever Happened to ‘Team Player’

One of the aspects that surprises me about this is that many jobs require that you be a ‘self-starter’ and a ‘team-player’. So, to my mind, that raises the question… why do all members of the team need the same skill set? Yet I would guess that is how most job requirements are constructed; by building a list of all the team members individual skills, and (to use a database / set term) UNION them. Of course, there will probably be core skills for a role that really are pretty vital… but surely the ideal job specification considers other factors too.

For example, tools such as Myers-Briggs personality analysis can be used to bring together team members who think differently… and therefore will almost inevitably have different (technical) strengths and weaknesses. I recall that Edward de Bono says something similar in ‘Six Thinking Hats’. Having team members at odds with one another because they think differently can sometimes be frustrating… but conversely imagine a team entirely filled with cautious people who never got anything done, or a team entirely made up of bullish extroverts who rushed headlong into failure (probably because they were not very keen on working to the same goals!)

Personally, I am against direct testing of an applicant (be it of their handwriting or some other personality testing tool) as a precursor to employment… but it is inevitable that some amount of ‘personality assessment’ is done in an interview. I remember interviewing one guy once who seemed technically qualified for the role, but a couple of remarks he made in the interview made me and my colleage think that his attitude was all wrong for the kind of job we had.

If this kind of criteria is on the list for employers (and I think it probably ought to be) – then it unfortunately does not come through on the job role descriptions – other than the platitudes about being a ‘team player’ etc.

Context Switching

Read any amount of Joel on Software and you will probably encounter some of his comments on the costs of context-switching. Here’s a good one. Now, think about it. If the role that you’re advertising really includes 10 different skill sets, how often will you be context-switching between different skill sets? How inefficient is that? One of the benefits of not being a terribly small employer is precisely the context of the team, and ideally helping to prevent the costs of individuals having to context switch too frequently.

As an aside, I wonder if this is why web development can actually get really harsh. Imagine a PHP / MySQL website. An individual page may contain PHP and HTML. The HTML may contain the PHP which in turn generates more HTML. Colour-coding of editors like Dreamweaver will probably break down in this instance, coding the embedded HTML as PHP strings not the normal colouring for hypertext commands. Also embedded in the PHP you may have database connections etc using SQL. Perhaps a dash of javascript, perhaps even javascript generated by PHP (really yuck, if I recall rightly). The HTML (generated or otherwise) may need to have a particular structure to gain the benefits of a particular approach to CSS formatting (but of course, the CSS is not there with the html / PHP so there is no reminder there). The developer may also need to factor in considerations of search engine optimisation, and so on. That is a lot of contexts to have all wrapped up in one plain-text file!

One Possible Solution

I think that one of the possible solutions to this morass of necessary tools and skills is documentation. I’m not necessarily talking about terribly formal documents that would pass ISO9001 certification (a Quality Management standard), but just useful documents that encourage team members to actually use them. Here are some examples:

• A crib-sheet for the most useful commands to control SCCS (if that’s your change management tool);
• A visual flow diagram of the overnight batch or process dependencies;
• Annotated html printed output highlighting key divs, classes and such to achieve a particular effect from the matched CSS.

Of course, a problem with documentation is keeping it up-to-date, but if it is documentation that is actually used, then the team itself becomes self-reinforcing about wanting up-to-date documents. Why? Because if they have crib sheets that they use, it allows them to forget complex command formats or ‘what the hell is job ISIS4256.ksh’ and concentrate on more important things.

Now, if you have living documents, any new team member does not have to read dry documentation about a thousand different things just to get the simplest job done. Well, OK I can’t guarantee that every document will be fun and thrilling, but having a practical ‘support’ document written by a colleague about the system that you are working on now is a whole lot more interesting than the average corporate staff manual. When I was working on overnight support, one of the keys was to realise that people are not at their most alert at 3am! That’s stating the obvious, I realise, but the end result was a picture (in glorious colour!) of the overnight batch being the key document, not a dry list of different streams of processing. Certainly, the documentation ended up having more complex and dry information in it, but you only ever needed to read that in small chunks having referred to the pretty picture (that essentially also acted as an index).

Documentation won’t cover every eventuality, and may be less likely to work for entirely new roles – but it could help in lots.

Learning to Get New Staff Started

I mentioned previously that I became a team leader by chance. I have to admit that one time when this created a little bit of panic was the sudden realisation that a new member of staff was joining my team… and it was my responsibility to get them working! I was entirely unprepared for that responsibility at first… and in fairness, I was probably rushed off my feet in any event, as we were short-staffed – a common catch-22.

I suspect that in that first instance, I probably just threw what documentation we did have at the new-starter and told them to read it. In this instance, documentation can be the bane of the employee. Having something specific to do, backed up by documentation must surely be better, perhaps with some focused training on the stuff that is really core ‘process rules’.

In fact, isn’t this point the very key one where employers start to think that they must have all these different skills? Because if they don’t have crib-sheets and helpful tools to quickly remind everyone ‘how we do things’, and if the new guy is not already up-to-speed with whatever technologies, then they really are likely to need a bit more skill up-front. Consider source-code control. Some companies have different approaches to it, so even if you know the code-control system well, a new employee may still have to ask questions or be guided on ‘the way we do it here’. If they are not entirely familiar with the particular version control software, they may have a double-whammy of learning. A simple crib-sheet could help people less familiar with the software, and really get those who do know it speeding along…

Abstraction can help too. If the programmers of a website have carefully placed all their PHP database-access functions in a separate file, this can help keep code elsewhere clean. Table names abstracted to variable names in another file (either to allow for multi-cultural tables names or to centralise a change if it was ever necessary) are a good idea, but there is still a potential learning-curve on that abstraction; not a massive one perhaps, but it is still there unless perhaps there is a brief document that outlines where particular key files are, and so on.

Summary… for Today

I guess today’s summary comes in the form or idea that not every part of your day-to-day job in a business uses the role’s supposed ‘core skills’. In fact, IT staff are increasingly being asked to integrate disparate systems with different technologies that they may well not have come to the company with.

I suggest that much can be done to improve the situation for current and future staff by paying more attention to those areas on the boundaries of skill-sets (as well as the disparate systems) to ensure that learning curves for new starters can be smoothed.

And if the fact that I see some job roles advertised and re-advertised over several months is anything to go by, then a number of employers would benefit by getting a bit more realistic about their expectations.