#3 Keep it Short · Async Work · Fast Feedback
Keep it Short
So the other day I interviewed this guy for a technical role, I asked:
"In your CV you say that you setup the CI & CD infrastructure while working on project XYZ. Tell me about the technical tools you used."
I was hoping to get a concise 1 minute answer ending in "do you want me to go into more detail?". What I got was 5 minutes of monologue, 2 of which didn’t even touch on CI & CD infrastructure, another 2 that half-answered the question and then another minute of waffling before it finally fizzled out.
I have interviewed over 60 people in the the last 18 months, I am usually the technical interview and/or in the semi-technical process-leadership-communication interview (I know have a proper name for it). In both I'm probing for pretty much the same:
Self Motivation & Responsibility - which roughly translates to ownership (in my mind at least)
Effective communication
Technical Knowledge
The difference in the 2 types of interviews is merely what I focus on and how narrow or wide the technical questions are.
Asking good interview questions, questions that produce meaningful indications about the candidates capabilities (ownership, communication, knowledge) is damn hard. I never formally learned how to do that, pretty much no interviewer in my organization did. Some of us got a little help from HR, for example we learned to ask behavior questions using the STAR method (at first they seem like BS, but when used correctly they bring out a candidate’s strengths by dissecting their experience). However as an organization our interview skill has room for improvement.
That makes it kinda hard for candidates. They are nervous and interviewees are always in a weak position. As an interviewer I want to uncover the strengths of each candidate, but our weak question and their weak position combined with a 60 minute time limit - how accurate do you think our output is?
In these difficult circumstances the single biggest mistake I see is: candidates talk too much.
As interviewer I try to focus the conversation, to help the candidate hit the on the right points and then stop. But I can only do so much, after 2 or 3 times it just seems rude to cut people off. Even if I am trying to help them. If I do it too much candidates become timid - they don't feel safe anymore and lose confidence. Recovering from that is near impossible.
So I accept that my organization and I have a lot to improve in terms of interviewing. While we do that: do yourself a favor and don't talk too much. Check yourself before you wreck yourself.
Asynchronous Work - Write it down
This week Basecamp’s Jason Fried writes that remote work is a platform. The key takeaway is: porting a workstyle from the old platform - office work - does not use the full potential of the new platform - remote work. Most office processes kinda work over slack or zoom. After 6 months of remote work I’m still learning how to leverage remote work to its full potential. Basecamp has a head start on us, they wrote the book on remote work after all. So I tend to trust them more than say middle managers that never worked / managed remotely.
One attempt to be effective via remote work is the modus operandi of my architecture team (I mention them in #1 and #2). An excerpt from our last memo:
Our work is asynchronous in nature.
We collaborate through writing.
We use the bi-weekly meeting for discussion and as a heart beat.
We coordinate all other work via slack.
Emphasizing asynchronous communication and writing is what will allow us to work distributed across teams, “offices” (well homes) and time zones. This is not an original insight - but last week it clicked in my mind. I hadn’t quite understood that yet.
Synchronous communication works well enough in an office. But it sucks remotely, because it doesn’t fit the remote work platform. Asynchronous communication (long form writing) takes full advantage of the remote work platform.
Jeff Nickoloff, author of Docker in Action (a great book), concurs: He advocates for long form writing, he even thinks it is a key ingredient to successfully scaling Amazon.
An edited excerpt from the interview (full transcript in the link):
If you want to do anything with a high degree of consistency, it has to be written down. At Amazon it came down to long-form writing. If there is something that they need to communicate, they do it using long-form writing. They'd talk about their "one pagers" or their "six pagers" or "Jeff Bezos' memos to shareholders”.
Long-form writing means: a single document that has enough content to allow the reader to think critically about that content. It doesn't have to be long. You can have long-form writing on a single page, if you can think critically about that subject matter in that page.
So this is something that Amazon does for everything. We wrote a couple of six page documents:
This is how to write, to communicate at work.
This is how to read to communicate at work.
This is how to manage using long-form writing as your medium.
I believe that helped Amazon scale. Because they're able to communicate en masse with high fidelity and asynchronously. Which is really remarkable.
He also puts power point slides in its place:
I see the things that slow people down, when they communicate using PowerPoint slides. They don't say anything. It's basically a cave painting, right? It's incredibly low fidelity, a raw construct. They get a little bit from the orator. But ultimately the author/presenter is hoping that the audience shares enough background context that they can understand what's even going on. The dirty little secret is: the audience speak so little because they don’t know what's going on most of the time.
It's almost a completely useless medium. Presentations are for sales. I don't mean that in a bad way, because the way people make purchasing decisions is very well-studied. It has absolutely nothing to do with merit, it's all about emotional appeal. If I can think of one thing that you should never do internally for a company, it's make decisions based on emotional appeal.
To put it all together: if you work remotely you need to work asynchronously in order to be effective. To communicate asynchronously you have to write it down, you have to master long form writing.
Fast Feedback
Let's talk about software quality. We strive to develop quality software, sometimes succeed, often we fail. Why is that?
The one principle that affects software quality significantly is fast feedback. Feedback underlies many of the generally accepted “best practices” (← horrible wording, but that’s a rant for another time): testing, static analysis, design reviews, code reviews, continuous integration, continuous delivery, acceptance criteria in requirements, small diffs, incremental delivery, etc.
Accelerating these feedback loops almost inevitably increases software quality - more testing identifies more bugs, smaller diffs facilitate better code review, continuous code review (aka pair programming) avoids rework, early design reviews avoid design mistakes, defining executable acceptance criteria before development starts avoids miscommunication (“we didn’t want this”).
On the other hand if we turn it around, if we slow down feedback we run into problems. Here are a few examples from recent memory when we lacked feedback and that resulted in lower quality:
Team A estimates 1 week of effort (based on optimistic assumptions) without checking with team B who they need to integrate with. Months later team A and B get together and clarify, now team A's effort looks more like 5 weeks. The outcome: the system is not functional.
Pull requests with weeks worth of development (more the 10,000 lines of code) - a lot of effort & pain to merge. A lot of code remains unreviewed (because it's just not feasible). The outcome: slower delivery, more bugs
No unit tests. The outcome: more bugs
No functional testing. The outcome: more bugs
This is enough anecdotal evidence to formulate a hypothesis:
More and shorter feedback loops in the development process deliver higher quality software
Side note: you can read the 4 statements in the agile manifesto as advocating for more & faster feedback.
So if you are facing quality problems instead of asking “how can we avoid this bug?” ask yourself “how can we accelerate feedback cycles?” instead. The former question often leads you down the new tool or new process route. The latter allows you to evaluate your existing processes and practices. Most of the time it’s not about introducing a new tool or process. It’s about getting more out of existing processes.
Hyperlinks
The Hiring Post - Why hiring is broken and how we can work around the broken system. Nothing much has changed since 2015.
Hacker Laws - A list of “laws” in software, you’ll find the typical suspects (leaky abstraction, Parkinson’s, Moore’s, Conway’s, various razors, etc.) but will surely discover new ones.
Alex Hillman on the Frontmatter podcast - Alex is a fun interview to listen to, from building a co-working space to educating the next generation of small internet business owners. I love his advice on starting a business: Audience comes first, product follows from audience.
Len: Let's say someone has an idea for a book they'd like to write. What should their next step be?
Alex: Your next step should be to write down that idea and then stick it in a drawer and forget about it. Because that idea [..] is not helpful to you or your audience.
Instead [..] figure out who you are best suited to create things for.