Work On Good Ideas

Despite what some people might want to believe, there is such a thing as bad ideas. In the context of building valuable ventures, bad ideas are typically bad in a few ways:

  • they’re trivial to implement — ideas that are easy rarely become valuable. Peter Thiel presents this argument as “Competition is For Losers”.
  • they’re wrong, either because they’re built on a misunderstanding of reality or faulty logic. For example, most recent ideas to use blockchain are based on a grossly oversimplified understanding of its benefits without understanding its drawbacks. The early-internet mantra of making up losses on volume (apocryphal though it might’ve been) is an example of faulty logic. Regardless, in this case, humbly remember that you don’t know everything and you could, in fact, be wrong.
  • they’re a marginal improvement in the best case. Even if successfully implemented, these ideas result in incremental improvements (measured in single- or low-double-digit percentages), often for a small audience (tech-literate knowledge workers and people with lots of disposable income are common examples). This is probably the most insidious and pervasive type of bad idea in the modern tech industry, especially because it’s often easy to hypothesize an ideal-although-unlikely world where the idea actually changes how something fundamentally works.

Last week, my team at work launched Disrupt Tech, a blog and community aimed at unsticking our industry from the allure of bad ideas. We see too much capital and talent wasted on incremental problems (like optimizing ad click-throughs) and also-ran products, while there exist big, real problems to be solved. While Trustwork is attempting to solve some of these problems, there are many more in the world, and we want to see more people working on them.

Disrupt Tech’s north star and manifesto is below:

Technology was supposed to make everyone more productive, unleash creativity, and bring abundance to the world. But at some point, we lost our way. As an industry, we’ve gotten caught up in our clichés and euphemisms and forgotten what it means to create real value.

The modern technology era began in the late 1960s, when popular culture collectively envisioned a future of space travel and valuable computation for everyone, and companies like Fairchild, Intel, and descendants kicked off the race to build that future. The subsequent decades ushered in a Cambrian explosion in hardware and software, unlocking world-changing innovations in communication, manufacturing, biology, and countless other fields.

The 90s saw the rise of the Internet, the foundation for an “information superhighway”, a nascent ideal that would’ve enriched the lives of every citizen. Instead, people decided it was more important to build warehouses to deliver pet food.

Since then, the internet has brought massive opportunity to more than 3 billion people, and fundamentally changed the lives for many of the 2 billion who carry access in their pockets. Yet we’ve seen massive amounts of capital and human talent directed towards incremental improvements, made-up problems, and tools for other techies. Our best talent isn’t working on real tech problems that could unlock massive value for most of those people — there is much more we can do with the internet than A/B test ad clickthroughs or build glorified chat apps.

We think our industry has gotten stuck in a rut. But we don’t think it has to be this way. Every day we talk to incredible workers who’ve figured out ways to work effectively and live abundantly. We see examples of human ingenuity, as well as people who want an outlet to express that creativity and build products for the rest of the world. We believe that technology can be a a life-changing tool for billions of people, and, in the hands of great people, we’ll figure out how to continue advancing humanity. And that is why we’re on a mission to disrupt tech.

Cover photo by freddie marriage on Unsplash

Evaluating Work Opportunities

Recently, I spoke with a friend about job opportunities. I briefly shared with him my framework for deciding between companies, which I developed during my job search last summer. I want to expand on the questions and the thinking behind them — as far as I can tell, this isn’t common knowledge, and perhaps someone else will find it useful.

The framework centers around three dimensions, two which look at the upside (trajectory and potential), and one to cap the downside (sustained damage).

As a example, suppose it’s 2018, and you’re looking at a (entirely hypothetical) company called Basebook — a social network for baseball fans. After a few rocky years, they recently raised a bridge round, hired a “professional CEO”, and are starting to find some traction. MAUs have been growing 20% each month for the past six months.

This post assumes you’re evaluating work opportunities that provide meaningful ownership or profit interests (via stock options, RSUs, stock grants, etc), and that you could live adequately on any of the offered salaries. This post is intended to be a thought experiment — it is not financial advice, and I’m not a financial advisor.



This framework should be used in the final round of your decision-making, once you’ve made sure that all your opportunities address your table stakes. These might include:

  • Location
  • Team culture, and whether you’d enjoy working with the people there
  • A path for the kind of growth you’re looking for
  • Salary — enough to allow you to pay off debts and eliminate (or at least mitigate) existential anxiety


