Werd I/O

The more distributed a team gets, the more important great communication becomes.

Distributed can mean many things:

• Geographically - not in the same place
• Temporally - either not in the same timezone or on the same schedule
• Organizationally - the organization might have grown to a point where people aren’t organically all working with each other anymore, or areas of focus are otherwise disparate
• Philosophically - areas of work are so different that there are entirely different mindsets, contexts, and modes of working at play

In most cases, it’s likely to be more than one of the above. For example, a team that works remotely is geographically distributed, may be temporally distributed, and depending on the size of the organization, may also be organizationally and philosophically distributed.

How do you stay on the same page with a team that has one or more of these properties?

A synchronous communication tool like Slack can be useful in some circumstances, but there’s a ceiling to the help you can get from it when people are in radically different timezones. Similarly, it’s hard to hop on a meeting to hash something out with someone who’s six hours offset from you. It’s not that you can’t talk - but you have to plan to do so.

Even without that temporal distribution, it’s interruptive to use synchronous tools. This is where philosophical and organizational distribution comes into play: they may not say so, but if you interrupt an engineer to have a quick meeting several times a day, they will be quietly plotting your demise. Their way of working requires long periods of deep focus in a way that some other roles may not. You’d better make sure those synchronous meetings are planned and predictable.

The truth is, every team is distributed, even if they’re in the same room. You can even think about temporal distribution as looking back at work that was done six months ago: you can hardly have a Slack conversation with your past self to understand what on earth you were thinking.

Luckily, we have a centuries-old method for sharing information across time and space. There are two important verbs to consider: reading and writing.

Writing is a core skill for everyone on every team. Being able to lay out your ideas, reasoning, and intention in complete sentences with empathy and depth isn’t a nice-to-have: it’s the only way to convey your thinking in an enduring way. Diagrams and illustrations can be additive, but aren’t a replacement for a well-written description. Similarly, rough notes don’t cut it: you might think they make sense in context, but months down the line, the context is stripped.

Reading is also a core skill. You can write all you want, but if that documentation is simply falling into a void, it’s useless. Active reading - the act of reading with an intention to understand and reuse the information - is a skill that every knowledge worker needs to develop.

Both of these skills must be intentionally developed as part of the culture of the team. A culture of thoughtful reading and writing as a natural part of building a product reduces dependence on interruptive, expensive synchronous communication, improves mutual understanding of the work being undertaken, and provides space for reflection on the approach before diving into execution.

As part of a software team, I believe each of these is an important written document:

• The product spec - a concrete, human-centered description of what the product is through the lens of the real people it’s being built for, what their problems are, and why this product will be effective in solving them. This document is designed for feedback from business teams and the engineering team that will be taking on the work.
• The engineering spec - a description of how the engineer intends to go about building it. This includes the technical goals, but also the non-goals: what’s intentionally being left out of the build. This document is designed for feedback from other engineers and the product team.
• Stories - concrete descriptions of atomic pieces of work, derived from the product spec, with well-defined acceptance criteria. These stories may embed illustrations or designs, but an illustration or design is not a story. Stories are usually wrapped up in an epic, a kind of meta-story that describes the arc of the work.
• Tasks - descriptions of the individual engineering tasks involved in building a story.

Each of these is designed for an audience in order to solicit feedback, which will then be used to improve the description; more feedback is sought, and so on. Iterative loops of feedback, testing, and improvement are the core pattern of software development.

Not everyone is a natural writer, or will be a native speaker of the written language of the team. Reading lots of documents with different structures also undeniably carries a cognitive load. Templates can help here: pre-defined headings and document structures that allow authors to fill in the blanks if they need to, and allow readers to more quickly find the information they’re seeking. In teams I run, I always make sure there are templates and examples to choose from.

In a tiny team, you can often get around having this level of description: you talk about it, you do the work, you check in with each other organically. But as the team becomes more distributed, this becomes less possible; context is lost and inefficiencies grow between the gaps. You can’t have everyone checking in with everyone all the time. Nobody would get anything done; meetings with lots of people are expensive; synchronous meetings tend to favor extroverts.

Like all elements of team culture, it’s important to intentionally create it early: the culture you create at the beginning will inform what happens when you grow. Because this inflection point is an inevitability in a growing team, setting a culture of strong asynchronous communication and documentation early will prevent problems later on. Like all elements of culture, that means you need to intentionally hire for it, intentionally train for it, and intentionally lead by example.

Photo by Lagos Techie on Unsplash

I am not looking for a new Head of Engineering position right now. I’ve been approached both directly and by a number of executive recruiters, and I’m flattered, but I’m not considering opening a process with any new companies.

If you’re looking for an advisor or board member on tech, product, or startups, I am potentially open to help in that way on a part-time basis. I’m mostly interested in mission-driven organizations, and need to be careful to avoid conflicts of interest.

Thank you!

I don’t think the web could happen again.

A public-minded developer, operating in a public service research institution, built an open knowledge-base with no eye on profit or even productizing it. Because of its openness and simplicity, it spread to other like-minded researchers, and then beyond. It wasn’t a product or a startup or a business, and nobody tried to build one around it until much later.

