Hamstaa!

Many people forget that the recruitment process is a two way street. While the employer is evaluating the candidate, the candidate is equally evaluating the company, position and management.

While the Weekend Australian article, “What Interviews foretell” by Karalyn Brown focussed primarily on the interview process from the candidate perspective, there were some good points for employers.

In my career I’ve been through quite a few interview processes, so it came as no surprise that Bob Olivier, director of Olivier recruitment

believes employers can easily overlook how a candidate matches the values and working style of an organisation - the “cultural fit”

One of the many attributes I’m looking for when we interview at Ephox is how the person will “fit” into our team. So while I’m ensuring the candidate gets a chance to evaluate our culture, we also ensure they will fit into the team through the code review and Coffee Interview.

Rightly so, Steve Begg, general manager of operations of executive recruiters Tanner Menzies and Olivier

believe that the recruitment process provides a glimpse into a company’s working culture. A formal series of interviews can indicate a more bureaucratic employer. A “meet the team” chat reflects a more open and casual working style. However, Begg stresses both method are valid recruitment tools

At Ephox we have what I believe is a good mix of formal and casual in our interview process. In addition, I’m are upfront at the beginning of the interview process with what the process is.

So what is our process? Well like many companies we start with a phone interview. As a significant amount of our communication is with overseas clients and our other offices, this also gives us a chance to evaluate how well a candidate can communicate on the phone.

We then move to a more formal, in office interview. We delve into the candidates abilities and also talk about us and the role, leaving nothing hidden. We want candidates to want to work with us so make sure they have the information to do so.

Successful candidates are then asked to do a coding exercise but unlike most “formal” ones, ours is a little more candidate friendly. We email the candidate a simple program requirements and ask them to submit the code, in their preferred language, when they have been able to complete it. After submission, we get the candidate back in to discuss the code and the solution approach with a couple of the senior engineers. This gives the candidate a chance to gauge what it is like to work within the team, and importantly for us, gives us a chance to evaluate how the candidate solves problems and discusses solutions.

Finally, if all goes well, we have the coffee interview to allow the entire team to participate in the process.

Why do we go to all this trouble to ensure both the candidate, the team and the company fit together? For one thing, we have very good retention and want to keep it that way.

The IT sector is heating back up again, and as such, salaries (at least in Australia) are increasing. With this increase however comes the challenge of retention of good staff. Most people see this as having to pay higher and higher salaries but I believe there are other options.

I was reading an article in a recent Campus Review entitled “Wellness & retention” which discussed some of these options.

Universities have traditionally not been the highest paid positions, so retention of good IT staff in this climate is becoming an increasing problem. The University of South Australia has tried a different approach to just competing on salaries. 

Over the past five years, its 100-strong IT team has been the focus of a wellness program aimed at encouraging employees and recruitment prospects to view the university as an employer of choice.

Some of the things that UniSA has undertaken are gym passes, weekly exercise programs, fresh fruit, fruit juices in summer, and soup in winter.

What they found was this focus on health of their staff resulted in a drop in attrition to 2%. It also had side benefits

The program costs about $15,000 a year but pays for itself with a reduction in sick days.

I believe there are a number of factors beyond just pure salary that influences a person’s decision to stay with a company. Things like culture, colleagues/team, stress, management and how much the company values them. 

At Ephox we’ve always had a great culture of fun. In addition, we have a great coffee machine, go to the pub on Friday’s for roast lunch and have beers at the end of the week.

Recently I asked the team what additional things we’d like to have in the office. I was looking for suggestions that meet one or more of the following criteria;

• Team Building
• Fun
• Health & Well Being

I got some interesting responses including fresh fruit, monthly neck/shoulder massages and quarterly team events. So we’ve started getting in fresh fruit, are about to trial in office massage and have nominated one of the team to be the coordinator for a team event.

I’d be really interested in what other companies are doing to retain great staff other than paying higher salaries.

