One of the great things about being a software engineer at Stitch Fix is that most of our applications are internal-facing. This means that many of our “customers” are also our co-workers and may even work in the same building as us. For example, I work on our engineering team that supports our merchandising organization - the people who plan, buy, design, and allocate our inventory. Our merchants work with us in our headquarters on Market St. in downtown San Francisco.
Why is this so great? There are several reasons, all of which help make building new features an enjoyable and collaborative experience.
The first is empathy. It is much easier to empathize with someone using your software when they’re in the same room with you. You can feel their delight in using a well-designed interface, or their frustration when something unexpected occurs.
The second is communication. There is greater transparency, and faster, more direct exchange of information. When your customer is also your business partner, each time you see each other is an opportunity to give and receive feedback. This leads to more innovation because of the increased number of opportunities for ideas to cross-pollinate.
The third is prioritization. When you work at the same company as your customer, it’s easier to see the clear path forward because you each have the same overarching goal - the success of the company. This doesn’t mean it’s always easy to prioritize, but everyone can agree that the first thing to build should be the thing that benefits the business the most.
Keeping these reasons in mind I’ll share a case study of how I built a feature in close collaboration with our Sample Coordinators to help them keep track of our samples.
Case Study: Using technology to manage samples
The role of the software engineer at Stitch Fix isn’t just to write the code, but owning the whole product development cycle from start to finish. This means we hear about the initial pain point directly from our co-workers, we work with them to prioritize and add it to our roadmap, we collaborate on the interface design, and we agree on a release date with options for training and support.
Pain Point
Because we work in the same building as our customers, we often hear about pain points from several different people, whether it’s face to face, over email or through our ticketing system. Eventually it becomes apparent that it’s a pervasive issue that needs to be discussed in a larger group setting. Fortunately, our engineering team meets weekly with the Chief Merchandising Officer, Directors and other representatives from the merchandising organization to keep track of outstanding issues, raise new ones and to plan how they will all fit on our product roadmap. As a team we decide when an issue will be addressed and by whom. It was at this meeting that we discussed the need for a system to help Sample Coordinators manage all the samples that we receive at our headquarters.
Samples are a prototype of a style on order. Sample Coordinators receive samples at our headquarters 5 weeks in advance of the main shipment, and enter data into our in-house merchandising application, such as item type, color, silhouette, and price among others. They also fit the samples on models and take any notes about sizing. Then, our Visuals team takes a series of photos and videos of the sample on a model, as well as styled on a hanger or flat-styled. Sometimes samples are also taken on the road to train our remote stylists or for PR events.
The problem is that we only have one sample per style/color. There wasn’t a good system in place to keep track of where any particular sample was at a given time. Sample Coordinators were wasting hours per week just looking for samples. At best, this meant that not as many items of clothing were being made available to style for our clients as there could be, and at worst it caused backups at our warehouses because shipments of clothing were arriving before we’d even finished processing the sample.
Learning
At our weekly meeting we decided that samples would be tracked in our merchandising application, much like a library where other teams could check-out samples from sample coordinators, and indicate where a sample was throughout the entire process.
The task to build this minimally-viable sample management system fell to me and I immediately started setting up meetings with Sample Coordinators to learn about their current process, and begin sketching out a tool that would satisfy their main requirements.
Luckily, new Sample Coordinators were being trained soon after the meeting, so I sat in on several training sessions as if I was a new Sample Coordinator myself. Ultimately the job entails preparing particular styles of clothing to be made available on our styling platform by working with individual samples. We were trained on how to use two of our internal web applications, used to track when a shipment of clothing was going to arrive at one of our warehouses, and to enter data and upload visual media of our inventory.
I was able to shadow a Sample Coordinator as she worked with a fit model to make note of both qualitative aspects of a style’s fit (“good for tall”, “cautious for petite”), and more quantitative aspects (how many inches above the knee a skirt falls) - information used by stylists as they style a client. Lastly I shadowed a Photographer and Product Stylist as they took photos and video of the clothing. These visual media are used not only for our styling platform, but also for the stylecards included in each Fix, as well as marketing, social media and PR purposes.
Throughout this learning process I gained an appreciation for the complexity of the sample lifecycle and how much work is needed (manual, error-prone and tedious as it can be) to get each and every item of clothing in our inventory. I also saw how technology could be used to alleviate some of those problems.
Development
With my newfound knowledge of the sample process, I set about designing the user-interface and the backend software to support it. After discussing some initial ideas with a co-worker, I put together a mock-up of a simple check-out form that would record who was checking a sample out, for what purpose, and when it was expected to be back in the hands of the Sample Coordinator. If a sample was already checked out, there was an interface to check it back in. It showed a summary of where the sample had been, and also a checklist of stages a sample had completed in its lifecycle.
I emailed back and forth with a Sample Coordinator and once we settled on a design I set up a meeting with all the Sample Coordinators to get their feedback as a group. During this meeting, other issues were raised that led to tweaks in the design, but overall everyone was happy and excited to be involved in building a tool that would save them time.
At this point the coding began in earnest and over the next couple of weeks I bit off small chunks of the larger project and got feedback along the way from my engineering team for each pull-request I made. In the end, the project involved creating three new tables, writing some new services, updating our Elasticsearch index that contains denormalized data about our styles, using a new datetimepicker library, updating the UI, and of course unit and feature tests using Rspec and Capybara.
Once my final PR had been approved, I wrote up some release notes, including a screencast of how to use the new feature, and pushed it to our staging environment for some manual QA.
Release
Although the feature was technically finished, we coordinate with our business partners about how and when to release new software so no one is taken by surprise. We have a monthly training meeting where members of Merch learn about new technology that was developed in the past month. During one of these meetings I first demo-ed our new sample management process on our staging environment.
Over the next couple of weeks I communicated with one of the Merch directors and we held one more meeting with a subset of the Merch team involved with process improvement and documentation. Together, we decided on a release date so they could coordinate their own internal training. As an engineer I could tell them what the new feature does but it is up to them to decide how they’re going to use it and incorporate it into their daily process.
Finally, the day arrived and I deployed the new feature to production. Migrations were run, Elasticsearch indices were updated, and an email announcement was made. Other than a few thank you replies, it was a quiet day. And that’s good.
Empathy, Communication, Prioritization
This was one of my first experiences building a feature end-to-end with close collaboration of its primary users. I really enjoyed taking the time to fully grasp the problem and putting myself in the shoes of our “customers”. It’s vitally important to our business that as engineers we have empathy for our business partners and the challenges they face daily. Meeting with them frequently and creating relationships built on mutual respect eases communication and the process of prioritization. I love working at a company where everyone’s opinions are heard no matter the hierarchy, and software development is a group effort, done in a measured and sustainable way.
