DEV Community: Jake Strang

I was the second hire at a company on Y Combinator's Top 200 list

Jake Strang — Sat, 05 Aug 2023 06:16:04 +0000

TLDR;

I spent the past four years as a Senior Software Engineer at Convictional, a venture-funded B2B ecommerce software startup. I was the second hire at the company and am credited as the #1 contributor to the codebase on GitHub (written in Go). During my time, Convictional grew to over 50 employees and reached spot #199 in YC's Top Companies by Valuation (they discontinued these statistics in April 2024).

For this next chapter, I'm looking for a new values-centered company that I can support with my learnings and enthusiasm!

Skip ahead...

A humble admission
Convictional in a nutshell
My contributions
My learnings
Where do I go from here?

A humble admission

I'm extremely fortunate to be able to say this.

With about 4 million software engineers across North America, it comes with a sense of pride to belong to the 0.01% that can claim the niche statistic in the headline. But if I'm being candid—as I hope to be for the rest of this post—every senior software engineer that I've met has had plenty to teach me. It doesn't so much matter where you work, I think.

In fact, in those early days at Convictional, Chris and Roger emphasized that our goal in growing the team was "to hire people who were smarter than us" and I believe we held true to that. So by exposing my earliness I'm also admitting to a certain level of underqualification.

I embrace this wholeheartedly. Running interviews is so much less stressful since accepting that it's okay—preferred, actually—for the interviewee to know more than me. To this day I still get that initial spike of nerves when a conversation moves towards some common technologies I haven't explored like Docker, Kafka, or Oauth.

The bottom line is, I guess, that my journey is just beginning. I had an exceptional first chapter though, so don't stop reading 😁.

Convictional in a nutshell

Chris and Roger were working at Shopify when they came up with the idea for Convictional.

An early version of the product was made—a platform that connects the ecommerce systems of retailers and suppliers to enable dropshipping—and they were accepted into Y Combinator's accelerator as part of the Winter 2019 batch. At YC, Convictional raised $2.2M and TechCrunch placed them in the top 10 of the 200 startups in the batch.

While this was going on, I was wrapping up my fourth-year engineering design project at the University of Waterloo. Roger and I had worked together in the past and he was keeping me updated on Convictional's successes in California. I had always been intrigued about working at a startup, and by April 2019 I had joined the team, just a few weeks after our first hire, Matt.

The next four years are best described as a punctuated equilibrium, rather than the roller coaster often associated with Silicon Valley startups. Most days were productive yet uneventful in the grand scheme, a good thing for the human psyche I think.

Roger and Chris poured meaningful hours into developing a humane work culture that is uniquely their own. No weekends, no Slack channels, and no engineer-on-call are all examples of ways—still in effect today—that they balanced focus with rest from day one.

Convictional's secret weapon here was Jess, our third hire, who brought with her a Masters in Adult Education and Workplace Learning. We read books, adopted mindfulness, and leaned in heavily to async practices. The people we hired often told me in our one-on-one syncs that Convictional had a healthier culture than their previous workplaces.

By the time I'm writing this, Convictional has grown to a 50 person company. We've attracted some recognizable logos, closed subsequent Series A and Series B rounds of funding—landing us at spot #199 in YC's Top Companies by Valuation—and continued to put our values ahead of profits.

My contributions

As much as I laud Convictional's culture and team-building, I should be clear that my own contributions in that arena were the quiet and indirect sort. I joined the team as a software engineer and stuck to the individual contributor track throughout my four years there.

Here are the highlights of my proudest work:

