What Working At Packback Has Been Like

On April 9th, 2014, just over 5 years ago at 18 years old, I set out on a journey of curiosity that has changed my life. That day I accepted an offer to join the fledgling startup Packback as a summer software engineering intern (back when Packback did textbook rental). I’ve been here for about five years now, first as an intern and the most recent 3.5 of them working full-time, now as a Senior Site Reliability Engineer. Getting to this point was not easy, nor did I foresee ever having this title when I first joined, partly because I would have no idea with a person with my title would do. So, I figured it’s time to explain what this person does.

Sidenote: if you don’t know what Packback does today (hint: it’s not textbooks anymore), go check out our new website first!

Success never comes on a straight line. I’ve been broke. Terrified. Excited. Rewarded. But every step of the way I had to grind. I knew that if I out-worked everyone today I would be able to out-party everyone at some point in the future.

Packback has the same opportunity. Every little accomplishment, every successful student, every happy school takes you closer to the rewards that I know are in store for Packback.

It’s not if. It’s when!

— Mark Cuban, early investor in Packback

Packback’s purpose is to awaken and fuel the lifelong curiosity in every student. One of our values is that we are fearlessly curious, and my journey has been very much about that. I tried to write similar blog posts many times before but couldn’t since there was so much to cover (particularly all the amazing team members), so I’ll try to keep this short.

What is it you do, anyway? #

The Site Reliability Engineering (SRE) team ensures we can awaken/fuel the curiosity of every student through delivering and scaling a reliable Packback platform. I’m responsible for areas like:

• Availability
• Latency
• Performance
• Efficiency (development, cost, systems, etc.)
• Monitoring
• Change management
• Emergency response (on-call)
• Capacity planning
• Security
• Risk management

On a day-to-day basis, this might be working on some performance improvement, making our release process more reliable (and less scary), or getting to delete some backend code because an architecture simplification made it irrelevant. I’m also doing various long-term R&D projects (discussed more below), so we have a better idea of how to implement certain reliability improvements or new features. My tool kit is “cloud-native”: Docker, Kubernetes (on GCP), Helm, GitLab, plus some shell scripting or Makefiles.

I previously was a backend engineer before becoming an SRE, and I still do a lot of backend work (and frontend work too). If I can fix an issue myself, I will, regardless of where it is in the stack. Other team members are empowered to do the same, with assistance from the specialist in whatever area they’re working on, as needed.

I like to think of my role as trying to find all the various ways I can break the site (or some automated test can), and then thinking about what we can do to fix it so the failure isn’t possible anymore, or it doesn’t crash the site if it happens. There’s lots of fun reverse engineering involved.

What else do you do? #

One of Packback’s values is “We earn leadership through ownership, optimism, and humility.” With that in mind, there’s a lot that can come up in a given month outside the usual day-to-day development.

First, there’s a lot of my time spent helping other engineers work out issues related to the areas of SRE responsibility (above) via doing code reviews or discussing technical specs. This is a valuable time to make our systems simpler, as the less code or logic paths there are, the less number of ways the system can fail.

Second, as the leader of the SRE team (by virtue of being the only one with SRE in my title), I get the freedom to plan out what tasks we take on next, in order to best support the product team doing their work. This comes with a lot of responsibility; I must ensure what I take on is the most important thing I can do at the moment, and that the workload/timeline is reasonable.

Part of planning is doing research and prototyping, trying to understand how we might solve some upcoming big problems. For example, testing out ideas for performance improvements, building out machine learning pipelines at scale, finding ways to improve our moderation algorithms, and researching various techniques to make builds run faster. Since SRE supports product development but operates behind-the-scenes, there’s a lot of flexibility to what we can deliver - as long as it helps the team as a whole achieve our goals.

Third, I help investigate some of the more complex or infrastructure-level bugs that we might experience. This is particularly fun for me since I love seeing how systems others have built work, and debugging gives me the opportunity to look into the internals.

On my very first day at Packback as an intern, I got in the office while other team members were in a meeting, so I just decided to jump in and try to fix a search bug we had, and after a bit of digging, ended up figuring out the issue. That spirit of jumping in on an unknown problem with fearless curiosity is something we foster in our team culture.

