“Moving too slow”

I’ve heard this concern a lot over the decades about engineering teams, and most often this is a symptom of a breakdown in communication and visibility into what’s going on, and possibly also a lack of trust in the product and engineering leaders.

The usual ‘foils’ for me as an engineering leader to avoid having people think my team is moving too slow are to :

• Demonstrate a sense of urgency — I talk about understanding business goals and that ‘time passing’ is an issue/commodity that I need to manage and show how I’m doing that
• Have tangible accountability to deadlines and deliverables — swiftly deal with blockers and issues slowing development, continuous introspection and improvement on what caused a missed deliverable/sprint, set expectations with my team accordingly
• Push for continuous delivery — typically stress levels in stakeholders drop when they can see a steady stream of changes getting out to customers and the business on a very regular cadence
• Leverage Lean principles — having a tight relationship with Product to ensure that everything is scoped down as much as it can be, to be able to launch ‘value’ sooner, and show that I’m doing that
• Provide extreme transparency around progress — continuous visibility into project status, and surfacing as soon as possible if something is off-track so that decisions can be made about how to course-correct

The important thing is to ensure that people on my team are working at a pace that they can sustainably go. Ways in which you can help the product and engineering team are :

• ruthless prioritization — make sure the team is truly working on the most important things to the business
• removing frictions and inefficiencies — keeping the engineering team focused on delivering business value
• ensuring the leader and team understand the accountability to deadlines and deliverables — make this a consistent thread through your interactions with them i.e. they need to know that you’ll be asking about : the status of deliverables, what’s on-track, what’s off-track, what are we doing about the things off-track, what are we doing to address the cause of things going off-track, what things are being prioritized and why, etc.

Culture comes from the top, and the management line and leaders around the product and engineering team need to be setting the tone. If the team doesn’t see/feel that sprint deliverables, commitments, project dates are important, and that there’s a relentless focus on prioritization and surfacing blockers/frictions then they won’t reflect that.

What you have to be careful of is setting the bar too high and making deadlines unmissable. Engineering work is hard to estimate with accuracy, and if people get put under the microscope for every deadline missed then this will drive people to pad their estimates with massive safety margins, or do way too much up-front analysis to try to get certainty, and you’ll actually slow things down. I would aim for something like 80% of things get delivered to plan and the remaining 20% are missed but then root-caused for continuous improvement purposes.

Measuring Engineering Teams

I could make millions of dollars if I could find and sell a simple way to measure an engineer’s effectiveness, but without that here are some rules of thumb that might be helpful.

• Generally speaking you should try to assess output/outcomes, not effort. Broadly-speaking impact comes from getting code into production quickly, consistently and reliably
• Many things that people suggest as proxies for engineer activity can be gamed e.g. if engs understand you’re looking at git commit history they will start to make their git commit history fit what you are looking for. “Lines of code written” is the other classic one — more lines of code equals more output, right?! I actually want fewer lines of code per unit impact but it’s easy to write more lines if that’s what engineers know they are measured on

For early startups this next section is going too deep, but many discussions in the industry around engineering team effectiveness have started to center around DORA metrics :

• Cycle Time and Lead Time — Measure the time it takes from when a feature is conceptualized to when it’s delivered to production. This metric helps assess the team’s efficiency in moving from idea to implementation, capturing both development speed and process streamlining.
• Deployment Frequency — Track how often the team successfully releases code to production. This indicates the team’s ability to break down work into manageable chunks, maintain code quality, and maintain a consistent delivery rhythm. Higher frequency often correlates with more agile and responsive development practices.
• Mean Time to Recovery (MTTR) — Calculate the average time required to recover from a production failure or service disruption. A lower MTTR demonstrates the team’s technical resilience, problem-solving skills, and ability to quickly address and mitigate issues.
• Defect Escape Rate — Measure the number of bugs discovered in production compared to those caught during testing. A low defect escape rate indicates strong quality assurance processes, thorough testing, and a commitment to delivering robust software.

The downside of some of these is that they can be hard to track without the right tools

Hours Worked

I would caution against too much focus on Hours Worked. I would say the sweet spot for an engineer is probably 50 hours/week, with performance dropping off beyond that. Certainly folks can spike up for short-term needs but 60+ every week is unsustainable for most to still be producing quality work

I would also suggest to think of Hours Worked as an output of hiring the right people and creating the right environment, and not an input to success :

1. Are you hiring people who are motivated by making a difference and having an impact?
2. Are you hiring people that feel accountable to their commitments to their team and company?
3. Is it clear to people the “why” of what they’re working on, and the impact?
4. Is there a team and company culture of ‘commitments matter’?
5. Is the culture one of reward, collaboration and “we are in this together”? (as opposed to a punitive, and micro-managed one)

From these things come more hours worked as people are motivated, excited and understand their impact.

Regardless, it’s important to set expectations at the interview stage so that people can self-select in or out. I would make no assumptions about what people’s norms/experiences are with startups.

When someone asks about working hours at interview, I usually say something like : “This isn’t a conventional 40-hour a week job but I also don’t want to run a sweat-shop. I try to manage things such that my team is working as fast as they can sustainably go. My goal as the engineering leader is to have an environment where people are motivated to work hard because they love the mission, understand the importance of their role, hold themselves to a high bar, are challenged, and are excited to work together on something big”.

One last attempt to make a case for not focusing on hours : let’s say you could get 10% more hours out of everyone with the right cultural/leadership changes, in my experience most startups have far greater ‘leaks’ of product and engineering time (20–30+%) through bad process, bad product decisions, poor quality, poor project management, lack of continuous delivery, etc. that are much more valuable to focus on.