So you’ve got talented people and as we all know, you need to invest in maintaining those skills. While there are a lot of ways you can do this, some of which are quite expensive, sometimes the little things have the biggest impact.

At Ephox we have a good collection of technical books and I’m always looking for new ones to add. It was suggested that we should get a copy of “Head First Design Patterns”. As the Head First series are designed to be written in, I purchased a copy for each member of the team. 

I was sure it was a good decision when the day after they arrived one of the team stopped me to tell me how good it was. This was quickly followed up by one of my senior engineers raving about how easy and compelling it was to read. Finally, one of the team rang me on the weekend prior to their week of leave to confirm they could write in the book, as they were really getting into it.

So, if you want a low cost form of training, don’t just buy books for your team library, but actually give them their own copies.

At Ephox we introduced the concept of Creative Coding Afternoons (or CCA) back in 2006 based loosely on the Atlassian and Jotspot Hackathons. Occuring Friday afternoon every 2 weeks, the original idea was to develop plugins for our editor based on the public APIs. Essentially do things that our clients could do. The best of these were posted on our LiveWorks! site as freely downloadable components.

Our CCAs are evolving into more advanced research that resemble 20% time, with projects spanning many CCAs. So when Atlassian announced it was going to emulate the Google’s 20% time model I was keen to see how it worked out for them.

It was with interested then that I read the recent followup on the progress over the last 10 weeks. In the post Charles reflected on their progress to date with a series of questions put to the developers.

The one I was most interested in was “How much time have you had to work on it?”. Charles summarised the responses by saying

almost all the responses were in the 2-3 day mark, and none higher.

This is closer to 4-6% for the 10 weeks they’ve been going than 20%. Why is this low?

In theory, saying to developers you can devote 20% of your time to do research/personal projects should result in 20% time being spent. The problem, as I see it, is that most project are on tight deadlines, and developers are committed to completing those project related tasks. A fact that seems to be borne out by the following response 

 …the biggest problem for developers finding time to work on their projects was fitting it around their scheduled work

So what’s the real problem? Well your projects are planned but no time is set aside in the schedule for 20% time activities. When your developers start working on 20% time, the schedule starts to slip, eating into “buffer” time. If the features then require that buffer time, how does the project manager deal with it? Easy, cancel 20% time.

How do we deal with this? The answer I think lies in a response to the question “if you could improve 20% time in any way, how would you?” 

“Mandate that particpants (sic) have to spend 2 days a fortnight on it, otherwise it's difficult to keep the pace up to 20%”

So, when planning a project, not only do we need to put aside time for feature overruns, but also time to accommodate 20% time. Again, all good in theory but at the end of the day, as a product company, we need to deliver product. The trick is to balance the successful delivery of new releases with the obvious benefits that can come from 20% time. 

I’ll be very interested in how Atlassian handles this over the remainder of their trial.

As part of our interview process for new engineers at Ephox the final stage is the Coffee Interview.

The Coffee Interview involves everyone in the the team, except the manager, going out with the potential hire and having a coffee. While discussions can be technical, it's not a technical interview but rather a chance for everyone involved to get to know each other. At the end of the coffee I get consensus from the team as to whether we should hire the person or not.

What we are trying to do in this interview is determine if the team can work with the person, and the person can work with the team. It's a case of ensuring the hire is a good "fit".

By involving everyone the person will work with, we are essentially building an emotional contract between the team and the new hire. These people are the ones who can exert the most influence over the success of the new hire and as such, the Coffee Interview provides a way to invest them in the success of the person.

I was reading an article, "Cultivate Commitment" by Julia Stirling, in The Weekend Australian recently that resonated with my belief that management and leadership is about people. The focus of the article was on employee commitment and the part management plays on the level of commitment.

Keeping employees engaged is one of the biggest challenges for managers. Happy people are productive people, and research suggests relationships are the biggest single determinant of productivity within a group.

