Are you offering a career in testing or just a job?

Many companies are offering a job in testing.

Many companies are offering a career in testing.

Testing - A Job or a Career
Testing – A Job or a Career

A career is a series of experiences. These experiences may come from many  jobs at many companies. Or they may come from a single place of work with a varied set of experiences.

A job is what some companies are offering. And there is nothing wrong with this.

Jobs are good. So too are careers. Some people can experience more in a single company than others may experience in 10 other jobs.

Being honest about the role you have is the key to getting the right person.

If you are offering a job then say so. If you are offering a career then say so too.

Some people just want a job. Some people want a career. It’s important to match the person and the job. By matching the right people to the right jobs you stand a chance of solving your problems. (You are solving a problem..right?)

It seems so simple but it’s a mistake many hiring managers make.

Get it wrong and you spend money recruiting the wrong person.

I once took a role that I believed to be a career. When I joined it was clear it was a job. I didn’t want a job, I wanted a career. I knew I would never get that at this company – I left after just 6 days (3 of which were spent trying to find out who to hand my notice in to).

I’ve also made the mistake of hiring people who wanted a job when I was offering them a career. It’s not good.

One is no better than another. Someone who takes a number of jobs can build a strong career.

Contractors, by their nature, are often looking for the next job. But they can build a strong career from those different jobs.

Your task is to match the right person to the right role.

In the interview be clear about what you are offering and strive to understand what the candidate wants.

Is it a job, or a career?

Be honest with the candidate and you’ll likely get the right match. Get it wrong and you’ll have probably hired the wrong person.

 

Standard. Or Not.

The international standard for Software Testing, ISO 29119, is soon to be upon us. There are people writing it and expanding it and creating it right now.

I’ve signed the petition against it because I don’t agree with some of it and it’s supposed to represent the industry I work in and I had no chance to input to it.

I wasn’t involved in shaping any of it, yet it’s soon to become a strong international standard in software testing.

My concern is not about how it will affect myself as such, but about how it will stunt the growth of the companies who sign up to it. It’s my belief that the standard will stunt the growth of the employees also.

I believe standards are useful. I believe standards can be helpful. They can turn laws in to process, or set out norms of operating that are good for business and society. This is useful.

Standards can also be restrictive though.

A company operating under this ISO 29119 standard may lose their ability to experiment and find new ways of doing good testing. Our industry and craft could suffer. The standard may hinder our ability to evolve our testing to be relevant to the market demands of the companies we work for.

I’m not overly worried just yet though. The standard is not even complete and it will take years before it starts impacting the market. The standard will likely be voluntary to adopt also. Companies that are experimenting and pushing boundaries will most likely not adopt it. At least not without a compelling reason. That means testing can still evolve.

That means there will still be a place for people like me. People who want to apply relevant test techniques and approaches. People like me who want to create new ways of testing that don’t yet exist.

And how can a standard cover something that doesn’t yet exist?

After writing this post I realised I’m describing a similar testing industry to right now. An industry where lots of companies rely on certifications. An industry where the minority are doing the innovative testing.

So will the ISO 29119 make a difference? Will it even get off the ground? Should we be trying to fight it if we don’t agree with it?

Or should we just accept it will happen and continue to do the best work we can; continue to be relevant to the companies we work for?

I suspect time will tell. As it always does.

If you don’t think the ISO 29119 is a good idea then consider signing the petition.

Kanban and Recruitment

We’ve been recruiting heavily for a while now and it’s been an epic journey from those early days 4 years ago when I started here at NewVoiceMedia to where we are today.

The Dev team has grown very quickly indeed and we’re still recruiting for talented Developers to join us.

I’ve been involved in pretty much every hire in to the Dev team over the last 4 years and have thoroughly enjoyed this recruitment process. It’s where the inspiration for this latest series of blog posts has come from. When you’ve interviewed 150+ people at various stages of recruitment you start to find ways to optimise this process, see interesting patterns and work out whether or not you enjoy it. I enjoy it 🙂

When you receive a tonne of good candidates each week it’s important to have a process that is efficient and effective. I like to use Kanban to visualise the process and aid with tracking people as they move through our recruitment process.

Kanban is a visual tool to show you your work in process so that you can start to make decisions from the information. LeanKit have a decent description of what Kanban is on their website so I won’t repeat it here.

A Recruitment Kanban Board
A Recruitment Kanban Board

Above is an image of a typical recruitment Kanban board. The above shows a simple recruitment process from the point of view of a recruiter.

Any Kanban tool will work for visualising your stages and process, from post-its on a whiteboard to a fully fledged Trello board. I like Trello because it’s super easy to use, is free and can pretty much be configured to map out any process. The above is a doodle I did in the Paper App.

