This blog contains whatever random tech stuff I'm thinking about recently. And a lot of conference reports.

Hacking scared humans

A manager I had years ago had a tremendous skill for matching people with projects that were juuuust a little harder than they thought they could do. If he'd just left them to sink or swim, that could have been disastrous, but he supported them through it, and everyone invariably went up a level in skills and confidence. Having benefited from that many (many!) times, I always try to pay it forward. 

If you've got someone who already believes they can learn, providing support for a difficult project is easy: you might just need to point them at resources, publicly endorse them, and send them off in the right direction. But often you have folks who don't believe they can do the thing.

Learning can feel risky.

For someone who feels insecure in their position, it's terrifying to spend a bunch of time on work that produces no output. It's safer to keep doing work that will show that you logged the hours.  And for folks who are used to interrupt-driven ops work, sitting down to read or tinker for a few days feels downright unnatural. 

Many times I've had this exact conversation with SREs with sysadmin backgrounds:

"I need to start coding"
"Yes, you do"
"I will start coding"
"...next quarter. I'll take on a side project".

But next quarter comes, and ... what? They didn't get an extra two days in their week. It's hard to learn something new in a spare hour here and there in between your day job. You need time to psyche up and then you need a good run at it, or it's not going to happen.

As a tech lead, there's a lot you can do to help people learn. You can sometimes trick people into learning things they don't think they can do. Here's three techniques that have worked great for me. 

1) Setting up a time and place. When you've got a teammate who can't get a foothold on a thing, set up a two hour meeting with them (after making sure they will find it helpful and not mean!) and book a conference room. I aim to make it a couple of days in the future, enough that it fits into their mental planning. Then we go sit in the room together and they close email and IM and work on their thing, and I noodle on a document or something (or do whatever thing I'm procrastinating on. I use these three hacks on myself all the time :-) ).

Something about having designated time makes people not feel guilty about not doing all the other things that are clamoring for their attention. By the end of the two hours, they usually have enough momentum on the thing to keep going.

2) Busywork projects to get past the anxiety. I had a colleague whose job description involved coding but who didn't believe in his gut that he could do it. I asked him to help me out. "I need to make some changes to this codebase, but it doesn't currently pass lint checks. It's going to be a pain for the code reviewer to separate the functionality changes from the style cleanup. Would you have a couple of hours today to fix the whitespace, maybe change a few variable names, whatever the linter is complaining about. Make sure the tests pass before sending it for review, obviously, but it should all be a no-op."

This is kind of tedious work, but it's useful, and it doesn't take much effort to psyche up to it. After he'd gotten his fingerprints all over the code and built and tested it a few times, he mentally 'owned' it enough to start adding functionality. And soon he'd logged enough lines of code that his brain had no choice but to believe he could do it. (And I went back to doing my own cleanup work :-) ). I've used this technique in a bunch of other contexts too, like getting people to lead a small meeting or ask another team for something or present something low stakes as a stepping stone to doing it when it's needed.

3) Out of band reviews. When someone's insecure, it's the *worst* to send out code or documents or whatever to the whole team for review. Even sending a group email can mean hours or writing and rewriting to say it exactly right. You can give your anxious colleague hours of their life back by volunteering to do early review. 

These days I'm super comfortable being like "hey, Kristina, can you explain static initialisation to me like I'm five?", but when I started learning C++ a decade ago, it felt devastating to not know things, and I didn't even know what I should go learn. I loved having colleagues who would quietly look at the code before I sent it for real review. And I've done that for other people's code, designs and documents more times than I can count. 

Early review can also give you a chance to give your teammate pointers to things they will find useful. One great review I got while learning C++ was "This will work, but it would be better with a callback. Here's a good tutorial for how callbacks work. Let's talk after you've done the tutorial and I can answer any questions you have". This was amazing for me. Callbacks were a complex topic that I wouldn't have waded into on my own back then: it looked like hours of learning without a guaranteed reward. But someone saying "this thing will be useful to you in this situation" and offering to answer questions was exactly what I needed to go up a level right then.

In each of these cases, it takes more of your time than if you just handed the project to someone who could do it without thinking. And sure, sometimes there's a time crunch and you just need the thing done. But this kind of investment brings your whole team up a level, and it pays off very quickly.

"You really don't know what feigned surprise is?"

Delegation means not answering all the questions