Hamstaa!

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 ↩

A few posts ago I talked about competency versus capability and recently I've seen a few posts supporting my assertion that the "tick in the box" approach to hiring isn't going to guarantee you get capable people.

Dan Creswell posted a great article in response to the job ad for a Senior Research Engineer at Amazon. 

So often I see companies create job specs for engineers where the key requirement is to hire someone who can hit the deck coding like mad using whatever tools have been selected. To that end they load the specs up with endless tech hubris and at interview ask the details of this or that bit of syntax or API call.

Frank Wiles continued the theme in his post on "A Guide to Hiring Programmers" where he identified  

You don't need to hire an expert in language X, you can and should look for expert programmers that are willing to learn language X. An expert can easily cross over from being a novice in any language in a matter of a few weeks.

If you are hiring solely on technical skills then, as Dan Creswell asks, "what about the next project within the company where the tech is different?". This is where capability wins over competence for me.

Having ways to judge the capability of potential hires in the interview process is crucial to successfully hiring people who can grow and evolve with your business. Ideally you don't want to have to hire a complete set of new developers if you change technology. The current ones know your business and will appreciate the opportunity to develop new skills, thus adding to company loyalty and retention. 

At Ephox, as part of our recruitment process, we have people undertake a coding exercise. This is a very simple program that the candidate can do at their leisure to allow them to fit it into their current commitments. Most importantly we allow them to develop it in their preferred language and tools. Once it's submitted back to us and reviewed by senior engineers, we invited the candidate back for a frank discussion on their thinking during the development process.

What are we trying to achieve? We are looking for how they approach problems and how they interact in a technical discussion. Basically all the things that indicate their capability for the role versus their proficiency with a particular technology stack.

We've already seen this approach work with our last hire. Suneth had only basic Java skills prior to joining us but when we evaluated his ability we could see the potential and an eagerness to learn more. In the 12 months since Suneth joined us his skills in Java have increased immensely.

How do others evaluate the capabilities of their candidates during the interview process?

You will often hear the terms "People Independence" or "Institutional Memory" used as a management reason for the creation of the huge volumes of paperwork often created in a BDUF (Big Design Up Front) project. The idea of course is that the presence of the documentation allows the organisation to use developers interchangeably.

For developers, documentation is extremely useful for the those who come after, even if it's you in 12 months time. This documentation however is only useful if it's up-to-date. Unfortunately in most cases it's written, read and never looked at again.

When I was consulting, and prior to my introduction to Agile practices, I often worked with organisations that didn't particularly want to spend time on documentation. This wasn't because they believed it wasn't useful, it was more a cost saving method. Still wanting to provide future developers some form of documentation I became an advocate for heavy commenting of code. Hence, the code became the documentation. 

With my introduction to Agile practices a few years ago the idea of "documentation in the code" has moved on to incorporate and focus on atomic tests. The application of the concept of waste from Lean Software Development on formal documentation also supports the use of atomic tests as documentation (unless the documentation provides some other value than the fulfillment of the process).

So does code (test cases) as a replacement for formal documentation meet the requirements of managers who are looking for "People Independence"? It does if they are looking for a way to fulfill the need to pass on knowledge to future developers. In addition the added benefits of atomic test on quality and confidence for future developers to make changes and maintain current functionality is immeasurable.

Continuing the "Growing Team Leaders" course, last week Greg Stockwell of Public Speaking Australia presented "Public Speaking and Presentation Skills".

Unlike the previous sessions, this session was presented as a series of exercises where Greg introduced a few simple techniques for dealing with the obvious nerves of speaking. Interestingly when you hear people say they don't get nervous when speaking, this can sometimes mean they are overconfident. This overconfidence comes across to the audience as disingenuous.

Greg also presented a few simple rules when speaking publicly. For example

• never tell the audience you're nervous, they'll focus on looking for the signs of nerves instead of the substance of your presentation
• if showing a video, tell them how long it is so they know what to expect
• if possible, see the venue before you speak so you have a sense of the layout and reduce the unexpected
• finally, be yourself, don't try to be something you aren't.

I think the point I really liked, that Greg made, regarding public speaking is

It's not life or death, it's only public speaking.

Yesterday I had the opportunity to hear Alan Noble, Engineering Director for Google Australia/New Zealand present on how they are tackling Google's expansion. While there were many interesting facts (for example, Google receives 12 resumes every second) and insights (like Google's approach to products, "Build it and see if people use it"), the one that I found interesting is regarding Branding.

We all know the value of and hence focus on building our companies brand. In today's environment, it needs to be dynamic, exciting and have "sizzle", as they say. When it comes to recruitment however, we tend to have a bland, boring, "check list" approach. Alan highlighted the obvious issues with this when trying to recruit highly talented professionals, especially "Generation-Y". On the one hand you represent a dynamic exciting work place, on the other your recruitment message says the opposite.

