The Developer Onboarding Time Tracking Pitch

I recently had the pleasure of onboarding another senior developer to my team in TimeLog. As part of the onboarding, we naturally need to get all developers to start registering time. It’s not always an easy sell. However, I crafted an introduction email that I share below for others to be inspired by or to comment on. I’ll be happy to get some feedback on it.

The email


Naturally in TimeLog, we register our own time. 

For you personally, and together with your immediate manager (me), we do this primarily for the following reasons: 

  • We can evaluate if you end up using your time on the right things according to our plan and priority (for TimeLog and for your personal growth)
  • We can evaluate if your balance between working and taking time off matches our expectations (in general your norm hours)
  • We can keep track of your vacation balance and requests for vacation 

For all, if we together identify that it’s not as we expect, we can address this and mitigate it for the future. I will not use it for pointing fingers (unless you are complete off the charts, which in essence means that I have failed to catch it early and work with you to improve). It’s a tool for finding the right balance. This only works if you register the actual hours you work! I rather want to have an open discussion of “why you needed to work 60 hours in a given week” or “why you ended up with 25 hours in another” than a picture perfect 100% norm time registrations that does not fit with reality. I encourage flexibility, and that only works if we see the same picture.

For TimeLog, we use for other reasons as well:

  • We evaluate if we use the hours we expected on projects. Budget vs. realized.
  • We evaluate which projects are profitable (internal projects can also have cost and financial upsides)
  • We calculate work-in-progress financial project value that are required for financial reporting

My philosophy is simple. If we satisfy the boxes above, I want it to be as simple as possible. It needs to be easy to track time. I don’t want to break something down in smaller pieces that I will never want to report on.

The science is clear, register your hours as close to real-time as possible to make them more accurate. Use the desktop and mobile apps to be efficient. At the very least do it daily 😉 Submit your timesheet every Monday before 10AM CEST.

Having said that, the following projects in TimeLog “local” (our own instance of product) are necessary for you as part of Team Platform right now:

  • _TIM – Team Platform 2022 (P22.0086) – for work related to our team
  • _TIM – R&D Scrum 2022 (P22.0002) – for scrum related tasks. However, as we use Kanban, it’s primarily for the shared sprint review meetings
  • _TIM – R&D Administration 2022 (P22.0003) – for hours not covered above
  • _TIM – R&D Internal IT 2022 (P22.0004) – if you end up doing regular IT support. Primarily used for Team Automation, but we want to be friendly for non-techies
  • _TIM – Administration 2022 (P22.0010) – specifically the “Mail handling” task
  • _TIM – Support 2022 (P22.0039) – the goal is that we don’t use this because everything we do is in backlogs. However, the world is not perfect, so register time here if you are pulled into it

You can add comments on time registrations. They are optional. I encourage you to add short context comments e.g. “Talk with SOX”, “BI 23563” in case we want to dive deeper.

When you are getting involved in other projects, they will have specific projects to register on. Ask if in doubt.

Feel free to copy it, if you see it could make sense in your context. If you change anything, I would love hear about your changes so I can learn.