RTR's Core Values

Core Value Award winners

Core Value Award winners

 Lots of companies have Core Values, but at RTR we take them very seriously! We have at least two important ways that we keep ourselves focused on them to keep them real:

At our all-hands company meetings, we have the chance to get up in front of everyone and nominate someone for a Core Value Award - describing how that person did something that embodies a particular one of our Core Values!

On our Tech Team we have a software tool that allows us to award micro-bonuses to teammates, tagged with a particular Core Value (#cinderellaexperience)! These micro-bonuses are visible to the entire team, literally echoed in our team chat, and can be redeemed for cool things like gift cards and charitable donations!

So what are these awesome Core Values, you ask?!

Rent the Runway's Core Values:

  1. Everyone deserves a Cinderella Experience!
  2. Dream big and go after it!
  3. Make the most with what you have…scrappiness is a virtue!
  4. Debating, honest conversations and collaborating make the company stronger!
  5. Happiness and positivity is a choice!
  6. Embrace the RTR family and bring your authentic self into the office each day!
  7. Bring your best intentions to everything and trust that others do the same!
  8. Adapt and learn from everything you do!
  9. Roll up your sleeves and get involved! Everyone should be accessible and involved with the day to day elements of RTR!
  10. We are all founders of Rent The Runway!

Tell us what you think of these! #honestcollaboration

 


As seen On Apple TV: A HackWeek Memoir

Last week, to celebrate months of hard work, Rent the Runway hosted HackWeek, a week-long hackathon. This was an opportunity to work with new technologies, hardware, languages, as well as coworkers outside of our usual teams.

So on the Friday before HackWeek, we gathered in the kitchen to hear the pitches and decide what projects to work on. That same Friday, Rent the Runway received the AppleTV Developer Kit (Fun fact: we won it in the AppleTV lottery for just one dollar!) Naturally, the mobile team was itching for an opportunity to tinker with our new toy.

On Monday, our team was formed. Its group members? Billy Tobon - Lead iOS Developer, Sandy Woodruff - Product Designer, and Lea Marolt Sonnenschein - iOS Developer.

We spent the first day reading the Apple tvOS documentation, looking at Apple's human interface guidelines, and learning from their examples. We also spent some time thinking of a clever app name. We ended up with TVGunn (Hint: Project Runway). We realized that building applications for the TV relies heavily on a strong understanding of the user interface to create an application that is:

  1. Simple to use: The user should be able to go through the entire app with just a few taps and flicks of the finger.

  2. Actually usable: Asset placement is important in tvOS. If two assets that can be hovered over are too far from each other, the user won't be able make the transition from one to the other.

  3. Sensible: There's actual value in creating a tvOS app. It complements your existing apps and doesn't just exist for the sake of having your app on all available platforms.

 

With that in mind, we brainstormed, sketched, discussed, failed a lot, and learned from our failures. For example, For example, Apple gives developers two options of developing tvOS apps: native, or using their new Television Markup Language - TVML (along with TVJS and TVMLKit). We spent hours trying to figure out what the best template was for our use case, and trying to work with this new XML and JavaScript. At the end of the day, we decided to scrap the project, and start off fresh with a native implementation the next day.

 

FIRST LESSON LEARNED: If you actually want to build something usable, stick to your guns at a hackathon. If you don't care whether the final product works, feel free to explore.

 

On Tuesday, things got off to a good start. We had a plan. TVGunn would be an app placed in Rent the Runway stores that could help users browse through their shortlists in-store. There would be iBeacons placed in the store to detect the user's shortlists, and automatically pull them up on the screen when the user's credentials were verified. This would help streamline the process of interacting with the stylist.

 

Sandy created fantastic mockups, while Billy and I had a clear division of labor on the tvOS side. I was going to work on the app's frontend, while he would try to make our RTR Foundation Framework work with tvOS, so that TVGunn could easily talk to the backend. In the spirit of HackWeek, we decided to write the app in Swift - the RTR iOS app is completely written in Objective-C. Not only that, but we decided to use Storyboards, something many a mobile team dreads like the plague.

 

SECOND LESSON LEARNED: Betas will be betas - things will break and there's nothing you can do about it.

 

In order to develop for tvOS, we had to download the latest Xcode Beta - 7.1. We quickly learned that the Beta is called a Beta for a reason. For example, using Storyboards resulted in a crash every time I tried to drag a new View Controller on the board. I ended up copying the default View Controller set up in the Storyboard 5 times to achieve the user flow that we wanted - #scrappinessisavirtue.

 

THIRD LESSON LEARNED: Cocoapods don't play nicely with tvOS (yet).

 

Despite the Cocoapods fix for tvOS, released on Wednesday, we couldn't import the frameworks we use in our iOS App as pods, so Billy ended up importing them into our project directly. That resulted in a massive amount of errors that took almost two days to debug. In the meantime, Sandy learned how to create LCR files and make use of Apple's new tools to design parallax icons - ParallaxExporter and ParallaxPreviewer. I, on the other hand, tried to figure out how to best mimic Apple's interface. When the user moves from one element to another, the second element has to expand and cast a shadow to create the feedback needed for the user to know what element they're currently on. While this is done for us in some UI elements, like the UITableViewCells, it's not done in others, like the UICollectionViewCells. In order to achieve the look and feel that the user expects, I had to learn how to use special Focus Engine Controls only available on the tvOS.

We could play with this icon for hours!

We could play with this icon for hours!

 

FOURTH LESSON LEARNED: Parallax icons look and feel fantastic. We played with that app icon just a little too long when we finally got it on the screen.


FIFTH LESSON LEARNED: Don't count on everything you see in examples to be pre-built. I had to put in some muscle in order to get the interface looking and feeling the way Apple does in their examples.

 

SIXTH LESSON LEARNED: Swift 2.1 has evolved-a lot. Make sure to always read the newest documentation carefully, instead of just assuming the old ways work. Otherwise you will experience unnecessary frustration.

 

Swift offers a severely streamlined process of creating apps. Unfortunately, because Swift is still evolving, many of the language's aspects have changed with each iteration. Because of that evolution, learning from older examples proved to be a little difficult, because they didn't work with this new syntax. For example, background tasks and requests now have to be wrapped inside a try/catch block.

 

SEVENTH LESSON LEARNED: Persisting data on tvOS is tricky. We knew from the documentation that there was no local store in the appleTV, and we planned not to persist anything in the device, but when we tried to use a SaaS solution (Parse) as a bridge between iOS and tvOS the app wouldn’t even load, because most of these types of frameworks use local store for caching.


 

In the spirit of HackWeek, we ended up using Parse via REST, and storing user credentials to Parse in plaintext (a definite no, no in production apps) based on data received from the iBeacon. Inside the app, we used a timing function that periodically checked if a new user had appeared on Parse. If there was no user on Parse, the app would play the official RTR promotional video. If the user appeared, however, the app immediately redirected to their shortlists.

 

By Friday, we ended up with a pretty solid working demo, and presented it to the whole company. Billy presented the hack and explained how it works, while Sandy and I did a small roleplaying sketch to make sure everyone understood our use case. Everyone seemed to enjoy it, and we're excited to explore its use. Even though, the demo was a success, we all know that the app has several problems, and is therefore not ready for production. Because this was HackWeek, though, we allowed ourselves to use not-so-stellar coding practices, pass data that shouldn't be passed around willy-nilly, and all in all, hack our ways until we made it work.

 

EIGHTH LESSON LEARNED: Never use the "F*** it, ship it!" method. If you decide to make a hackathon project a production project, scrap the whole thing and start from scratch. This will allow you to follow good development practices, and create a well-maintainable product, instead of having a codebase with so many leaks, you spend more time working on covering up the problems, rather than fixing them and focusing on moving the product forward.

 

All in all, HackWeek was a fantastic experience and a great success. Our team collaborated well and iterated quickly. We learned a lot of new things, and in the end produced a beautiful and exciting app using completely new hardware. I'm extremely proud of my team, and couldn't be happier I worked with them this entire week. We all can't wait to actually create a live Apple TV app, because we believe that the Apple TV has tremendous potential for how our customers can experience Rent the Runway!

Yours in Fashion,

Lea, Sandy & Billy


Sharing Our Engineering Ladder

I gave a talk last year at the NYC CTO summit on how and why to introduce structure into an engineering organization (slides available here). I am a fan of structure and the clarity that it can provide an organization, despite its potential downsides. I'm not going to talk about the WHY very much in this post, but I thought it was about time that I helped with the HOW.

Creating an engineering ladder (that is, the job descriptions and levels of an engineering organization) is a daunting task. If you do a half-hearted job, you're likely to cause more problems than you solve. The very first ladder I presented to my team was based on the ladder at Foursquare*. It was very simple, with one or two descriptive elements per "attribute" of engineering (technical skill, communication skill, etc), and by all accounts worked very well for their team. I hoped that this style of providing fewer details would result in people being less obsessed with the ladder, less likely to try to negotiate their level on "technicalities". Boy was I wrong. Almost immediately I had engineers debating me over whether they were at the right level, and there was a great deal of anxiety and confusion throughout the organization. I left room for generous interpretation, and it made it difficult for me to explain what I really wanted and expected.

In addition to the ladder causing problems inside of my team, we were having a hard time evaluating candidates during interviews and determining what level to hire them into. Particularly at the more senior levels, it wasn't clear what the criteria for success really looked like. So, together with my tech leads and engineering managers, we rewrote the ladder to be more specific. It has been very helpful both for the process of reviews and promotion committees as well as for the process of hiring.

I have since shared my ladder privately with several engineering managers around the country who were looking for inspiration, and today we're making it public for the benefit of all. I'm sharing this ladder not to suggest that it is the be-all end-all of engineering ladders, but to give you what I hope is a more thorough starting point than you might have seen elsewhere. After all, no one is really writing these ladders from scratch, whether we pull directly from other companies (as this one does at points), or indirectly from our past experience, so the more data points the merrier. 

Without further ado, I present our engineering ladder, in both spreadsheet, and long-winded text, warts and all. Please feel free to clone this ladder and update it for use in your own organizations.

 *A special thanks to Harry Heymann, Jason Liszka and Andrew Hogue, authors of the original Foursquare eng ladder!


ChatOps! Or, How I Learned to Stop Worrying and Love the 'Bot

I hope that when future historians look back on October 18th, 2013, they do not identify it as the start of the robot apocalypse.

On that date, I made the initial commit for Fashionator, Rent the Runway's Hubot instance. Until then, most of the communication from machine to human at RTR had been done via e-mail: service alerts, Nagios, Airbrake, and so on. We did have PagerDuty, but rather than having accounts for everyone, we had one shared account tied to a physical on-call iPhone. It was pink. I was led to believe it had been dropped in the toilet at least once. It was so noisy that most people turned off the ringer and just kept an eye on the deluge of e-mail devastating the inbox. I was not a fan.

To be clear: I didn't initially create our robot to solve this problem. Fashionator was born the way all Hubots are born, with community scripts to spam people in your company chat with animated GIFs clipped from '80s cartoons or pictures of put-upon looking pugs donning dollar store Halloween costumes. I figured the robot would be a welcome diversion from our fires rather than a tool to help extinguish them.

I don't remember the first useful script I added—it might have been one that checked Heroku's status, since we used to host some of our Sinatra applications there—but I remember the moment when people began to think of Fashionator as a productivity tool instead of as a distraction. A member of our product team asked one of the engineers to flush caches in the storefront stage environment. I said, "Fashionator can do that," and asked the robot to flush Memcached, which she did.

HipChat exploded. "I had no idea she could do that!" "What else can she do?" Pull requests started coming into the Fashionator repo over the next several days, and at our next hack day, I volunteered to help people hack on Hubot. Over several more hack days, scripts to automatically handle stage orders, query the PagerDuty API, write JIRA tickets, and deploy our WWW site to QA and stage environments appeared. We put her under Puppet's control and gave her her own Jenkins deploy pipeline.

The benefits of maintaining Fashionator have been surprising and tremendous. The centralization of communication afforded by having her in HipChat, where most of us spend our day anyway, means that we see alerts and deploy announcements immediately; if there's an incident, we can gather in our war room and ask if there are problems with GitHub, find out who's on call, search JIRA tickets if we suspect a recent change has broken something, and more. Fashionator also increases transparency and accountability, since everyone can see (or review in HipChat logs) what she's doing and who asked her to do it. Improved communication facilitated by our Hubot has made us better at everything from identifying and fixing bugs to onboarding, and with API integration with GitHub, Jenkins, JIRA, PagerDuty, and more, we're constantly making it faster and easier to share knowledge and get things done.

There are, of course, still times when she's bad:

But Fashionator has become an integral part of our lives at Rent the Runway, and we couldn't imagine working without her.

If you'd like to download your own Hubot, you can find instructions here and a repository of community scripts here.


Bridging the Design-Development Divide

As a user experience designer (and occasional developer) at a tech startup, I’ve seen many different types of friction between designers and developers. Designs handed off to engineers may be missing critical functional or visual specifications, include patterns that diverge from existing styles, or specify things that are overly costly to implement. Code created from designs may change flows unexpectedly, stick to existing patterns when new ones are needed, or not deliver the pixel perfection that designers expect.

When our team began work on a rebrand, I was focused on keeping these issues to a minimum. How could we communicate effectively to see a new look and feel come to life?

Initially, it was an easy sell to convince the design and tech teams that we needed a style guide: a living document to keep us in sync on how to use our new styles.

On the design team, our challenge was to take a brand package and bring it to life in a consistent, cohesive way across our website, app, stores, and packaging. We knew that ultimately each designer could not start from scratch on every new project, but we wanted to give ourselves the time to let our imaginations run wild and play with the new visuals.

To do this, we held design hack days, where we cloistered the design team in a room, uninterrupted, to envision where this new direction could take us. After several days, we had dozens of beautiful new concepts, but we hadn’t figured out all the nitty gritty details, so we continued working individually to flesh out different touchpoints.

I brought the design team together to create the style guide. It started as a Sketch file, where I gathered common elements and left blanks for components we needed to add.

  An early Sketch file we deliberated over

 

An early Sketch file we deliberated over

As individual team members worked on different touchpoints, we met to hash out each component of the guide. How were we using fonts? Colors? What signified interaction? We debated details like inner shadow on inputs, button states, and font hierarchy; we worked as a team to agree on a set of visual and interactive styles that contained enough variety to serve our many needs, but no more. These styles filtered back into individual projects so designers stayed on the same page.

As the design team solidified the styles, I coded the guide and published it online. Then, I worked with our developers to make it more useful. I added SASS variables, HTML elements, and CSS classes for quick reference. I also added our designers’ descriptions of how to choose between styles and make design decisions for the site.

Swatches, names, hex codes, and SASS variables live together in our style guide

Swatches, names, hex codes, and SASS variables live together in our style guide

Although we had gotten buy in to create the style guide, there was a period of time where it felt like nothing visible was being accomplished. In a sense, this was true – we weren’t changing styles on the site until we settled on our guidelines. However, the payoff for having a guide soon became clear.

As designers worked on the rebrand, we avoided recreating the wheel on each page – we stuck to visual treatments and interactive patterns we had collaborated on. Since there were relatively few treatments, we were able to cut down the need for detailed specifications. We could tell a developer “this is a title” or “this is sage” and know that they had an easy reference to check against.

Styles reserved for editorial usage

Styles reserved for editorial usage

Our guide also streamlined work for our developers, who were newly empowered to take a first pass at design and make design decisions without always needing a designer. Our new styles were both more semantic and more consistent, so we were also able to cut down on bulky HTML and CSS.

On our office wall, there’s a poster imploring us to “Move fast and break things,” and I do love the attitude that we should always be pushing fearlessly forward and trying new things. That said, we shouldn’t only focus on tangible output.

To work well together as designers and developers, we need to be willing to invest time in communication – to learn what the other side really cares about, what they’re willing to compromise on, and how to express our point of view in a way they understand.

The style guide continues to evolve as a conversation between designers and developers. In our next iteration, we plan to tackle responsive font styles. I’m sure there will be plenty of debate about how things should work. Ultimately, I believe the upfront time will be worth it, that we’ll avoid friction and communication overhead to see a shinier product with the same effort.