[Reprint] What does a Director of Engineering do?
I’ve been fortunate in my career to be part of organizations that have always constantly pushed me. When I started with the company I’m currently at, Roundtrip, I was a software engineer. At the time, Roundtrip, a company in the healthcare transportation space was an early state startup with six employees, including me. As the team grew the CTO, my direct manager, had to elevate himself to out of the day to day and so I was put into a leadership position out of necessity. My accountabilities and responsibilities changed but at the time my position in the organization chart didn’t.
I had no idea what the expectations were of me, but I knew I had to grow the team by finding engineers, handle technical and personal reviews and create processes to keep us moving forward. Aside from all that, I also had to figure out what responsibilities fell under my domain.
Three years on, I’m finally at a place where I feel confident talking about my accountabilities and the worth I feel this position brings to an organization. Recently, I challenged myself to mind map my role and break each part down into granular expectations (feel free to zoom, move and expand/collapse the map below).
My personal mission is to create a world class engineering team that create world class products. This starts from the individuals. Understanding and managing peoples motivations, emotions, skills and expectations, helping them set goals, removing personal and professional blockers and keeping them happy with their salary and their current roles are imperative to maintaining their focus and ensuring high quality output. I meet with my team individually on a weekly basis to keep a pulse on their needs and give them a platform to be heard.
To build the best team you have to find the best people. Each person you bring in should be better than at least half of of your existing team. This keeps the bar high and makes sure that everyone constantly feels challenged.
Recruiting goes beyond just position. I have to find personalities that match my teams needs. I do this by identifying the teams weaknesses and needs and finding people that complement them. If I have strong executors but am lacking in people leaders, I bring in someone who has that focus. Overall, I hire for an individuals strengths, not their lack of weaknesses. This ensures that I have a great, balanced team.
Defining the Engineering Growth Map
Progression is key to motivation. People need to know whats expected of them to keep challenging themselves. Theres a cliche, “dress for the position you want”. I encourage this behavior on my team too, in that by setting expectations and success profiles for every position and measuring them to this during 1-1s, theres a clearly defined career progression path and transparency around what they need to accomplish. If someone shows competency, promotion becomes obvious.
I used to think hard work leads to promotion. This is because I didn’t understand why different positions exist outside of a title change. Now I see things a bit differently. If an individual on my team is working hard, I’m going to keep them where they are because they’re getting the job done. Rather, I’m looking to elevate my 10x engineer - not the one that’s the doing their job well but the one thats mentoring those around them to do their job well too.
Enforcing Core Values
Core values are the main pulse for me to make sure individuals are the right people in their seats. For me it helps to be at an organization who’s values I believe. For example, Roundtrip has 5 values:
- Listening First
- Keeping it Simple
Holding myself and my peers accountable to these 5 values constantly helps keep the level of the team high.
Driving us towards our Mission
The best way to keep us all rowing in the same direction is to use the mission as our source of truth and guiding light. Every person, process and initiative should be measured against the mission to ensure it gets us one steps closer to achieving it.
As Roundtrip has grown, we use the mission to remind us of empathy. It’s easy to become a “growth organization” focused on clients on their needs, but for a mission driven organization trying to help the underserved by removing transportation as a barrier to healthcare, we need to remember that those that don’t significantly contribute to revenue numbers are just as important. It’s the responsibility of every leader to push this message constantly.
Software Development Lifecycle
A great Software Development Lifecycle (SDLC) helps us predictably and consistently deliver high quality software. Although I’ve been out of an execution role for a while, and every Director of Engineering likely has very little time for coding, I’m still accountable for how we get things done.
The right balance here is for me to focus on outputs, value and costs while letting my team focus on the outcomes. I’m responsible for reporting on how many hours it takes to create a feature, or how many points we can achieve per sprint, or how much it costs to keep my team running. I’m only able to manage what I can measure.
Scaling the Team
My accountabilities when scaling a team go in both direction. Downwards, theres a responsibility to my team to find them the right people and i’m putting them all in the right seats. Upwards, it’s about costs and optimizations. I have to fall within budget so that I contribute to the companies profitability. It’s easy to throw money at a problem, it’s much harder to solve it in a financially responsible way that helps the company grow leaner.
When a new team member joins us, I’m responsible for creating onboarding processes that give them the necessary context to set them up for success. I do this by breaking it down into 3 stages. The first stage is to make sure they “get it”. This means introducing them to the organization, problem scope and our existing processes. The next step is to make sure they “want it”. During this period of onboarding, I ensure the individual has the right motivations and drive. This is where I start measuring them against our core values and setting some goals for them. Finally, I make sure they “can do it”. Are they able to challenge the rest of the team? Are they bar raisers? Success for me is maintaining a process that constantly evolves to meet the needs of the team and my measure is having a healthy engineering culture.
Define Technical Strategy
The Roundtrip Technology team is split into 2 parts - Engineering and Product. Engineering focuses on the “how” and Product on the “what”. Although I’m not responsible for defining the product roadmap, it’s my responsibility to ensure that the challenges my team is facing are also addressed. We meet weekly to strategize on what things we need to be put on the roadmap, from fixing tech debt to infrastructure enhancements.
The other part of this is architecting the product to meet the ever changing needs of our clients. I used to be more heavily involved in the technical side of creating solutions, but recently I’ve had to elevate myself out of this to focus on other accountabilities and trust my team to do this.
Running a company is hard. Roundtrip has tried a few different systems to keep us rowing in the same direction, but the one that’s worked best for us is EOS. As a leader in the organization my responsibilities including running my teams L10 meetings which give me a weekly heart beat of how we’re doing and helps us work on the business not in the business so that we can identify and solve problems quickly.
Resourcing for the Roadmap
Ben Horowitz put it best when he defined the two stages of a company - peacetime and wartime. During peacetime, we experience extended periods of growth where we focus on building our product to create better processes for our customers. At this time, the Product team defines a roadmap and I have to make sure the Engineering team is resourced appropriately to ensure things get done. During wartime, for example when we’re in a recession, it’s time to optimize our roadmap and processes. During this time there’s likely restrictions on resourcing which means the Product team has to define a roadmap based on the resources we have available. At this time it’s more about focusing on initiatives that drive revenue and client retention and acquisition so my accountabilities shift from finding the right people for the work to staying as budget neutral as possible by finding the right work for the people we already have.
As a Director of Engineering, I have to make sure we’re delivering consistently. If there’s a barrier to this I have to coach my team through this. Deployments are usually the last, and hardest part to delivering software so a lot of my focus goes in to making sure we have a solid process in place.
I also have to take into account the impact a deployment has on both the clients and my team. Ensuring that clients feel as little impact as possible while maintaining my teams health because of odd timed deployments is definitely a tough balance.
Exposure helps us grow, but from a technology perspective these are the initiatives that introduce the most amount of risk because there’s a lot of third party influences we can’t control. From initial technical discussions through to implementation and onboarding I keep an eye on the processes being run to keep things running smoothly. At the end of the day, we only get one chance at a first impression so it’s important for me to make sure that we give off a good one.
Part of this is making sure I limit risk by only giving people access to the things they need. But there’s a different dimension to this too. I want to ensure my team feels empowered and owns the products they’re creating. I try to hire smart people to do the smart things and delegate tasks out to them to give them access and make them feel in control.
Building vs Buying Features
With the number of services available these days is so easy to create a product by just stitching other products together. But by doing this you lose a lot of control and specificity in functionality. As developers, it’s just as easy to decide to create everything ourselves. But by doing this you lose time and increase complexity.
In my position it’s about constantly having the “build vs buy” argument in my head to optimize on costs and keeping things simple. Overall it comes down to which decision is going to give me the best return on investment.
Being an engineering leader is challenging. There’s multiple accountabilities, both towards the people and the technology. This inherently means that the biggest problems fall on your lap, and often when it rains it pours. There’s no schedule or predictability, and it’s definitely more of a work until the blockers are removed rather than a standard 9-5. But if you embrace the challenge you see the direct result of your work in both the people and the product which makes it incredible rewarding.