We Invite Everyone at Etsy to Do an Engineering Rotation
codeascraft.com
codeascraft.com
"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.
Obviously the direct output isn't great but the experience is always beneficial.
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.
"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...
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.
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 is often seen as a burden/cost, and the employees expendable. Unless the company thinks differently, then you'll have issues.
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.
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.
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?
That actually probably works pretty well, but I have done my time in a call center and never want to go back.
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.
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.
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.
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.
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.
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.
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).
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.)
At the places/projects that have these policies, (and whenever possible) software won't (or shouldn't) be rocket surgery.
"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.
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.
It's a key part of our 1st day push program: https://codeascraft.com/2012/03/13/making-it-virtually-easy-...
Also it would violate my first rule of engineering which is: "Never build a CMS"
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.
Rotations are a wonderful idea and, IMO, should be done more regularly.
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.