What’s in a name? Help me pick a job title.

I have a new role at MOO. I’ll be charged with improving department processes, including recruitment and development. I’ll also be responsible for looking at the way we communicate and collaborate, as well as modifying our review process and our objective setting process (I’m looking at OKRs, anyone have experience of these in software delivery?).

In a nut shell, my job is to help the people in the engineering team be as happy as the can be. It’s almost a People, or HR role, but under the umbrella of tech.

I’m looking forward to this new challenge as it’s something I’ve aspired to for a while. The only problem is, I’m not sure what the role is called. It was tentatively “Head of Organisational Development”, but this implies I’ll be doing this for all of MOO, which I’m not – just in tech. So, I have to find a new title, this is where I could do with your help.

Here are some that I’ve come up with and a few from my lovely team, I have my favourites, but what do you think?

  • People Engineer, Tech
  • Tech People Engineer
  • People Services, Tech
  • Happiness Engineer
  • Happiness Ambassador
  • Engineering People Manager
  • Head of Internet Technology Learnings and Extra Research or HITLER for short
  • Human Accountability Happiness Architect
  • Engineering Community Lead
  • Human Accountability Architect
  • People Tsar
  • Developer Development Developer
  • Engineer Wellbeing Evangelist
  • Engineering Workflow and People Manager
  • Engineering People Manager
  • Tech People Manager
  • Online Media Guru Workflow Technological Facilitator Bureaucracy Buster Quesadilla/QUEEN or OMGBBQWTF for short

Common vs. best practise

I’ve heard the term “best practise” a lot over the years. It’s always fascinated me as quaintly ridiculous notion. If you’re not doing “best practice” then, I guess, you’re doing “common practice”.

But why would you do that? Why would you expend effort on doing the same thing as everyone else is doing, when there is clearly a better way of doing it, the “best practise”?

Perhaps it’s simply the fact that best practice slowly become common practice as everyone starts to do it. You have to invent new ways to practice your craft, or trade, in order to be better than those slogging along at a common place.

The trouble is, if you start looking at “best practice” as a way to improve on your current “common practice”, you’re just exacerbating the problem, you’re just turning “best” into “common” quicker.

What can you do about it? Well, the first thing is to quit worrying about what best practice is. Focus on what is best in the context of what you do and not in the context of your industry. The next best thing for you to do probably isn’t best practice and, it may even fly in the face of best practice, but if it helps you do better, reach a wider audience or climb higher, than who cares whether it’s best or not?

Stop following trends and start making your own path.

Annual/Half-yearly/Quarterly Performance reviews: if you have to do them, do them well.

I have mixed feelings about performance reviews. On one hand, I think they’re not a useful way of going about appraising an employees performance, on the other hand, I think they’re a useful way of appraising an employees performance.

It’s all about context.

If you’re in a company that requires you to do them, then do them – it’s part of the process in which the company is entrenched and, unless you are way up the food chain, all  you’ll be doing is causing trouble for people by not doing them and, if you’re going to do them, do them well.

Don’t leave them until the last minute, spend at least a couple of weeks going over your notes (you have notes about what you/your reports have done, right?) talking to peers (if you don’t have 360 reviews) and drafting and re-drafting the review. If you’re doing them for direct reports, then you damn well owe them this time and effort, a large part of their career is in your hands and, how else will they grow without this kind of feedback? If you’re doing it for your boss, then do the best job you can there too – this will give him or her the best opportunity of providing you the feedback you need if you take it as seriously as you should.

Doing reviews well involves good, constructive (or destructive) feedback, using examples where available and appropriate and making sure you cover all the bases. Be honest, but supportive. Be clear and don’t waffle around the subject, especially with “How can this employee improve?” type of questions.

Finally, if any of your feedback comes as a surprise to those it is intended for, you suck as a manager – this stuff should be coming up long before performance reviews.

How to write a tech CV (that doesn’t force me to judge a book by its cover).

I read a lot of CVs. A lot.

Most of them are terrible, eye-watering, piles of shite. This post is a guide on how to write a decent tech CV. I review and interview software engineers mostly, so this post will be focussed on that kind of CV, but there should be something useful for anyone wanting tips on writing a technical CV.

Formatting

First an apology – all CVs I get are first triaged by my lizard brain, this means that I’ll make a judgement about you without even reading anything on the CV. This is unforgivable, but also, unavoidable. First impressions are important, so please make sure that your CV is legible, sensibly laid out and, above all, not in comic sans.

