Werd I/O

I’ve been really enjoying Rick Klau’s series on OKRs. Rick worked at Google on Product and then at GV as Partner, and is now California’s Chief Technology Innovation Officer.

This week on OKRs as institutional memory:

In the absence of OKRs, an organization’s mistakes made and lessons learned are locked in people’s heads. New team members struggle to get up to speed with what the veterans already know; “this is the way we do things” can feel mercurial and opaque.

Last week on squirrels:

Is the idea related to one of the few things we’re focused on as a company? If we pursued the squirrel, would we make a meaningful impact on one or more of the metrics we agreed to influence? Does this squirrel matter, right now, to the work we’re doing?

On the danger of setting “true / false” OKRs:

What if you launched v1 of the product and it sucked? What if you develop a roadmap for some big idea and… nothing happened? The fatal flaw in committing to OKRs like these is that you can get a great score on the OKR when it’s time to grade yourselves, and fail to achieve much (or, worse: actively do damage to your organization).

The whole series is worth following and subscribing to. His blog is one of my favorite subscriptions, and if you’re a technology operator in any capacity, it’s a must-read.

Every job I’ve had has been a kind of dojo. At every position, I’ve had the privilege of meeting and working with a bunch of smart, interesting people; I’ve got to work on disparate products with real-world applications; and I’ve learned a lot about new markets and industries.

But they’ve also stretched me personally in important ways. Here’s one way of breaking it down, from the very beginning.

As a SysOp at Daily Information, I ran a BBS and later one of the first classified websites - but ended up doing lots of very different things that crossed development, computer repair, visual design, sales, and more. It was an idiosyncratic small business that was run out of a Victorian house in North Oxford and I loved every second. I learned to flexibly wear different hats and move from role to role to role as needed, as needed. For an introverted kid who was scared to talk on the phone, let alone make a cold call, that was a pretty big deal. (I learned how to make a pretty decent G&T, too.)

As a learning technologies developer at the University of Edinburgh, I learned how to explain complicated technical ideas to a non-technical audience. I was immersed in the web, and I quickly realized that my colleagues were not. Helping them through the new internet world became pretty important for them, and for me. I gave my first ever presentation here, and saw connections between the emerging web and the potential for facilitating learning that no-one else had seen yet. (I also hacked the cafeteria menu to get the lowest-cost possible meal and was banned.)

As a web administrator at the University of Oxford’s Saïd Business School, I learned about navigating corporate structures and helping advocate for agile ways of working. I became a go-to resource across the School for internet startup knowledge - by the end of my time there, MBA students were stopping by the IT department to chat with me.

As co-founder of Elgg, I learned how to bootstrap a business, build an open platform from scratch, seen an open source community, run events, do marketing, and more than anything else, how to identify assumptions and work from first principles. I had no idea about how investment worked or how to think about valuations; I had no idea about team dynamics or how to build a company culture; I didn’t know what user-centered design was; I wasn’t sure how to run a team remotely. I learned all of these things. I hired and fired my first person, and hated it.

As CTO at Latakoo I learned a lot more about leading a team and interfacing with non-technical management. I also learned about how to build for legacy industries - I’d done that in education, but broadcast television was a new universe for me. I helped build a pitch deck and give an investment pitch to investors for the first time. I also had my first VC experience on Sand Hill Road.

As co-founder of Known, I learned formal design thinking and user research. I built more pitch decks and investment documents than I ever had in my life. I gave design thinking workshops and learned how to be a formal consultant. And I engaged in acquisition talks for the first time - a very different kind of sales.

As a senior engineer at Medium, I learned about software development in a much larger team for a much higher-scale product. My software development skills were pushed much further than they’d been in the past. I worked with formal product management and had a very different class of problems to solve. And honestly, got over my nervousness and some of my imposter syndrome: chatting with Ev, who I held in very high regard, was initially terrifying. The people I worked with had been on very different, much more high profile journeys. I spent the first three months sleeping very little, but eventually decided that I belonged.

As Director of Investments at Matter, I had to become an extrovert. I took over a thousand startup pitches, sometimes over continuous twelve hour days. I taught design thinking bootcamps and held strategy opening hours for dozens of disparate startups. I attended industry dinners and tried to represent the organization well. But most of all, I evaluated the teams and business strategies for many, many startups run by all kinds of different founders; I read their legal docs and understood their structures; I evaluated founder mindsets; I got to know many incredible people. I invested in them, and was there for them as best I could. It was my first (and last) job ever that didn’t involve coding: instead, I was a human standing with other humans, using my experience to be the wind at their backs.

As VP Product Development at Unlock, I re-learned being a software developer, and learned blockchain decentralization for the first time. I coded apps that ran on Ethereum and attended industry events. I learned about DAOs and gas and all the rest of it. It transformed how I think about the internet - and I did it during some of the heaviest personal struggles of my life, so I learned (imperfectly) how to juggle these things, too.

