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.


When Defining Reality, Don't Forget To Deliver Hope

I had a great 1-1 with one of my tech leads today, who came by my office hours and asked me for advice on becoming a better manager. I gave my usual rambling reply to broad inquiries; we talked about making personal connections, reading a lot of blogs and books, experimenting with different ways of asking questions to get people to reveal their true interests to you, so that you can better help to nurture and serve those interests.


But then, at the end, I had a thought. I asked him, how often do you talk to your team about what the future is about? How well do you know what the future of your team should be like? Not the product roadmap, which is in the capable hands of an amazing product lead, but the technical future. How to think about building systems that are future-thinking, becoming a better team, writing better code.

"Not that often" he admitted.

So, I persisted. How often do you spend some time away from your keyboard, away from the internet, away from meetings, and think about what you think the future of your team should be, the areas that you could focus on, the big opportunities for growth?

Again, the answer was "Not that often."

This is not at all surprising, of course. When you work in an industry where you focus on building out technical skills and getting more things done for the first many years of your career, making that shift into management (really a career change) can lead to the temptation to focus on solving today's problems now. Solving today's problems well is probably how you ended up rising into a tech lead role, and we all know that there is never a shortage of problems.

But when you focus on nothing but today's problems, even if you are a great manager who does everything right, you are unlikely to motivate your team to greatness, or inspire the level of loyalty and passion that makes a team gel and prosper. You are missing the one thing that you cannot overcome with great management skills. You're missing leadership.

You can be the greatest manager in the world, but without leadership and vision, your team will not be truly sticky to you. 

Fortunately, leadership is not a skill you have to be born with. It just requires that you identify the future and articulate it. "Define reality, give hope." Too often first-time tech managers focus on reality. We're comfortable with reality, reality is our bread and butter. But the future? Painting a vision for the future, even the future 6 months out, is a risk. You may not be able to deliver on that future vision. It may not be the right thing to do when the time comes. Reacting to today is so easy, and trying to predict the future seems really hard

But there's a simple (note: not easy) secret to breaking that habit and creating a vision: practice. Get away from your keyboard. Force yourself to sit in an empty room with a whiteboard or a pen and paper and write some ideas down. Grab a colleague or two to brainstorm with if you need to, but do some of the work by yourself. Then start painting that future to your team. This is the most important thing you can do to become a truly well-rounded manager, and if you aren't doing it, block your calendar tomorrow and start.

This originally appeared on Camille's blog, http://whilefalse.blogspot.com/


Analysis Paralysis

     I was unaware of this phrase until a friend and colleague mentioned it to me but I was well aware of the symptom.  So many options and choices where do I start?  I suppose I'll come back to it later or even start on a different project with a more obvious starting line.  I believe everyone at one time or another has come across this syndrome and it might have even hindered their production. 

     Personally, I get through this barrier using some other idioms.  I 'jump right in with both feet', 'throw everything at it and see what sticks' and 'move fast and break things'.  Hesitation only makes me think more and when beginning something, that might not be the best way.  Sure, a well thought out plan is great but rarely does anything in my experience end up exactly the way it was planned.

     I believe just knowing the phrase 'Analysis Paralysis' is the first step in conquering the problem.  At least now I have something to search for while I am avoiding what I really need to do...