There are some creative, wacky and alarming CVs. You’ll need yours to stand apart from a plethora of other, similarly written CVs. Spend some time thinking about what you want me to know about you and how you want to come across. I hire for culture rather than a set of specific skills, make your personality shine through your CV.

I’m usually not the only one to read the CVs. I’ll pass it to others in my team (lead and senior devs) and, if you’re in engineering you’ll know this already, some engineers can be very cynical – so, get a good balance of great presentation and content. It’s a challenge, definitely, but I want to be able to get a good idea of who you are from your CV, as well as what you can do.

Ratings

While on the subject of formatting, some people give themselves star ratings on their CV, or marks out of five or 10. Please don’t do this. If you give yourself five out of five, or five stars, you are telling me that you are absolutely perfect at whatever you’ve rated yourself on. This is rarely true and, if it was, I’d be contacting you to work with me, not the other way around.

I will bring you in for an interview just for fun, to watch you squirm (well, I won’t, but my engineers will – they’ll enjoy watching you squirm under the intense laser beam of knowledge of bleeding-edge features that only a five star engineer would know).

What to put in your CV

So, we get to the content. Broadly speaking, I want to know what tools/languages you know and use well and what kind of problems you have solved with them, and how.

Summary/Description/Personal Statement

I’ve never seen one of these that was any good. Mostly it’s fluffy bullshit that I don’t need to know. Words like “hard working”, “trustworthy”, “mature”, “team player”, “versatile”, “creative” and “hands-on” are almost entirely useless. I will assume you are these things because, without them, it would be hard to hold down a job. They are “permission to play” virtues. This is a good summary paragraph:

With a strong focus on innovation, research and development of challenging solutions, I’m a firm believer in using the right tool for the job.

ONE list of languages/tools/technologies

Put a brief list (10 – 15 items long) of tools/technologies you’ve worked with that you know well. If you put PHP or JAVA on your CV, I’ll know that you can do python, ruby or any other similar language – I don’t need to know you wrote a python script to sync your flickr photos a couple of years ago. I want to know CORE language skills and tools and I can work out the rest based on what you put in the rest of your CV. If they match the ones I’m looking for you stand a better chance of landing an interview. Huge lists make me think you’re a fraud or a liar (or both), unless your job history is long and varied and I can see evidence of a history that would allow for that many tools to be learnt in depth.

Huge lists of tools and tech are usually for the benefit of lazy recruiters who simply search CVs for keywords. If you really must put all your languages on a CV, then put them at the end so I can safely ignore them. Knowing what and what kind of language you’re most comfortable in is more useful to me that knowing how many languages you’ve read about.

Things you’ve done, not technologies you’ve worked with

Now you’ve added the list of things you can do to your CV, you can stop worrying about stuffing each and every position with the technologies you used there. What I really want to see under each position is the problems you solved and how you solved them. I cannot stress how important this kind of information is. If I see this on your CV you will be 90% of the way through the door because it usually shows that you’re agnostic to your choice of tools – the problem will dictate the tool, not the other way around.

For example, something like this will get me excited:

Company Inc – July 2010 – Jan 2011
At Company INC, we were asked to make the search functionality on the site faster and more accurate. Our search requirements were unique enough to not allow us to buy search from a 3rd party. After some research and prototyping, we settled on using Hadoop to allow distributing the keyword mining across clusters – something that we found MySQL wasn’t very good at for our needs.

This shows that you can think about a problem without worrying about tools. it also gives us something interesting to talk about in your interview.

Something like this will cause me to be sad:

Company Inc – July 2010 – Jan 2011
Hadoop, MySQL, scrum, PHP, kanban, javascript, jquery, angular, java, bananas, apples, pears, BBC, RAC, RACI. Built search engine from scratch with PHP and MySQL. Completed objectives. General maintenance of platform including x, y and z.

It’s not that this is a terrible way of representing your work at Company Inc. It just doesn’t give me any clues as to how you went about solving problems.

Accurate dates and explicit sabbaticals

Pay attention to the dates you put on your CV for the periods of time you held the positions. If positions overlap, it throws up a red flag for me – either there was some reason for the overlap, or your attention to detail sucks. I’m going to go with the latter because I don’t really know why you would have overlapping positions. The only exception to this is if you’re running your own company while working somewhere else, or you’re a contractor. If you’re a contractor, make that explicit in the position title.

If there’s a gap in your employment, it doesn’t alarm me, but it would be interesting to know what you’d done. Perhaps you’d gone to Tibet to train to be a monk, or taken three months off to learn a new skill – either way, it will help to add to the overall picture I have of you and where you might fit into my organisation.