There are three levels of employee commitment identified in the article; Engaged, Not Engaged and Actively Disengaged. The level we should be striving to cultivate as managers is the Engaged employee. Engaged employees work with passion, feel a profound connection to their company, drive innovation and move the organisation forward.

What was disappointing to read was the percentage of people that are Actively Disengaged versus Engaged. Only around 10% of employees are Engaged with over 50% at the Actively Disengaged level.

Michael Mere, an educational consultant with Swinburne Industry Solutions says

"The poor levels of employee engagement show how much 20th-century management theory and practices are failing today. Emphasis on obedience, diligence and even thinking are no longer delivering competitive advantage. In the 21st century, what you need to be competitive is a workforce that is using its initiative, is committed to the organisation and is passionate about what it does."

As a manager, we have the most influence over the level of commitment our employees have. What is interesting is that relationships are a major part of this influence. There are two major reasons identified by Mere for why people become disengaged. These are:

dysfunctional relationships (particularly with their immediate supervisor/manager and within their work group), and failure, real of perceived, of the organisation to fulfil an obligation or expectation

Over the years, I've occasionally found myself in situations where promises where made that were never kept and as such I found myself becoming "Not Engaged". I left very soon after.

Because of these experiences, something I've strived very hard to do since I moved into management is to meet the promises I make with my team. I've also worked at cultivating a good working relationship with everyone I work with.

So why do managers have problems with building relationships within their teams? Mere says that the

Lack of emotional maturity in supervisors and leaders is a major contributor to disengagement

Interestingly, this emotional intelligence is not a contributing factor in the promotion of people to a management role, despite how important it is in building and maintaining an Engaged team.

One of the basic principles of XP is to provide value. To achieve this ,you do the stories first that bring the most value. Now if those stories are risky or big, then you want to fail fast and move on. However in software development, most things are possible…it's just a matter of time. So how do you fail?

At Ephox we are extremely good at making the impossible possible, just take a look at EditLive!. The things we did in the early days were not possible with the limitations of the Java APIs, so we found a way around them. As such, it is possible to continue with a feature beyond the current return on investment of the feature.

What we need to do is find a way of identifying when to stop the investment in a given feature, mark it as "failed" and move onto the next most valuable feature. To do this however, you need to know what are the conditions by which you define something as having failed.

We recently moved to a tri-estimate approach¹ where all stories include a Best case, Worst case and Most Likely estimate. These estimates not only give us an indication of the risk associated with a feature, but also a basis by which to determine "failure".

My framework for "failing" a story is as follows. Once we hit the Most Likely estimate, we re-evaluate the Worst Case estimate with the knowledge gained so far. Assuming the revised Worst case is an acceptable investment in the feature, the new value is then considered the "line in the sand". Once we hit the Worst Case estimate, we review, asking how much longer to go to completion. If the time to go is acceptable, then this is the "failure" time. Once that time has expired, the story fails.

So, for example, figures of 20 and 40hrs are given for Most Likely and Worst Case estimates respectively. At 20hrs, the team revises the Worst Case to 45hrs. It is accepted that the features value is worth 45hrs, and development continues. At 45hrs, the team says there is an additional 3 hrs to go to completion. This final amount of effort is short enough that development continues for the 3 additional hours. At the end of that time, we "fail" the story if it's not completed.

Now of course, there are exceptions to this,  but the aim is to identify when a feature is just going to keep going and stop it.  

1 - Doug discussed the idea in his article Estimations - Best, Expected and Worst ↩

At the final, for 2007, QUT Dean's Industry Working Breakfast last week I found myself discussing the disturbing trend in the decline in IT enrolments with Bobby Barnett, a secondary school IT teacher at John  Paul College. 

We talked about the fact that kids today¹ are so comfortable with technology. They use it voraciously and for so many purposes, so why is it that we haven't seen an increase in IT enrolments. It seems that while they are more than happy to use technology, they aren't fired up with the idea of creating it. 

