Margaret Adams

My work continued on the customer onboarding experience - refining existing features and experimenting with different ways to drive engagement. I later moved to a team that was focused mostly on building out new features. We shipped Paper Checks and Certificates of Deposit. I led the efforts to add Live Chat to our web app and built out self service Card Reorders as part of a larger initiative to give customers more Self Serve options. I started a reading group for Frontend and QA engineers to learn Typescript. I also wrote up a proposal for customer education that was greenlit for development. I helped organize quarterly community service volunteer outings for the Engineering department and a pandemic themed hackathon in 2020. This part of my career at Simple saw a lot of personal growth -- taking on lots of solo projects, proposing new features, and contributing to service design discussions.

As a Frontend Engineer II the main change from being an Engineer I was that I spent more time building out Frontend components on my own, versus on a team with someone more senior than I, collaborating on the same feature. I continued working on the product team focused on onboarding for some time. We scrapped a lot of the work that had been done on my previous team, and built out a new Welcome experience for when new customers logged in for the first time. We shifted to encouraging them to try out some of our features and giving users a bigger overview of what they could do next. We also rebuilt part of the application flow to send image uploads to a third party to automate reviewing of documentation, versus having all images reviewed manually by our customer operations team.

A lot of the work I had been focused on was refining and updating existing features. The image upload change had zero customer facing changes: I needed to build a second version of the form that looked *nearly* identical, but behind the scenes was managing the uploads completely differently. This was a huge win for our Cust Ops team (something that always motivated me) and I liked working on refinements - it felt good to commit to an area of customer experience and really dig deep, but I was soon on a new team that was building out and launching brand new features!

This was fun too - the first thing we shipped for customers was Paper Checks. When we were discussing what we wanted from the API, we talked about the need to stop check payments. We’d have an internal endpoint that a Cust Ops agent could hit from SalesForce with a check number to cancel the payment. I made the suggestion that we build the stop payment feature right into our apps, so that customers could self serve, and cancel a payment themselves. This was a carryover from my work on the Customer Support team - always looking for ways we could eliminate the need for customers to reach out to us to begin with. I really liked working with Backend engineers at this stage of projects - talking about API design and thinking about the full product experience for our users.

The next big feature we built was Certificates of Deposit (CDs). I had never heard of a CD. We built an application flow within our banking app, a list view of the CDs and a transaction list of interest deposits. It was sort of a funny experience because although I had never heard of a CD at the beginning, it ended up being one of the most straightforward product development experiences I had. It was a clearly defined financial product, and we did our best to make the signup process as “Simple” as possible. Unfortunately we launched at the beginning of the COVID-19 pandemic, right as the Fed dropped interest rates - and a product we hoped would attract customers with a high interest rate no longer had a high interest rate.

After that work wrapped up, I had the chance to focus on an initiative I was really passionate about: customer quality of life enhancements. We called them paper cuts - anything that was causing customer confusion, overly burdensome flows, or otherwise product annoyances. The biggest priority was building out more self service offerings: customers should be able to order new cards online, without contacting Customer Support. This was a project I led - working with Backend to define the client needs and legal/compliance requirements, and working with other clients to provide entry points to a webview flow. Another project I led during this time was our first Live Chat feature - using the SalesForce embedded Live Chat, integrated into our web app.

My other goal was to build out a set of Customer Education tools - we knew we had a great product, but it wasn’t always easy to get people to really USE it. We had budgeting tools that had helped lots of our customers save thousands of dollars and pay off huge debts - how could we connect more customers to that value? I wrote up a proposal for Customer Education experiments, worked with design on some mock ups for different approaches we could take and test out, and presented the proposal to the company. The proposal was greenlit, and had the go ahead to be worked on. Not long after, when Simple announced that we would be closing down, our focus reshifted again - this time to self service account closures. 😢

I joined the Frontend Engineering team to focus on building out our customer facing tools in React in addition to continuing to build and support our customer support tools. I was the primary contributor on the work to support Shared Accounts in our internal tools - requiring a huge reworking of the app, updating customer profiles from an assumption that each customer would have only one account to the reality that each customer could have several accounts. I was also part of a team that was also heavily focused on our application and onboarding customer facing experience. I helped build an initial funding flow, integrating with Plaid and running experiments that increased users first deposits into their new accounts.