As of May 2023, I'm credited on GitHub as the #1 lifetime contributor to Convictional's main backend codebase, with 520 commits. This is a server application written using Go and MongoDB and tightly integrated with some major ecommerce APIs such as Shopify, WooCommerce, and Stripe.
As our team grew I took on ownership of our API architecture and design. I wrote our API style guide, maintained our public API documentation, and worked with the team on all aspects of API enablement. This included some things like designing new APIs or consulting with those who did, improving our monitoring for API-related metrics, introducing auto-generated API docs using in-code annotations, and defining our API versioning procedures.
From 2020 to 2021, I worked on a special project with a well-known Canadian retailer's engineering team to build them a standalone integration bridging our two systems (using Go, MongoDB, and GCE). As my first collaboration, I quickly learned about the challenges of navigating organizational complexity. The project was late but successful, and ended up converting them into our largest customer. A few months later, we secured $6.7M in Series A funding.
By 2022, we started to have new engineers joining the team each month. This gave me a treasured opportunity to practice more peer leadership as an individual contributor. I doubled down on making PR reviews my top priority and was delighted whenever I could approve within minutes of the request. I made daily efforts to respond to questions from team members by writing improved documentation. I shared learnings more intentionally across the team and hosted "lunch & learns". This sort of team contribution is now my favorite part of the job.

My learnings

Here are some takeaways I have from my time at Convictional. I don't think any of this is earth shattering, but hopefully I've chosen well enough to provide something of interest.

1. Work at a company where you feel honored.

I got my first 12% raise within a couple months of being hired. Roger told me, "we started you out on the low end, but it's obvious you're worth more than that". This sort of proactive wage increase became a pattern that continued all four years.

Convictional applies what might be deemed "radical trust". All employees have access to the company metrics and investor updates, including our burn and runway. We worked remotely before it was cool while being adamantly against surveillance tools.

Chris and Roger assured us that if they couldn't trust us they would rather just let us go. And they lived up to that too. We were able to enjoy a high-performing team because toxic individuals that slipped through the cracks were quickly removed.

There's a lot more I could mention here and I think this must be what happens when values flow top-down through an organization—they show up everywhere. You can pick up on it during the hiring process too. Look for companies that post salary ranges upfront, share employee handbooks, and go to greater lengths for a humane hiring process. For example, Mindera is looking pretty smug right now 😉.

2. Our biggest engineering bottleneck was support.

This was true on day one when I was hired, and I think it's still true at Convictional today, though it did get markedly better once we hired our all-star support team (thank you Dan, Danielle, Jared, and Ty 😭).

I think this is an example of where learnings were left on the table at Convictional. I don't think we quite figured this one out. Because, in theory, this is a great thing—people care enough about the product to complain about it! I suspect that this is exactly where you want your bottleneck to be.

Our shortcoming was that we didn't land on a way to leverage this rich support data arriving hourly back into the product roadmap in an elegant way. There were support tickets we first saw in 2020 that were still plaguing engineers in 2023. There were complaints coming in repeatedly that engineers were diagnosing from scratch each time rather than building up in a knowledge base. As our issue tracker filled to the brim, we would just archive the oldest tickets to clean it up.

As one of our earliest engineers, looking back I consider this a personal failure. I can't wait to try again.

3. Eliminate toil enthusiastically.

First, a quick clarification. "Toil" isn't just any tedious task, in my opinion. It's a tedious task that also feels ineffective or wasteful. That nagging "there must be a better way" is a sign of toil. It's the pain of feeling like your pain is for nothing.

Eliminating toil for the other engineers at Convictional was one of my highlights. I've already written an article about how early on we eliminated the toil common in typical daily standup meetings (that "can we be done yet?" feeling). The "oh thank GOD" moment that comes from making broken things better is something the team should experience regularly.

There's a lot more that I'd like to experiment with in this area. Like, can all the toils of a team be enumerated and tracked in a spreadsheet? How much of the psychological weight of toil is lifted if we communicate about it better?

Where do I go from here?

Chapter one is over. It's time for chapter two to begin.

One thing I've tuned into this year is that I care a lot more about people than I do about software. I see code as a means to delighting someone and I'm not as interested in deepening my backend knowledge for it's own sake. I'm also a feeling and intuition-driven person rather than thinking/sensing. All of this has me considering whether software engineering is where I'll find my tribe in the long run, or somewhere else entirely!

For me, I get excited about making things that other people will get excited about using. I like the puzzle of the design, how to make the pieces fit together elegantly? I like the challenge of the execution, how to sequence the project to bring it to success? I like the feeling of leadership, how do we come together as humans with a common goal while embracing our best selves?

