I’ve been a technical leader since we started conceiving of the Elgg project back in 2003, twenty years ago. Back then, I didn’t know much — about leading teams, about running startups, about building projects — and I had to pick it all up from scratch, sometimes inventing processes and ideas from first principles. In fact, there wasn’t much of a startup scene in Edinburgh, Scotland, when I started my career, so almost everything I did was either from first principles or from what I’d read.

Since then, I’ve worked for startups and non-profits based in San Francisco, Austin, and New York City. I lived in the Bay Area and was steeped in Silicon Valley culture for over a decade. I’ve learned about building culture from very smart people while working at companies like Medium, as well as from the companies I supported when I was the west coast Director of Investments at Matter Ventures. Matter both taught me a formal framework for human-centered product design when it funded my second startup, Known, and gave me the opportunity to pass on that knowledge to startup founding teams and newsrooms when I joined the team. Later, I helped teach inclusive product design with Roxann Stafford as part of the Craig Newmark Graduate School of Journalism’s Product Immersion for Small Newsrooms program.

All of this is to say: I’ve had to figure out a lot, I’ve learned a lot, and I’ve had the opportunity to have some real wins and losses, and all of this has led to a theory about what works and what doesn’t work when you’re leading a technology team.

Everything can be split into two categories, so the joke goes, and sure enough, I’ve noticed two main schools of thought. I think these are well-illustrated through a real-world example drawn from one of the places I worked.

At this particular, unnamed startup, I joined as the engineering lead, but in reality was the de facto CTO. Everything technology-related rolled up to me, and I found myself in countless meetings about company strategy, often late into the night.

I learned very quickly that the previous technical leader had made a particular choice when he hired for his team. He noticed that engineers with poorer communication skills were not being hired by other companies, even if their technical skills were strong. So he decided that he would over-index on technical skill and deliberately not hire for communication skill. That way he could hire what he considered to be stronger engineers more affordably.

He had left the company and they’d had trouble finding another technical lead. The engineers had essentially kept the lights on by themselves, writing code at a furious pace to keep the entire company afloat. Technical debt had built up and built up, and they were spending most of their time on maintenance. They were often re-directed to work on new tasks and pet projects when old ones hadn’t been finished or well-documented. There was next to no testing, either through automation or with users. Meanwhile, the rest of the company complained that the engineers weren’t productive. There were suggestions that code output be measured, or that the team move to one-week sprints to — I am not making this up — make them write code twice as fast. They were great humans, but they’d been placed in an impossible position without the tools that could possibly hope to lead them to success.

Every aspect of this was counter to my own intuition. I took a step back and had some productive conversations with an old boss, who ran technology at a much larger and more successful startup. He confirmed to me that he would have made different choices every step of the way (and helped me feel a little less like I was insane).

One school of thought, then, is this code-led, metrics-driven approach: management by spreadsheet. The other is a qualitative, human-centered approach: management through empathy. A central question is whether you prioritize the things you can measure (lines of code, minutes of engagement in the product) or the motivations of the humans involved (the needs of the people who use your product and the people who build it).

I’m closer to the second camp. The map is not the territory.

My approach to technology is holistic: someone at that same company described it as “supporting the whole engineer”. How could it be anything else? Everybody brings their whole self to work, whether it is acknowledged or not. If you lead a group of people who are engaged in any directed endeavor, whether it’s building software or organizing an event, the experience of being a part of that group has to be intentionally designed. At work, we call that “company culture”, although it’s really community-building: every team should be thought of as a community of human beings who have their own creativity, intelligence, skills, motivations, and preferences.

The output of a technical team is not code. Code is a means to an end, and is only one part of the complete breakfast of tools needed to bring a project to completion. Measuring code is not a good way of figuring out a team’s ability to be successful. While code is likely integral, the job of an engineer is to engineer a solution, not just to be a programmer. That means you’ve got to have a lot of very collaborative human skills; we call them “soft” skills, but perhaps we should think of them as “software skills”, because you really can’t write software without them.