In an effort to get more resources to build out internal tools, the decision was made to divide and conquer, and the Internal Engineering team dissolved. Some of us moved to the Backend Engineering team, some to Frontend, and some to Data. I joined Frontend because our other Backend systems at Simple were written in Java, not Ruby - so I felt I had a better chance picking up speed on the Frontend team. I also found it very gratifying to make things look nice, and Backend felt out of reach to me at the time.

At first I was still working exclusively on our internal tools, but from a different domain team. Many of our services and apps were built on the assumption that 1 customer = 1 account. Building out Shared Accounts was a huge undertaking for all of our engineers. I was responsible for updating the customer support application to handle both accounts per customer. I was in over my head, but I pulled it off! I was used to working closely with a more senior developer who was no longer at the company, and it felt like a real sink or swim moment for me. Succeeding on that project made me feel like a Real Engineer. Ha!

There was ongoing work to “retire” our homegrown support tool and move to SalesForce (this, to me, was tragic). It had admittedly always been a struggle to support internal tools - we were always under-resourced, and frequently forgotten until the last minute when it came to new feature support. I understood this decision, but also wished that we could have dumped the money that was going to go to Salesforce into rebuilding parts of our homegrown tool. To this day (2021) many teams still depend heavily on that tool, while also running Salesforce in parallel. Despite its shortcomings, it was and is a great product that just needed a little extra love!

This was around the same time that I started working on our customer facing products. My first introduction to our customer facing products was also our customer’s first introduction to Simple: I began working on our web bank account application flow and the first landing page flow when a customer logged in for the first time. We built in our first Plaid integration to drive initial funding by making it quicker and easier to link an account and initiate that first transfer. We continued to run A/B tests on initial funding and were successfully raising initial funding amounts. It was really fun to work on small refinements that were having an impact.

I got to cut my teeth in software development working on the internal tools at Simple. This gave me a chance to work on the full stack - a colossal Ruby on Rails app with every JavaScript framework you can think of (including one you probably didn’t think of, because it was our custom framework - Butcher). I kept in close contact with my friends from Customer Support to help guide my work, and utilized this tight feedback loop to iterate quickly. We typically worked without product or design guidance, but had to build out support in our internal apps for any new customer facing feature. I also helped organize an Engineering wide hack week that would focus on improvements requested by our customer support agents: updates that would help them work more efficiently or could help cut back on main contact drivers.

It was a very proud day for me when I accepted a job offer to join the engineering team at Simple. I joined the department as a Ruby on Rails developer for the Internal Engineering team. Throughout this time, I stayed in close contact with all my pals on the engineering side - and these relationships helped us stay in a short feedback loop.

Working on internal tools was challenging and rewarding for the same reasons - your customers are in the same room as you. When we shipped a slick new feature, we quickly saw the impacts and heard the positive reviews from across the room. And when we screwed something up, it was our friends who hurt because of it. Ultimately, though, I think this was my favorite part about working on internal tools. We learned what worked and what didn’t quickly, and we could also iterate quickly. We didn’t have our own product manager, so it was often just the three of us engineers making decisions about what to build next and how it should work. There wasn’t a lot of overhead, and it was fun to experiment.

One of my favorite projects was redesigning and rebuilding the flow after customer contact where an agent would categorize the topic and leave notes about the call or chat. It was this data that I had used when I was an agent to make product requests and suggestions for our customers. I knew this data was really powerful, and was what the support team could leverage to help our customers be heard inside the company. I was happy to have a chance to update the flow so that we could gather data in a more precise and detailed way.

I learned and grew a ton in this role. I was writing a lot of Javascript, in a lot of different frameworks - Mootools, JQuery, Butcher (a Javascript framework built in house), vanilla JS, Bootstrap for most of our styles, and Ruby on Rails to interact with our data. When the decision was made to dissolve the Internal tools team and to support these products from the other existing functional teams at the company, I made the decision to focus on Frontend development, but I would miss the full stack life!

