Not Bad at All: Part II

*This is Part II of II. Read Part I here.

On Hiring, and Shortcut’s Fantastic Engineering Team

So, as I was saying.

It's been fascinating to watch our frontend engineering team work. They can pick apart my weird code that I wrote, standardize it, and turn it into something that resembles a modern application. It's been fascinating to watch because there are a lot of fundamentally different ideas about data fetching and holding onto state and other things they've had to resolve, and they've done it.

I’m so proud when I think of the various people that make this organization work, who I regularly sit in meetings with. Sometimes I still can't believe that what started as a Hack Day project turned into a whole team of this size and caliber.

I’m often asked about hiring. How do you tell if someone is the right fit? For me, there are certain values / behaviors / principles or whatever you want to call that thing. To me, this is: a sense of curiosity, an interest in improving yourself and improving the team in the process, and being able to think deeply about problems. I think it’s important to take your time and not attempt to plow through things too quickly.

Another big trait for me is humility, and how collaborative you are. What does it mean to be collaborative and humble? (Cue my thoughts on Mr. Rogers below.) A lot of it is really just about how you disagree, how you carry your opinions, how you avoid stalemates, how to admit when you don’t know something, and how to admit when you’re wrong.

I look for people who are professional and people who operate on good faith - which means, to me, that they are inclusive and operate transparently, that they work “in public” so to speak, rather than have backdoor dealings. To me, this transparency is especially important for a product like ours. We need to capture what our opinions are so that in six months or a year or two, we can go back and say, “Oh right, this is why we thought this” and “Oh right, this is why we made this decision.”

There's also a bit of domain-specific first-hand experience I look for. Have you worked with really aggravating B2B products before!? Seriously. Have you worked on a dysfunctional software team before!? And do you want to use that experience to make something better in this space?

Everybody seems to have a story about a dysfunctional software team. The reality is that a lot of companies are operating on low trust - and what's funny is that we're trying to build something that puts you on a path toward trusting your team. Our tool is designed to combat the more dysfunctional dynamics that can occur between teams. You probably know what I mean. Which proves my point.

A Roadmap for Roadmaps

We, as leadership, want to make sure that we're going in the right direction, but we also want our various teams to feel empowered and trusted and autonomous to be able to make decisions.

Our role, from the executive side, is to define principles, values, mission, and business objectives. Once we have those in place, we trust the teams to make decisions that align with these foundational opinions.

So, the team is given the direction we want to go in, then the team figures out how to get us there.

I’m a big proponent in ensuring that teams have specific backlogs - not just a giant mountain of stuff. Because many people want to pretend this backlog doesn't exist, because then they can play with their own tiny pile of stuff. But you have to acknowledge that there are a thousand things in the backlog, and they're all good ideas, and it's important that we try to break that down and say: Okay, what are the big features, the most impactful features that we want to work on? What is the most impactful kind of tech debt, design debt, and product debt that we want to pay down? What are the most problematic and most irritating bugs that we want to solve? Then it’s about pulling from this backlog and working with smaller broken down piles of work, and having a defined ratio between these things.

There’s no perfect method, and it’s something we’re constantly experimenting with, but it’s good to be explicit about the ratio of time we want to spend between features and chores (chores: what we call improvements - paying down tech debt and bugs, bug fixing). Having a defined ratio helps with the quick and dirty planning. Maybe we, as a team, decide: Hey, we're going to do more infrastructure this week. Or: Hey, we're going to do more feature work, because x, y, and z. But, basically, the baseline ratio remains. Maybe it’s a little idealistic, a little inspirational. (Cue Mr. Rogers again. I’m getting to him.)

On Making Mistakes

I’ve made many mistakes over the years. One of these mistakes is that I took it to myself to write a caching layer for our activity feed. It worked great until we realized that it was creating bugs that were completely impossible to diagnose. This was an example of trying to solve things in a very complex way without considering enough ripple effects. The lesson was not to over-optimize one thing at too great an expense of another.

We all make mistakes - some small, some huge. Once, early on, a team member actually deleted the entire database! But it was okay. What's important - and this is one trait of a high-functioning team - is the psychological safety in making mistakes. People need to know it’s okay to mess up. Otherwise, they won’t take risks. It’s important to trust, to have faith, that people are going to learn from these mistakes. Even when they delete the entire database.

Does Anyone Else Love Mr. Rogers as Much as I do?

He's always been a huge role model for me, what can I say? I watched Mr. Rogers as a kid. I still watch Mr. Rogers - now with my wife and our six year-old son. I love Mr. Rogers.

I love Mr. Rogers because he embraces what makes you different and unique. He embraces what's different and unique about all of us. Mr. Rogers was - and is, still, on-screen - into the concept of neighborhood and community. He’s into: it's not about everybody agreeing with each other, but the fact that we all can all work together and disagree and resolve our differences and just live together.

Sometimes it feels like his message runs counter to the world we live in. Which is why I hold onto it. Which is why I think it’s so important. Which is why Mr. Rogers is so moving. Mr. Rogers is into the concept of telling stories. He’s into feelings. He’s into working through these feelings.

Back when people actually went into work, it was such a pleasure to tag along to customer meetings with our cx team, and walk into people’s large, terrifyingly open office spaces and see all the people with our work - which was their work - up on so many computer screens. Moments like that were very real reminders of what Shortcut set out to do. The neighborhoods we created, the communities. Moments like that, I would think, “Not bad at all.”

Check out what we built by starting your free trial.