Maker to Manager: Interview with Director of Engineering at Dribbble
In the Developer Interview series, we talk to engineers who use Semaphore and pick their brains about how they work, what wisdom they would like to pass on, and the most challenging problems they’ve faced during developing.
This month, we had a chat with Jeffrey Chupp, the Director of Engineering at Dribbble.
You joined Dribbble in 2015 as a part of the development team, and currently your job title is Director of Engineering. What was the most challenging part of this transition from a “hands-on experience” developer to a more business-related/strategic role?
I think my experience has been fairly typical of people moving from maker to manager roles: the hardest part for me has been getting comfortable with the change in how my value is determined. When I was purely a developer, my value was easy to measure in terms of my speed and the quality of the features I worked on. Now my value is measured in how effective my teammates are.
That’s a lot fuzzier and harder to quantify – you have to take a much more zoomed-out view. And you aren’t great at being a manager at first because the skill set is so different from the developer skill set.
Because of how difficult it is to quantify your value as a manager and because you aren’t great at it yet, it is tempting to fall back into the maker role for that dopamine hit that comes from the visible progress of shipping code.
That temptation hasn’t gone away entirely but I’m making good progress rewiring my brain to get that same feeling by amplifying my teammates. It helps that I have great teammates.
I understand that this change has a lot to do with Dribbble scaling its engineering team. Dribbble is a 100% remote team, and one of your co-founders, Dan Cederholm, admits in an Interview that for ... a tiny, bootstrapped operation, the scaling has been a challenge. Can you tell us more about what are the biggest challenges in terms of scaling a remote engineering team?
You’re exactly right, I was promoted internally because of growth. We’re still growing (shameless plug: come work with us!).
I think remote jobs have a huge advantage in hiring: When location isn’t a factor, you can hire the best people from a much larger pool of candidates.
Asynchronous communication has been a challenge as we’ve grown our remote team. When you’re 8 people, interrupts are naturally capped by the small team size. Once you grow to 40-ish people and stretch across time zones (from the UK to California) things start to get trickier.
For example, when you’re co-located in an office, there are visual cues to help you see that someone is deeply focusing and shouldn’t be interrupted (e.g. Patrick has his headphones on and is typing furiously while squinting at his text editor). Working remotely, you have to be more deliberate about choosing the best method for communicating without breaking someone’s flow.
To minimize interrupts, we try to have as few scheduled meetings as possible to optimize for heads-down time. Monday and Friday are 100% meeting-free. Engineering has stand-up on Tuesday through Thursday to ensure face-to-face time with other engineers and do some knowledge sharing.
Our product teams have weekly sprint check-ins. Finally there’s a weekly company meeting. Beyond that we’ve landed on communicating heavily through our tools.
When it comes to scaling up a dev team, how much do you rely on management techniques, how much on company culture and how much on tooling?
This is a good question. I think our company culture drives all the other things you mention. Put simply, we try to hire excellent people then trust and empower them to do their best work.
If our company Slack is constant @channel and @here notifications, that’s not helping people do their best work. If our tools aren’t reliable and async-friendly, that’s not helping people do their best work. You see where I’m going with this. I try to get people to talk about the frictions they’re experiencing in 1:1s and then I own figuring out what steps we can take to reduce those frictions.
Our tools are mostly about facilitating async communication to get things done. Broadly speaking: Slack is where ideas are discussed before they become tasks in Flow. More discussion happens in Flow as-needed, and then a developer submits a pull-request on GitHub proposing a solution. More discussion happens in the PR. If the tests pass and the code is approved, things go to production.
Sometimes that process takes minutes and sometimes it happens across days. Being spread across time zones means it is common for a developer to submit a PR as they leave for the day, and find it already reviewed when they start work again the next day. That’s async at its best.
Speaking of tooling - Dribbble has been using Semaphore since 2013 - if you could point out a couple of specific Semaphore features that enable you to deliver your software and scale up without obstacles, what would those be?
Our Semaphore usage has been really boring – in a good way! We have a pretty vanilla Rails app and Semaphore “just works.” Everyone on the team feels comfortable using it, from hardcore backend developers to markup and style experts.
There are a couple features that have helped us scale: we make good use of Semaphore’s caching between builds and have our test suite split across multiple parallel jobs to help keep it speedy.
We’re curious to investigate Semaphore’s Docker support in the near future. We’ll keep ramping up our parallel jobs pool as we grow as well.
To what extent is a CI/CD tool such as Semaphore also a collaboration-empowering tool?
I appreciate how reliable Semaphore has been. This means that we get to focus on making our users happy, and don’t have to spend time trying to divine why our CI isn’t working.
With its GitHub integration, Semaphore adds to the PR conversation. We have a thorough test suite, so a green build gives us a high degree of confidence that the code changes aren’t going to have unexpected side effects.
What is your current focus when it comes to advancing the product and its dev infrastructure and why?
We have a lot of cool features on the roadmap for our users. My current focus is doubling-down on reducing frictions for my teammates and enabling them to be more productive so they can deliver on those features. Some practical applications of this include being hyper-aware of fixing missing technical documentation, flaky tests, and clarifying confusing parts of our ever-expanding codebase.
Things on my list to investigate in the short term are how we might be able to leverage continuous deployment, further speed up our test suite, and improve collaboration across product teams.
I took a peek at your side-project “Hall of stats”. I would love to see its equivalent when it comes to the NBA Hall of Fame. What was the main motivation behind it - was it just for fun, or were you on a mission to demonstrate that according to maths the National Baseball Hall of Fame should look differently?
Haha. You’re not the first one to request an NBA version of the Hall of Stats. I love that side-project. My BFF Adam Darowski is the brains behind all the goodness there.
Players get into the Hall of Fame via a voting process and (like all voting) the results are political and somewhat arbitrary. Adam felt it was worth exploring what a merit-based Hall might look like and he’s worked hard to refine a powerful (but simple) algorithm for determining qualification. You can read more about this on the Hall of Stats about page. The project has been hugely successful and I’ve been happy to help Adam work on it.
Fun fact: When I first saw a rendering of Babe Ruth’s stats chart for the Hall of Stats, I was convinced that something was broken in the code. I told Adam and he assured me that the code worked fine, Ruth was just that good.
Big thanks to Jeffrey for taking the time to answer our questions. Read our related articles below, and subscribe to our newsletter to keep up to speed with our future posts, updates and interviews.