After joining Simple’s customer support team, I was quickly hitting the top end of our production goals for the number of cases handled per day. More importantly, I loved the challenge brought on by each call or chat, and I loved helping to find solutions for every customer I interacted with. I was a regular contributor to our Product repo, documenting feature ideas or updates based on my interactions with customers. I leveraged my background in Sociology to analyze large sets of contact data to support these proposals.

I discovered Simple a few months after I graduated college. I was eager to find a job in tech and I was actively teaching myself to code on the side. I applied for a Simple bank account as enthusiastically as I applied for a job with them. Everything about it felt really promising - they had a great product that I needed (badly) to help me get a grip on my finances, they had open roles in customer support (a job I was well qualified for and excited about doing), and I knew they supported women who wanted to learn to code (as I’d seen they hosted a Women Who Hack day).

To my complete delight, I got the job! And I loved it. I loved figuring out how to build rapport with each customer I talked to - getting to know them a little bit, and also doing everything in my power to resolve their issue. I initially found phone support to be nerve wracking, but I later found it exhilarating - thinking on my toes and finding solutions to whatever problems the customers threw my way.

I was also an active participant in product discussions - documenting customer contact, articulating clearly the problems they faced, and making suggestions for how we might improve them. When we rolled out customer to customer transfers, we were developing a roll out plan and ran into a roadblock when we realized people with early access might want to transfer to people who didn’t have access yet. I suggested we start by rolling out to a small group and then give feature access to anyone those users attempted to add as contacts. And that’s how we rolled it out.

One of the things I was most impressed with when I started my job at Simple was that the support software we used was built in house. Belvedere. There were two engineers working on the app, and we saw quick and routine updates as needed. It looked really nice (Bootstrap, I later learned) and it was tailored to our specific needs. I never expected that the internal apps would be as user friendly as our customer facing products. The best part was that the engineers working on Belvedere sat 20 feet away, and so I started pestering them with requests. The two of them started a “Code Club” after work to teach any interested employees, and after a few weeks, I was the only one still showing up. This turned into an opportunity for me to work with them on the clock, on the same requests I had been pestering them with! It was the best! I was closely connected with the support team, and with the job myself, and I knew how we could improve efficiency through updates to Belvedere.

The first thing I added to Belvedere while I was still working as an agent was a button at the very top of a customer profile that copied their user ID to your clipboard, an idea that came from another agent, and an update that saved us all time and clicks on every call and for every chat.

I led a five person team through Lewis & Clark’s first annual Venture Competition to the final round. We designed, built, and tested a platform that encouraged students to share resources on campus. We formalized ourselves as an LLC and registered a Trademark. In parallel with that work, our team was hired to build the campus digital wayfinding system.

What started as a group project in a Cyborg Anthropology class turned into a team effort in Lewis & Clark’s first ever Venture Competition. I led the five person team as CEO (I cringe at this now, but we had to walk the walk!) and we pitched and built a product called Kokonect - a tool that would help connect students to valuable resources on campus. This was a time in the tech world when the Share Economy was a major buzzword, and we were exploring what that could look like on college campuses.

We got funding through the competition, and were subsequently also hired by the school to build their online wayfinding/campus mapping system. We had two sources of funding - we were on top of the world. With the money, we hired contractors to build both projects - a web app that allowed anyone with a Lewis & Clark email address to create an account, post offers or requests, and view a feed of resources other students wanted to share or were looking for. We also built an interactive campus map and an admin UI to update the map and all points of data on it.

Additionally, we formalized ourselves as an LLC, and filed a Trademark. Ultimately the mapping project became a higher priority because we had real, paying clients (good call), but unfortunately we ran Kokonect into the ground when we couldn’t support both projects. Devastating! I learned an incredible amount in those 6 or so months, and was also teaching myself to code on the side (with hopes I could maintain Kokonect myself) when I saw a Women Who Hack event on Portland’s tech events calendar hosted by a company I hadn't previously heard of: Simple.