I recently got dinner with a rad friend who I used to work with at Simple. (Rachel is a skilled wordsmith and a sharp wit — she’s recently launched her new business, Gimme The Lute, and if you might need help with your brand, you should get in touch with her! She’s also an excellent florist, because of course she is. But I have more experience with her writing, and she is masterful. She was the one who did the majority of my initial training, and her blend of directness and compassion made a huge impact on me.)
We talked about resumes and how to distill several years of experience into a few bullet points. I’d really been struggling with this, so she suggested I write down the good-parts-only version of my time at Simple. It was just the push I needed, and I ended up with two pages of things I’m really proud of, which surprised me a little!
It’s occurred to me that this might be fun to share, so I’ve copied it below. If you’re wondering what I did in my last role, this covers a lot of it!
I found out about Simple (then BankSimple) at a networking event in the summer of 2011. I met Al3x, the CTO, and was impressed with his energy and his complete lack of ego. I went to Simple’s site to see what they were hiring for, figuring it would be “lots of programmers,” and was really excited to see that they were hiring for support.
Simple was about two dozen people at that point. I was the second customer relations (CR) hire; the first [Rachel!] had been there for almost a year and made the move with the company from Brooklyn to Portland, OR. We were pre-launch by an undetermined amount of time (it ended up being about seven months more), and all our customers (~100-200) were friends or family. Our accounts were so lightly featured that we gave every new account holder some spending money right off the bat, because depositing money was a particular pain point. (There was no check deposit, no Simple-initiated bank transfer, and we couldn’t accept electronic debits.) We had a nascent Rails app for managing customer interactions, coupled with external partners’ well-developed and kinda creaky old systems. Our whole phone system was two iPhones that rang with the wee-ooo space-robot noise. At that point, they often didn’t ring for days; that ringtone is still a good way to get my attention.
My training was shadowing the person who had been doing all (potential) customer interaction [also Rachel], plus having several meetings with the founders and a few other key people. I got occasional programming help from my boss as I worked through Chris Pine’s “Learn to Program” book (which uses Ruby), following a summer Ruby/Rails workshop with Stumptown Syndicate (through their Portland Tech Workshops, which may someday see a second workshop!).
When the VP of engineering found out I was learning to program, he told me that the best way to learn was to look at other people’s code, and so he set up an internal GitHub (GH:E) account for me. The CFO walked by in the middle of this, said “you can’t do that,” and the reply was “yes I can,” so I got my GitHub account, the first for someone in a not-technically-technical role.
We hired a few new support folks the next month. None of them had previously worked in a customer relations role (one was a bank branch manager, one was a lawyer, and one was a civil engineer). We talked about what had worked well in previous jobs, what might be transferable, and what our big dreams for the team were.
Customer Relations instituted a lightweight scrum-inspired daily standup, where we reported on what we’d accomplished the previous day, what we concretely hoped to accomplish that day, and any potential blockers. I later began recording all our daily goals/accomplishments (in handcrafted JSON!), with an eye towards building out a small web app. The web app, alas, never came to full fruition, but did make me very good at handcrafting JSON, and as a bonus I started learning to use different text editors.
I interviewed candidates. I joined the Twitter team as it grew from a single person’s responsibility to a shared one, and later mentored new members. I jumped right in when our internal Code Club started up, where engineers volunteered to teach some programming to anyone who wanted to learn. (There were a few iterations of this over time!) I suggested hand signals to our now-weekly CR standup meetings, which dramatically reduced interruptions and are still in use several years later. I ran CR’s new-hire education program for a while. I taught the culture class in new-hire education for a much longer while, and cultivated a space where we talked about fears, hesitations, and how to be successful even if you’re not perfect (mistakes are okay! Responding well is key to getting through them). I joined our off-hours PagerDuty team to help customers with urgent needs in off-hours, whether they were in Los Angeles or India.
I noticed that a lot of coworkers said nice things about each other behind their backs. Suspecting that it was at least partly due to shyness, I started a “Box o’ Compliments” form for sharing compliments with coworkers (anonymously or not), and regularly sent out the incredible results from this project. (It impacted people enough that it’s still in use, and its administration has been adopted by someone new. I am absolutely delighted by this.)
I pioneered a stats-inclusive, human-focused, peer-review-driven QA process for CR messages. I sent regular reports to each member of the CR team, and I worked with certain teammates one-on-one to improve particular problem spots. (Sometimes you need someone to understand where you’re coming from and figure out a game plan with you; sometimes you can use TextExpander to ensure you never send “withdrawl” again!) After an illuminating conversation with our Communications Lead in marketing, I learned how to strike the word “but” from my vocabulary almost entirely, especially when giving potentially difficult feedback, and saw strikingly positive returns.
Our customer numbers grew ever higher. We were acquired by a big Spanish bank. Our employee ranks soared into the triple digits.
I worked with our amazing, supportive engineering leadership to pilot a half-day weekly collaboration (tiny internship?) with our ops team. I paired for about half the time, and hacked on my own the rest of the time. I learned to use vim, and I made multiple PRs and contributions to our internal continuous integration tool, written primarily in Python. Ultimately, a large infrastructure upgrade (and the resulting complications) pulled the plug on this pilot after a few months, but if I hadn’t caught the programming bug before, this cemented it. The bug, that is. The bug was cemented. But not in a “sad butterfly in concrete” way. In an “I’m excited and I air-punch with happiness way more than I used to” way.
A few months later, I worked with one of our data engineers to try to implement something similar, with the ultimate goal of joining the data team. We started meeting one-on-one twice a week, before work, to teach/study Python (and a bit of SQL). For a while, we shifted focus to data structures and algorithms, and invited a few members of the data team to join us.
I was really hungry for the opportunity to learn programming for more sustained periods of time (an hour here and there is hard!), so I applied to the Recurse Center in NYC, which describes itself as “a writer’s retreat for programmers.” I was accepted, took a leave of absence, and moved across the country for three months. I loved the RC community, loved the supportive environment, loved the space to be joyfully intellectually curious. There’s much more to say about that, of course.
And now? Now, I’m more certain than ever that I’m on the right path. I like being intellectually tired at the end of the day. I love the challenge of a good problem. I thrive around kind, hardworking people. And I can’t wait to join my support experience with something more technical.