Cover image for The Development Lead’s Guide to Understanding & Managing Time

The Development Lead’s Guide to Understanding & Managing Time

madeby7pace profile image Devs @ 7pace ・8 min read

One of the most misunderstood aspects of software development is the role of time.

For many development teams, the idea of measuring–or even acknowledging–time is seen as a non-starter. Developers, in particular, are predisposed to reject the notion of tracking time largely because it has historically been used as a weapon for control.

Management has wielded the timesheet as a way to dress-down developers for not meeting arbitrary quotas or performing at an “average” level.

Of course, this is not an effective way to manage.

Coercion and strong-arming employees is almost never an effective tactic. But it’s made worse when applied to creative professions like software development, where progress and “work” is never a linear measurement.

This points to the root of the problem that plagues many development teams. There’s a type mismatch in how time tracking is applied and used within the team. Rather than a means for “enforcing productivity”, time should be used as a learning and professional development tool.

Time management is, of course, a critical part of running an effective development team.

In order to harness the power of time as a motivational and professional development tool, we need to shift the way that time is discussed and used by software teams.

The importance of time

There’s no denying that understanding, measuring, and managing time is an integral part of any software developer process.

Hell, it’s a central part of life.

Every person has a finite number of minutes and hours to accomplish what they want to accomplish. This means taking control of time at some level. And at work, it’s no different. There are only 168 hours in a week. That won’t change.

Time is the central metric that other measurements of progress and productivity revolve around. While different teams use different systems for estimating and evaluating work are really just dressed up ways for trying to cloak the passing of time.

Ultimately, time is the most important unit of work for any development team.

This means that it’s imperative to not only acknowledge time, but learn the right ways to manage that time in a way that works both for management and for developers.

But in order to turn time measurement into a tool that drives the team forward rather than holding it back, time must be used as a positive force rather than a negative one.

Time as a carrot, not a stick

Central to recognizing the importance of time management is reframing the role of time tracking within the team. This means shifting from the idea of time being a way for management to control how developers spend their time.

Instead, timetracking is a tool meant for developers themselves.

It’s a mechanism by which they are able to measure, understand, and learn about their own abilities. From that, developers have data and insight they need to grow. This means that they will become more productive and efficient without the need for management to use time sheets as a stick used for driving performance.

In other words, for management to realize the intended benefits of draconian time tracking practices (e.g., more productivity, improved efficiency, accurate estimates/forecasts), they must first relinquish the control over time to individual developers. Allow them to take control and accountability for their own work.

Daniel Pink’s book Drive outlines the three principles under which creative professionals thrive. They are:

  • Autonomy1
  • Mastery2
  • Purpose3

Each of these elements applies to the way we understand, measure, and manage time.

In order to give engineers autonomy, we must understand time through the lens of the engineer–not the manager. Time is theirs to own and control. Any attempt to subvert that ownership or assert dominance and control over someone else’s time is likely to be met with hostility and resentment–which, of course, leads to poorer performance.

Secondly, time is a tool used to allow professionals to create mastery. It’s clear that the desired outcome for management is for development teams to become more productive and efficient. Likewise, developers who seek greater proficiency will be able to solve more difficult problems in less time.

Lastly, finding purpose is largely a function of how one spends their time. If every hour of the workday is spent on work that feels mundane, unfulfilling, and unrewarding, then it stands to reason that one would feel bored and unmotivated.

Taken together, we can see that the role of time–and how a team uses and considers time–is central to all three of these components that make up the drive to perform.
Alt text of image

So, a team’s relationship to time will shape how individual team members perform and whether they’re more likely to stagnate or grow in their roles.

Ideally, development leads will recognize this relationship and steer toward professional development.

Professional development and the role of time tracking
While some teams and managers seem interested in maximizing the amount of time developers spend working (versus “non-productive” tasks), the reality is that productivity is a measurement of efficiency.

The best engineers get more work done in less time.

Unfortunately, many managers don’t seem to understand this concept. So, they punish their best performers by expecting them to spend more hours “working” rather than rewarding them for being more efficient.

This is also one of the main reasons why managing through timesheets is ineffective at best (or stupid, at worst).

Time as an absolute metric–hours input–is a terrible way to measure of evaluate performance.

Time is best used as a relative measure of performance over time. It’s less important for an engineer to know how long it took them to complete 2 story points than it is for them to know how long it took this month versus last month.

  • Did they improve?
  • Are they becoming smarter, better developers?
  • Have they improved their ability to recognize patterns and solve problems?

These are the true benchmarks that engineers should use to assess their own professional development. But they’re difficult to measure.