Some prefer to see “solidity” in a job history – so, loyalty to a company, staying around for three or four years. I don’t. I’m aware that people do “tours of duty” now and loyalty is something that works both ways. Thats said, five jobs of 2 months each on a CV would ring some alarm bells (unless they were contract jobs).

URLs

There’s some contention over this; some people say you should add URLs to things and some people say you shouldn’t. To be clear, I don’t want your FaceBook URL, I want your Github (or bitbucket etc) URL and your blog, that should tell me what I need to know about you. If you contribute to any software, throw that one in too.

Adding URLs to websites you’ve worked on is OK, if you tell me what you did on the site. Just a URL on its own doesn’t tell me much, but something like: http://www.somecompany.inc (worked on the search and the three homepage widgets) is useful.

Interests

Yes, I do want to see this. If you put “visiting parks and gardens, bird watching and making iced cakes” it tells me a tiny bit about you and, like the MBTI assessment, helps me understand what team you might end up. It probably won’t be with the “play epic WoW sessions, pheasant shooting and gluten free savoury buns” guy (or it might be, depends on the rest of the team).

What you aspire to (optional)

(This is optional, because you may not have any aspirations, or any aspirations that are further than getting a job at my company). Do you want to run your own department or team? Does your future lie in management, architecture or systems? Adding this kind of detail allows me to see where you might fit and what kind of career path you may have. I need to work out where you will a) provide the most value and b) get the most value. I know that you’re interviewing us to and if I can help you understand how a role with my company might positively affect your career, you’re more likely to want the job.

Tailoring your CV

If you get an interview, you’ll more than likely want to research the company so you can ask questions and understand what it is you’re trying for before you get there. Why not get ahead of the game and do it before you even send your CV? Spend some time researching my company, my website it’s problems, the stack we use and anything else you can find, then tailor your CV to match. If you know Java, PHP, Scala and Ruby very well, but find that we do Java and PHP only, then put those first on the CV. Offer the problems you solved with PHP and Java over those with Scala and Ruby (that’s not to say you shouldn’t put the latter on your CV, only that you should favour the former).

Psychologically speaking, this works well.

Summary

Your CV is usually the first point of contact I will have with you. It needs to make a good first impression and, while I am able to sort wheat from chaff, it makes it easier for me if you’ve done the hard work for me. If I have to decode three terrible CVs only to find each candidate was useless, then I get to your CV (and, in fact, you’re amazing), my threshold to decode shit CVs is lowered and you’re may just go in the bin because I’ve had enough.

I want to know what problems you’ve solved and how. I want to know what tools/technologies you’re great at. I want to understand your work history.

I want to get to know you a bit – think of it like online dating and try and woo me with your true self.

Throw out the contracted hours model, ring in the contracted value model.

Unless I’ve been out enjoying myself with a bottle or four of beer the night before, as soon as my eyes are open in the morning, I’m awake, ready to face the day, and absolutely cannot lie in bed (the weekends are sometimes different though).

I feel able to do some of my best work between the hours of 5am and midday. There are exceptions though, sometimes I’ll be working on some code in the evening, get in the zone and forget to go to bed until 2 or 3am.

The point, though, is that my body and mind don’t work well with the normal 9-5 working hours. Yet, most businesses _still_ insist on keeping these office hours. It’s in my contract, 9am – 6pm. But my body doesn’t care about my contract, it does what it pleases because that’s the way bodies work. Yours will do a similar thing. Think about when you’re most productive, is it during 9-5, or some other time?

My peers all function better at different times too. Some of my team get in at 10am, some get in at 8am, this is fine, they work to their pattern, the problem still remains though that they are obliged to do the correct number of hours per week. It’s in their contract afterall that they have to do 40 hours during the five business days of the week.

I think this is dumb.

If my best hours are 5am to midday, the company only gets three of those hours as I have to be in work at 9am. Three productive hours a day for five days is only 15 hours. So, 25 of the hours that the company has me for are not as productive as they could be and this is because I have a contract.

Let’s say though, thay my company says I can start at 5am and leave at midday (if we forget the obstacle of actually getting to the office, in London, for 5am). That’s still only 35 hours. What about the other five hours I owe the company? Where can they fit in? There are two answers to this.

The first is that I do those missing hours sometime over the weekend. If I can fit in five hours of productive work on Saturday and Sunday then the company and I are square. I am doing all the hours that they are paying me to do. Fairs fair.