So perhaps another startup could be a good fit, ideally one with a product that's more tangible and closer to consumers, away from the ecommerce space. A values-centered company looking for senior/staff engineers that will add to the culture. Maybe even something that's addressing humanity's biggest concerns head on?

Or, maybe 6 years in tech is enough and it's time to try my hand at toy making 😄.

Got an opportunity you think I'll like?

Find my contact info on my resume here.

Eliminating Toil: Standup Meetings

Jake Strang — Wed, 26 Jul 2023 15:20:03 +0000

"Ugh, can we move this along already..."

- Sincerely, everyone in the standup

It has been my experience that many software standup meetings are broken. They go on too long, the attendees are zoned out, and it creates a productivity dead zone before and after. Broken processes are motivation killers, they should be weeded out with a sense of enthusiasm and urgency.

While at Convictional, we landed on a really good thing here. Our standups usually interrupted less than 10 minutes of my day. They ranged from boring to highly engaging, but the less engaged I was, the less interruption I also experienced. This gave our standups a feeling of effectiveness.

The recipe

Do not do standup meetings in person.

Do not do a video call.

Instead, do the meeting in a shared Google Doc. Add a new section to the doc each day, and let each person have a dedicated area to write.

The effect you will see is the whole team writing their updates simultaneously, and they will be able to engage with each other through typing without holding up anyone else. Everyone can leave as soon as they want, or stick around as long as they want.

This is the secret to effective standups, you've got it now. Give it a try 😁! Here's an example of what this doc looks like after one day:

Daily Standup

The purpose of this doc is to share blockers, questions, reminders, and project updates with the team.

July 26 2023

Alice A:

Adding some custom JSON marshalling for nil maps, found this great article on reflection that helped me get the lay of the land.

BB: oh cool, thanks for sharing! Btw what's the issue with nil maps?

AA: Check out this issue, a lot of people have complaints about how it works. Basically doing a workaround for our API clients.

Brian B:

Continuing work designing the new Address API. I did some research into address validation rules, its more complex than I thought. Any suggestions on 3rd party API for this?

AA: I've used EasyPost (scroll down to the example) for a side project and worked well, but pricing isn't upfront :S

Template (Copy and replace with date)

Alice A:

Your update here

Brian B:

Your update here

My personal observations

What about face time?

My guess is that teams hold on to the face-to-face standup because they want to give the team frequent face time. If so, I think this is well-intentioned but misguided.

True, we want the people on our teams to develop familiarity and trust with each other, i.e. we want them to develop personal connections. But personal connection is not built by listening to your teammates try to summarize tasks you don't care about while trying to prepare your own summary in your head which they probably won't care about. And that's regardless of how closely you stand to each other.

Surprisingly, when using a Google Doc standup I did build personal connections as we typed out our one-on-one side conversations, as we picked shiny emojis to react to each other's wins with, and as we shared more thoughtful updates by taking the time to write without all eyes waiting on us.

Not to mention, face time does still happen if we realize our side conversation is too arduous to type and the two of us will hop into a Google Meet link to continue (hmm, sounds a lot like those post-standup breakout conversations that never seem to happen...).

In general though, my preferred way to increase that personal connection on the team is to go at it intentionally by having a combination of regular one-on-ones, and running weekly book clubs with small groups. In both cases, the point is to engage with each other, not to give a status update 😝!

Neurotypical, anyone?

In the software industry we celebrate our neurodiversity, and my guess is that it's one of the most accessible high-paying careers out there, especially for those with attention-related and sensory-related neurodivergence.

In my junior years I didn't question why after walking out of a 20 minute daily standup I had difficulty recalling a single detail of what was said. I assumed the information must not have been that important and went on with my day.

Moving to the Google Doc standup clued me in that there was an abundance of learning opportunities passing me by every day, simply because my brain struggles to process rapid-fire lists—which is essentially what the entire standup meeting is.

When ideas are written down instead, my visual processing can kick in and suddenly I'm at an advantage. You shared an article? I'm reading it. You noticed a bug? I'm sharing the issue I wrote for it. The team is a fully connected neural network for that brief moment each day.

