In my eternal quest to understand how to deliver high quality software, I’ve spent a fair amount of time observing how very high level decisions and policies can expedite or impede this. A while ago, I read a discussion on “what makes a good engineering culture” that inspired me to put some of my thoughts to paper (as it were).
I think the top 10 list there is great, and if you read the referenced post on Quora, the details are even better. But there is one aspect that I feel needs to be explicitly addressed, and isn’t, though many of the posts come very, very close.
Encourage developers to be the developers they want to be
Another way to phrase this would be “be inclusive of developer identities”. While your organization may have specific needs, your developers are not puzzle pieces that are going to perfectly match up to those needs. Developers, especially the best ones, are always growing, and if you’re not providing opportunities for that growth, even outside of the official “responsibilities” assigned to those developers, you are missing some engagement.
There are a lot of ways to understand this. At a previous, very large, employer, I was fond of saying that they lacked a program to “build better geeks”. They possessed a tremendous amount of talented people, but they only had very narrow areas where they could engage the passion of these individuals. For example, many people I worked closely with in software testing were serious hardware geeks, but outside of an official career change, it was very difficult for them to find anywhere to engage these interests, despite there being hundreds of like-minded geeks throughout the company. An officially sanctioned way for these people to explore these interests would have not only been enjoyable for the employees, but would have helped nurture them into people who would be be appropriate to switch into those careers.
When your employee gets up in the morning, you want the most exciting thing in her day to be related to your company. Obviously, that’s an ideal, and isn’t always going to be possible. However, plenty of companies go out of their way to shut down that possibility altogether, which not only makes their employees less happy, it also reduces the amount of time their employees spend mentally engaged with their company. When your employee discovers something cool, you want their second thought to be “how can I use this at work?”.
Building Better Geeks
As the above should have made clear, what’s important is that you engage your employees, not how you engage them. But that doesn’t mean I can’t make suggestions.
Google’s 20% time is probably the best single model you can follow. Whether it’s actually 20% or not isn’t the most important thing. What matters is that employees have a regular opportunity to do something else that interests them, and just as importantly, to talk about that something else. But there will be areas where 20% time doesn’t work, either because it’s too developer focused, or extracting enough time out of the schedule to make it worthwhile is not feasible. Don’t despair, there are plenty of other options.
There are a lot of types of geeks. Software, hardware, networking, these are pretty classical geek models I’m sure you have encountered. But there’s also music geeks, food geeks, video game geeks, nature geeks, science geeks, etc. It’s quite likely that it will be difficult to sanction official activities to support all of that geekiness. But at the least, you can provide communication venues to allow the geekiness to flow. Joe in UI design loves molecular gastronomy, so give him a place to talk about it. Provide forums or internal blogs, have occasional “show and tell” events where people can spout off on whatever interests them. If you’ve got a handful of film buffs who want to try their hand at being behind the camera, arrange to lend them company resources.
The point is, whatever your developers are interested in, there are ways you can nurture it, even without any significant budgetary investments.
How Arc builds better Geeks
When I interviewed at Arc, it was for a specific position (actually two specific positions), but we basically talked about what I was interested in doing, along with what kinds of problems they had that needed to be solved. In some ways, my interests were significantly different from my existing skill set. They hired me for a position which matched my skill set very well, but quite rapidly transitioned me into something which was closer to what I had expressed interest in.
There’s an argument to be made that it was simply a coincidence that my interests were actually in areas where they had greater need than the ones they hired me to address, but having been here for a year now, I’ve seen enough of how things work that I don’t buy that. Time after time I’ve seen roles shift, at various levels of magnitude, but always towards what matched the passions of the employee.
Of course, being able to perform that kind of alchemy requires a deep knowledge of your employees. So what does Arc do to get that knowledge?
- Holds bi-weekly code and design review sessions where developers and designers can volunteer anything interesting they have been working on.
- Has weekly company lunches where everyone attends, and discussion is open.
- Frequently re-arranges everyone’s desks to ensure groups of people don’t become isolated from the rest of the company.
- Provides an in-house Kindling instance for employees to ferment ideas for just about anything.
- Provides “lab days” to allow employees to work on other projects that interest them.
- Every Friday, our Director of Employee Development, Jen, takes a different employee out for coffee.
Now, this certainly isn’t everything that happens to nurture geeks at Arc (I haven’t mentioned anything about happy hours), but it’s representative of the approach that the company takes.
In summary, let me emphasize two things:
- Encourage the passions of your employees to get the best out of them.
- The specific tools* or processes you use to do this don’t matter, so long as they allow you to communicate openly with your employees about what interests them.
*Except Kindling, every company should have a Kindling instance