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.


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.


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


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: (worked on the search and the three homepage widgets) is useful.


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.


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:

Write to your own MP here:

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

Surface Acting: bad for business and your health

Angry Twins by Pelle Sten (

Angry Twins by Pelle Sten

Have you ever been in any kind of meeting that made you angry, sad, excited, disappointed or frustrated? Sure you have (if not, I want to work with you!) and you’ve also probably tried, on occasion, to mask that emotion. If you’re British, there’s the idea of the stiff-upper-lip and there’s probably similar in other cultures. However, this is bad for your long term emotional balance.

‘Surface Acting’ is a means of managing ones emotions. This technique allows you to pick the right emotion for whatever situation you are currently in. We do it in all kinds of situations; doctors, waiting staff, the police. Any situation where we’re unable to generate any kind of sincere empathy means we resort to acting the correct emotion.

A recent study highlights that we even do this in meetings. The study claims that 15% of of personnel budget is spent on meetings, yet up to a third of all meetings are a waste. They make links between surface acting and the perceived effectiveness of the meeting. Because an attendee is expending energy on portraying an emotion they might not be feeling, that’s energy that isn’t being spent on the purpose and outcome of the meeting. It requires self-control and limits our ability to attend to what is going on, as part of your attention is turned to acting.

It’s also exhausting. Those who reported high levels of surface acting, when quizzed three months later, exhibited higher emotional exhaustion, or burnout, scores and an increased intention of quitting altogether!

So, next time, you feel an emotion, let it out. Be truthful with the way you feel about the world around you. Be mindful that you’re not being a dick and ensure you’re meeting the needs of the people around you, but don’t mask emotions. It’s unhealthy and, usually, untruthful. I’ve blogged about lying before, so this study further supports the idea that politicking around the office is not only bad for business, but also bad for your health.


Shanock, L. R., Allen, J. A., Dunn, A. M., Baran, B. E., Scott, C. W. and Rogelberg, S. G. (2013), Less acting, more doing: How surface acting relates to perceived meeting effectiveness and other employee outcomes. Journal of Occupational and Organizational Psychology, 86: 457–476. doi: 10.1111/joop.12037

Are you intelligent? Do you do intelligence?

Well, are you? Are you intelligent? Or perhaps you do intelligence. Do you? You do? No.

No, you don’t do intelligence just as you don’t do clever and you certainly don’t do agile|Agile|aGiLe.

I read this article today Kanban Is Not Agile and I’ve read a few others like it in the past. No, Kanban isn’t agile. But neither is scrum or DSDM, or crystal or SAFe or whatever.

You cannot DO principles and values, you are principled and you hold values. When someone says “We’re agile!” challenge them, ask “What does that mean?” because I can almost guarantee they’ll say “We do scrum|kanban!”. You’re following practices that stem from upholding the values and principles of the manifest, but you’re not doing agile.

What’s more and what will hold business back until they realise it, is that while these values and principles are software-centric, they certainly aren’t software dependent. If you distil the values and principles, you get things that any one can uphold, regardless of industry.

You don’t DO agile, you ARE agile.