Leading a technical community as a non-technical community manager Leader: Austin Smith with Singly Session 8, Sunday, 2:00 PM Andy Oram, note-taker The challenges of being non-technical in a technical environment: Never to pretend to know something you don't, but do explain what you know. Take on things the technical people don't want to do. Don't want to turn the technical people off because they're afraid they'll have to train you too much or you won't understand them. Hang out with the technical people, and Don't admit you're not an expert. You can't say "I'm not technical," but you can say you're not a programmer, not a developer, etc. Preserve the right to talk about the technology. There's a point where you're technically knowledgeable enough to be dangerous. Useful to listen to the complaints and ideas of the technical staff, even if managers complain that you do it. Technical people respect you when they try to do the things you can help them do, such as organize an event. Remember you add value by doing outreach, etc. Train the technical people that they can't ignore users because they seem too stupid to understand the web site. Getting the respect of developers: Keep a dialog going; each side has something offer. Important to genuinely like the engineers you deal with. Be willing to listen and understand as much as you can. Example from another field: somebody working for a football team came into their gym to work out. Not only got respect from the team, but she made the team feel more comfortable with their own struggles. Developers may be hypersensitive, being used to having their friends outside the field complain that they're talking about things the friends don't understand. They have a hard time believing that someone outside their field is interested. Besides talking to the technical people you work with, keep up with their field: read the blogs they read, etc. It's good to understand their excitement when an important release comes out, for instance. How can you get hired at a technical firm without a technical background? What you've done is valuable on its own. But there is a problem with human resources, which ask for arbitrary buzzwords and filter out people with the soft skills community managers specialize in. Community management means different things in different places, so still kind of a vague profesion, but there is a set of skills you need. Many jobs are never advertised, but created to use the skills of someone internal. It's valuable to speak the user's language, and the organization should understand that. Good to find developers you can talk to freely and whose technical knowledge you trust. Helps you focus on the areas you're good at and feel secure that the technical matters will be handled. Someone you can pass technical problems on to. Beware of people being in the zone, try not to interrupt. Send an email, don't just walk in the door randomly. It may take them a long time to get their systems set up and put their minds in the framework to do their work. Know each developer's skill set, so you can point one developer to another who is appropriate to answer a question. Don't send a person directly, but be the go-between so that a busy developer can choose when to interact. Spend time with them at the time that they're comfortable: probably not nine in the morning, but more like between eight in the evening and midnight over pizza and beer. When you talk to developers, ask for the same answer that they would give to someone at their technical level. If they dumb it down, it may come out wrong. Instead, they should start at the level they'd normally talk at, and then interrupt them as necessary and ask them to explain. Often developers are bad at explaining what their project does and how it's used. (Don't say how it works, but what it does.) You can be valuable by getting them to explain that clearly, and it affects what they do in their technical work. Also, you begin to grasp the terminology. (You can do a web search for it later.) Engineers can also be shy about asking questions when they don't understand something, and you can be the person to get the explanation. Some organizations are more congenial to start with; the engineers are helpful toward each other. Other (often older) organizations hold on competitively to information (not normally a problem in open source communities). Popular TED talk: The Power of Vulnerability. Need to admit your lack of knowledge in order to grow. Technical writing (such as blogs): best to interview someone knowledgeable, ask for the background you need, and go back later to fill in gaps. If you do ask a technical person to write a blog post, offer them some bullet points to get them started. Let them know it can be simple: what the project does and how they made it work. If the technical people can't review your posting before it goes up, send them the link later and fix things in the published posting. In fact, asking for a review ahead of time can hold it up indefinitely.