The foundations of the web are pure. And they changed the world.

I wonder what kinds of conditions would need to be true for another platform to be built in a similar way? Lots of people have tried, but none of them have the purity of participation for the love of it that the web has. Even Tim Berners-Lee’s own subsequent attempts are a startup.

Why have we lost that community-hacker sensibility? How can we get it back?

One answer might be that we don’t have the right kinds of research organizations. TBL’s work at CERN was kind of a fluke that happened at the right point in the development of personal computing. There are design organizations, and R&D organizations, but all of them are looking to productize. There’s nobody just jamming on openness platforms with significant institutional support.

Imagine if he’d built the web while trying to test the principles of product design. Desirability: well, who knew if anyone would use the web? Where would that kind of user research have taken him? Viability: it was inherently unviable; just a server living on a NeXT box. Feasibility: who on earth would think that a global hypertext network is feasible? Instead, albeit with a great deal of thought, effort, and skill, he just did it.

Did he hope or expect it would make him a billionaire? No. Did he hope or expect it to get major traction in the way that it has? Also no.

I love startups; I do. I enjoy watching people make things that serve real problems and turn them into sustainable flywheels. But not everything has to be a business, or financialized in any way. Those things are not prerequisites for impact or success. They’re just one way to go about it. The web shows us that there are others, and that purity of thought and intention go a very long way indeed.

My friends at Shady Pines Radio are running a fundraiser to cover their costs for 2022.

It’s been really fun watching Callie and Brian build this station. When they moved to Portland a few years ago, they converted the basement of their house into a recording studio; as well as recording a bunch of really great live music performances, they’ve been running an independent radio station with an eclectic mix of independent DJs as a way to connect the independent music scene during the pandemic. (Disclosure: my sister runs a weekly show featuring new independent artists, which reminds me a little of John Peel’s old BBC show. You should check it out.)

I spend a lot of my time immersed in startups and high-growth media endeavors; Shady Pines Radio is a labor of love, more a community than anything else. It’s all put together with a high degree of professionalism and skill, but also with obvious passion. I’m really inspired by what they’ve built, and how they’re continuing to build.

One aspect of this has been music licensing. It’s an independent station, but it’s not pirate radio: everything is fully-licensed and above board. That takes a fair amount of money, which is funded by the community (hence the fundraiser). Not only is it honest, it’s pure in a way that most media startups could never hope to achieve.

Before the pandemic, they ran a series of events - open mics, shows - that were popular gathering points. The pandemic made that impossible, but it’s been great to see how they’ve taken their skill for community organizing and brought it online. All the things you need to do to bring people together in real life translate very well to the internet. The tools are different, the communication is remote, but the people and connections are very much the same.

I’m listening right now. Hit the Play button on the website to join me, or grab the apps for iOS and Android. And if you like it, maybe knock them a few bucks?

This is what makes the web so special: communities led by people out of love. Callie and Brian’s work makes me really happy, and is an example of why I’m still in love with the internet.

‌‌I’m posting Fairness Fridays: a new social justice organization each week. I donate to each featured organization. If you feel so inclined, please join me.

This week I’m donating to HealthRIGHT 360. Based in San Francisco, HealthRIGHT 360 provides “integrated medical, dental, behavioral health outpatient and residential treatment, and re-entry services” regardless of cost in 11 counties across California. Particularly during the ongoing pandemic, this work is vital.

It describes its mission as follows:

HealthRIGHT 360 gives hope, builds health, and changes lives for people in need. We do this by providing compassionate, integrated care that includes primary medical, mental health, substance use disorder treatment and re-entry services.

A growing number of agencies are part of the program, including the Lyon-Martin Health Services and Women’s Community Clinic, which provides “primary medical care, sexual and reproductive health care, and mental health services for women, gender non-conforming people, and transgender people of all gender identities and sexual orientations”.

I donated. If you have the means, I encourage you to join me here.

This year I’ve directly hired for lots of different engineering positions and skillsets: in particular, Ruby on Rails, React, DevOps, and QA. In the process, I’ve read through thousands of resumes. Some patterns and anti-patterns have become clear.

I can’t speak for any other Head of Engineering or recruiter, but here’s a short guide to getting your resume noticed by me. Perhaps these ideas will help you with other people who are hiring, too.

Your resume is a story about you.

I’m a real human being who will read your resume from top to bottom. I’d love to understand a little about you before I dive into your history: in particular, what’s driven you in your career so far, and what you’re looking for from your next position.

It’s best to avoid clichés. “I’m passionate about building high quality software as part of a dynamic team” doesn’t tell me anything at all. On the other hand, “I’m excited about cryptocurrency’s potential to disrupt centralized finance” or “I’m concerned about the widening wealth gap and want to work on projects that help the underserved” both speak volumes. Don’t be afraid to be specific and personal.

I hire for mindset as much as I hire for specific skills, so the more I can learn about you, the better. Are you empathetic, a great communicator, a team player, ego-free, and excited to grow? Those are things I really want to know.

It’s got to be legible.

Any good story needs to be read. That means using clear language with complete sentences, set in a layout that’s easily parsed.

