One of the most common issues I have seen with experienced professional software developers who start to work on community software is a reluctance to engage with public communication channels like mailing lists. Understanding the reasons why, and helping your developers overcome their timidity, is key to creating a successful and fruitful relationship with the community you are working with.
In my experience, common reasons for this timidity are a lack of confidence in written English skills, or technical skills, nervousness related to public peer review, and seeing community interaction as “communication” or “marketing” (which are not part of their job), rather than just “getting stuff done” (which, of course, is part of their job).
Lack of confidence
For non-English speakers, this phenomenon is more prevalent, but in general, professional software developers have not developed writing skills during college, and often have not been required to learn them as part of their job. In addition, while most engineers appreciate good logic, they are never taught how to structure an argument. The end result is that when asked to write about their work, or to ask a question on a public forum, they hesitate.
One engineer I worked with would (eventually) write an email about a topic if I specifically asked him to, but would not react to responses or questions from community members. When I approached him, he would rationalise, say he hadn’t had time, or didn’t see the need to reply, or refer the questions to someone else. But as part of a pattern, I concluded that he was nervous about sending an email to a publicly archived mailing list. He was nervous about making a mistake, writing something he shouldn’t, overstepping some unwritten corporate policy, or felt uncomfortable expressing himself in writing. It doesn’t help that “bad netiquette” is often dealt with rather harshly, reinforcing the lack of confidence.
The only way to cure the problem is with baby steps.
A great first step is to get your engineers answering questions. One way I have found to help get this to happen is to publicly refer a question to an engineer on the mailing list, while affirming his expertise in the area. “Tommy knows the RLE algorithms inside out – Tommy, would you mind answering Franz’s question, please?”
This serves a triple purpose: an individual can easily ignore a question if it is addressed to a group, but it is a rare person who doesn’t answer when you ask them a question directly – it’s human nature; affirming your engineer’s skills makes him feel good about himself, and gives him more confidence; by identifying an individual engineer with a specific skillset inside your team, you are giving people outside your company a glimpse inside the walls – you are making your team human, a collection of individuals with different strengths and weaknesses, rather than an amorphous group – “the Acme Co developers”.
Another good step is to give a series of creative writing workshops to your developers. It is not enough to stand over people with a whip and ask them all to have a blog. First you need to get them in the habit of writing regularly. Since terse language, often in bullet form, is the norm for mailing lists, the goal is not to turn them all into novelists, writing perfectly crafted works of art. The goal is to get your team in the habit of writing.
Finally, you should train your engineers in basic netiquette and writing good email – there are lots of good resources out there, including Producing Open Source Software by Karl Fogel, The Open Source Way, the Linux Kernel Contributors Guide from the Linux Foundation, and ESR’s “How to ask questions the smart way“. Michael Meeks suggested to me that developers should treat writing email in a similar way to patches – when you generate a patch, typically the last thing you do before you send it is you check over it, to make sure nothing silly is included. Michael suggests that the same habit applied to email will identify any places where phrasing is awkward and ambiguous, resulting in better email.
Nervousness related to peer review
It is one thing to have engineers answer questions when they have the knowledge to do so. It is another thing to have them submit their plans and patches to a community forum and have them exposed under the harsh light of peer review.
On more than one occasion, I have heard a hiring manager say that he didn’t have time to have a developer go through peer review of specs or patches – after all, he was hired because he was competent to do the job, and what are we paying him for if he’s going to be second-guessed by “the community”? After a first job or internship, peer review is more an exception than the rule for professional software developers (regrettably, I might add).
In community projects, peer review is expected – in fact, it is a best practice, one of the things that separates successful community projects from the crowd. Developers expect to hear about features before they are developed, and have an opportunity to suggest better ways the feature can be implemented. They expect new contributors to submit patches that they can review – it is the way a new contributor builds trust before getting the keys to the house. It is such a recommended practice that the only treatment I can suggest is that you should help your developers to get over their nervousness & embrace peer review, by making it the norm in your team.
The best way I know to get people used to peer review is to have a company policy against the “day one commit bit” – the practice of getting commit access to the project repository on the day you start in the company. For corporate-sponsored projects, new developers should go through the same review process for their work that contributors outside your company have to go through.
For corporate contributions to community projects, that means discouraging internal branches and a “gatekeeper” project structure, where one or two developers commit the work of others in the team. Developers should submit their work upstream at the same time it is being submitted internally. For those changes which only apply to your internal branch, you should create a probation period when patches are submitted via an internal mailing list, and subjected to the same peer review you would expect outside the company. This is a hard change for many organisations, but one which is necessary to transition your team
to successful community contributors.
Having new developers go through this review period is important for a number of reasons – the most important is that you are demonstrating that employees have the same burden to prove themselves in the project as non-employee contributors, and it ensures that new employees have a period where they familiarise themselves with project coding & communication conventions & norms, and when they also introduce themselves to the community at large.
Communication & marketing are not my job
The developer I mentioned before shied away from the mailing list because he set a very high bar for himself on any public communications. In his mind, posting project plans to the mailing list was an announcement, and needed substantial preparation. In reality, most communities have a very high tolerance for things like spelling errors, incomplete plans (as long as they are marked as such) and other things which would be unacceptable in a press release or an official announcement. This is very definitely a case where Voltaire was correct: the perfect is the enemy of the good.
The developer was framing “sending an email to a mailing list” as “making an announcement”, something which fit in the “marketing” box in his head. One other developer I worked with once told me that he didn’t have time to send email to the mailing list because he had real work to do – “dealing with the community” was my job as community manager, as far as he was concerned.
Part of this issue comes from a general discomfort with written communications. But another part of it comes from the culture which is pervasive in most companies – only a small number of people get to talk for the company, and everyone else should just keep quiet. The authors of “The Cluetrain Manifesto” claimed that in the modern connected world, there is no such thing as a marketing department, that every interaction between an employee of your company and someone outside your company is an opportunity to win or lose reputation.
In free software development teams, this is even more true. There is no marketing department for project communications, and nor should there be. To be productive you need to talk to your peers, so the institutional barrier to external communications *must* disappear for people dealing in community projects.
It is all fine & well to say that this should be the case, but even if the organisation is clear about giving engineers a free hand to talk about their work, the engineers may impose limits on themselves, requiring proposals to be perfect before sending them on (which, of course, they never are). In fact, waiting until a proposal is finished is usually a lost opportunity, since by the time it is finished, there may be so much emotional investment in the proposal that making changes to it can be difficult. It is better to release a rough early draft, giving the author an opportunity to integrate early feedback.
The best way to prove to your team the benefits of “release early, release often” is to do so by example. As a team lead or manager, you can lead by publishing team plans publicly and early, and pointing out the benefits which result to your team. Breaking down this barrier will take time, but by making it clear that perfection is not expected, and by rewarding early release of information and encouraging feedback, your team will soon learn that participants outside your company are peers, not an audience.
Another useful technique is to ask your engineers to break tasks into smaller parts, so that even if they do hold off until the first part is up to a high standard, information is still getting out there more quickly, allowing feedback to inform later stages of the process.
However, another phenomenon is fighting against this desire for openness.
It is not uncommon for companies to want to keep their plans secret, so as to have a Big Reveal announcement effect at a major trade show. This can lead companies to ask their engineers to work internally on significant features for fear that the big surprise will be ruined otherwise. The alternative seems to be to announce a project when you start, rather than when you have something to show – but this can result in a long wait before products get to market, and impatience and bad press from the mainstream press.
I would argue that having engineers talk about design decisions & implementation details of significant features in a mailing list will not result in significant attention outside of your community – and when the press release and announcement comes, the community who knew it was coming will feel better about having been in on the secret from the beginning, rather than feeling worse because they have to deal with a big code drop which no one person can review.
The key lesson here is that you want your developers to feel a connection to people working outside the company. That requires people outside your company to feel a connection with them, too. By drawing the curtain on your team, its members and their skills & priorities, you are creating the circumstances for people to come to appreciate each other as peers, and to feel comfortable discussing features & patches on their merits. When you get to that point, you have already won – it’s impossible to be shy when you’re among friends.
7 Responses to “Curing “Shy Developer Syndrome””
- Drawing up a roadmap (June 6th, 2011)
- Effective mentoring programs (June 6th, 2011)
- Follow-up to “Shy Developer Syndrome” (December 18th, 2010)
- MeeGo report card (November 12th, 2010)
- GNOME Census report now available as free download (July 29th, 2010)