Time To First Commit: A Barometer of Technical Excellence

How can we work faster? That’s probably the question a lot of founders ask.

You can't improve what you don't measure. - Peter Drucker (and many more…)

There are many metrics but only few make sense. I've seen countless teams obsess over velocity metrics, story points, and sprint burndowns. Most can be gamified & improved without affecting final result. But here's the thing - there's one metric that often gets overlooked, yet tells us more about our development efficiency than all the others combined.

Enter Time To First Commit. As every good thing needs acronym, we’ll have one - TTFC.

I wish I use it more often. It’s also interesting from the employee perspective. It can tell a lot about company. But that's history for another post.

What exactly is TTFC?

Imagine you are joining new company (or just remind how it was). There are quite a few things that need to happen to get your first commit. First commit usually means everything (or most stuff) is setup. You have task. You know what you need to do. You can find required info. You can access everything. Your machine is setup. And finally you can push code to repo. Quite a lot of things at the beginning. Each and every thing takes some time, all of them together result in TTFC.

Which elements do influence TTFC?

• how long does it take to get required access - Slack, Mail, VPN, GitHub?
• how long does it take to get access to commit to the project?
• how easy is that to start working on the project?
• is everything centralized? is there single person that can onboard new employee?
• are tasks well defined?
• do you need help with project setup?
• do you need help with local setup?
• is there README to get started?
• how many people do you need to know in order to run project?
• how many people do you need to ask for help?

Why should you care?

TTFC tells about company culture, organization and engineering excellence. From the spot, you can tell how easy it is to setup project, how good is documentation, or how well-prepared is CI. That single metric tells a lot. And you can easily spot bottleneck(s), when you look closely into each step.

It reveals:

• How streamlined onboarding process is
• The quality of documentation
• The complexity of development environment
• Teams collaboration effectiveness
• The clarity of task definitions

Most companies are working remotely. When working remotely, onboarding requires more care. That’s a good thing. In the office, a bit of chaos would do the work. But when working remotely, waiting time can easily double or triple. You won’t knock the door or stand in the middle of the room waiting for the response. So usually you just wait…

If you have pleasure to work with team in the same room, you would be running stuff in a matter of day or hours. 😜

As a bonus, we want to reduce boring & repetitive tasks. New person joining is common scenario. It should be similar to onboarding new customer. The key is to provide more value. That’s why new people are joining. Don’t make them wait. Remove obstacles & let them code.

When should you start timer?

The minute you join the company.

Of course, there are introductory meetings. Of course, you need to message some people. Of course, you need to talk with PM about first task. Count everything. Timer stops when first commit gets to main branch. Yes, it means it went through CI, got review & got merged.

It happens again & again…

If you don’t measure TTFC or you lack ideas, let me give you some. I’ve been working in few companies and have friends in many more. There are issues that repeat over and over again:

• Long time to get access - I know companies where first week can be totally wasted. You wait few days to get access to mail, repo and communicator. There’s no list of all required accesses to grant. You get one and need to request another. Often multiple people need to grant access to different stuff. There’s no coordination. Simply prepare a checklist. Go for 80/20 analysis. Definitely, there’s no need to grant access to all resources. But there’s a bunch of stuff that everyone needs…
• Request for each and every thing - You don’t know what you don’t know. Joining a company is often the case. You usually even don’t know what software company is using. Do we have password manager? Do we use VPN? Do we use support ticketing system? Do we have alerts? From security perspective, the less you know, the better. But it often backfires. You spend time looking for things, just to realize that there’s VPN to access particular server…
• Missing README - I’ve never experienced well-prepared README (which means that I also never prepared one 😳). You clone a project and … you ask John for help to setup local env. No guidance. Missing or incomplete .env.sample. At best, you see npm install . Often, there’s README, but it’s not up-to-date. Sounds similar to documentation & comments in code 😂
• Knowledge is spread across many teams & devs - You want to run that locally? Ohh, Mary knows how to do it. Integration tests don’t work? Tom has that one. You are missing DB configs? Alex has the latest version. You have problem with Node version? Emmy knows how to solve that one. Been there, done that.
• Tough configuration - It would be perfect to have all systems “Dockerized”, to have one command to run everything. Often it’s not the case. For me, that’s critical. Easy setup is a must if you want to be productive. Second- & third-order consequences are enormous. If you have limited time, invest here
• No high level architecture - If you work in bigger company, they usually have more than one system. Plus there was big push to microservices some time ago. If you have several services talking to each other, it helps to have some high-level description/diagram. Unfortunately, as everything that’s not run, it could be out-of-date. Remember about updating that from time to time. Keep that high-level and it won’t obsolete often.

Beyond new hires

New employees join not that often. That’s the problem. Tracking TTFC is that’s just for First Commit. Still you can simulate similar events.

• Devs switching between projects.
• Setting up new services
• Onboarding contractors & consultants
• Running hackathons

Simplicity

The beauty of TTFC is its simplicity. Start the clock when someone joins, stop it when their first commit lands in production. But remember - context is the king. If you're a two-person startup working on a single project, obsessing over TTFC might not be worth it. But for larger teams or organizations juggling multiple projects? It's gold.

TLDR;

Measure Time To First Commit from the moment new employee joins company. Start the timer on day one and stop when first commit is merged to main branch. Track what’s the bottleneck. Take notes on what to improve. The goal is to reduce boring & repetitive tasks so that you can focus on what matters & give value.

And let’s be honest - nobody enjoys spending their first week fighting with environment configs.