In left-to-right languages, left-aligned text is easier to read. Pay attention to your typeface, line height and headings. You don’t have to be a designer, but keeping your layout consistent, simple and readable demonstrates attention to detail. Similarly, you don’t have to be a great writer, but full sentences and easy-to-follow text demonstrate clear communication.

By the way, I don’t mind how you set your resume up. Most people use a word processor, but I’ve seen plenty of LaTeX typesetting, and I’m always impressed when I see well-written HTML. Whatever works for you is great.

Use as many pages as you need.

Some people ask for a one-page resume. I’d rather you took the time and space you need to represent yourself well. If it’s five pages long, I promise I’ll read all five pages (as long as they’re relevant).

I always follow your links.

Whether you’re using HTML or have sent me a PDF, I’m going to follow any link you give me to demonstrate your work. The more the merrier.

I don’t care where, or if, you went to school.

There are some people who specifically look for a “top 20” school or a prestigious CS course. I’m not one of them.

Particularly in a world where college costs tens of thousands of dollars a year to attend, only some people can take this journey. Even if you have the money or can get a scholarship, you might have had to be a carer for your family. Or you might just have taken a non-standard path through life. Why would I penalize you for that?

I care about what you can do, not whether you’ve conformed to an approved career path.

Don’t worry about “culture fit”.

Culture fit is one of the pervasive, bad ideas in tech hiring. Instead, I like to ask the question: what new perspective will this candidate bring to our team? If you can convey that in your background or work experience, that’s fantastic.

I like context.

A list of skill keywords doesn’t tell me much. Some candidates draw a little progress bar next to each one to show their relative proficiency; that tells me a little more, but it also feels like a character sheet from some technology-themed roleplaying game. It doesn’t let me know how you’ve used those skills.

After your introductory description, the work experience section of your resume is the most most important. I’d love to understand the work you did at each position, and this is an opportunity to discuss the technologies involved. Please do namecheck them here, but do it as part of a description of what that work involved.

I’m not an algorithm, and I’m not keyword searching your resume. I am interested in the technologies you’re proficient in, and how you used them in context. Again: tell me a story.

Finally: skip the photo.

Some people like to include a photo of themselves to give their resume more human character. I appreciate the thought, but please don’t do this.

I don’t want to select candidates based on what they look like, and no employer should. For the same reason, I typically like to conduct interviews over voice, not video (except for pair programming sessions, where some video sharing is necessary).

It’s about how you think and who you are, not how you appear.

*

Looking for an engineering position? ForUsAll is hiring. We’re looking for Ruby on Rails and DevOps engineers, as well as product managers and a host of other roles.

To illustrate why geographic ecosystems are important, I used to tell a story of three cities. It went something like this:

I founded my first startup in Edinburgh, Scotland. At the time, there was no startup ecosystem at all: there was no money, and no culture of support. Everyone told us, “it’ll never work; why don’t you go and get a real job?”

The second startup I joined was founded in Texas. There, it was possible to raise money, and everyone was super-enthusiastic. But there wasn’t a ton of local knowledge, and expectations from investors about involvement in an internet startup were not clear.

The third startup was founded in San Francisco. There, there was money, enthusiasm, and a ton of deep knowledge.

The story had a satisfying sort of Goldilocks and the Three Bears structure, but here’s the thing: while it may have been true back then, when I experienced those things, it simply isn’t today. It also misses some important nuance.

Let’s take them in turn:

Edinburgh now has a pretty decent, if small, startup ecosystem. There’s money, expertise, and a few success stories (FanDuel and Skyscanner are two). There was always a deep computer science community centered around the university, and they’ve done a good job building an entrepreneurial culture around it.

Austin, Texas is now considered a startup hub. It’s got a rich seam of investors and tech talent, and industry people are moving there in droves. (The company I joined over a decade ago, Latakoo, is doing well, too.)

And San Francisco’s startup story is well-documented, but the depth of expertise is a double edged sword: it has been less welcoming to startups that want to take an alternative funding route, or that sit outside of established patterns. Its success has led to a degree of conformity, unfortunately, and rapidly rising costs have made it inhospitable to the communities that defined its culture, including its anarchic hacker scene.

We’ve all become familiar with working remotely - something I’ve personally done for over ten years of my career - and as such, our geographic centers are decentralizing. Founders can find support and investment, as well as an experienced team, from anywhere. There’s no need to pay a premium or to go without needed expertise.

Today, if I were to tell that story, it would be far different. There’s no need to be in San Francisco or anywhere else. All that matters is how you execute on your idea.

I think about this when people talk about Miami as a blockchain hub, as they’ve been doing for a while. Yes, there will be some interesting events on the beach there if you’re into that space. But there’s no need to live there. You can be anywhere, and anyone who says otherwise is trying to sell you something.

For me, the smart move is to find somewhere nice, with a diverse community of generally-progressive people, low property values, great food, and good transit links. Make your base there; put down roots. And then use this incredible global communications network we’ve all built - this “internet” thing is really worth checking out - to stay in touch and build communities with people all over the world.

San Francisco? Miami? Austin? Edinburgh? It doesn’t matter. Pick what makes sense for your lifestyle and values, and work from there.