Hamstaa!

We recently had two new businesses move into the offices next door. Looking through the doors highlighted to me how important the first impression of an office is to the energy you bring when you walk in the door.

One of the offices is very evidently a call-center. It’s clad in shades of grey and blue with small cubicles. It seems to suck the energy out of you just looking at it.

The other (pictured) seems to draw you in. In fact, upon entering, I had not idea what they did¹, but you felt that it would be an interesting place to work.

It may seem obvious, but it’s important to consider the impact your office environment has on potential employee’s as well as the current ones.

When recruiting, if a candidate walks in the door thinking, “wow, I want to work here”, or compares favorably your office/team with their current office and team part of the hiring process just got simpler.

For your own staff, having a place that they want to work in, along with an outstanding team to work with brings it’s own rewards. Higher productivity, less down-time due to illness and greater retention to name just a few. These rewards have value not easily measured but a lot higher than what it can cost to make a great environment.

1 – My wife’s first guess from the photo was travel, but it turns out they are a tattoo artist.↩

When I started writing this blog, one of my aims was to provide an insight into what is involved in Engineering management to engineers considering or recently moved into management.

Most engineers I’ve worked with, I would consider “creative”. They are constantly finding and developing creative solutions to problems but just as importantly they enjoy creating things.

I’ve always enjoyed creating things so I gained a lot of satisfaction in my career from creating solutions in code. In the years before I moved to management, I was mostly involved in Web and GUI development. Both of these not only give you great feedback on your development but also provide a sense of creation.

About a year ago, I started playing GamesWorkshop’s Lord of the Rings. While I enjoy the game, I really got involved in the painting of the models.

I spend a reasonable amount of time making and painting models which culminated in me entering a painting competition (the model was from WarHammer not Lord of the Rings)

I recently came to the realisation that I had substituted the creative experience I had as a programmer with my modelling.

So, when you move from development to management, consider that you will no longer fulfill your creative requirements with your work and find a creative outlet.

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