Something not often recognised in the IT services industry around here is the fact that software is a creative process. No matter what an organisation has in terms of processes or whatever, good software development is still overwhelmingly dependent on creativity. And creativity is heavily dependent on the environment.
I've seen a couple of blog posts on cool workplaces with a whole lot of photos, one of which is here and the other here and the bigger services firms have some pretty funky campuses with swimming pools and stuff, which is pretty cool. But a funky office isn't really the silver bullet for employee dissatisfaction - indeed, a funky office which interferes with the core principles of your work - ISO, CMM, Agile, common sense, whatever - is no good at all. So a cool workplace is nice, but one shaped to help you get your job done better is far more important. If you can have both, then nothing like it. Now our Bangalore space is nowhere as cool as the Pune space in that photo - but the underlying principles remain the same. In fact, the Pune office borrows all it's principles from Bangalore - since the Bangalore office is considerably older and evolved these principles to start with - and then adds a whole load of coolness. So you'll see the same dining tables in both offices and the same lack of cubicles in both spaces. Of course, Bangalore got both the XBox and the PS2, but then Pune got the cool look - so it's all fair I suppose.
The configuration of your office is just one part of the environment, of course. There are multiple factors which contribute to a positive environment and these tend to change over time. Regularly reviewing what these factors are and trying to enhance them is something which can hugely impact employee happiness. For example, something that some of my colleagues and I have been worrying about for some time now is that ThoughtWorks India seems to be losing its edge. Unlike me, they (and they're developers, not managers, before you ask) went ahead and did something about it.
They've just gone ahead and executed an office wide retrospective to identify things people like and things people don't so we can have more of the former and less of the latter. A retrospective is an enormously powerful tool to improve environments and there is no reason why it needs only be applied to individual projects. There are always macro issues which affect employees which don't usually show up in a project retrospective. The latter inherently tend to focus more on factors specific to that project, thus effectively hiding larger, office-wide concerns and trends. Implementing one across your entire office may not always be possible - ThoughtWorks India only has about 200 employees as opposed to any of the other services firms which usually have tens of thousand of employees - but one can certainly do so within a 'sub-environment' like a single floor, say. While retrospectives started as an 'Agile thing', there's no reason why they can't be applied everywhere. The secret is to have good retrospective facilitators who can keep an even pace and have people identify the good as well as the not-so-good. It is a natural human tendency to complain about stuff and while this is important, the nice stuff is probably even more important. It also falls upon the people involved to actually act on the knowledge distilled from a retrospective to bring in change - and of course, buy-in from management is essential for the whole thing to succeed.
The other important environmental factor in an IT firm is to encourage interest in technology. There all these really cool and really powerful languages and tools out there that could hugely benefit enterprise applications. Yet we still insist on doing things the same old way to minimise risk - or so we claim. How many .Net teams in Bangalore use Resharper? How many have even heard of it? Yet anyone who has developed with it installed for even a week would never care to do C# without it. Ditto for stuff like Rails, or Python or Hibernate or Ngnix or even, in some cases, Lisp. Again, none of these is a silver bullet, but identifying problems which they solve best and then using them appropriately can greatly mitigate risk and speed up delivery. Encouraging exploration of technology is essential to maintaining an edge, which in turn is essential to most IT firms (and not just startups, contrary to popular belief). Setting up stuff like hack days, conferences and tech seminars are pretty good ways of encouraging developers to do their stuff. Nothing keeps a developer happy like a healthy dose of admiration. Seriously.
No comments:
Post a Comment