#people community


Dear people persons and hr folk,

I was looking for a community of like-minded hr and people, professionals – some place I could go and ask questions about the things that make my company better for it’s staff. There is precious little out there of any quality. LinkedIn is OK, but swamped with irrelevant material and a plethora of groups all doing the same thing. Quora has some nuggets of gold but it’s not real time. I wasn’t really satisfied with anything I found.

So, I decided to create my own, you can find it at http://hashtagpeople.co.uk and I’d love it if you could join us.

The #people community, powered by Slack is the first real-time community for those in the HR industry. It’s a curated membership community, meaning the adminstrators vet each application to ensure that the bar remains high. We hate spam and sales as much as the next person, so we wanted a way to filter that kind of stuff out – curated membership is our first stab at that.

Once you join the community, you’ll find there are a bunch of channels, each with a specific theme; there is recruitment, interviewing, benefits, compensation, training and coaching, and more. What’s more, if you want a new channel for whatever reason, you can simply request for one to be made.

It’s early days for this us, but we’d like to invite you to join and help us build a community that we can all benefit from, on a platform designed for just this kind of thing.
The URL to apply http://hashtagpeople.co.uk and you can join the chat by going to http://hashtagpeople.slack.com.
We really look forward to chatting with you.

Thanks for your time,

Mike and the team at #people.

Ways and Means committee

The inaugural meeting of the Ways and Means committee convened at ThoughtWorks Werkstatt Berlin on the 31st of March. This first event of the committed brought together tech industry people from all over Europe. Hosted and conceived by Dmytri Kleiner and Dino Frese from ThoughtWorks, the Ways and Means committee is a group that aims to help tech leaders share experiences, discuss problems and cultivate a network of a trusted peers with which to seek advise.

This meeting asked the question “Why do sprints fail and what can we do about it?”. We were not looking to solve the industrys problems in a single session, but really, to see what kind of things that, as tech leaders, are within our power to influence.

After an introduction presentation from Dennis Traub from ThoughtWorks and a conversation starter from Mike Pearce from MOO.com, the session broke into groups to brainstorm just why sprints do fail. The teams jotted down ideas on post-it notes with no filtering, trying to capture the behaviours or conditions required for sprints to fail. Once that was done, we grouped similar post-its toeether and identified the following themes as being categorical causes of failing sprints:

  • Stakeholder expectation management
    • Some examples of these kind of issues were stakeholder patience, predictability issues, lack of transparency, bad requirements and stakeholder mandated solutions
  • Team Culture
    • Picking the “easy” bits of “agile”. The inspect and adapt loo is missing. People are “convinved” to commit to too much work.
  • Bugs and Fires
    • Business as usual will always be a fact of life, how do we deal with these kind of things without losing momentum on what really counts.
  • Process as ritual
    • When you decide what to do, you decide how you’re going to do it. But many become slaves to what is laid down as process – unquestioningly following it without really understanding why. The backlog becomes a theological debate, velocity is the only truth of progress etc.
  • Purpose/vision/Focus
    • Why do we do what we do? What is driving is to build these particular feature? Lack of understanding around what the purpose

Given we had three teams and limited time, we dot-voted on which were the themes that we’d most like to discuss further. These were “Stakeholder expecatation and management”, “Team Culture” and “Process as Ritual”. We agreed that our goal, like the original Agile Manifesto, was to come up with a set of principles that could guide a team when coming up against any of the above problems. As we weren’t able to solve for every issue that we had recorded (and frankly, wouldn’t be able to) principles were a better way of providing broad guidance for a multitude of sins without being too perscriptive.

So, after some lengthy debate, these were the principles that we created.

  • Stakeholder expectation management
    • Values and Metrics: Meet a business value over showing productivity.
    • Transparency and Dependencies: Transparency over commitment
    • Milestones and continuity: Goals over features
    • Goals and business value over showing productivity and finishing features.
  • Process as ritual
    • Question the process
    • Don’t be a backlog pack-rat (don’t keep every story for the sake of theology)
  • Team culture
    • Agile has to be cultural (not from a scrum manual)
    • Culture starts small. Build organically, infect and contage.
    • Hire to cultural fit
    • Teams should look at their own balance of culture, but needs to work bottom-up-top-down.

We closed the session with a mini-retrospective on how we should continue with the Ways and Means committee, the general consensus was that it should be a little longer, less warmup and more discussion and that we should communicate by way of a mailing list.

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.


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: http://www.somecompany.inc (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.