Time is one of the only static metrics that can be used to evaluate performance and growth of engineers. This means that managers must allow their engineers to own and control their time. If there are arbitrary goals or quotas put around metrics of time, then engineers–like most people–are more apt to do the bare minimum to meet those quotas.

But if time is used as a personal way to assess progress, it becomes a tool for empowerment.

Runners, athletes, and office workers alike have flocked to FitBits and other personal fitness devices. Why? Because it gives them a way to measure themselves, assess their abilities, and hold themselves accountable for growth and improvement.

No one is enforcing that people must take 10,000 steps a day–and yet, people all over the globe are striving to walk more and sit less. Because they have an easy way to measure and compare their own activity.

As such is the role of time tracking for developers.

It’s an incredibly strong motivational tool, but only when paired with the tenets of autonomy, mastery, and purpose.

Improving time estimates, forecasting, and planning
One of the most common challenges for development leads is dealing with estimates, forecasting, and planning.

While each individual engineer is accountable for their own estimates and the work they commit to complete, it’s the team lead who is often ultimately held accountable by upper managers.

Development leads take the heat when sh*t goes off the rails.

So, it’s not surprising that managers are often frustrated by inaccuracy in estimates and forecasts. It’s one of the most common questions we get–how to deal with inconsistencies.

Of course, one common response to inaccuracy is to clamp down and enforce strict rules that try to wrangle estimates into shape. But, as discussed above, often the key to improving the performance of a team is a counterintuitive approach. Rather than grasping for control, take a step back to assess the real problem to be solved.

The reason why time estimates don’t line up with reality is almost never some kind of intentional sabotage. It’s a lack of data–it’s inexperience.

This is fundamentally about professional development. More experienced engineers with access to more accurate data (and more time to evaluate their own performance) will be able to provide better, more accurate forecasts on future projects.

The best way to improve estimates and forecasts is to empower engineers.

It’s to help them grow and improve their own abilities.

Imagine that you ask someone on the street about their bowling average. Chances are, they will have no clue–they rarely, if ever, go bowling and they have no consistent frame of reference. But, any long-time bowler can rattle off their average in a second. They know exactly where they stand and they strive to raise that average every week or every year.

Based on that, they can tell you–with a pretty high level of accuracy–what they’ll score in any given game of bowling. And they can begin to understand their own tendencies and adjust for externalities, like if they tend to bowl their best at the start of the night or if they know they don’t perform well when people are watching.

With the right data and a consistent feedback, bowlers–and engineers–gain insight about their abilities.

This leads to better predictions and more accurate estimates.

Making time tracking as effortless as possible

We’ve seen how valuable time tracking can be. But implementing time tracking for a development team–especially one that’s not used to tracking their time–can be a difficult proposition.

Beyond framing it in the right context, the other key is to minimize friction.

As most studies show, engineers rarely find extraneous activities like time tracking, meetings, or even planning work as being particularly productive. So, if the idea of time tracking is introduced as an extra responsibility or an arduous task that will take away from more important projects, it will almost certainly be rejected by members of the team.

This means finding a time tracking process and program that minimizes the amount of time or efforts that must be spent on actually tracking, but confers the benefits of having granular time data.

One of the reasons we developed 7pace Timetracker is to solve this exact problem.

Rather than shifting between programs or manually inputting time values at the end of the week, 7pace automatically keeps track of time spent on individual work items. This makes it nearly effortless to measure how any minutes and hours were spent on specific tasks and also compiles time spent on larger user stories and epics.

This means insight without the hassle.

If the ultimate goal of tracking time is to allow developers to grow and improve their efficiency and effectiveness, then the worst solution is one that steals time away from work that truly matters.

Effortless time tracking, autonomy, mastery, purpose, and personal growth are all part of the equation.

For development leads, this means understanding time as a finite resource. But also understanding how to manage for performance without robbing the team of their motivation.

It can be a delicate balance, but the best software teams work together to improve both their individual performance and the team’s abilities as a whole. No single member can carry the whole team, but the wrong team dynamics can stifle the abilities of every member.

7pace Timetracker is the only integrated, professional time management solution for teams using Azure DevOps.

Alt Text

Posted on by:

madeby7pace profile

Devs @ 7pace


Account for the devs at 7pace because we all write but don't want to deal with multiple accounts. Check out 7pace Timetracker for Azure DevOps (and soon GitHub)


If Engineering Was a Guessing Game, Anyone Could Do It. We take the guesswork out of planning and reporting for development teams using Azure DevOps (& soon GitHub)


Editor guide