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.
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...
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!
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...
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."
Zappos seems to stress a rock star image of it's executives and that it has a "family atmosphere". Meanwhile they pay low wages to their customer service and warehouse employees. It's really hard to believe they truly care while paying employees barely enough to stay afloat.
This is pretty typical of all call centers. Most employees bond together to create a "work family", while they while away the hours until they find something better.
The cynic in me says
(i) having "everyone, even the CEO" help out with customer support is a good motivational device to emphasise in what might in every other respect be a substandard customer support working environment
(ii) paying regular customer support staff at the low end of market rates is one way of recovering the imputed financial loss of having your $100/hour senior engineers and top bizdev staff focusing a part of their working year on basic customer support queries...
In my experience People don't dislike helping others, people dislike getting yelled at. No matter how good Zappos is, their CSRs will get yelled at, and I think everyone has a right to not enjoy getting yelled at, I sure don't enjoy it.
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.
> 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?
Customer service & tech support departments often suffer from broken communication and lack of resources. I'd rather resources be devoted to improving communication and documentation between customer service and other departments. It's kind of a novelty to have people who shouldn't be on the phones or who don't want to be on the phones taking customer calls. Perhaps you'll get lip service that things will change, but those promises fade as quickly they are off the phones.
Customer service is often seen as a burden/cost, and the employees expendable. Unless the company thinks differently, then you'll have issues.
"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.
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?
If management is going to be realistic, they can't leave deadlines unadjusted and still expect rotations through other departments.
But if you want a good business, you need to cross-train, which means this sort of rotation. That's something Toyota learned, something Etsy has learned, and something Microsoft inadvertantly reinvented if by accident.
That makes the assumption that zappos has tight-deadline projects that take priority over taking care of their customers. If they're truly a customer comes first type company, they'll make room to take care of the CSR.
I think sales may be more important. Getting an appreciation for how hard it is to get a customer would alter how a lot of engineers think about features. Customer service is honestly easy in comparison.
Agreed, but one huge problem here is that getting a customer often requires more than a checklist of features, but rather a product that solves a customer's problem well.
I agree that sales, support, and engineering should all have rotations. The sales and support give you very different insights into what customers need which help you out with your engineering.
At the first software job I had (94-97), every engineer was expected to do customer support on rotation. Typically it amounted to one day a fortnight. I found it to be hugely helpful, in particular the software we were building (Desktop GIS) wasn't something that I was going to use myself, so understanding what the users got hung up on was really helpful. We could also be pretty responsive, it wasn't unusual to just fix a bug either while on the phone to someone, or within an hour or so of getting off the phone, and then we could just dump in on our BBS and tell them to dial-up and download it...
Everyone in the company does these as well (our CEO Chad answered did his holiday rotation a couple weeks ago), typically during the holiday season when we slow down our deploys and our support volume increases. But we're encouraged as engineers to do them once a quarter.
I don't know if it's more important, but I agree with the sentiment that customer service rotations are extremely important. Nothing brings your brilliant head-in-the-clouds engineering ego crashing down to earth like reading an email from a frustrated user who can't figure out how to get (what you thought was) your brilliant product working right.
I agree. Understanding the customer is a key principle of good business. To paraphrase Ducker, you're selling satisfaction to the customer, and if you're building it, you should know what makes for a happy customer.
If you truly feel that way, then I honestly am curious as to why you get up in the morning. Dogfooding, and listening to customer problems and feedback are two of the best ways of making your product better for everyone. A few hours on the phone, or responding to emails is fantastic for breaking up preconceived notions as to what people are doing with your project, and can give new ideas.
A superficially boring issue like someone who doesn't know how to fucking google it could be a much more interesting problem. Is your program laid out well? Is there some hitch in the workflow that you're not noticing because you've gotten accustomed to some misfeature? Are they trying to do something with the software that you didn't intend, but could make good money at by offering as a companion product, or other upgrade? These are things that support can teach you, because you're actively engaging with someone who has a problem.
I love to solve interesting problems as much as any hacker, but software businesses are about helping people and when people are having trouble using their computer then that is part of the job. I think it's worth to spend 1% of your work time on customer support to gain an understanding of that on a deep, visceral level.
Different leadership roles in our company spend the occasional day on different teams. Whether that be IT on the phone doing sales or someone from engineering writing ad copy, etc.
Obviously the direct output isn't great but the experience is always beneficial.
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.
You're not performing surgery and you're not arguing in court. You're making many mostly-trivial changes to a website, and that process should be trivial enough that it can be learned in a day.
Having people deploy on their first day is a check on the complexity of the process as much as it is intended to educate new employees.
(n.b. I don't work for Etsy anymore, but I still feel compelled to go to the mat on this thing.)
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.
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.
> 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.
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.
> 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).
Most isn't all tho! At any time I can come up with a dozen really small fixes. Changing the timing of a task, updating a string, or any other small things that are always hanging around.
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?
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.
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?
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.
I assume it's more about understanding the processes. Once they understand how everything works, they probably just add the image to the code base and add an html tag to the about page. Nothing complicated, and it doesn't sound like they are really "coding" but it seems like the idea is more to give them some perspective on how the engineering team works.
One answer is that it's convenient to have the task around for engineer first-day deploys, which serve a greater purpose.
A second answer is building a database-backed CMS to replace editing html for every dumb page on the site would be a boondoggle and not an improvement.
Indeed. I've seen this in academic labs as well that have a lot of undergrads exposed to research - deliberately keeping something undone, or less efficient than it might be to have an experienced postdoc do it, do that someone without a lot of experience can get their feet wet without having to try and tackle a full-blown project (coding or otherwise).
"This is what we do and how we do it" with a non-critical system that's approachable seems to be a great way to set up rotations.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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!
"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.