The DevChix community recently attacked the issue of what to do about a “blah” workplace environment. If you’ve done development for any length of time, or for more than a few companies, you’ve probably experienced the same thing somewhere along the way. Your coworkers are nice folks and everyone gets along, but there’s no real camaraderie. People work hard and produce good code, but no one seems too terribly excited about it. Sound familiar?
Lots of companies try to guard against this with perks meant to be fun and make work feel less formal. But sometimes all the kegerators in the world don’t make a difference. One of the DevChix described her experience in an office that sounds on paper like the Disneyland of workplaces:
“There are foosball tables, pool tables, air hockey tables and a beer keg in the kitchen. We work in quad-pods where there are 4 people in each large sized pod. The idea was to create a space open to collaboration. Nobody really talks much though. Things like the gaming tables are nice but I don’t see them having much impact. Some people grab a pint [from the keg] after 5pm and work at their desk, again not talking much. “
A “neutral” company culture, it seems, is not a problem you can just throw a couple foosball tables at. The DevChix suggested the problem is rooted in how a company treats its devs.
Where does uninspiring culture begin?
If you guessed “management”, the list agrees with you (at least partially). Developer empowerment was highlighted as one of the biggest things that make a difference in developers’ passion at work. Without realizing it, managers may be making their developers feel isolated or ignored:
“Management might be thinking that what they’re working on isn’t that relevant to their staff, or is relevant but they haven’t made significant enough progress to share – but communicating the use of your time, however vaguely, on a regular basis has a way of clearing the air. It says, “I’m not forgetting about you” and also promotes open communication (when I’m not hearing anything from a manager, I don’t feel as comfortable going to him or her with my problems). I’ve been surprised at how strong of a reaction seeing upper management going in and out of meetings without sharing any details whatsoever has had on me, and it’s not even that I want to have a lot of data.”
Another problem can be the ways in which developers are encouraged to interact. If collaboration is rare, developers have less to talk about as developers. The extroverted ones will probably find other things to discuss around the water cooler, but if they aren’t working together, it’s likely that company culture is repressing the urge to share ideas over the cubicle wall. It’s important to consider how many developers are likely to be introverts – development, after all, isn’t sales – and leave a space for interaction at work that isn’t so unstructured that it exhausts anyone or excludes them. In short, aimless chatter can be tiring or distracting, but active teamwork is inspiring.
What can companies do differently?
One of the more unanimous suggestions was to offer developers the opportunity to do non-business-driven projects. Giving teams the opportunity to use new technologies, proof of concept the things they think are important, and generally develop something to their own standards gives developers a voice in what they’re doing. Google’s 20% time was offered as an example of this. Having a policy like this and promoting it as aggressively as Google does creates an impression of a place where developers’ ideas are sought out and supported, even in outsiders. And supporting developer-driven projects doesn’t mean simply tolerating them. The DevChix who gave examples of similar projects they’d worked on mentioned that these – in whole or in part – had eventually been used by their employers in “normal” projects.
Something that was new to me was the idea of project leads bidding on resources to give developers more control over what they’re working on (a project owner could say, “I need this done but it’s the only thing I need done this sprint,” if I understand correctly). At a busy agency or a start-up just getting its feet under it, committing 20% of each developer’s time to projects that might turn out to be technically infeasible might be too expensive. Letting developers choose their projects would be a great alternative.
Toward the end of promoting camaraderie and sharing knowledge, something developers might be able to do without having to get management approval is peer code reviews. This is certainly more challenging when everyone is working on a separate project, but consider that not everyone has to share all their code all the time. The woman who suggested this mentioned that her team had one or two people presenting once a week, something that should be manageable no matter how many different projects a dev team was working on.
A simple but important suggestion that was brought up by different people with different examples was offering developers the chance to “learn something cool”. This could be done by in-office trainings, brown bag lunches, or sending developers to conferences, but the DevChix who mentioned it seemed to agree that it’s a big part of getting developers excited. These can range in cost to the company all the way up to (and occasionally past) $2k, but consider what the employer gets in return:
“It was amazing how [attending a conference turned] jaded, tired corporate workers into ra-ra cheerleaders like overnight. The amount of info you can get at these things – along with connections of course – is intense. And it’s great to show that the corporation is willing to invest in the employee.”
If a company can’t spend the money on conference registration, air travel, and a hotel stay for an employee, they could also try to bring the expertise to the developers. It was pointed out that many technical leaders are happy to share an hour of their time, and this gives everyone on the team the chance to learn together instead of one or two people getting to go to a conference while the rest of the team is back at the office park slaving away. If a company is so isolated that the only way to boost developer knowledge is through sending employees out of town for conferences, one suggestion was to give the rest of the dev team the same time off their peer attending the conference was getting to read, learn, and work on exciting proofs of concept.
In summary, the DevChix who participated in this thread emphasized the need to treat smart, valuable people like smart, valuable people, whether you manage them or sit next to them. One nice thing about developers is that you don’t really need a foosball table to get them excited about coming into the office – generally you just need to give them the freedom to do what they love: write good code.