At the end of last week, I encouraged readers to ask me anything related to my work. I wasn’t sure if anyone actually would, but I was curious about what kinds of questions people had.

I got a surprising number of questions! So much so that I think I’m going to make it a series. Let’s open it up: you can ask me a question about anything, and I’ll do my best to answer in a future post.

Here are my answers to the questions I’ve received so far. Questions have been edited for spelling, punctuation, and grammar only.

Burnout is common in our industry. What is your approach to avoid or recover from burnout?

My take on burnout in tech is that it usually happens when we are disempowered to make decisions that relate to our workload. For example, if you’re a developer, it might be because you’re being asked to build something at speed with ill-defined specifications and an unrealistic deadline. (We’ve all been there.) Or you might have a dysfunctional work culture. Or just be completely swamped.

Those things go together: a company’s dysfunctional culture might encourage you to work over the weekend, or pressure you to make commitments to deliver something that hasn’t even been defined yet. It might feel utterly Sisyphean: you’re working hard at the best of your ability but the nature of the workplace or changing goalposts makes success impossible. This is incredibly common in dysfunctional tech workplaces where non-engineers are empowered to make decisions about engineering without deeply understanding the problem - often while declaring, “it should be easy!”

I’ve also found myself burned out because of external factors. Being a part-time carer for my mother, for example, was something I felt privileged to be able to do. But maintaining the energy to do that and a demanding job wasn’t always possible. (I always, for what it’s worth, prioritized my mother’s care.) For many people, just having to live in the society we do, with its biases and prejudices, can be a really legitimate source of burnout.

I always start by talking to my manager, if I can, about my concerns. But particularly in a dysfunctional workplace, it might be hard to achieve any change. My coping strategies have been threefold:

Immediate: Intentional breathing exercises really help. So does, well, exercise: either going for a run or a really long walk out in the world. I’ve also found that constantly having a book on the go has been really helpful; the act of reading is, in itself, meditative. There’s a reason I mostly don’t read books that are directly related to work.

Proximate: Take a damn vacation. Back when I lived in the UK, I would try to take three week vacations: typically I’d only start to really relax and decompress during the third week. In the US, which is a more psychotically workaholic culture, this tends to be frowned upon. So I always say to my team: know when your next vacation is. Not taking vacations isn’t a strength; it’s a character flaw.

Long-term: Get out.

I feel comfortable giving this answer in tech, which is the context the question gave, but I don’t take this privilege lightly. I know it’s not something everyone can do. But I’d rather have a sustainable position that doesn’t burn me out but pays less well than one that leaves me ragged and has a higher salary. I’ll do better work; chances are, I’ll do more mission-driven work, too. Like any dysfunctional relationship, sometimes it can’t be saved.

Check out Tricia Hersey’s Nap Ministry (and follow it on Instagram): it’s such a great collection of condensed wisdom, deployed to free us from the treadmill many of us have been conditioned to put ourselves on.

What do you look for in deciding whether a startup is worthy of investment?

I have to give two caveats here.

The first is that I’m not an active investor right now. I actually get quite a bit of dealflow, and I still have a small carry interest in Matter’s second fund. But I’m not making any new investments.

The second is that no startup is worthy of investment: it’s not a value judgment. There are plenty of startups, projects, and endeavors that are incredibly valuable, but don’t happen to fit a venture-scale investment thesis - or just one investor’s particular thesis. Because investment is an informed bet that a fund’s money will grow while invested in a startup’s equity - and not a grant, gift, or value judgment - everything comes down to how that investor thinks about becoming more informed.

I invested at a very early stage. At this point in a startup’s life, the thing that matters most is the team: who they are, what they’re capable of, and most of all, how they think.

I don’t care where someone went to school or what degree they earned, if any. (I feel the same way about hiring, for what it’s worth.) Their skills are important: I’m probably not going to invest in a tech company that can’t build software, for example, or doesn’t have domain knowledge relating to the problem they’re trying to solve. And their mindset is even more important than that. Can they identify their assumptions and de-risk them quickly, finding a well-defined core community to focus on first? Or are they quixotically ploughing ahead powered by blind belief, refusing to contemplate that they might fail, while declaring that “this is for everyone”? The latter mindset is really common and absolutely deadly.

I care deeply about societal effects and wouldn’t invest if I thought something was potentially harmful. I was also careful to source a pool of startups with diverse founders. Everyone was evaluated according to the same criteria. Nonetheless, a more diverse pool naturally led to a more diverse portfolio. Not only is supporting diverse founders the right thing to do, a wider set of perspectives can more effectively solve a broader range of problems.

