I’m starting a new company, with Steve Fisher. I can’t reveal just yet the first product we’re building, but don’t worry, there’ll be more on that in the not-so-distant future. This post is focused on deeper considerations about the company we’re building and why those matter.
In 2015, at The Design & Content Conference, I watched Sara Wachter-Boettcher give a career-altering talk on designing for kindness.
In 2016, this theme was built upon at the same conference by virtually every speaker, but I want to call out two in particular who’ve stuck with me:
Anil Dash’s talk “Storytellers” — particularly the unintended consequences of design decisions, and accountability at a personal and organizational level for them. The Alexa Story, starting at 3:45 is such an excellent illustration.
Ron Bronson’s talk “Designing for Empathy: Context Matters”, largely about the idea of recognizing one’s own blinders and working through them to discover other context, other uses. The story about Pokemon Go/Ingress starting at 6:35 is solid example.
These three talks in particular have informed a pretty massive shift in my approaches to: code, operations, design, business, etc. Positive shifts that also come with a set of concerns that I hadn’t been as focused on.
Concerns we will address:
We’re going to have customers, at least to start, across North America. I also recognize that where your data resides has become more important than ever. For many companies and organizations, where their data is stored, and the locations of libraries they use matters. In BC (Canada!), government entities aren’t allowed to use US-soil services. Governments will use our product, and so we need to ensure that every piece of code we run, every piece of data we store resides in their country. So, from the get-go, we need to write software that is portable and works with third-party-hosted libraries, tools or services that are similarly portable. It’s an interesting and exciting constraint.
We’re two middle-aged, middle-class white dudes from Canada starting a tech company that is mostly self-funded. The privilege in that is staggering. Basically, we’re walking around with blinders on when we think about the product, the company. We need to do the work to see past our own biases and blinders. First step for us is to engage with a set of advisors who are significantly more diverse than we are, to provide alternative insights and voices in our planning. AND, most importantly, pay these advisors fairly for their time.
Protecting the Vulnerable
The product we’re building exists to help our customers. But it only took a few minutes to think of how someone could abuse our product to help them advance their less-wholesome objectives. Unintentionally so, but it would be easy to use this tool for bad. It is our responsibility to build in constraints, restrictions, community, etc that could prevent this. But, how far does that go? Not everyone is going to do things I like or agree with — but they’re not necessarily bad. Nothing is politically neutral, but do we want to have “neutral” software, run by an opinionated company? We’ve seen first hand the damage that can cause with companies like Twitter. We need to dig in and discover what tools, features, guidelines, legalese we can, and should, build into the product and company. It should be part of our job to build tech that protects the most vulnerable.
We will be tracking lots of activity within our product. This is for growth targets, sales, insights and customer support. All good reasons. And we will require user accounts. For most use-cases that’s not an issue, but I can’t guarantee that’s true for everyone who might see a use of our product.
Some guidelines we’re working from:
- Data security must be baked-in at every level.
- We hold our customers’ data in trust, and data should only be used for our collective greater good
- Our customers’ data remain theirs, and they should be able to remove it as needed.
- Data available online is vulnerable. It is our duty to both minimize that vulnerability and to act responsibility if it is ever targeted.
- Privacy doesn’t mean the same thing to everyone. We must support various levels.
Tools & Software
We’re building the first version of this software on our own, but hope to be able to hire engineering staff quickly. Cutting edge is less important than broadly known — for both hireability and learnability. Our team will leverage, and contribute back to, existing and potentially new open source projects. Where possible, we will prefer open-source tools over proprietary (particularly given our concerns about geophysical location). We’re building a web-app first, but I expect we’ll soon see use for both a mobile-native app for at least parts, and, perhaps less expectedly, a desktop app.
We need things such as revenue, first, but I’ve learned from my previous companies that hiring happens faster than you’d expect, and having values and policy in place is essential.
Some things we’re thinking about:
- Both Steve and I have dogs, who we want to have around the office.
- We have kids, and we like to see and hang out with them.
- We like to travel.
- Be able to offer valuable perks like full parental leave, childcare and flexible hours.
- Encourage and support community involvement and personal passions.
- Collaboration and conversation is better than competition and direction.
But, I don’t want an office full of perks and free things. There’s some middle ground of “recognize your staff have lives and accommodate fully” and “your staff should be treated like adults” Be passionate, stay passionate, engage and encourage passion, but leave work at work. A few years ago, I wrote a piece about finding other paths to success (“A million dollars isn’t cool, you know what’s cool?”), and the ethos behind that still resonates with me. I want to build that into this new company.
I’m confident we’ve identified a need and a niche that we can work in, but there’s something to the axiom “the greatest minds of my generation are figuring out how to make people click ads”. There are real problems that people can, and are solving. Teams at Code for America & the USDS are solving real problems, for real people, using tech. We need to make sure we’re contributing too — if not directly through our product, through our expertise, our staff, our community.
A Company for Good
Starting a company is hard. Most fail quickly, so adding additional constraints, or targets could feel like a fool’s game. I’d like a company that structurally contributes back to our community (see HR, above). And I’d like a company that isn’t just building a product and selling it. Existing isn’t enough. We need to put our effort, success, and privilege towards something more. We’re not totally sure where we’ll draw the line, but it’s something to figure out. It’s too easy to leave these decisions to later, and then later never comes. We need to start these as we start everything else.