Hamstaa!

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.

It's been exactly a year since I started blogging and so I thought it would be good to reflect on my experience so far.

When I set out, I wanted a means to communicate my experience as a manager to anyone considering the move. I've continued to keep the primary focus of my articles to management and leadership, however there has been the odd time when I could have blogged about other areas. This is something I think I'll do in the future.

I haven't received alot of feedback on my articles but that's not surprising considering how little readership I have and how many posts I've made. I did however receive some great feedback at a business event from Karl, the presenter of a session on the leadership course I undertook last year. He complimented me on my post Capability versus Competence and said he regularly points people at it when explaining the differences.

The one problem I do find is that I start an entry, get caught up in something else and don't get back to it for ages. In some cases, it is then too late to be relevant. 

The main thing I think I need to take away from all of this experience so far is that "the publish button isn't as scary as it looks" and I just need to publish those articles that end up in draft.

So my "new years" resolution is to publish more often.

Over the last year I've been working on building better relationships with our local universities. I see this serving two purposes. Firstly, it provides an avenue for promoting Ephox and subsequently using this self-promotion as a means to attract high quality staff. Secondly, it is a way to give back to the industry and help attract more people into IT.

So as part of this outreach, I jumped at the opportunity to present as a guest lecturer at QUT recently. The subject, Core Project Management, has provision for guest lecturers so we took up the offer to present two lectures.

Damien presented last week on the topic of requirements gathering in a product company and yesterday I presented the differences in project management between a product company and a project (professional services) company.

It was the first time I'd given a lecture so it was a little daunting initially. Once I got started and found my groove, it all flowed together nicely. Unfortunately I had little feedback from the students on how useful they found what I presented. The lecturer however seemed happy with both the clarity and topic. Overall I'm happy with how it went and look forward to other opportunities to speak.

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

I was having lunch with Adrian recently and we were talking about how people work with email. One thing he said made me stop and think about the different ways people treat email and the potential problems that can occur if they aren't aware of the differences.

What he said was, "e-mail is a conversation, not a considered media".

Now some people treat e-mail as a "considered media", I must admit I'm one of them. When I put together either a response to an e-mail or create a new email, I spend time crafting it and reviewing it before I send it. In a few cases, the people I send them too are "email conversationalists" and so I regularly get short responses that don't always address my entire e-mail. 

This reminded me of the Myers-Briggs "E" versus "I" categorisation and the confusion that can occur when they interact unknowingly.

'E' types tend to think by talking, whereas 'I' people tend to think then speak. As such, when an 'E' is talking to an 'I', the 'E' is looking for the type of feedback they would give that they understand. As the 'I' internalises this feedback, it is possible for the 'E' to continue way past the point the 'I' understood, causing frustration on both behalfs.

Understanding this makes for significantly more useful conversations between the two types.

So what happens when a person who treats email as a considered media gets a quick response from someone who doesn't. Well it's possible they read more into the response than was intended and hence draw the wrong conclusions. Alternatively, they get frustrated that not all of their questions were answered.

Equally, the other party can get frustrated with the "long" email and so skims, possibly missing important information or questions.

Next time you receive an email, consider the approach the person sending it may have taken and engage in the conversation appropriately.

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 ↩

How do you view and hence refer to the people who buy your software or services? As Customers or Clients?

While it sounds like a simple case of semantics, it is a significant change in how you look upon them and how you treat them.

To explain the difference, consider the following analogy.

We refer to the doctor, lawyer and accountant we use as "My Doctor", "My Lawyer" and "My Accountant" but we never refer to the shopping centre we go to as "My Shopping centre" . It's referred to as "The Shopping Centre".

A customer is someone who you don't build a relationship with. You don't necessarily gain repeat business with. They are someone who can easily switch to a different product (shopping centre)

With the subtle shift to considering them as Clients, you are focussed more on working with them, finding solutions to their problems and gaining their appreciation and repeat business.

Like most engineers I thought management was the "dark side" but was something that, as your career progressed, couldn't be avoided. After 13 years of development and technical consulting, I was offered the opportunity to see what it was like in management, while still requiring me to maintain my technical skills at an architectural level.

I've been the Engineering Manager at Ephox now for 2 and a half years and have found that I really enjoy what I do. I've learnt alot and grown my team both in numbers and professionally. Most importantly we produce some amazing code while having alot of fun.

Why am I blogging? Blogging for me serves a number of purposes.

• At a corporate level, it provides me with a forum to show prospective engineers what it's like to work with us and have me as a manager.
• At a professional level it gives me the opportunity to help other new managers and dispel the engineering myth of management being "the dark side" by providing an insight into what is involved in Engineering management.
• At a personal level it's a place to keep notes and comments on things "management" and to grow the brand that is "Brett Henderson, Engineering Manager".

So welcome to my blog. If you're an engineer who like me thought management was an evil necessity, or are new to management come on a journey with me. If you're an experienced manager I'd welcome your comments and advice.