Trajectory looks at how well the company has been doing — it takes into account both the magnitude of the growth and how quickly it happens. Trajectory matters in both the growth of the business (customers/revenue/profit/cash flow), as well as growth of the product (shipping rate and value of what is shipping).

Interpreting these metrics will depend on the nature of the company. For example, strong growth in users may be a good thing if there is a clear path to monetizing users, or if there is a strong funding environment for user counts, but may be a neutral or negative signal if it comes with high CAC or a cautious funding environment. Similarly, a company might be generating little profit, but it’s collecting large amounts of cash up front (and presumably reinvesting its free cash flow). In the product dimension, a slow shipping cadence usually isn’t a good sign.

In Basebook’s case, the user growth trajectory appears promising. However, without other clear signals, it’s difficult to attribute clear value to that signal — MAUs on their own don’t necessarily lead to monetization. The rocky early years might be a negative sign for trajectory, if they were spent making bad decisions or pursuing misguided ideas.

If the trajectory on any dimension is flat or flattening, that’s a strong negative signal. Instead, look for accelerating progress. For smaller companies, it may be the case that many metrics are flat or humbly linear while one or two important metrics are accelerating. That may be a good thing — it’s a sign of focus.


How big is the company’s opportunity? This is different from asking how big the company’s market is — it should take into account the competitive nature of the market and the dynamics of customer acquisition. A market crowded with competitors, or one with difficult-to-reach customers, will likely cap the amount of the market any company could capture.

Alternatively, a company may be able to expand its market by rethinking the laws of economics and consumer behavior (example: Spotify) or the laws of physics (example: SpaceX). If the company can execute well enough to capture that growth, that can be massively valuable. A company may also be able to expand into other markets (usually adjacent, but not always) — Amazon is a classic example.

For Basebook, the market likely isn’t very large; the number of people who are baseball fans and want to use a dedicated social network is likely small. In addition, the fundraising market for social networks has cooled considerably, and user growth without profitability isn’t likely to be able to attract more funding.

Sustained Damage

I believe that companies sustain damage as they age. Most of it is self-inflicted; sometimes it’s external. Damage might come from specific decisions, faulty decision-making frameworks, or poorly handled events. Of these, faulty frameworks are the most insidious. It’s difficult to spot a systemic pattern of bad decision-making, except in hindsight (often when trajectory has already been impacted).

Signs of bad decision making include a lack of zeal or clarity, especially when asked about goals, direction, or the rationale behind goals or direction; a hesitation to make and commit to decisions; and problems that persist without apparent progress in resolving them. In fact, sustained damage, at first glance, usually looks more like systemic stagnation rather than outright negativity.

It’s possible Basebook sustained damage during the early years, especially if it wasn’t able to develop a strong culture and execution discipline (indicated by hiring a “professional CEO”). Furthermore, a bridge round usually leads to significant dilution, resulting in what you, as a potential common shareholder, would likely consider sustained damage as well.

There’s More to Coding than Just Writing Code

For most of my life I firmly believed that a Computer Science degree wasn’t necessary to work as a software engineer; there exists a massive amount of resources and practice opportunities to learn outside of the context and cost of a university degree. I maintained this perspective even after I ended up getting a CS degree, partly because of the lack of practical skills in a typical CS program.

I still don’t think a CS degree is a requirement, but more recently I’ve realized that it’s a very good proxy for a baseline of skills and ways of thinking. If nothing else, a CS degree indicates that someone has spent a lot of time understanding software patterns, becoming familiar with a range of patterns, and developing the basic abstractions necessary to understand more complex problems.

This post is based on observations from my personal life and interviewing junior and mid-level engineers for work. I taught myself to code in high school from a few books, got a CS degree along the way, and continue to refine my software thinking through higher-level books and videos. I work at Trustwork, a seed-stage startup in San Francisco with four engineers. For the near future, we’ve made the choice to prioritize shipping speed over harnesses and processes to train very junior engineers; at our size we don’t believe it’s possible to be great at both. This perspective underlies this post. This post is not intended to be specific to any technology, language, or library. This post doesn’t split semantic hairs — I use the terms code and software, developer and engineer, etc interchangeably. 

Understanding Software

At a first approximation, learning to code simply means learning to write code — the act of manual code generation. The much more valuable component is learning to think about software. In my experience, the latter is almost completely overlooked by existing resources.

