
We Invite Everyone at Etsy to Do an Engineering Rotation - kevingessner
https://codeascraft.com/2014/12/22/engineering-rotation/
======
karmacondon
I'm a huge fan of cross disciplinary rotations of all types. A startup
company, or any organization, should act as a unified whole. "It's not my
problem" is not an option, especially when the company is small and the stakes
are high. Sales depends on engineering which depends on support and
management, an interconnected web. Rotations build empathy, lead to innovative
thinking from outside perspectives and give people greater context. I've
proposed them at several of my past jobs only to be shot down each time. It
says a lot about the management of Etsy that they encourage designers and
product managers to do a rotation on the coding side, when I wasn't able to
convince my team leaders to let php developers from one project rotate to work
on another.

"Human resources" has come to mean paperwork and discipline, but the real
value of the term is much closer to its literal meaning. Developing peoples'
innate capability is very important. Any company can compete to hire the "best
people", but the really smart companies put that effort into increasing the
value of the people that they have. The capacity of the human mind is one of
the broadest and most versatile things in the universe, but most of us quickly
settle into limiting patterns of thought. Just a few days of seeing things
from a new perspective can make all the difference in the world. Etsy's
engineering rotations seem like fun, but I think they will pay off in a big
way. It's hard to put a number on increasing teamwork and understanding.
Programs like this are a great way to maximize that value.

