Not Bad at All: Part I

My first experience with a computer was in 1984 with a Macintosh Plus. I still remember how it felt to use: like it was lovingly crafted by a small team of human beings. I loved the interaction between art, design, and technology that it inspired. Later, I attended art school and intended to enter the contemporary art world. There was just one problem: I didn’t particularly want, or know how, to enter the contemporary art world.

But during these years, I learned how to think, how to see things, how to be creative, and how to solve problems. After I graduated, I ran a couple of web design and development agencies before being pulled into the startup world.

At one of these startups, the opinionated nature of the project management tool our team was using started to annoy I mean get in the way of our team’s productivity. It was also impossible to get a bird's-eye view of direction and progress across multiple projects. So, during a Hack Day project, I built a way to aggregate this tool into one single view.

It was then that something clicked.

A few months later, I, along with my friend, colleague, and eventual Shortcut cofounder, Kurt Schrader, were onto something.

Here’s the story.

First: About Shortcut

Shortcut is a collaboration project management tool built for entire software teams. Not just engineering, not just product, but your entire research and development organization and the people they collaborate with: design, marketing, CX, sales, executive teams, and of course, engineering and product. Shortcut is a place for these cross-functional teams to come together, collaborate, manage roadmaps, track and document work, and measure success all within the same system record. A single source of truth.

What’s more is that using it every day doesn’t make you feel angry. It doesn’t suck! So much it doesn’t suck, in fact, that plastered across San Francisco buses these days, you’ll see quotes from various software engineers about Shortcut, things like: “Not bad at all” and “I don’t hate it.” Coming from engineers, there’s really no higher praise.

Back to How We Started

Pivotal Tracker was the tool we originally used at this startup, the one I mention above. It worked well, until the opinions and methodology baked into the product started to annoy I mean not make sense for us anymore. Once our company reached the mark of about fifty employees, we had people working across multiple projects with no real way to achieve a high-level sense of what was going on. That’s when we got Jira. “Because it’s the industry standard.”

As soon as we exported and imported everything into Jira, we felt the impact immediately. It was harder to use. It was confusing. Nobody wanted to use it, so people were talking outside of the tool. It truly affected our daily working lives and company culture.

This move coincided with the Hack Day event, where I built a Trello-y UI on top of the Pivotal Tracker API that we’d used before. This allowed for a kanban board of multiple projects. It worked! The entire engineering team actually exported everything back out of Jira and into Pivotal Tracker. In hindsight, this was crazy. But it was an interesting lightbulb moment: maybe there’s an opportunity here?

A couple of months later, Kurt and I were talking in the office kitchen. We thought: If we back out of the Pivotal Tracker API and build our own API, then we can go in our own direction. This was exciting.

Of course, we knew that the market was very competitive and crowded. But the reality is, that because all of these products had opinions baked into them, nothing seemed to really nail it. There was nothing that really worked well for a small, scaling, agile software team.

That’s how we ended up leaving that company and starting Shortcut.

Seven years later, we’re still here, building and improving on this product that we believe in and continue to use ourselves.

A Note on Architecture and Speed

From the beginning, a big part of our philosophy was: Let's build something small and encapsulated and fast. The original framework was very custom built using intentionally boring, unfashionable libraries. We wanted to build something that was going to be stable that allowed us to work on the product itself, and the user experience, and not necessarily spend all of our time upgrading the core library framework and all the dependencies.

Around this time, Ember.js was getting a lot of heat for being too complicated to upgrade; Angular was seen as this massive framework; and React was still very new. So, that’s what led to our decision to build something very custom and lightweight.

Another decision, in the beginning, was to load almost all of our data up front and keep it in memory, so that once you've taken that cold page load hit, everything feels instant. This allowed us to put out an extremely fast product. Speed was, and still is, our secret weapon. Speed is a feature, in my opinion. It’s a multiplier. It impacts every single kind of business metric.

Now, obviously, it becomes a matter of scaling. Which is what we’re doing now.

Cool Framework, Bro

The reason that we went in this direction was because, for me, it's always much more about what you are comfortable with versus ‘what's the cool new framework’ to try. The important thing is: what’s actually going to work?

I wanted to be able to know the inside and outside of this code, and when you're building effectively on bare metal, you can optimize all the way down to bare metal. But if you’re using something like Ember.js or React, eventually you’ll get to a point where you're trying to do something that it doesn't want to do, and now you have to figure out how to break open that black box and start optimizing it and working around it.

Sometimes, people tend to build things for the wrong audiences. They tend to build for their peers. It’s like design agencies who tend to design to impress other designers - or writers who write to impress other writers - not so much to achieve the business goals of the client. We didn’t want to do that.

My feeling is: at the end of the day, who cares what tools you use to build your product? It’s ultimately about user experience. Nobody uses a product because of the tech stack used to build it. They use it because it feels great, and because of the value they get from it. That’s what we wanted Shortcut to be.

This is part I of II of Not Bad at All. To see how Shortcut works, start your free trial.