Wikia

Community Leadership Summit Wiki

Managing a technical community as a non-technical person

Comments0
178pages on
this wiki



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.

Around Wikia's network

Random Wiki