And then there’s the big question: do I believe in the problem the team is trying to solve? Can they make me believe in it? Do I believe that other investors will also believe?

After that, there’s math, and there are logistics. Is the potential market size of the startup big enough to support the sort of financial growth the fund needs? Is the capitalization table (the list of who owns how many shares) clean enough to invest in? (Red flags here include people who are no longer involved in the company owning a potentially controlling interest.) Is it a legal entity that can be invested in easily - not just by me, but by future investors - and does it own all the IP? Are there debts? And so on.

This is a pretty narrow set of criteria. So it’s not that a startup is worthy of investment as such: it has to run such a tight gauntlet of restrictions that it just might not fit into the template.

Personally? I’m hoping to bootstrap my next startup. It’s genuinely nothing against VC: I’m just not sure I want to commit to a venture-scale market size, and I’m not sure I want to be beholden to investor commitments. Call me a control freak.

What’s next? (Big picture—technology trends)

There are a lot of trends I could be interested in. Here are some I actually am:

Ambient computing. Broad adoption of 5G is starting to mean broadband-quality internet in more and more places outside the home. These enable a new set of devices and experiences that go far beyond just the laptop / tablet / phone paradigms we’ve been tied to for decades. Moreover, as we move from one context to another, we’ll expect our services to seamlessly follow us. How do we build this future while maintaining personal privacy and freedom from advertising?

Human-centered data. The aforementioned future requires that all our data can be pooled together and kept under our control. We’re going to see an end to data that is locked up in silos belonging to individual services. A lot of investors call these customer data platforms because of the implications for commerce; I think the implications go far beyond.

Decentralization. Blockchain isn’t the trend: it’s a technology, in the same way that the web is a trend and CSS is a technology. Decentralization doesn’t need to depend on blockchains, although they’ve captured the zeitgeist right now because of the earnings potential. My interest continues to be in the potential to empower co-operatives, collectives, and other alternatives to centralized wealth and power structures. I’ve been a part of efforts to do this for as long as I’ve had a tech career; what’s super-cool is that mainstream interest it now enjoys.

The creator economy. There was a time, not so long ago, when I thought this was all about influencers, which I’m explicitly not interested in. But empowering individual creators - artists, writers, independent journalists - to make money on their own terms from their own sites and experiences? Sign me up.

And some trends I’m not:

Self-driving cars. Say it quietly, but I think this might be a red herring? I can easily imagine self-driving mass carriers though: think anything that has a set route along well-maintained roadways, like a bus, a sort of longer, rail-less tram, or a cargo truck transporting goods between distribution centers.

Machine learning. Again: call it a technique or a technology, but not necessarily a trend in itself. It’s too often described in magical terms that downplay the inherent problems both in its use and prerequisite data collection.

Audio rooms. See: Clubhouse, Twitter Spaces, whatever the Facebook thing is called. Someone took panels, which are the worst part of every conference, and turned them into a 24/7 product? Great.

VR. Maybe I need to be more of a gamer, but I don’t see this becoming more than niche.

What’s scary and what should we be doing about it? (Are we?)

Two growing trends genuinely scare me:

Global warming. We’re not doing nearly enough about this. Like many people, I’m worried about the focus on individual responsibility vs widespread industrial change. To be clear, both are necessary - particularly as we live in a representative democracy - but the onus of change can’t be placed on individuals over the industrial forces that are ultimately responsible for so much of the underlying pollution.

We’ve got to change the way society works, and we’ve got to make and enforce far stronger rules. A lot of global climate policy amounts to rearranging the deck chairs on the Titanic. And I think ideas like carbon trading just perpetuate the problems we need to solve. We need massive, government-led change, and we need it decades ago.

Rent-seeking. Just about everything is available on a subscription basis these days, with true ownership diminishing. The effect in housing is well-documented: generations of people are being more or less locked out of home ownership. But it’s also true in everything from software to cars. The effect is to create a stratum of wealthy property owners, whose property continues to expand and grow in value, and a much bigger one of less wealthy people who are forced to pay rent on an increasing number of things. The property owners get to set the terms by which their property is rented; the renters must abide by them.

We’ve always had a disparity in rule-making, where the wealthy held more of the cards, but it grows the more the gulf between property owners and renters widens. A lot of this situation has been enabled by the tech industry, VC-enabled business models, and the desire to maximize recurring revenue at all costs. I don’t see this trend slowing down, let alone reversing, but it only leads to widespread poverty and, with it, unrest.