As Bobby put it,

They want to drive the car, but aren't interested in building it.

I find it odd that there is a perception that, while using the technology is fun, designing and building it isn't it. 

I love motorcycles, so to me, the passion with which they are designed is evident in the form and function of the bikes. You can't tell me that the designers of the latest Ducati 1098 or the MV Agusta F4 don't have the same passion for riding as they do for design. 

Similarly, the developers of the iPhone or Facebook I'm sure were equally passionate about the design and development as they are in the utilisation of the final product.

The real challenge appears to me to be, how do we show potential IT students the challenges and opportunities in the development of  technology? How do we fire up their desire to develop new technology and applications to the same level as their passion in consuming them?

1 - I suddenly feel old. ↩

Suneth attended QCon last week and in his post "The Great Convergence" he summarises Kent Becks comments on "the great convergence of Business Trends and Developing Trends in the IT world". 

I totally agree with the view that today's developers require far more social and people skills than evidenced in the traditional view people have of the developer. I also think that the Agile practices help focus a development team on the needs of the client and hence force engagement with the business users, resulting in the need for and development of these skills.

Where Suneth and I depart in our views however is in his assumption that technical skills don't matter for a developer. His assertion that

Anyone with a healthy brain can learn any programming language and write good code with some guidance and practice. But it is not easy to train someone to behave a certain way or teach some values like being positive or working as a team. 

I think misses the fundamental training in Software design that engineers gain during their degree. There is a big difference between "Programming Skills" and "Language Knowledge". To borrow from Dylan's comment to Suneth's post 

There is [the] art of developing quality software - a strong degree of craftsmanship involved, which separates code-monkeys from true engineers.

I also think that Suneth sells himself short in his comment that

… technical skills of a programmer should not be the main requirement while hiring. For example, prior joining Ephox, I was a .NET developer.

I'd disagree with Suneth suggesting he didn't have the technical skills of a programmer, we wouldn't have hired him if he didn't. What Suneth lacked was commercial experience in our language of choice, Java, but his technical skills in developing quality software were evident and why we hired him.

As a manager, when I'm looking for new recuits I'm evaluating the whole package, social and technical and weighting them equally. In the interview process, the face to face covers the social, and the programming exercise covers the technical. In one way we differ from the traditional though in that our programming exercise doesn't require the canidate to program in Java. It's their analysis, design and development skills and philosophies we are interested.

Last week I went to the QUT Dean's Industry Working Breakfast and again it was commented that the challenge for ICT in Australia is attracting students to study IT at uni.

Interestingly, the ABC news last week also featured an article, "Research shows IT worker shortage looms" that also raised the looming shortage of ICT professionals.

As someone responsible for recruitment for the Engineering team at Ephox this concerns me when I look to how I grow the team locally. As an Australian this also concerns me if Australia is to continue to compete on the world stage in ICT, something I believe we are well suited for.

The major problem as identified by QUT's Dean appears to be attracting new students into IT related degrees.

Dr Dobson says since 2002, the overall number of enrolments in the discipline has fallen by about 20 per cent1

So what can we do about it?

I know that universities in Brisbane are actively engaging with high-school students trying to encourage them to enroll, however they need our help. When they go out to talk to students and explain the benefits of IT as a profession, the main reaction they get is "well of course you'd say that, you want us to come to your Uni". I think this is partly due to Uni's being seen more as businesses (students represent revenue) than educators and that the vision of an IT professional is sometimes seen as just the guy that fixes PCs. We can help by engaging with High Schools and showing  that there is still an active career path in ICT with a diverse range of opportunities.

It was recently suggested to me that the ICT industry needs to "market" our profession more, both to students and government. I think that if we don't, then we will find it harder to attract new staff, the costs associated with staff will increase and staff retention will become a larger issue.

1 - Taken from the ABC Article, Research shows IT worker shortage looms ↩