Of course, we can assume everyone has different strengths in these areas. But I don't think we should be too surprised if having information written down, preserved, and—best of all—hyperlinked turns out to be vastly more helpful to most of us than our "oral traditions of the past" 😉.

"I don't know how to get my team on board!"

I'm going to make up an answer here that I think will help, and then I'll update it as I get your comments so we all learn from each other's success. This advice may sound overengineered (and maybe for your circumstance it is!) but I've learned not to underestimate the difficulty of leading even minor change in an organization.

Even if you are a junior engineer, you probably have more power to make that change on your team than you realize. However, success in this area often relies on a different set of skills than you typically use as an engineer. Hopefully my suggestions below can give you the confidence to take the first step. Pick and choose from them as you see fit.

Aim for the tipping point

Importantly, I believe that once a team tries this out for themselves they won't want to go back to their old ways. That is the tipping point. So your main goal isn't to change your team's process, but just to get buy-in to run a short experiment, say for a week. If all goes well, you'll have many hands helping you after that.

Eliminate moving parts

The less involvement you need for that experiment the better, so if your standups usually include a lot of people from different groups, consider narrowing the experiment down to just one sub-group of people, ideally one having a common supervisor or team lead.

In this case, schedule your "new" standup to happen 10 minutes before the "old" standup. That way you all get your updates written down in time for your team lead to attend the "old" standup on behalf of everyone in that small group. The rest of you can skip out, you've just eliminated your need to attend in person!

To be clear, the Google Doc standup works just fine even with lots of people, but the point here is to reduce any friction so your experiment can take off. You'll undoubtedly need to tweak some things at the beginning, and having fewer brains involved will help with that too.

Rally others to the cause

Pitch the experiment to your teammates first and get their buy-in. Share this article, discuss the merits together. Then go to your manager after for the decision already having the weight of some of your peers backing you.

A good manager will naturally be intrigued by an experiment like this, but could be hesitant to make changes that affect your peers before talking to them, and any time delay at this stage can grind the idea to a halt. Your manager will be grateful to see multiple supporters from the start.

Do the hard work first

When you pitch this idea to your manager show them the Google Doc all ready to go for the next day's standup. Have the date already in there and all your team members names. It's remarkably easy to say yes to an idea that feels like it already has the momentum to carry it to success.

I've seen a few budding initiatives fizzle out on someone's todo list at the "write down a few words and pick a date" stage, maybe your manager has as well. Doing the hard work first shows your manager that you have skin in the game to make this happen.

Thoughtfully address concerns

You've spent so much time with this idea at this point that it may seem like a no-brainer. Your manager will have a different perspective. Be willing to hear it out and reflect on the new information you're given.

If you're not used to pitching your ideas, it can be easy to get defensive or think of this part as a debate. It's not. In a debate both parties are on opposite sides vying for their positions. You want to be on the same side as your manager, coming to a thoughtful agreement about what is best for your team. The more you show this thoughtfulness, the more you will both win together as well as gain trust.

That said, come prepared so you can give this initiative it's fair chance! Your most compelling point is that the experiment has no cost and is entirely reversible. Even if it fails, the team will just continue doing the current process. And since you have your peers' buy-in already the team will likely feel motivated by the effort of having tried something new.

Know the roadmap

Your manager will ask you what still needs to be done to make this experiment happen smoothly, so have that list prepared as well. It will look something like:

Send an email to the participants to explain the experiment and what they need to do. Include the Google Doc link. Give a reminder of the "why" here and don't hesitate to pump people up!

Send the recurring standup calendar event to teammates, with helpful event description and have Google Doc link included here as well.

Schedule a debrief for the end of the experiment with your manager and anyone else interested. The goal can be to discuss how it went, and make a decision on next steps.

Success?

As you can probably tell, I'm weirdly excited about this idea. Once we discovered it, we used it solidly at Convictional for the 4 years I was there. It feels so good to take a process that's working against you and to get it to work for you instead. It becomes fuel for solving other problems.

Please share your standup experiences with me! Have you tried something like this on your teams? How did it go?? So far I've never come across another team doing this, but I'm sure it's out there. Share your even better ideas too! 🙌