In the first half of 2009 the Preload department at Novell was building a team in Taiwan. There were two main reasons for this – our customers (the OEMs and ODMs) were located there and we wanted to be near them and the first question a customer in Taiwan always seemed to be “how many people do you have here”. Local support in the native language backed with a large team is very important to companies in Taiwan.
We hired excellent people who were both experienced Linux engineers and people straight out of university. However, all were pretty inexperienced working with open source communities and I had a perception that any previous workplaces they were at in Asia was more likely to be hierarchical in nature where open communication was discouraged because you don’t question the boss. I believe this type of work place leads to the surfacing of issues until its way too late to solve them and leads to sub-optimal problem solving. I wanted to ensure that the new team understood open source was a key component of our work and that open communication was important both internally and externally in support of this.
This type of situation is not one I would have thought about at all when I first became a manager, but a couple of prior experiences (including failure) suggested this was something I could and should address. In particular the OpenOffice “indoctrination” about 4 years ago when we were expanding the team. At that time I managed the OpenOffice team at Novell and Michael Meeks interviewed everyone we hired during the expansion and many of them spent 1-2 nights sleeping on his couch in the UK or getting trained in the Toronto office in person. Due to this, that team (now the team working on LibreOffice) to this day cares a lot about tenacious fixing of customer problems, reducing code duplication/bloat and particularly about building a great community around the project.
So for Taiwan Greg KH, Michael Meeks, Aaron Bockover and Stefan Dirsch all visited the office within a year to cover engaging with community, supportability (no one time throw away code here!), upstreaming commitment to debug and find the real root cause and more. This had two major benefits. First the culture of open source and open investigation into problems was transmitted by people who lived it. Second communication pathways were built so that the engineering team in Taiwan felt comfortable asking questions and had people they had met to ask the questions to, without needing “big boss” (me) to facilitate or hear potentially “dumb” questions. So what do we have now? Those previously inexperienced with open source engineers who are now proposing, submitting and maintaining code upstream.
(BTW Greg is really great at the kernel piece of this and was able to help Ralink in a similar manner with these two items as well – in fact Novell is happy to help any component vendor this way).
Don’t get me wrong, you can’t just hire anyone and expect to imbue them with your organization’s culture, you have to have to get people that are interested in and receptive to the culture. For instance its unlikely every single Facebook engineer was previously part of a culture of shared code base ownership and review that required them to be in the room to fix bugs on the fly or allowed them to change and submit code to any part of the app or required checkin review. These are cultural pieces that are transmitted post hire, but you still have to pick people who are in general receptive to that culture.
I will always think about training engineering people in a cultural context not just in a technical manner now, particularly when building new teams or offices since it will be tougher for them to get it by osmosis. Future communication connections are built and you display the culture you have and want to have in the organization.