A few years later, we needed someone to maintain the office network (after we had moved into our first non-shared office), and I volunteered to take on that effort, so got experience dealing with various WiFi issues. One of our values is “We employ an investor’s mindset” so sometimes I needed to make sure I wasn’t doing too much IT stuff, but it is a fun change of pace from regular development.

I probably missed some other things I do, but in general it’s all about making sure the whole engineering team can be efficient and deliver stable software.

Why work at Packback when you could join a bigger company (e.g. Google) or run your own business? #

The work I’m doing now didn’t exist when I first joined, or even a few years in. I didn’t know what a “Site Reliability Engineer” was when I joined, and didn’t know how to do the job. Through learning and evolution of what I want to do, I was able to create this role for myself.

The rate of learning someone can get working at an early-stage startup is hard to beat. Sure, there are super smart and experienced engineers at big companies, but for someone starting their career, will you have the same impact on the business, being able to shape the company?

It’s generally accepted that the bigger a company gets, the slower things move. Even at high-performing companies, there can still be a lot of bureaucratic overhead. I know friends that went the megacorp route, and I’ve experienced that culture before. It’s often not very fun.

The key part that keeps me here and propels me to do more for our customers is our purpose, to awaken and fuel the lifelong curiosity in every student. I personally believe that when students can become more curious and satisfy that curiosity, they can expand their horizons and find new ways to think about problems. We might be able to understand each other better if we are more curious about each other.

On the second part of the question, I don’t think running one’s own business has to be mutually exclusive. Eventually I may start my own company, but for now, I have a great opportunity to see the startup journey.

Here are some stages I’ve been thru and quick lessons I’ve learned (most applicable to other early employees):

Seed, Pre-Pivot (2014-mid 2015) #

• Take ownership, don’t wait for responsibility.
• Be Kind.
• Don’t worry about making things perfect, at this stage we might not need the code in 6 months or a year.
• (as an intern) Build relationships early with your coworkers as they can be invaluable later in your career.

Finding Product-Market Fit, Post-Pivot (mid 2015-late 2017) #

• There are no right answers in software engineering. One framework is not outright better than the other, and there isn’t one correct way to write a REST API.
• People are going to leave as the company changes, and that’s OK. Not everyone is the best fit at every company stage. Building a strong culture can help rally the team around a shared objective though.
• (related to the above) Culture is a competitive advantage if done right (making it intentional, rather than just words on a poster).
• Microservices aren’t a great idea for an undefined product. Your results may vary, but IMO it’s not worth the additional complexity.

Another lesson as I’ve discovered new fields (such as SRE):

If you’re an explorer and you live in a small valley, then you will slowly begin to believe yourself a better explorer as time goes on. But one day you will get to the edge of the valley and look out onto a vast landscape and believe that you have become a worse explorer.

Growth, Series A (late 2017-present) #

• Code becomes easy (or at least less difficult) once good frameworks/standards are in place. The “soft-skills” type stuff was actually hard for me, such as writing docs, training, building easily repeatable processes, etc.
• Automate early if you can, and don’t reinvent the wheel - try to use what’s already available if it’s not a core competency. Otherwise, you can incur a lot of tech debt.
• It’s OK to give up responsibility, empower people to do things on their own. Look for single points of failure in people, not just systems.
• Time management becomes critical as more responsibilities pile on and the stakes get higher. Remember to make time for yourself or face burnout.

What’s next? Becoming a leading EdTech engineering team through thinking in terms of 10x (and 100x) scale, delivering product improvements frequently and efficiently, and being confident in the stability of our platform despite operating at a high velocity. With the right team, we can get there. Speaking of that…

We’re hiring #

If you’re interested in joining a culture and team like this, I’m looking to grow the Site Reliability Engineering team by bringing on another SRE. It’s my priority to raise/mentor this next SRE to have the same amount of learning opportunities as I did to get to this point in my career.

Feel free to reach out to learn more about the role, or apply on our job board.

This was post was based on Patrick McKenzie’s “What Working At Stripe Has Been Like”.