I'm back from an unexpected, last-minute week in Boston. It was my first chance to practice, in person, what I've been doing online for my colleagues: teaching. It turns out there's a need for technically-minded people who can write, communicate, and share their knowledge.

This is something I needed to see in person.

Career-wise, I've been facing a bit of a conundrum. There's a saying in the Drupal community that is well-meant but can be unintentionally disparaging: "talk is silver, code is gold." It's a good and humorous saying, and serves as a reminder that you can talk all you want, but it's the code that matters...

Except when it doesn't. 

If you're successful at convincing businesses and individuals to use what you've created, you need infrastructure to survive. It's possible, albeit rare, for a phenomenally gifted programmer to be comfortable providing one-on-one support, or to write documentation. It's possible, albeit a waste of resources, to have the original programmer doing migrations; true, they know the software better than anyone else, but wouldn't it make more sense for them to spend their time bettering their code?

Enter people like me.

Am I a programmer? Maybe. Depends on your perspective. Can I do it? Yes. Am I great at it? Not really. I've described myself in interviews as "more persistent than gifted," which I believe is both an accurate as well as fair assessment. What am I really good at?

Bridging the gaps. Teaching. Synthesis.

Last week, I focused on training our new staff in two areas that matter: technical knowledge, and customer care. Correctly intersecting the two makes for an amazing support staffer:

It's easy to miss the concept of 'care' in a technical support job, because the focus is so frequently on knowledge, knowledge, knowledge. It's what our new staffers think they're asking for when they say, "How do I solve this problem?" They focus on "solve the problem" and forget that the customer sees the "how," as well.

Everyone's encountered the tier 1 drone who doesn't perceive rising frustration in your voice, your email, or your support request. Even if they solve your problem, you're well aware that they don't give a damn whether or not it's solved. Worse, for companies: they might solve the immediate problem and lose the customer.

Erring on the other side doesn't help much, either. You can rant to your mom about the fatal error you just can't fix in your code, and while she might serve you up a truly tasty slice of pie, she's not actually going to be able to help you fix the problem. You'll get a hug, but not a solution. Comforting in the short run, but not useful in the long run. (Disregard this paragraph if your mom is a support staffer.)

If I do my job well, I'm seeking to combine the best of both worlds. Imagine reaching out for technical support and reaching someone who:

• Correctly assessed the nature of your problem.
• Correctly assessed your level of technical knowledge, and neither insulted you nor talked over your head.
• Understood whether or not your problem was urgent, and took that into consideration while working on your problem.
• Had a good grasp of the platform or system being worked on.
• Knew the limits of their technical knowledge, did not attempt to bluff past their limits, and brought in additional help when the problem's urgency or complexity dictated it

Teaching knowledge is easy. Teaching self-awareness in a technical support position is devilishly hard; it requires a staffer to be hungry for more knowledge but aware of their limits. It requires the company culture to embrace 'knowing what you don't know' while encouraging the employees to fill in the gaps.

Teaching it to support staffers who are supporting an actively-developing open-source software package is teaching them to do it while aiming at a moving target.

'Knowledge' is easy to teach. 'Urgency' is a cast-iron bitch.

* * * * *

I've wrestled with the ramifications of this teaching for some time, and much of it can be condensed down to a reaction to the "talk is silver, code is gold" mantra. In my case, though, I tend to focus it through the lens of the Support department. The traditional path is normally to ascend through the tiers of support as one's knowledge grows, becoming ever more technical and close to the code.

I am increasingly uncertain if this is my path.

In our company, we have two tiers of support, but they break down differently than in most companies. The tier 1 crew in my company consists of front-line staffers with a great deal of autonomy and leeway; if they can completely solve the problem they've picked up, great. There's no script, no pre-programmed moment of escalation. The tier 2 staffers tend to have more focused and specialized knowledge; I've said (with a great deal of truth and a minor amount of levity) to some customers that the difference between T1 and T2 in this company is a master's degree.

I look at T2, and I know that I'd like to be there. I enjoy solving problems, and I've earned my front-line stripes. I'd like to broaden and deepen my problem-solving skills, but as part of the process of doing so, I've sunk my teeth into two aspects of a problem I find deliciously complex: building up new hires and ensuring they have the technical documentation they need.

Not only am I interested in it, I'm good at it. If I could get past my pesky fear that choosing that path is somehow lesser, somehow not-gold, I think I could find peace with it. For myself, I want to broaden and deepen my knowledge ... and then have the freedom to pass along that knowledge.

I'd like to be the rising tide that lifts all ships.

We're working internally to sort out what can be done to make this happen.