The other answer is that I don’t do them. Yes, I just don’t do the hours. You see, my job is about generating value for the business. I do it by coaching, writing code and “managing” a team, not by being at some place for 40 hours a week. “But Mike, that’s what your company is paying you for!” cry one or two of my peers. Yes, that is what they’re paying me for, but they shouldn’t be. I’m not a security guard, or a working on a checkout (two jobs where you do have to be someplace for some period of time), I’m a (shudder) “knowledge worker” and my goals and objectives aren’t the same as yours, the security guards or the checkout person.

The company *should* be paying me to generate value. They should be setting down guidelines on what that value is and how much of it I should generate (I’m simplyfing massively here as objective setting as HARD) and then paying me to deliver it. How I deliver that value and how long it takes me should be entirely up to me. The trouble is, companies, as a rule, don’t do this. We’re tied to the old model of a contracted number of hours and, until we break this, we’ll never get the best out of our employees.

So, throw away the old model of contracted hours and ring in the new model of contracted value. Tell me what results you want me to achieve and when you want me to achieve them by, then let me be free to do this. If I can deliver those results in half the time, then next time, make my goals and objectives harder. I guarantee that, with the freedom and trust that this model will evoke in me, you’ll get the best out of me. I’ll be happy, you’ll be happy and our company will prosper.

DRIP: my letter to Sam Gyimah

Seems like the government are trying to stitch us up again with regards to our privacy. In a nutshell, they want ISPs and phone companies to retain ALL of our data. The worst part? They’re rushing it through without proper scrutiny or debate, this is an underhanded cowardly move.

Read the boingboing article here: http://boingboing.net/2014/07/11/uk-surveillance-stitch-up-cow.html

Write to your own MP here: https://www.openrightsgroup.org/campaigns/no-emergency-stop-the-data-retention-stitch-up

Dear Sam,

It seems I only write to you about something that is bothering me. I should take the time to write you a nice letter soon.

In the meantime, I am disgusted that there is legislation being rushed through that so clearly requires scrutiny an debate. Privacy is a serious business, no doubt, but this, frankly impinges on my privacy and I will not stand for it.

You cannot simply shout “TERRORISM” at the top of your voice and expect the public to believe what you say. It’s no wonder that ridiculous parties like UKIP garner more votes every year when the parties that actually have the ability to affect the future of the country behave in such tragically desperate, underhanded ways that are bordering on the criminal.

I do not want ISPs and phone companies to retain all of my data. Neither should any right-minded member of your constituency. You just have to look at the facts about ‘security theatre’ to know this is all blustering idiocy anyway. Retaining all this data WILL NOT STOP TERRORISM. When I can buy a cheap, contract free phone, use an internet cafe or ENCRYPT MY DATA before it is sent, what use is it? Any sufficiently technology savvy terrorist will circumvent this and make the whole thing a mockery.

For one, there will be the increased cost which will UNDOUBTEDLY be passed onto the consumer, so, thanks for that.

Then there are the potential privacy issues from leaks of this data, I mean, the government isn’t THAT good at keeping the data of its voters safe now is it?

There is no legal basis to be rushing this through without proper understanding and scrutiny.

We are not in a national emergency situation, so this shouldn’t be rushed through, it needs scrutiny by MPs, Peers, and civil society – you know, the people who understand this stuff and do it for a living, not people like yourself and your colleagues who don’t understand the technology enough to make decisions like this.

The European court rules that blanket data retention is incompatible with human rights legislation and the UK has an obligation to comply with the European Convention on Human Rights.

Should this legislation be pushed through, I will be voting for one of the parties that tried to stop it in the next election. I hope that I can count on yours to do the same.

Sam, I would appreciate a response to this message that isn’t a boilerplate email. I want to know exactly how YOU feel about this and you will, or have, voted on this issue.

Yours sincerely,

Mike Pearce

At the risk of repeating myself about what agile is…

It is not a set of practices. There is no silver bullet, golden nugget or platinum compass. The agile manifesto is a set of values and principles that have learning, excellence and collaboration baked into their very heart. They will not prescribe how to deliver valuable, delightful software, they will not explain whether TDD or BDD is best. They do not insist that you use a product backlog, user stories, story points, iterations, stand ups, demos, code reviews, peer programming or continuous integration.

“Agile” adoption will not help you if you do not understand this. It will not help you if you are conflating “scrum” with “agile”. It will not help you if you do not truly understand what it is you’re getting yourself into.

… agile is defined by its principles rather than specific practices.

- Mike Cohen

The agile manifesto is what it is: guiding principles and values that empower you to make your OWN decisions on how to deliver valuable software (or anything for that matter).