As Head of Engineering at ForUsAll, I’ve learned a lot about the importance of culture and structure. I’ve managed a larger team than I’ve worked with in the past, and have navigated a variety of human issues that have been very challenging. I’ve also played the part of a formal product owner in a very different way, writing formal product specs, Jira stories, and sprint plans, as well as working with engineers to build new architectures and refactor technical debt. I’ve also learned a lot about how to think about cultural change within a larger organization: ForUsAll is on the journey from being a financial services organization to an empathetic, scalable tech startup. And on top of that, I’ve learned a ton about how finance works, and the underlying mindsets required to navigate a whole new set of legacy infrastructure and ideas.

Looking back to the beginning of my career, I wouldn’t have imagined getting to where I am now: the things I’ve learned have pushed and pulled me into a whole new person. I’m grateful for all of it, and I’m excited to keep learning. It would be a sad thing to join a team and not learn or be pulled in these ways.

I wonder if finding meaning is like finding your keys: it’s not going to come to you when you’re looking for it, but maybe it’ll sneak up on you.

I’m a little envious of people who have made religion a part of their lives: the cultural structures of organized belief seem to be aligned to help you create and find meaning. There’s a sense of spiritual laws of the universe that you can follow to understand what you’re meant to do while you’re here, and (depending on the religion) there’s a sense that there’s a whole other world when you leave this one, that potentially goes on forever. Earth is just a testing ground before your real life begins.

I don’t have religion, and I’ve struggled to find real meaning. The best I’ve arrived at is that I want to feel like I’m useful. I care a lot about equality and fairness, so I want to work on projects that make the world more equal and fair. I feel like centralized wealth is antithetical to those ideals, so I want to work in ways that share equity rather than allow people to hoard it. I believe that collectives and communities and more than the sum of their individual parts. The needs of the many outweigh the needs of the few.

A chronic self-questioner, I’ve re-examined this ethical philosophy over and over again, and found that it’s right for me. I do think it’s morally correct. But I also think there’s a certain amount of self-justification involved, too: as in, my feeling the need to justify my presence in the world. Why do I deserve to be here? Why should I exist? This ethical structure is one way I can answer that question and sleep at night.

But why should we need meaning at all?

Lately I’ve come to realize that I display classic signs of co-dependency. Most people don’t feel guilty for putting value on their own needs or asserting themselves; I do, and so do people who have been diagnosed as being co-dependent. Although the idea of co-dependency was originally developed through the study of alcoholism and substance abuse, I don’t have a history of those things in my family; instead, I think I came by it through over a decade of caring for my terminally ill mother, and from the intergenerational effects of the concentration camp.

My whole life, people have told me I was “nice”. It feels good. But it’s also the direct effect of not putting enough value on my own needs; of not being assertive enough. The feedback loop of being rewarded for being nice compounds the problem over time: although everybody who has ever told me this has done it with love and good intentions, it’s ultimately a reward for not being assertive.

I read Codependent No More, one of the classic texts on the subject, and although it’s frequently uncomfortably close to the bone, I also found it a bit wanting for my needs. It’s overtly about alcoholism, and is also far more religious than I am. It talks about getting to a healthier place through dependence on a higher power, and I simply can’t bring myself to believe in one. I wish there was something like a recovery program designed for people who don’t have that framework for meaning or belief in something beyond the physical universe.

Nonetheless, it was helpful. There was a passage that hit unexpectedly close to home, which talked about not wanting to end your life not because you enjoyed life and saw potential in the future, but solely out of guilt for its effect on other people. That is how I feel. It is not how I want to feel. I want to feel like life in itself is joyful and meaningful and worth continuing, and I just don’t. I want to run away from it, and find myself in some alternative mirror universe where there aren’t the same pressures and guilts and currents. I don’t want things to stay the same, and I feel guilty about change. I’m set in sadness like aspic.

Don’t get me wrong: I’m in no danger of hurting myself. I’ve had friends die by suicide, and I’m not interested in inflicting that pain on others. There is definitely an allure to ctrl-alt-deleting myself, but only in a vacuum, as a thought experiment. We’ve just got to keep swimming: there’s no alternative.

If we’ve got to keep swimming, and if the status is not quo, and there’s a dynamic I’ve identified that is inhibiting real change, then changing that dynamic becomes the paramount thing to do.

I need to work on myself, in order to undo my codependent traits and build a new bedrock of self-worth. (A major blocker: I find it hard to believe that you can both be a good person and put yourself first. I know, I know.) In parallel, I need to make sure I’m in a situation where I feel like the people in my life - all of them, in every facet - are looking out for my interests and well-being as much as I’m looking out for theirs. Transactional relationships, which are about what one party can provide to the other, are the enemy of healthy self-worth and well-being. They’ve got to go.