------
robertwalsh0
I loved everything about this article. At my company, we've also found that
providing spaces where people are able to work in a cross-disciplinary fashion
gives the opportunity for innovative ideas. Every Thursday, a team member is
paired with another from somewhere else in the company. While say, a marketing
person can get to learn tech – it's also very rewarding to an engineer to be
able to work with a marketer or a sales person to see that side of the
business. Exposing a marketer to engineering may help her have epiphanies
like, "i might be able to track how effective my last campaign was by doing X"
and an engineer might think about things that could be added to a feature to
maximize user growth. We wrote a blog post about our intra-company pairing
here: [http://blog.scholasticahq.com/post/91759651948/pairing-
thurs...](http://blog.scholasticahq.com/post/91759651948/pairing-thursdays-
how-we-keep-our-team-sharp-by#.VJhVvsABA)

------
pvnick
That is just the coolest idea ever. For non-engineers, software can be a sort
of black box filled with "code," whatever that means. This knowledge gap
frequently leads to conflicts when engineers take longer to build a feature
than non-engineers would like, or when things break that just seem so simple.
Getting everybody involved in the deliberate, painstaking process of writing
quality software is a fantastic way to ensure the everybody is on-board with
the way code is written and minimizes interdepartmental friction. Kudos to
Etsy!

------
Wonnk13
Great idea. I'd love to see a writeup about a rotation in the other direction,
ie give engineers a taste of the business side of the house. As a data
scientist I speak a lot with Sales and Engineering and sometimes the two teams
seem worlds apart...

~~~
lexap
A customer service rotation for everyone in the company is more important.

~~~
stevesearer
Zappos does this and their customer service is some of the best in the
business:

"Each new employee goes through a rigorous month-long training that focuses on
nothing but customer service. They spend 40 hours on the phones helping our
customers because regardless of the specific department they were hired for,
customer service is the priority. Each holiday season when call volume goes
up, everyone in the company pitches in and jumps on the phones because we want
to maintain the same level of service no matter how busy it gets."

[http://www.zapposinsights.com/blog/item/zappos-insights-
anno...](http://www.zapposinsights.com/blog/item/zappos-insights-announces-
its-latest-offering-in-culture-and-customer-service-training-the-school-of-
wow)

~~~
paulhauggis
So instead of temporary staff, they take people off of their current projects
to work in customer service?? This doesn't sound like a good idea to me.

Especially since I've been in positions where I have been on tight deadlines.
The most likely outcome in this scenario is that the employee will not only
have to get their customer service rotations done, but also get their tight-
deadline project done. With me, it's difficult to move from customer service
right back to software development/engineering.

~~~
einhverfr
> So instead of temporary staff, they take people off of their current
> projects to work in customer service?? This doesn't sound like a good idea
> to me.

Why not? It improves solidarity. Actually when I worked at Microsoft doing
tech support, I got pulled _off_ the phones to help with sudden mandatory tech
support rotations due to virus outbreaks. It was great to see marketing
managers have to help people assess whether their systems were infected and
apply appropriate tools. I would take escallations but generally people did a
good job. (Oh and these people showed up with very little training on customer
service or tech support so that was fun).

But I think one thing that Microsoft got out of it (this was in 2002-2003) was
a stronger sense by everyone why it was important to focus more on system
security. I think this improved the company and lead to better software.

> Especially since I've been in positions where I have been on tight
> deadlines.

If management know of the rotation, they will have to adjust the deadlines.
How many deadlines are really necessary beyond a simple measurement rationale?
Management can usually adjust as needed, or reschedule the rotation to a
better point.

> With me, it's difficult to move from customer service right back to software
> development/engineering.

Isn't the point though to ensure that people are engineering and developing
software with customer service in mind?

~~~
paulhauggis
"Why not? It improves solidarity."

There are plenty of better ways to do this.

"I got pulled off the phones to help with sudden mandatory tech support
rotations due to virus outbreaks."

It doesn't sound like you are in any kind of engineering role. When you are on
the phones, you don't have one large project to work on with deadlines and due
dates. It's easy for you to be shifted over to another position.

"If management know of the rotation, they will have to adjust the deadlines.
How many deadlines are really necessary beyond a simple measurement rationale?
Management can usually adjust as needed, or reschedule the rotation to a
better point."

This sounds like a nightmare to deal with. In addition to tight deadlines as a
manager, I now have to deal with customer service rotations?? It's hard enough
to get projects completed with upper management changing scope (which has
happened at pretty much any place I've worked over the last 15 years).

"Isn't the point though to ensure that people are engineering and developing
software with customer service in mind?"

I'm fine with this as long as management realizes that deadlines will need to
change and it might take a couple of days (or even a week) to get back into
the flow of a project that an engineer/developer has been taken off for
customer support. In my experience, management doesn't know or care about
either of these things and thinks you can just move people around when needed.

I'm glad I run my own company now, so I don't have to deal with this bullshit
any longer. I would never implement something like this.

~~~
hhandoko
I think the better way to put it is: it improves empathy.

More often than not, in large teams or organisations there is often a culture
of blame or lack of accountability. I believe these exercises do help to
foster greater teamwork and a sense of ownership (of the business).

I would assume from the fact that you run your own business, surely in the
early stages you would have to take on multiple roles / responsibilities?

------
frostmatthew
I like the rotation idea, but I can't say I see much logic in the desire to
have new engineers deploy to production on their first day mentioned/linked in
the opening. At VMware (or at least on my team) we try to have new engineers
commit code their first week (this doesn't always work out, and when it does
it's usually the 4th or 5th day) and I almost feel that's too soon...first day
just seems nuts.

You don't see this in other professions, e.g. I doubt doctors are performing
surgery or lawyers are going to court on their first day at a new hospital or
firm. I'm just not seeing the value in having someone commit code before
they're possibly familiar with the codebase and [unless it's a product they
used before getting hired] may be equally unfamiliar with what the product
even does.

~~~
rahij
In my experience, I think it has more to do with getting an engineer
acquainted with the pipeline from writing code to getting it live on
production. Once he/she is familiar with this, it takes a huge barrier out of
the way for the person to be productive whenever they are ready to write some
non trivial code in the codebase.

~~~
enjo
That's exactly right. It's not about pushing meaningful or complex code to
production, it's about pushing a small change so that a new engineer can see
the whole process from end-to-end.

We do have people push on their first day here at Gridium and I think it's
really beneficial. The new engineer sees how we work, and the rest of the team
sees that new name in the git logs, on chat, and everywhere else. It sends a
strong message that there is a new _member_ of the team who is going to be
contributing from now on. It helps to establish cultural norms (everyone makes
a big deal out of that first commit which is fun).

I really like the effect it has on our team. Even changing two characters in a
string feels like a big deal and that's awesome.

~~~
frostmatthew
> it's about pushing a small change so that a new engineer can see the whole
> process from end-to-end

Is that really an accurate portrayal of the process though? Most changes
aren't small and take days of development, not minutes or hours. Not to
mention code reviews and QA.

~~~
mcfunley
Yes, it really is an accurate portrayal of the process. Etsy isn't pushing
days of development out in a deploy. That would be considered poor practice at
Etsy.

To make a sizable feature live, you use a bunch of methods in cooperation:

* Only mutate a bare minimum number of executed lines as code deploys.

* Turn features on and off quickly with (much faster) config deploys.

* Release and test features for internal users first (in production).

* Ramp features up to small amounts of production traffic at a time.

* Deploy new code paths and queries so that they're executed, but aren't visible to end users. (You can use this to detect performance problems early.)

But what you never do is sit on days of sizable code changes that you don't
deploy. If you try to deploy a massive diff people in your push will generally
suggest that you not do it.

~~~
frostmatthew
> But what you never do is sit on days of sizable code changes that you don't
> deploy.

That's certainly sensible but I wasn't suggesting sitting on "days of sizable
code changes" \- just that it takes days to make the code changes
(particularly once you factor in code review and QA).

------
zavulon
It's a great idea, but I'm having difficulty understanding the specific task
non-coding employees are doing: adding their own photo to Staff page.
Shouldn't there be a nice user-friendly back-end interface that would let them
do that in about 10 seconds without any code knowledge?

~~~
kellanem
We actively resist automating this process. Because of the way Etsy
development is structured this gap gets fixed periodically and then we have to
go back and un-automate it.

It's a key part of our 1st day push program:
[https://codeascraft.com/2012/03/13/making-it-virtually-
easy-...](https://codeascraft.com/2012/03/13/making-it-virtually-easy-to-
deploy-on-day-one/)

Also it would violate my first rule of engineering which is: "Never build a
CMS"

~~~
zavulon
Thanks for the explanation. Totally agree with "Never build a CMS" rule. But
why not use a pre-built CMS in the first place? Either use Wordpress, or a CMS
plugin for your framework if you're using something like ROR. If you're not
using a CMS, how are you updating the copy on pages like About? Does that
process require a developer each time?

~~~
chucklarge
The Etsy blogs use Wordpress, so we do use existing third-party tools where is
makes sense.

Kellan might have a rule to not build a CMS but we certainly have built one to
manage help page content and other knowledge base pages. That content is
largely managed by our support staff.

I wrote the current tool but it is actively being replaced. We chose to to
roll our own since we'd have to do some work to integrate a third party tool
into our database architecture and authentication system. The tool is heavily
integrated into other internal tooling and has specific workflows that also
make using an existing tool challenging.

The About page content is largely static, aside from the staff photos
mentioned in the above post.

------
drderidder
Kudos to Etsy for doing this. I think there's great value in learning basic
programming skills even if not everyone has the inclination to become a
software designer. Kind of like how taking music lessons has all kinds of
tangential value even if the student doesn't turn out to be another Van
Cliburn.

------
pnathan
I'm continually impressed by Etsy Engineering's descriptions of their
practices and process.

Rotations are a wonderful idea and, IMO, should be done more regularly.

~~~
code_duck
Their descriptions of their practices and processes are the best part about
their practices and processes. For all of Etsy's talk about how wonderful they
and the enlightened philosophies that drive them are, it's very hard to see
evidence of this working with them as a customer or developer.

------
badmadrad
From a UI perspective, I don't love Etsy but I think they really have a world
class engineering team. This not the first time I've heard of good things from
that outfit.

------
hw
As much as the rotation idea is interesting, and can be beneficial on the
surface, I'm not sure if doing so on a recurring basis provides more value
than interruption and the setup/teardown costs of context switching.

Sure, a non engineer could learn a thing or two about how code works, and an
engineer as well on handling support, but I'd be cautious about these sessions
leading to a false sense of understanding how things actually work, which
might eventually lead to, for example, a support person making wrong
assumptions about an issue a customer is having just because he/she paired on
the relevant code base.

IMO cross disciplinary 'rotations' should happen naturally, instead of making
it explicit on a certain day in the quarter. Engineers should have exposure on
a day to day basis on what customers want as well as have exposure to the
product and business side of things in the planning stage of a sprint,
understanding why a story or task is prioritized the way they are, etc. Same
goes for non engineers like product managers or support personnel who often
deal with engineers on an ongoing basis, and the sharing of technical
knowledge should come naturally with each discussion.

------
Havoc
Wish my employer had that. I'd kill for an engineering / IT dev
rotation...since those we're close 2nd & 3rd on my choice of career.

~~~
Kiro
What's your current career?

~~~
Havoc
Finance.

------
pkaye
I wonder how to do this with engineering that requires deep knowledge. At my
work we have SoC designers, layout, analog designers, board layout and
firmware among the engineering departments. I don't think we can even rotate
within the engineering departments as everything is so specialized.

------
radicalbyte
It's not just tech companies doing this. At Volvo we did it as part of our
continuous integration process. It was great fun, it really helped you to
understand the business better.

~~~
Fomite
Many academic departments do this as well, to give people exposure to lots of
different projects in their first few years of graduate school.

------
sytelus
This should be also applied to within engineering teams as well. Employees
when encouraged to move from team to team after certain intervals (such as 3-4
years). There has been argument that this doesn't allow people to specialize
but I feel 3-4 years is long time after which returns are probably diminishing
in developing specialization. This keeps life interesting and you get insights
on how other teams work, their process and tools etc.

------
gohrt
Thank you for not putting "Why" at the beginning of the article title.

------
deepGem
This is really cool. What would be awesome is a design rotation for engineers.
The way some of the top designers work is a joy to experience. Even their
scratch book looks so well organized.

------
kevinSuttle
So many parallels to other industries. The greatest chefs often describe how
they'd held every job in a restaurant before becoming chefs.

------
logicallee
This is like an opera company inviting everyone - altos, contraltos, baritone
and bass male singers, the conductor, the symphony orchestra - to do a
rotation as a soprano singer.

------
frsandstone
This is awesome.

------
productcontrol
It is true, i used to clean the bathrooms there and i went on code rotation,
or as we called it "stink patrol". I thought the stalls were bad, but man,
that codebase was far worse!