For this example I’ll use a standard recruitment process that starts with a backlog of applicants, then a phone interview, then a coding exercise, followed by a face to face and then hopefully an offer and a “Yes”, or it may just be a “No” from any stage within the process. Testers and Scrum Masters miss the Code Review stage unless that exercise is relevant but essentially follow the same flow.

An important part of an efficient system is to ensure you don’t spend time copying and pasting details. If you work closely with your recruiter you should be able to get them to send an email directly to Trello (with or without salary details depending on your level of sharing) so the candidate they are putting forward appears directly in the backlog of your Kanban board.

On the backlog are people who are applying for a role (hopefully you’ll be as quick as possible to provide timely feedback for the person applying 🙂 ). Then it’s a case of moving them through the different phases as you do your interviewing. I think it’s important to include an “Offer In Progress” stage because there are sometimes delays and of course, until you receive the signed paperwork back they technically have not accepted.

Each stage will no doubt trigger some actions for you and your team such as sending the coding exercising, reviewing the code and then getting all of the contract preparation stuff sorted for example. Simply flow people through your system and use the Kanban board to show you where people are in the process, where your bottlenecks are and also give you clues as to how efficient your recruitment and interviewing process is.

I find Kanban a really effective way to see how applications are processed. I firmly believe in responding to every single candidate as quickly as possible and Kanban helps me to do this and avoid bottlenecks in our system.

How do you manage your hiring?

 

Dedicate time each day to recruiting

Recruiting good people takes lots of time, energy and focus.

In my current busy work schedule it’s almost impossible to find a block of time to sit down and rattle through recruitment tasks. So I’ve tried to focus on doing just one or two recruitment based tasks each day.

I’ve come to realise that this is much more effective than leaving all of the tasks to bunch up and create a daunting wall of project work.

To work through this backlog I’ve found it particularly useful to block time out in my calendar specifically for recruiting. An hour here and an hour there works a treat.

The Dev management team here at NewVoiceMedia share a backlog of recruitment tasks all focused on evolving our recruitment process to be industry leading. We want to hire the best people in the industry to help us achieve our business goals so we need to evolve our recruitment process to be the best it can be too.

Your own recruitment process will likely reflect the amount of effort you put in to it. It takes time (and hence costs money) to create a good recruitment process but it’s time and money well spent.

If you feel you have a daunting wall of recruitment goals and tasks then try breaking them down and kick start daily actions towards your recruiting goals.

 

Don’t rush in to a hiring decision

 

We regret to inform you image
We regret to inform you – Image from Caro Wallis “Sweet Sorrow” March 24, 2010 via Flickr, Creative Commons Attribution.

It’s very easy when recruiting to rush in to a decision about hiring somebody, especially so when you haven’t been inundated with a significant number of good candidates.

Be cautious though when making a decision and be sure that you’ve truly explored the options open to you. 

It’s sometimes better to delay a hire (and sub-sequent knock on to work load) than it is to hire someone who’s not right for the team. Hiring someone who is the wrong fit can have a real detrimental impact to the whole team.

One way to mitigate rushing in to a decision is to have a number of different people interview the candidate and then be responsible for making a decision about hiring them. 

If you have at least 4 people interview a candidate then you can get a balanced view of the candidate. Ideally the other interviewers will be from other functions across the delivery side of the business (agile, dev, product, service etc).

If any one person says “no” then it’s up the others to try and convince them to change their mind (if the candidate is worth fighting for) or the other must simply accept the decision and move on.

It can be hard to say “No” to really good candidates, buts it’s a process that helps keep the bar high. It is of course more expensive and time consuming but if you’re trying to hire the best talent then it’s a system I would absolutely recommend.

So why do we rush in?

Of course there are commercial deadlines to meet and hiring constraints to work within but in my experience most people rush in to making decisions on candidates because the candidate is the “best” of the rest.

This sounds harsh but it happens very frequently, especially in the testing and scrum master hiring arena (no doubt others too).

After a string of pretty bad interviews it can be tempting to say “yes” to someone who stands out. And this may be a good strategy as you may get the person you want, but is the person standing out because they are exactly what you’re after, or just because they are somewhat better than the others?

In the future I’ll share ways to get the right candidates first time so you spend less time interviewing bad candidates, but for now take it easy when hiring. Take some time, don’t rush, don’t feel the pressure too much and always try to be objective in your decision making. Hiring someone that doesn’t fit can be a very costly and demoralizing event. Instead, consider a group consensus as a way to get a more balanced view of a candidate.