What does a Director of Engineering do?
It’s difficult to explain my set of responsibilities without understanding the context of my role within our engineering team.
I’m responsible for thredUP’s Web and Mobile Engineering Teams. As a result, I work with our product, design, and marketing teams very closely.
Our engineering team also has a VP of Engineering who is responsible for thredUP’s Operations Engineering Team. He works very closely with our COO, VP of Analytics, and our merchandizing team.
Our engineering team does not have a conventional org. chart. Our VP of Engineering and I both report directly to our CTO. That might seem strange to some, but the intention is to position our engineering leadership team such that engineering leaders are directly interfacing with business units within the company that can leverage our engineering strengths in terms of competencies to maximize efficiency and output.
My journey to this position started when I joined thredUP in the summer of 2010 as a front-end Rails engineer. At this time, thredUP was a peer-to-peer (P2P) marketplace for used kids clothing. I was immersed in core feature development, conversion funnel optimization, A/B testing, customer acquisition efforts, and standard e-commerce functionality (cart/checkout/payment processing system).
One of the problems with a P2P marketplace is that you have to depend on your customers to deliver great experiences to your other customers. While you can help inform customers, you can’t control quality, timely shipping, etc.
In late 2011, we changed our business model to hold inventory so that we could deliver the experience we knew our customers wanted. This was a game-changer for us because when you hold inventory, you have to worry about inbound/outbound shipping logistics, inventory management, order fulfillment, order returns, and the workforce that will handle all the manual labor. No one on our engineering team had prior experience with the engineering systems required for operating a distribution center. This is when Michael Santhanam, formerly VP of Operations Engineering at Netflix, joined thredUP as our VP of Engineering.
Because he joined Netflix early, Michael knew what back-office systems were required and how to quickly build those systems with limited resources within the long-term vision of how those systems would need to exist at scale.
To give Michael the time he needed to accomplish this, Chris Homer, our CTO, continued to run our Web & Mobile Engineering Teams. As those teams grew and the demand of Chris’ time rose within the company, he needed to pass the torch of the day-to-day operations of the web & mobile teams to someone else.
At this time, I was the Lead Engineer for our Web Engineering Team. I ran point on our projects from a technical and project management perspective and I also managed a subset of engineers on the team. I led scrum, sprint retrospective, and was working with the team to scale and improve team processes and engineering culture. When he was needed elsewhere, Chris could rely on me to lead the team and our efforts, which is why I believe he passed the torch to me and promoted me to Director of Engineering in the summer of 2013.
Responsibilities
While there are a number of things I’m responsible for, there are two things that take higher priority than everything else.
The first is empowering the engineers I manage to make the biggest impact possible for the company while reaching their professional development goals. I believe the two of these are highly correlated to job satisfaction. thredUP’s emphasis on professional development is a big reason why it’s been over two years since our Web Engineering Team experienced any turnover.
The second is consistently delivering projects on-time with quality. If a project is behind schedule or the website is experiencing issues or an engineer is disheartened, I will refocus energy from other efforts (hiring, planning, etc.) to figure out how to get obstacles out of the way to get everything back on track.
If the business is healthy, our engineering efforts are on-time, and the teams are motivated, challenged, and moving towards their professional development goals, then all is right in my world.
Management
The majority of my time each week is spent on management, project planning, and project management, which are intertwined responsibilities for me.
Engineers need opportunities through projects to push themselves and reach their professional development goals. To arrange projects that align with these goals, I need to work with product to figure out the roadmaps for our teams. I also need to know when current projects are scheduled to be completed so I know when engineers will be available for new projects.
At thredUP, we call this engineering resource allocation. Each week I meet with our VP of Product, Head of Design, CTO, and CEO where I communicate the state of all of our web & mobile engineering efforts as well as discuss product’s current priorities and the upcoming roadmap. This is how I keep track of all of this:
This document is my sanity. I’ve tried out a number of expensive software solutions, but this simple Google Spreadsheet is the easiest to maintain. It keeps track of all of our efforts, when they started, when they’re slated to end, what engineers are working on them, and when engineers will be able to work on future projects. This knowledge fuels professional development opportunities for engineers.
Planning for a project typically starts with an architecture planning session. Product or myself will walk the engineers through the project’s background, purpose, and desired high-level execution. We then go into one of our brainstorming rooms where the entire wall is a whiteboard and we explore our options for how to architect the project.
Once we have our options, we use a number of inputs to determine which execution to use: is there a deadline? is this an experiment or do we believe this is here to stay? do we need to build for scale? is there an opportunity to pay down technical debt with one of these options?
After we determine the execution, we’ll bake out the project in detail followed by time estimating each effort. I’m usually creating Asana stories during this discussion so that any details that surface can be documented within the story’s description.
Next we’ll look at the project and figure out if the project should be broken into multiple milestones. When possible, we try to deploy these milestones to production over the course of the project so we can review code, test and release along the way.
At this point, the engineers on the project and I are on the same page, which means I can get started on project management. Once Asana is sorted, organized, and the engineering resource allocation document is updated, I’ll send out an email to our product team breaking down the project’s execution and the timing of how/when it will be released. As the project progresses, I’ll email comprehensive bi-weekly updates to inform everyone where we stand against plan.
When a project is nearing completion, the project is put onto one of our staging servers for testing. Once it’s ready to be released, we debrief our customer service team about the project and its potential impact on them and on our customers.
Deploys vary on the project, but the preference is for all engineers who worked on the project to be present and active in the deploy. Although we plan and test well, we’re always prepared to firefight. Once we deploy, we manually test the project in production and we’ll monitor the data flowing in until we’re confident everything is working as expected.
In regards to engineering management, the cofounder of RethinkDB wrote an excellent post on this topic that hits on all the major points that I focus on as a manager. On a side note, I highly recommend Clay Christensen’s How to Measure Your Life to any manager that wants to learn about the theory of motivating vs. incentivizing as well as dive into the contributing factors of what drives job satisfaction/dissatisfaction.
Hiring
I’ve found that hiring engineers in San Francisco is a very humbling endeavor. Performing countless phone screens followed by scheduling multi-hour interview loops that eat away at engineering throughput that more often than not results in dead ends can be very disheartening.
Despite this, I try to wipe my mental slate clean with every resume I come across since hiring the right engineers is paramount to scaling an engineering team, culture, and technology infrastructure.
The saving grace for us in our hiring efforts has been that our engineering teams have extremely low turnover. Our web team hasn’t had someone leave in over two years and our mobile team has only had one person leave in that same amount of time. Because the teams aren’t churning, we can be more calculated and patient with our hiring efforts.
When candidates moves past a phone screen and into the interview pipeline, my job is to assemble the right interviewing team to assess what we need to know about this candidate, which is unique to the candidate’s background and the position they’re interviewing for. Some engineers will be tasked with determining the candidate’s technical depth on certain technologies. Some will dive into the candidates approaches and explain difficult problems and whether their interpersonal skills are compatible with the team.
When I interview, I’m trying to find the red flags. Why did you leave your last job? Three jobs in four years, what’s the story there? What are your salary expectations? If the team is on board and no red flags appear, I switch gears and open up for questions. I try to be as transparent as possible so every candidate knows as much about the position, team, and company to ensure a two-way fit. If we hire someone and either party decides a couple months later it’s not a good fit, that’s a big waste of engineering resources (and money) ramping that engineer up. It’s also my job to sell that person on why it’s so great to work at thredUP (this is my favorite part because it’s the easiest).
For me, there’s no better feeling in hiring than getting through reference checks and completing negotiations with someone who you’re excited to join the team. Getting ready for their first day and watching the team welcome that new person like a family member gives me great pride for the engineering team and culture our team has worked so hard to build.
Being an Engineering Leader
Any engineering leadership activity I perform falls into one of two camps.
The first and more straightforward of the two is technical leadership.
Even though our VP of Engineering doesn’t actively code anymore, he is an excellent architect because of his prior engineering experience. For me, the majority of my professional engineering experience is from thredUP so I try to leverage my experience of our product, my application domain knowledge, and the history of previous engineering successes/failures for architecture planning sessions.
Another form of technical leadership is championing engineering initiatives. As our team, product, and infrastructure grows, issues arise consistently regarding systems/processes/environments that no longer work at our current scale. As a technical leader, I consider it my responsibility to find a solution to those issues (often with the help of the team) as well as putting together a plan of action to execute that solution. It’s really easy to identify pain points or systems that aren’t working well, but the leaders are those who influence outcomes by getting solutions for those issues prioritized.
Another way to be a technical leader is to rally behind another engineering leader for one of their initiatives. For example, Chris, our CTO, recently laid out his long-term technology roadmap and there are a lot of new technologies we’ll be using to build out his vision. I’ve found that whenever an engineering team is about to undergo a technology paradigm shift, it’s essential that everyone is pulling in the same direction, which starts with engineering leadership team leading by example. As one of the leaders, it’s my responsibility to study and learn these new technologies and help inform, motivate, and ramp up the team to be ready to contribute with the new technology stack.
The second and more nuanced part of engineering leadership is the soft skill side.
It’s hard to tell someone how I know when to rally the team or attempt to bolster morale. Having a good daily pulse of the team and all of our projects certainly helps, but a large part of being a leader is just perceiving the situation and knowing what to do. Knowing when to take charge and knowing when to sit back and let the team hammer it out.
Having said this, I don’t believe of all of the soft side is innate. My experience from when I was a contributor helps me to know when to push the team and when to pump the breaks. I’m able to emphasize with nasty bugs, scope creep, and burning out from grinding through long, hard projects because I’ve been there before. While I’m obviously biased, this is why I believe technical engineering managers are more suited for the job than non-technical engineering managers.
Conclusion
Being an engineering leader can be difficult. The hardest decisions and biggest messes always fall on your plate. It’s not a “check in at 9 and check out at 5” kind of job. It’s a “work until all the obstacles are removed for the teams” kind of job, which abides to no schedule.
While the workload can be demanding at times, being an engineering leader has been the most rewarding experience of my career. There’s never a day where I wake up and say “I don’t want to go to work today”. When I wake up, I think “I have a lot I want to accomplish today. I better get my ass into gear.”.
P.S. You might have noticed that I never said ‘my teams’ — this is intentional. While I am responsible for the teams and their actions, these are our teams. It’s not my website, it’s our website. It’s our iPhone and Android apps. Everything we’ve built, including the team itself, has been done together as a team.