The former approach conflates the skill of coding with the act of typing code. This approach generally consists of a rough project description, code listings, and descriptions of what the code literally does. The teaching approach is essentially “write this code, in the right place, and you’ll have a working project, which means you’ll understand what we did”. Success comes from carefully following instructions, and understanding rarely happens. The outcome for going through this form of training is someone who is very good at rote syntax pattern matching, someone who is good at putting network calls in the relevant framework-provided method and filling in boilerplate.

Admittedly, a lot of software is little more than boilerplate, but that’s a different topic.

Pattern-matching on syntax breaks down as soon as the syntax or framework looks unfamiliar. Instead, being able to pattern-match concepts and abstractions is much more valuable. For example, both snippets below represent a network request, even though they look very different.

Put differently, concepts and abstractions are the vernacular of software. As with human languages, an intuitive understanding of constructs and slang are a core part of being a native speaker.


Building Software

Syntax pattern-matching facilitates building up: writing software from a foundation to successively higher levels of abstraction. For each layer, the developer can take advantage of an intuitive understanding of the layer below because she just wrote it. She understands the abstraction, and can therefore make progress.

However, this doesn’t work if she’s asked to build down: plugging code into existing use cases or implementing an interface. During our interviews, we test this by showing candidates a code snippet and describing its intended behavior, and asking them to implement the API being used to make the code snippet work. Candidates who do well here are able to identify the functional concepts in the code snippet, as well as the potential seams in the stack of abstractions where they can insert their implementations. In other words, they’re comfortable being dropped in the middle of a stack of abstractions and building both up and down.

Thinking about Software

Beyond building software is building great software. There are many ways to define great code (elegant, clear, performant, well-documented, etc), but producing any kind of great software requires thinking about the code both granularly (perhaps in picking the best name for a function) and abstractly (perhaps when refactoring for readability or better performance).

Across the spectrum, this can only be done with a deep, intuitive understanding of both the application code at hand, and the breadth of existing software implementations and developer expectations.

A deep, intuitive understanding is characterized by simplicity — the hallmark of such an understanding is the ability to explain the subject in one short, clear sentence. It comes from wallowing in the complexity, understanding the subject one line or short chunk at a time, pattern-matching ideas and abstractions, until the whole subject becomes something you can hold in mind all at once. You can inspect the idea from different angles, zoom in to confirm details, and use it as a building block to understand a bigger subject. Some would call it grokking the subject.

Bonus: CS as a Common Language

Credit to David Ko for this line of thought

Practicality aside, the traditional CS topics form a common foundation and vocabulary when talking about software.

For data structures, a deep, intuitive understanding of how strings, arrays, hashes, and sets covers 99% of the code we write. A “deep, intuitive understanding” might be defined as being able to implement each of those data structures and some of their common functionality using the primitives of a language like C (where there are no existing standard library to hide behind).

For algorithms, I think being able to evaluate performance is more important to knowing how to implement any of the traditional ones. This means understanding what Big-O represents, and, crucially, choosing the relevant N. This also means knowing common latencies to within an order of magnitude, and being able to identify bottlenecks in an implementation.

👉 If this resonates with you, we’re hiring and would love to hear from you. Details here.

Photo credit: Fabian Grohs on Unsplash

Personal Lessons from Taking Over SXSW

I just got back from taking over SXSW with Trustwork. It was an exhausting eight-day marathon, complete with an air mattress in the office, questionable food, and hundreds of rejections a day. I wouldn’t want to do it again. Despite all that, it was a fantastic experience, and I’m really glad it happened.

For reference — Trustwork is essentially a jobs marketplace, backed by professional profiles for each user. It’s like the marketplace of Craigslist plus the reputation of LinkedIn plus the on-demand aspect of Uber. For the past week, our team of 20 stood on various street corners in downtown Austin giving out a variety of free stuff in exchange for user signups, one at a time. Most days were 10+ hours across a day shift and night shift; at our best we were sustaining over 200 signups an hour.

Our five giveaways, which played into a scavenger hunt with a mystery box at the end


At some point on the second day, rejections started feeling normal. When someone said no to a free bag, it stopped feeling like a personal failure; I’d simply move on to the next person walking over. This was due in part to a natural detachment (more on this below), but mainly my track record — I knew that every few minutes, someone would come along who would say Yes and sign up. All those rejections in between were simply part of the process to getting to that Yes.

To be entirely fair: we had a signup goal each day, but we didn’t have anything personal on the line. We weren’t being paid per signup, or per day. We didn’t need to get Yeses so we could afford food or shelter. But none of us wanted to let the team down, and unlike hired/outsourced teams, it was our company.