As Engineering Managers, I see it as part of our job to build "brand awareness" of our engineering team. This can include involvement with universities and the local technical community but it's also important to consider what message we are giving when we advertise for positions. 

At Ephox we have a team of outstanding developers working on the edge of technology. They work hard as a team and have a heap of fun doing it. It's this kind of message I want to get across when building awareness of our technical team, but it is also important to get this across when we advertise for new team members.

During the recent session of my leadership course the presenter (Karl) raised an interesting point regarding the under-recognition of Capability compared to Competence.

If you aren't familiar with this, consider the image on the right. For any Situation, there are known and unknown situations. Similarly there are known and unknown Problems. Our ability to deal with Known Problems in Known Situations is reflected in out Competency. When we are presented with an Unknown Problem in an Unknown Situation, it is our abilities that assist us. This is our Capability.

The problem is that Capability is both hard to define and hard to measure.

Many in industry want be able to put a "tick in the box" when it comes to a persons abilities. This usually results in competencies being essential. Like Karl, I feel Capability is under-valued due to the difficulty in measuring it.

This also fits with my long held belief that in the "People versus Process" equation, People stand out. Sure process ensures replicable results, however when the inevitable problem arises that the process doesn't address, having good people with the autonomy to make decisions will get you through. It is their Capability that delivers in the end.

In the second session of the "Growing Team Leaders" course, Karl Buderus from Success Solutions presented "Leading IT Projects".

Karl started out stating that "Leading Projects" is different to "Managing Projects". Project management involves activities like planning, budgeting, organising, controlling and problem solving while leadership is about vision, alignment of people, motivation and inspiration. So, where management is a Science, leadership is more of an Art and involves enabling, empowering and supporting the team.

One of the key messages I took away from this session is that Leaders helps people find the answers versus telling them. In most cases, team members know the answers, by assisting them to find the answer, you not only grow their abilities, but empower them solve problems without your involvement.

Similar to the previous session, good communication was highlighted as essential, along with negotiations skills. This time, communication with project sponsors was discussed. Identifying how the key people required to make your project succeed want to be communicated, is essential to your success.

The remainder of the course then focussed on things like governance, organisational alignment and management tools.

So when you are working on something involving high innovation, which can result in high risk, good leadership is essential to succeed. Share the vision, excite the team and ensure key stakeholders are involved, clearing the way for your team to innovate and deliver.

While writing a post about retrospectives and deltas, in response to an article by Deborah Hartmann on InfoQ (Frequent Retrospectives Accelerate Learning and Improvement), I noticed a disturbing comment mentioning the "traditional blame party". 

Deborah's post referred to and quoted from an article by Rachael Davis entitled "How To: Live and Learn with Retrospectives". The quote from Rachael's article included the following sentence.

Without these in place, conversations are likely to be full of criticism and attributing blame

Rachael's comment, when put into context of her article, is about avoiding a situation resulting in blame, however, while the commentor's remark may have been facetious, it seems "blame" in retrospectives is a reality.

Attributing blame, be it in a retrospective or in the development process seems to me to contradict some important elements of eXtreme Programming. 

The principle of Accepted Responsibility and the practice of Collective Ownership (which comes out of the Shared Code practice) both imply that the team accept and own the decisions collectively. Pointing the finger tends to do nothing but breed resentment and cause people to "switch off" to potential solutions to the problems.

Finally, attributing blame in a critical manner ends up breaking the core value of Respect. 

I think it's an important role for a manager to encourage an environment where people feel "safe" to raise issues in a retrospective without feeling that blame will be attributed.

As I mentioned in my first post one, of the reasons for this blog is to help engineers new to management. 

When I first started in management, I went looking for books that would help me develop the skills necessary to be a good manager. On the "Management Books" page you will find a collection of books I've read so far.

These range from management and leadership in the form of the "One Minute Manager" series, to the "Fish! philosophy", a way to drive productivity while maintaining a sense of fun.

I mentioned the other day that I had recently attended the first session in a course on leadership. While waiting for the session to begin, I chatted to one of the attendees. Like many technical people in management, after many years in development, they are promoted to a management role with little to no training or management experience. As such he was struggling with the balance between managing people and development. 

More importantly, because he had been with the company for a number of years prior to his promotion, he knew the code base intimately. As such, when one of his engineers had something complex to do, he would inevitably do it himself, in case they failed to do it right.

He realized that as a result he had becomes the bottleneck of his team. In addition he is failing to give opportunities to his team to develop skills. 

When I joined Ephox, I had a heap of experience with J2EE but only a limited experience with Swing. What this meant was I focussed on building my management skills, growing the team and putting in place the processes to ensure we provided the best code, without taking anything away from the team.

Once I'd built up some skills in management and put in place the processes to continue to improve the team, I could then focus on regaining the slightly rusty technical skills to be able to play a key part in the architectural design of our products.

When you start on your path in management, don't be afraid to let go some of your development  focus in favor of management skills. Give your team the opportunities that you were given, to show what they can do, and to grow in their abilities.