What’s exciting and promising and what should we doing about it? (Are we?)

Decentralization! Renewable energy! Better mass transit! A move away from selfish individualism to a better collective future! Better societal infrastructure!

I’m also really excited about remote working. Being able to work in your own home empowers people who couldn’t necessarily make it to an office before; it also spreads wealth across the country and potentially across the world. Everyone’s comfortable with it after a year of doing it; in my opinion all of the reasons to go back into an office come down to personal preference rather than it being inherently better.

Consequently, when we look back a decade or so from now, I think we’ll find that tech companies which have embraced remote working after the pandemic will do far better than those that don’t. They’ll be more attractive, they’ll attract a broader set of candidates, and they’ll have solved communication problems that allow them to work more efficiently.

Do I want to go back to an office? I do not. And there are a lot of people who feel the same.

You once wrote a blog post suggesting that a 4th 'bubble’, sustainability, be added to the traditional design thinking bubbles of 'desirability, feasibility, viability’. I found this while researching Design Thinking for Social Innovation for a presentation I was doing. I explored it with the audience, themselves all heavily vested and involved in Social Innovation, but the resulting debate led us to the conclusion that if the existing 3 bubbles are used appropriately, then the 4th is not needed, and that between 'Desirability' and 'Viability', Sustainability is covered. My question is, have you explored this further in your work, have you since changed your perspective, and have you encountered further widespread support (for or against) your thoughts on this?

I agree that if the existing three principles are used appropriately, the fourth is not needed. That’s a big “if”. I think, in most cases, that it’s important to have a model to explicitly consider these issues. It’s possible to have a desirable, viable product that you can feasibly build - if you only evaluate first-order effects - that also has negative societal effects. Some teams understand that sustainability is baked right into desirability, viability, and feasibility once you evaluate how the product sits in its context over time; for others, calling it out directly as part of the model may be helpful. And it may not be possible for a product team to properly evaluate in which group they sit: some may think they don’t need it, while in reality they could still benefit.

In teaching our Designing for Equity session in the Google News Initiative / Newmark School / News Catalyst Product Immersion for Small Newsrooms course, Roxann Stafford and I talk about reframing from building a Minimum Viable Product to Maximum Distributed Equity. While this isn’t a direct continuation of the Sustainability idea, it lives on the same spectrum. It’s not that maximum distributed equity is the only lens you should use; it does, however, force conversations and design thinking that would not occur if you didn’t evaluate it intentionally. Some teams might think (and often say so, vocally) that they don’t need to explicitly consider equity; generally, they’re wrong. It’s something we all need to work on, and naming it helps us remember to consider it carefully.

Can you share your thoughts on where you see crypto going in the future and projects / possibilities to keep an eye on?

I see a few things as inevitable:

Moving away from proof of work. Possibly legislatively. These algorithms, and their environmental effects, are absurd. Great proof of concept, well done, now let’s move on. I think proof of stake is a great v2, and I’m sure there will be something better in the future.

Stronger smart contracts. Again, Ethereum was a pretty fantastic proof of concept here. But let’s keep an eye on Algorand, Polkadot, and others that are pushing the envelope of what can be built.

Privacy. I don’t see a network that is completely public as being desirable. Privacy is a prerequisite for democratic freedom.

Blockchain as part of a delicious, decentralized breakfast. Right now, as described above, blockchain is often considered to be the trend in itself. It’s just one decentralized technology; it wasn’t the first and won’t be the last. It also has enduring limitations. We’ll do more off-chain than we do on-chain, and making that more seamless will be part of building the decentralized future.

Should I code indieweb or fediverse protocols?

Yes.

Longer answer: it depends on what you’re trying to build! The indieweb and the fediverse are two complementary ideas. Both are sets of protocols that allow people to communicate with each other from their independent websites and platforms. Neither is a monoculture. So I don’t see it as a debate: start with the experience you want to build for the user, work backwards to figure out the best way to build it, and go from there.

"Specialists know everything about nothing, generalists know nothing about everything". Should person attempt/claim to be a full-stack developer+ops+dba+tester, or welcome specialists within a broad team/community/church? In my opinion we should foster mutual co-ed training to raise cultural awareness without claiming expertise in every field. What ever happened to brown bag lunch sessions as bite-sized learning?

Speaking as an unashamed technical generalist:

My answer to most questions about engineering approaches like this is that it comes down to the human context. There’s the perfect situation, and then there’s the one you’re actually in.

So the answer to this question depends on the organization you’re a part of, and what you’re trying to do. In a larger company, you’re more able to have people who occupy specialities and can go deep on those. In a smaller one - let’s say a three-person startup - you’re forced to be a generalist, whether you like it or not. It’s not so much about what you claim to be as what you have to do in order to get the job done.

Given this reality, should there be cross-team collaboration and learning? Absolutely. We should do better at that as an industry. As an engineering leader, I should also be better at doing this within my own team; in all honesty, I haven’t found a way to effectively replicate brown bag lunches / continuous group education in a remote context, and it’s something we all need.

I am guilty of debugger-based development to muddle towards an eventual solution. Is there any hope for this repentant sinner?

You’d be surprised which engineers write code by using console.log all over the place. Just do what works for you. We all code differently, and coding sucks for everyone. Wear it proudly.

That said: I can’t overstate the utility of automated testing. It’s not a fun habit to get into, but it’s so much better than having to go back and add them later on. You don’t need to engage in test driven development (where writing the tests comes first), but you really should write those tests. Every language you write in has a test framework; use it.

Patterns and interfaces = good, over-engineering (ability to change DB etc but seldom required) = bad. Newbies always overwork the latest read/fad instead of pragmatism. Do cyclomatics etc help dictate the tipping point?

Pragmatism is learned, and the opposite comes from nervousness. The solution is not to apply more metrics to force the issue, in my opinion. It’s about laying out good team / project principles.

Engineers often overlook the “soft stuff”: team principles, coding culture, communication, and conveying why we do things. They’re crucial. The non-deterministic aspects of engineering are at least as important as the algorithms and data structures. This is one of those questions: how much abstraction is too much abstraction? The answer will vary depending on the needs of the project you’re working on.

If there is a hard and fast rule, I think it’s around readability and flexibility of architecture, and speed of execution. Abstractions shouldn’t interfere with ease of comprehension: too abstract and you may have to learn to play four dimensional chess just to figure out how it all fits together. Not abstract enough, and you may find your architecture is largely defined by the structure of external services or libraries. There’s a sweet spot in the middle.

Finally, of course, spending your time on building abstracted interfaces that you don’t have an obvious use case for is just yak shaving. Ship that code.

Should you be a polyglot language speaker [coder] or accept that your favorite language/framework/OS/protocol/Db is good enough to meet your requirements?

Again, this is a fuzzier, less-deterministic question than it appears. It depends!

You should use the best language for fulfilling your requirements. Probably, that’s the language you already know rather than one you need to learn. At the same time, not everything is interchangeable: Ruby on Rails is not like-for-like with Node, for example. They work in different ways (one’s a framework, for one thing), and therefore some tasks can be done better with Node than Rails. They have different ecosystems of libraries and supporting documentation, and so on. Whether it’s worth switching to a technology you’re not an expert in yet depends on how much better it’s likely to be.

Nobody can be an expert in every language and framework, so there’s always going to be some level of shoehorning requirements into what you already know, and there’s always going to be some level of learning something new.

An unsatisfying answer if you’re looking for something deterministic, perhaps, but it’s an insight into why programming is both super-fun and terrible.

There are many open source software packages but the huge time it takes to assess whether they’re good/bad/ugly is largely wasted. How do you find the right package before you build? Then how do you best keep it updated [or replace it] without finding yourself in dependency hell?

First assess: do you need an external library to begin with? Every addition does create a dependency. The story behind left-pad is a great example of why care is needed.

Then it’s about social proof. Who wrote it? How many people are using it? When was the source code repository last updated? Is it active or abandoned? Is the maintainer a jerk? Are there reviews or tutorials on the web?

Don’t forget to assess if the license it’s distributed under is compatible with your project. Are you legally allowed to incorporate it?

This kind of due diligence takes a little time, but it’s worth it. And a little friction means you don’t end up adding libraries to your code without thinking about it, which is probably a good thing.

As for dependency hell: there are plenty of useful tools that can keep your projects up to date. As a GitHub user, I like Dependabot, alongside its dependency graph tools. I’m not even remotely interested in keeping my dependencies current manually. Who has the time? But this is another reason to maintain robust automated tests: because an automated update could break your code, it’s important to have a test suite that Dependabot (etc) can test its updates against.

...

Those questions were fun to answer. I’d love to do this again in a future post; ask me anything at this link and I’ll do my best to answer in the future.