Contrary to popular belief, most people are not coin-operated. It’s not about money (although they need to make enough money). Everyone wants to make progress on meaningful work, in an environment that makes them feel valued as people, and where they feel like they can succeed. I’ve mostly worked in startups, and I like to tell people that although these environments aren’t a Google with kombucha on tap and on-site gyms, they’re opportunities to try lots of different kinds of work and bring more of themselves to work than you might at a much larger company. I want everyone who’s been on one of my teams to look back ten years later and think, I’m really glad I was on that team, because it gave me confidence to be myself at work and helped move my career in a way I care about.

The bottom line is: people who feel supported do better work. Or, as professors Sigal Barsade and Olivia A. O’Neill put it in Harvard Business Review: employees who feel love perform better. In a medical setting, their longitudinal study showed that a strong emotional culture had the following results:

Employees who felt they worked in a loving, caring culture reported higher levels of satisfaction and teamwork. They showed up to work more often. Our research also demonstrated that this type of culture related directly to client outcomes, including improved patient mood, quality of life, satisfaction, and fewer trips to the ER.

It’s impossible to achieve this on a team that focuses on metrics over motivation. It also makes diversity, equity, and inclusion a business imperative: if the only people talking in a meeting, having their ideas heard, or receiving accolades are managers, and particularly if those managers are predominantly white men, will everyone else feel supported? Or will they tune out and feel like they’re not valuable members of the group?

I think even the words we often use in software development don’t serve us well, at least if we don’t consider why they’re there and why they exist. The goal is to create, maintain, and improve a project together, as a community of people, to meet real human needs, in a way that also satisfies the goals of your community.

Some examples of terms that are bad when left unexamined (and I think should probably be changed):

Documentation sounds like the driest thing possible. But we’re not writing a manual for the hell of it. We’re leaving signposts in the code that explain why we built something this way, how it works, the context behind its creation, and most importantly of all, who you are writing it for. Code is never self-documenting, because it can never tell you who it is for and why it exists. One might (might!) be able to follow clean source code, but you’ll never be able to understand the hopes and dreams of the people who made it, which are crucial for understanding the choices that were made in the past and how to continue to maintain the project.

Specifications are a subset of documentation that sound like bureaucracy. What I think is important is that, when you’re embarking upon building something, you take a step back and reflect on what you’re about to do. It’s good to get social feedback on your intended approach, but I think the personal reflection is the biggest value. These don’t have to be super-formal, but should be clear enough to be (I’ve had engineers literally yell at me: “I just want to code!” But after a few times going through this, they’ve all seen the value.)

Retros are, again, reflections. It’s about creating a space to learn what could have been better. A team’s processes are prototypes that are never too precious to be improved; sometimes individual team members need to think about how they felt during a project, and how that might have been better for them. If a project didn’t go well, it’s worth thinking about what the definition of success was, whether they had the tools to achieve success, and what might make a similar project go better next time. Standups are mini versions of this: about learning and supporting the engineer, not reporting back to managers.

Coding standards also sound like bureaucracy. But they’re there to help engineers make decisions about how to write code so that it’s usable by other people in their community. If everyone in a community is writing code the same way, the cognitive load to understanding someone else’s work is much lower. It’s a way of helping other people to understand what you’ve done more quickly.

We could go down the list — and maybe I will in a future post — but it’s clear to me that technical team management has fallen into a metrics over motivation trap that looks at hard numbers over experiential stories. That’s been a trap in technology overall: teams are more likely to do quantitative research rather than truly get to know the people they’re trying to help and learn their stories. The truth is that while some of the tools of the trade are drawn from math and discrete logic, software is fundamentally a people business, and the only way to succeed is to build teams based on great, collaborative communication, human empathy, true support, and mutual respect.

In turn, that means that I look to work in organizations that have those things (and in particular, mutual respect). It’s much harder to change an organization’s existing culture than to establish great norms in a new one — although it is possible, as long as management is on board.

I’ve rarely spoken about my work directly in this space, but I intend to do more of it over the next few weeks and months, including practical examples of techniques I use. If these topics are interest to you, and you haven’t yet, sign up for my newsletter.