Today marks the end of a three-year journey I’ve taken with Groupon. I could write at length about my wonderful experience here, but I think it’d more useful to share some of the valuable lessons I’ve learned along the way. So here are a few of them, in no particular order:
Good management is extremely multi-dimensional
I’ve had the privilege of working with extremely effective managers at Groupon. Across the board, I’ve noticed that they:
- request honest feedback, and receive it without defensiveness. They encourage feedback by creating safe spaces to give it, such as in regular team retrospective meetings, in one-on-ones with direct reports, and via anonymized 360° reviews. I cannot recall a single time I’ve given feedback to a manager after which they’ve argued with me or attempted to defend themelves. Nothing is taken personally, which allows for refreshingly honest conversations.
- give honest feedback, and encourage teammates to do so as well. I remember being told, during one mid-year review, that my peers felt that elements of my code quality needed improvement. In many places of employment, this would be a bit disheartening to hear. But at Groupon, my manager talked with me about specific things I could do to address this: a mentor I could pair-program with on a particular problem, blog posts I could read that were useful for the areas of improvement, etc. As a result, I found myself feeling excited to learn about coding patterns, rather than feeling self-conscious about my abilities.
- create a growth vision for me. This means painting a picture of my potential career growth, providing big shoes for me to fill so as to realize that picture, and then advising and backing me as I awkwardly try to fill those big shoes.
- connect my daily work with the company’s mission. This is tightly related to growth vision. One of my previous managers in particular used to talk about three-tiered alignment between Groupon’s mission, my immediate team’s charter, and my personal goals. This created a frictionless work environment in which I always had a strong sense of what was in vs. out of scope, and what areas of career growth I would receive the most support from management in.
Interviews are most useful when they bring out the best in candidates
Most people who work in engineering have heard (or experienced) horror stories of entitled, arrogant engineering interviewers trying to trip up interviewees and then belittling them when they make mistakes. Fortunately, Groupon’s recruiting staff is very aware of this problem, and has taken deliberate steps to make our interview process more effective.
Before giving any interviews to candidates, Groupon engineers are required to participate in thorough, thoughtful interviewing trainings. One element of the training that particularly impressed me was the focus on making sure a candidate feels comfortable during the interview. This should be obvious, but it turns out that most interviewers don’t think about this unless specifically prompted to.
This idea, in my opinion, is based on the premise that tech interviews are unfortunately a bit inherently flawed. Tech interviews test candidates on their technical abilities in an environment in which they’ll never actually work: that is, with an employee over their shoulder, watching them code, and all the while deciding whether or not they deserve a job at the company. Not many people perform at their best in that environment! And those that do aren’t necessarily the most qualified developers: being able to write code while someone watches and evaluates you is a very different skill set from being able to write code that meets a team’s and company’s needs on a daily basis.
So the culture of interviewing at Groupon was focused on ensuring that a candidate feels at home during a technical interview. I often would tell candidates to treat me as a coworker while coding on a problem – that is, to talk through their thought process verbally, to ask me questions to the extent that I can answer them, to Google things when it makes sense to, etc. The result is that I was able to get a sense of what it would be like to actually work with the candidate day-to-day, which is far more useful interview feedback than whether they can uncover traps I’ve laid for them while I berate their coding ability.
Software development is about so, so much more than writing code
I think that learning this lesson was necessitated by the fact of working at a huge, international corporation. I’ve observed that the most successful developers at Groupon – and by successful, I mean those who are first to be promoted, are granted the most autonomy, and tend to have the most influence over significant engineering-related decisions – are those who understand the anatomy of a large company. They are those who understand that interpersonal/-departmental interactions don’t function in the same deterministic, “tidy” way that code does.
The challenge is that it is in the nature of software engineering to encourage engineers (or at least, junior engineers) to think about problem-solving in a very specific, narrow way: I’m given a task, and I have specific tools with which I can complete it. But being successful at a large company like Groupon requires also working with people, not just code.
With teams distributed around the world that each have their own viewpoints and codebases and timezones and concerns, being a successful software engineer thus requires that you learn additional tools. Among others, these include:
- building consensus
- demonstrating empathy for other individuals’ and teams’ concerns (which makes consensus-building much easier)
- using video conferencing effectively
- understanding that being “right” comes second to being respectful
- signal-boosting the voices of those who aren’t often heard
- thinking about long-term code sustainability
- getting buy-in from others on new ideas
- balancing “geeking out” with shipping code
- mentoring less experienced devs
- seeking mentorship from more experienced devs
- iterating on team processes
- maintaining open and honest communication among team members
I’m sure there are many others, and I certainly don’t claim to master all of these. But it’s been educational for me to see these tools in use at Groupon, and they have in turn become criteria I use when interviewing candidates for senior positions.
Career growth doesn’t have to mean moving into management
I, like most other developers I’ve worked with, really like writing code. And it doesn’t make sense to us that, the better of a developer you are, the more likely you are to be “promoted” into a management role where you’ll no longer get to write any code. What a waste of a great developer! And furthermore, the skills required to be an effective engineer have limited overlap with the skills required to be an effective manager. As my former manager Chris Powers mentioned in his great talk on making the switch from developer to manager, asking a developer to manage a team is reminiscent of the Mitch Hedberg joke, “Oh, so you’re a chef! Can you farm?”
That’s why Groupon doesn’t force engineers into managerial roles when they’re promoted. You can instead work your way up the software engineering ladder by growing technically and by learning to contribute effectively to the company’s engineering organization.
Prior to Groupon, I had worked primarily as a solo developer, with only Google to consult when I wanted to learn about some new technology or best practice. I joined Groupon in part so that I could be surrounded by experienced devs from whom I would learn and grow technically. And while I’ve had the privilege of being surrounded by some of the most talented devs I’ve ever met, I’ve found that it didn’t just make me a better “code-writer”: it also taught me what it means to be an effective contributor to an engineering organization and a whole company.
So while I’m excited for my next opportunity, I’ll always look back fondly on my time at Groupon. And when I mention Groupon’s name in writing, it’ll continue to be accompanied by Unicode code point U+1F49A. 💚