First I’ll get some personal-goings-on out of the way.
As my previous post implied, I’m now quite happily working as a software designer at Sininen Meteoriitti, which just so happens to be the other one of the two companies recieving honorary mentions in the earlier industry-related rant.
Things are pretty good here. I’m surrounded by brilliant people and a refreshingly easy-going corporate culture. Programmers follow conventions meticulously and thus the codebase is clean and easy to get into. Not all of them are exactly radiating with passion, but it clearly is there nevertheless.
The company has reached a respectable size of 60 employees, but there still is a distinct air of work-in-progress about. That is by no means a bad thing. When there isn’t an answer to everything, you kinda get a chance to slip your own thoughts in.
I’m not saying that you really need any corporate tactics nor politics to get your voice heard here. The hierarchy is there but communication-wise it’s flat as a pancake.
I was talking with the CTO the other day on MSN, trying to conjure up an idea for a blog post. The subject that kinda jumped at me was the challenge of keeping employees involved in the constant stream of new technologies.
Two prime motives for tackling this challenge
First, to keep enthusiastic and information-hungry people engaged to the company. People belonging to the aforementioned category (including yours truly) like to stay on the cutting edge and experiment with new things. Doing project work on the same platform for years on end – to me – seems like a valid motive for job-hopping.
Second, to keep your company on the cutting edge. This isn’t to say that you should embrace each and every new framework, O/R mapper or project methodology thrown at you – updating and refactoring your existing codebase to support new technologies all the time is an easy way to waste money and keep the bug tracker busy – but you definitely should stay on top of things. This is a vast subject on its own, and better covered elsewhere, so I won’t go deeper into it for now.
So what can you do to keep your staff educated?
There’s the traditional approach of sending people off to courses and seminars. A good approach as such, but I’ve often found it somewhat slapdash in execution. Sending an employee off to a crashcourse on WPF is merely driveby-education if you don’t provide means to apply that freshly acquired knowledge on anything. Slightly problematic, taking into consideration the fact that the first client case shouldn’t hastily be seen as a concoction to acid test Ruby On MonoRailCat 0.02 Community LOL Preview in.
However, I’ve yet to see or hear about a software company that has its own toolset fully covered and refined. The shoemaker’s daughter has no shoes and all that. Internal development is a great field to test one’s skills at and really learn the practical ins and outs of new technologies. A typical example of this is the dreaded timesheet application. Every software company needs one and everyone needs it to be just slightly different than the other one.
Sending an employee off to a course and then giving her the chance to apply the freshly learned skills onto something relevant – but not too critical – is a really great way to keep an employee’s skillset up to date and bring a breath of fresh air to the job.
An idea of a slightly more comprehensive and academic approach came from our brilliant CTO, Jouni Heikniemi. He proposed that I could perform a speech to the company on the subject of a technology I’ve had my eye on for some time now, namely Microsoft Oslo. The idea being that I first have to learn a thing or two about the said technology.
Needless to say that learning a technology to the point that one can confidently speak to an audience about it should develop a pretty good understanding on the subject. However, the trick here is actually to make a project out of learning and allocate some time and resources to it.
Lastly, there’s the Google way: 20-percent time. It’s about giving the employees a chance to work one day a week on stuff not necessarily in their job descriptions. Funding employee-driven open source projects seems like a good idea to keep employees experimenting and innovating. It doesn’t have to be 20%, nor does it have to be any other statically defined amount of time. Encouragement and allocating time on need is enough.
The 20-percent time principle somewhat overlaps with the first technique, and indeed the way forward could be to let the employee think of her own projects, but if none emerge, she could be given an internal development project to fiddle with the way she likes.
To boil it down, there isn’t a silver bullet here, but I think you’ll agree that people should be given the time and possibilities to educate themselves and apply the knowledge on at least something. But even more than simple methods and principles, the constant education process requires the right atmosphere.
Encourage. Inspire. Host your own techdays. Build an extensive library.
P.S. My blog scored a fancy caricature of my hairy mug. Thanks go to Janne Itäpiiri for that.