What I Learned Working At My First Startup

Today is my last day working at Talent Inc. I’ve been there four years, which is the longest I have ever held a job and it’s the first product startup I’ve ever worked at. I feel extremely lucky for this experience and I would like the opportunity to say goodbye and share some lessons I learned.

Having Good Users Is a Blessing, Give Them Powerful Tools

When I first started at Talent Inc, I was working on software that was used by our internal operational team. I was paired up with an engineer that had been with the company for forever through an acquisition. In my first month working there he said something that has stuck with me ever since:

We have the best users, we have to treat them right. They are patient and we should reward them.

After four years here, I have to agree! That operational team works with job seekers whom can understandably be demanding. Job searching is in the top 3 most stressful moments of their lives. What’s incredible about both of these user groups (customers & staff) is how kind and helpful they can be when something breaks. How creative they can be when a fix is delayed to get the job done. This made my life so much easier and less stressful when the chips were down.

How can I reward this team effort? I was lucky during my tenure at Talent Inc many opportunities to build systems from the ground up to empower these users. I feel that we delivered on those opportunities and the fact that we exited kind of validates that belief.

Here are some cool tech patterns I learned around this:

1. Tagging systems are amazing. It allows non-technical people to add metadata to records that you can later build technical processes around.
2. I had never worked with a BI platform like Periscope Data and now I don’t think I can work anywhere that doesn’t have one. The amount of SQL I’ve seen written by supposedly non-technical people to empower their own processes was not something I expected. It allowed me to share new schemas I made with them and then they were able to make their own dashboards to accomplish their tasks.
3. At previous jobs, I was likely to script up a CLI program to alter data in bug recovery mode. My definition of bugs was very loose and frequently I would become a point of failure. My time at Talent forced me to move these scripts to a web interface where I or anyone could run them with a press of a button. The next step of that is to design admin interfaces that are as close to writing to the database itself so that users can fix their own mistakes. The less work I do, the happier I am.

It goes without saying, but I will say it because it’s important: I am going to miss working with these people so much. I will never forget your kindness and understanding.

So Many Data Pipelines

All my jobs previous to this were mostly at consulting firms. One thing I can tell you about consulting is that you are somewhat separated from the end user. My joke about consulting is the main problem you are solving is getting that next check to show up. As such, your users can become adversaries in your mind. You get okay with dropping events. You deprioritize bugs because it doesn’t effect your bottom line. You wonder what all the bellyaching is about when an email doesn’t show up.

The concerns are different when you work at a customer focused startup, though. Things have to be fast, so you push as much off the request thread as possible. That stuff off the main thread needs to run reliably, so you throw money at AWS for SQS and write a lot of Lambdas (which are my favorite technological discovery during my time at Talent Inc, if I ever start a company, it will be all Lambdas). If you drop events, you’re dropping revenue and user trust.

Experimentation Is Crucial

I’m ashamed to say that I never ran an A/B test before my time at Talent. It’s just not a concern for early stage consulting gigs. That changed very quickly for me and now I can’t go back. We used A/B tests for everything:

• You want to see which version will make more money? Split test and let revenue tell the truth.
• You have a feature that’s a little raw that you want help debugging? Hide it behind a feature flag and watch Sentry, the users will test if for you.

That said, there were certainly times that instrumenting an A/B test was annoying and I wished that I didn’t need to, but I would get over that in the long run. The thing I’m looking forward to most in my next role is what A/B testing system they use. In my time, I made an A/B testing system, used a homegrown system and Google Optimize, and feature flagged a bunch of stuff by roles/tags.

If It’s Not In Production, It’s Not Done

At previous jobs, especially the consulting ones, we followed some version of a Git flow branching model. At Talent, we followed something closer to a trunk based approach. At first, if I’m honest, I really hated the trunk based approach. With Git Flow, you have time and space to perfect your code with constant merges. Only when your feature is ready to go do you release it to the world. With the trunk based model, once your code is in main and someone requests a release, 99.999% of the time, that code is going to production ASAP and we’re not cherry picking around it.

To get around this limitation, I would make massive PRs and only put them in main once I was happy. But that would cause me to ship bugs and would make it hard for larger changes to be shared with other developers. Then I started making “long lived feature branches” for the larger changes that I would have teammates put PRs against that. That’s the right move sometimes, but it leads to a lot of code drift as main moves ahead of it. Finally, our team had a rule that a ticket/card cannot be marked as done until it’s in production. I was frustrated and I wanted to blow the whole thing up!

In a 1 on 1 with my boss, I brought up my issues and why I hated it. Could we change it? And this when he dropped this bomb on me:

You can get it to production, I believe in you, users don’t have to be able to access it, it just needs to be in production. You can wrap it in a feature flag, put it behind a split test at 0%, you can even disable it based upon environment variables. If you get it to production, the velocity will move faster, trust me.

This was revelation! Oh how could I have been so close minded!? On my next task like this, I simply wrapped my feature so it was only accessible by developers and project managers and I shipped it. And wouldn’t you know it, by being able to share this feature for feedback, my tasks got done faster and faster. Furthermore, I was able to debug production level bugs (like access issues) before users ever got their hands on it. I was shipping stuff a lot faster and became a little bit of a single branch zealot.

As we onboarded developers coming from Git flow teams or teams that shipped code on a monthly or quarterly schedule, I got the delight of explaining that this is a little bit of an adjustment but it works in ways that you wouldn’t expect. It won’t fix everything, but it will fix a lot of things.

Here’s To Tomorrow!

As you can tell, I enjoyed my time at Talent Inc and I hope they enjoyed having me. If you’re looking for your next gig, I cannot recommend them enough. The future is very bright there and I’m sad that I won’t be around to see it.

At the same time, I’m very excited for what’s next. I don’t even know what is next. I only have one speed which is “go so hard I burnout once a year”. I should probably work on that… I’m going to take a few weeks to establish some better habits and doing a thorough job search next year.