Beginning with day three, I kept a personal rejection quota in mind — my goal was to get at least 200 rejections (an arbitrarily-chose number). I didn’t really keep track during the day; it was intended more as a way to prime my mind than an actual goal.

At some point I realized that the people passing by were only rejecting what I had to offer. It wasn’t personal; they were saying no to “free shirt?”, not me. This led to a natural detachment made it easy to de-personalize each rejection.

I spent time working each giveaway station, and came to see that the rejection rate varied dramatically based on the item and positioning. Free pizza and cupcakes were easiest. Free photos (akin to a mobile photo booth) were the hardest; we fell flat, and axed the idea halfway through the first day. (Photo booth was later resurrected as the hardest-to-find item on the scavenger hunt, to greater success.)

Finally, sometimes the rejections were downright funny. A sampling:

  • To “Free photo?”: “I can take my own **** photo”
  • To “Free cupcake?”: “I ain’t eatin’ that shit!”
  • To “Do you have a phone [for free pizza]?”: “No man, I lost it last night tripping hard on acid”
Free cupcakes drew crowds

Personal Interactions

Sometimes, a Yes turns into a great interaction, in a variety of ways:

  • People have interesting stuff on their phones. Typing in “tr”, some brought up Trump results. Others surfaced a search for “trust fund baby”. Adult content, unsurprisingly, made an appearance as well.
  • Sometimes we’d ask people to add a profile photo. Many people took selfies on the spot, and posed in a variety of ways. Occasionally, they’d want to take a selfie with us. After one particular photo I took with a guy, he said “dang, you look like a damn model!”
  • The first step in our signup asks for a phone number. One guy saw that we were successfully exchanging pizza for numbers, asked us for an empty box, and proceeded to go around trying (unsuccessfully) to get phone numbers until I asked him to do that somewhere else.
  • A few days in, a group of guys came by and said “You guys are legends!” They’d gotten the free cupcakes, limo ride, and shirt, and told us that Trustwork made them think of “hustling entrepreneurs”.
  • Free pizza and free limo rides offered to a late-night crowd led to some interesting interactions. Details are left to the imagination.
  • I found myself matching the volume and mannerisms of the people I talked to. I slipped into more accents than I thought possible, and said “hey man” (which I normally never use) enough times to embarrass a hippie.
We signed up a wide variety of people (as intended)


The combination of late-night shifts and activation energy (the willpower needed to prime my mind at the start of each shift) made for an exhausting week. But on balance, the entire experience was deeply satisfying, and I’m very happy to have done it.

Something really interesting happens when you work closely with a group of people and share in the struggle of a difficult task. At some point, quite suddenly, people let down their guard, and you get to know what they’re like at a more human level. This leads to better stories, funnier jokes, and shifts the balance of selective memory (more on this below).

Across hundreds of interactions with strangers, I was fortunate to make a bunch of observations on human behavior and how people used their phones. More on this in Part 2.

Most of those interactions were a net positive — ranging from the satisfaction of closing a Yes, the incredulity when people realized we were giving away free pizza (I was asked “why are you doing this?” several times), and the excitement of our scavenger hunt winners. This further shifts the balance of selective memory and contributes to that feeling of deep satisfaction.

Since each interaction was relatively quick and occurred frequently, it formed a rapid feedback loop allowing me to improve my pitch and selling ability. I settled on three versions of my pitch, tailored to different listeners and varying in complexity, and committed them to muscle memory so I could focus on other interaction details (identifying who was interested, who had the slowest phone in a group, and loading the signup page on my phone to make it easy to set everyone up). Mastering the pitch allowed me to get into a state of flow when interacting with a group of people, and it was exhilarating to perfectly narrate and time the pitch and signup process across a group of three or four people.

Coming into this week, I would not have thought that street-corner sales was something that I could do. I’m happy to have proven myself wrong — to know that it’s something I’m capable of doing, and that I even enjoy it.

Working hard or hardly working?

Selective Memory

Selective memory is an extension of the idea that people remember how they felt, but not the details, as well as the peak-end rule. If you know yourself well, you’ll know the types of details that you’ll remember and forget after an experience is over. For example, I know I’ll remember the conversations where everyone can’t stop laughing, the satisfaction of delivering joy to strangers, and discovering cool restaurants in a new city — but I’ll forget the hassle of setting up an air mattress each night.

If you’re deciding whether to do something, selective memory can be used as a framework (possibly in combination with fear-setting) to discount certain aspects of the experience to determine if it will be a net positive.