Then there’s this other question: who actually am I? If codependence has become a deeply ingrained part of my personality, which it seems like it has, what does my personality look like when I strip it away? That’s terrifying to me. What if it’s bad?

But what if it’s not? The single biggest piece of feedback I get at work is that I need to be more assertive and do better at holding people to account. There are real-world effects to holding back that go far beyond my own boundaries. Being an effective leader, or an effective anything at work, means setting boundaries based on your expertise and being clear about what’s needed. Being an effective and happy human being means setting boundaries based on your emotional and practical needs. Being more assertive - not being an asshole, but just having those boundaries and standing by them - doesn’t make you a worse person, it makes you more effective. In the right people, with the right relationships, those qualities build respect, not animosity. And the wrong people, the wrong relationships are just that: wrong.

Intellectually, I know this. The thing I need to work on is helping my heart, my nervous system, my cowardly lizard brain, to follow through. I know in my head that my needs are important; I also feel the adrenaline, the cortisol, the feeling in my stomach that tells me something bad is going to happen when I do.

It’s pathetic. I feel pathetic. Other people find this so easy. But that feeling too, the self-flagellation, has go to go. There’s a reason there’s a name for this; it’s a thing, a mental condition, a way of thinking, that people actively suffer from and have to work to get better from.

I’m trying.

I want to build things, and write things, and create and love and find joy in the small beauties of everyday life. I don’t want to feel like my life is sort of built like a trap and that I’m a bad person for wanting to escape it.

I know there’s meaning to be found; more than meaning, I’m looking for satisfaction and belonging. I want to know that it’s right that I’m here, that it’s okay for me to take up space, that I have value in myself.

I’m trying.

This is one of those pieces that probably very few people want to read: you’re here for open source and tech utopianism and how we can all do better on the internet. But this is how I figure out what to do, where I am, how to be; it helps me to put it down in writing. And if this resonates for someone, somewhere, and encourages them to look up the symptoms for codependence and find a way to health, or even just helps them feel a little less alone, then it’ll have been a good thing.

People in tech, in the workforce, in the professional world are still people. We’re all human. I don’t think it does any of us anything but a disservice to try and paper that over. If we put ourselves out there, we can build community, find help, share ideas, and do better together.

Not that I need to justify this piece or anything. Just so you know.

This is not really what it’s for, but I’ve been having fun building an interconnected personal website using Obsidian.

These are personal notes that anyone can read. So, for example, you can read my thoughts on the software development process, and also religion and nationality. Yes, it’s super-idiosyncratic, and it won’t be everyone’s cup of tea. But it’s been a long time since I’ve had any kind of homepage that isn’t a blog (my personal text adventure aside), and this is a nice way to go about it. Obsidian makes it really easy.

Behind the scenes it’s just a set of markdown files, so if I decide to stop using Obsidian or change the way I host the site, I can do that without fear of losing any data. But I’m happy to be using Obsidian Publish and Sync and to be supporting the project.

Also, Werd Cloud is a fun name, and I’m excited I got the domain.

Let me know what you think!

I’m posting Fairness Fridays: a new community 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 Montgomery Pride United. Based in Montgomery, Alabama, Montgomery Pride United hosts “support groups, supply emergency food, hygiene products, masks & clothing, facilitate community education, provide senior services, host sexual wellness workshops, offer mental health support, and accommodate community gatherings for progressive groups” - a much-needed service in the Deep South.

Its programs include an Emergency Resource Program that provides “resources for LGBTQ+ individuals in need of food, shelter, medical services, or any other help to ensure their safety, health, and stability”, as well as a grief and loss support group, support for LGTBQIA+ youth, a free pantry, and more.

On my journey across the US last year, Alabama was by far the most oppressively conservative place I visited. Providing these services is a vital lifeline.

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

Does my excitement outweigh my hesitations?

Who benefits financially or reputationally from my work?

Does this project have the potential, if successful, of helping me succeed in my personal mission?

Does this project make the world better? What does it meaningfully change?

How likely is it to succeed, given the top-down trends, the team, and available resources? Is it worth trying anyway?

Who is the user or customer? Can you describe them or picture them?

Is the culture of the team empathetic, blame-free, and inclusive?

Why was it started? For personal gain or something bigger?

If there are already people on the team, why did they join? If there are existing investors or backers, why did they make that choice?

Why me? Why this team?

Does this project fit in with my life and life plan?

Can I grow here? Can everyone?

Will I be happy and healthy while working on this project? Will everyone?

Will I be respected? Will everyone?

Is it financially viable for me? Is it financially viable for everyone?

Is this team equitable and diverse? Do the answers to these questions reflect this?

If working on this project replaces working on another project, are the answers to these questions markedly better on this one?

After asking these questions, does my excitement still outweigh my hesitations?

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