Raising awareness of project costs in a software development team

In this article you’ll learn how we try to raise awareness on the cost topic at Doctolib, while keeping quality at the core of our work. We do not talk enough about costs in development teams, or when we do, it’s easy to convey a message that will lead to unwanted restrictions.

Project management at Doctolib

You might have heard of our Tech Holding process here at Doctolib. All developers from a feature team embrace the project management role at some point, going through all tasks from the functional specifications workshops, with the product managers, to post-delivery checks.

If you didn’t read about it yet, here is an article explaining in full details the tech holder role.

We really think Tech Holding is a great benefit for both the company and the developers. Whatever the seniority level, it’s an empowering opportunity that let them work on functional specifications, take code design decisions and lead projects.

Naturally, being a project manager is not innate and we expect from our Engineering Managers to be the best possible coaches to their teams, both technically and as a project manager. As tech holding is part of Doctolib DNA, all developers have items related to them in their quarterly objectives at some point, the most famous being “I have at least 1 success as a tech holder”.

As Engineering Managers, we accompany tech holders on a regular basis. I personally have a dedicated tech holding coaching slot after the Daily Stand Up Meeting where the tech holder and I assess together what has been going well and what can be improved. We are working following a continuous improvement model, trying to answer everyday the question “How can you make things differently next time to improve as a tech holder?”.

Definition of success

During our weekly 1:1, the objective is a bit different, as we’ll assess progress over their quarterly goals. In order to make a goal like “I have at least 1 success as a tech holder” measurable, we have to provide a clear definition of a successful project.

Let’s try with:

• We designed the best technical solution based on available budget
• We provided the best customer value based on available budget
• We balanced minimum effort with maximum stability
• We were uncompromising regarding quality and security
• We delivered the project without available budget being overrun

Rephrased, the success of a project revolves around bringing as much value as possible out of a set of defined deliverables without sacrificing quality nor security, while staying on budget.

Note that “best technical solution” and “best customer value” stay arbitrary, though we heavily rely on gathered data, field trips, product workshops and technical scoping discussions to take decisions.

Budgeting a project

Each feature team has limited time and resources. Developers at Doctolib don’t code all day long, and even when they code, they distribute their time between projects, technical tasks and bug fixing.

We call “Feature days” the time granted as a budget to work on projects, and represent it with ₮ (which we borrowed from Mongolian tögrög symbol). Obviously, that budget can be negotiated with the product manager at the beginning of the project, or even during the development if we think there are benefits.

In most companies, project managers tend to do a lot of paperwork to make sure the project is on budget. They track the time spent by each team member on the project. Some companies also track the cost of each developer individually over the budget, as an intern does not cost the same as a senior developer.

At Doctolib, we don’t have project managers and we don’t like paperwork, so we decided to add a rule, called “1 = 1”, stating that developers would all consume the ₮ budget at the same pace whatever their velocity or seniority level. It’s known and accepted that senior developers will reduce their velocity and spend time to help junior ones to grow.

The dangers of cost control

We strongly think that focusing too much on costs has a lot of drawbacks. In previous professional experiences, I witnessed weird behaviors induced by cost-control, like:

• preventing pair-programming (de facto making knowledge spreading harder)
• reducing test coverage, documentation or even code quality
• refusing junior developers access to specific tickets (lowering opportunities of technical progress)
• introducing toxic behaviors, like race to productivity (individualization) or lowered estimates making deadlines impossible to cope with

But because cost awareness can lead to those extreme behaviors doesn’t mean we shouldn’t mention it.

The cost of ignoring costs

As Doctolib teams are budgeted with feature days (I’ll use ₮ from now on), the only way we can go over budget is by being in a situation where we need additional development time and delay projects.

Not meeting deadlines represents a cost. As we consume more ₮ from the envelope, we’re missing opportunities we had identified and are unable to deliver as much value to the healthcare sector as we intended.

The Tech Holder contract

The contract of the tech holder is to:

1. balance customer value against development costs
2. maximize his or her team efficiency
3. deliver the project on time

The will to balance customer value against development costs can be explained easily, as each saved ₮ will be dedicated to creating value through another project.

Aiming at maximizing team efficiency shares the same goal, as efficiency relates to costs. It requires some day-to-day work from the tech holder. Here are four focus points.

Update the project timeline

At Doctolib, we draw a timeline at the beginning of every project to reflect tickets prioritization, parallelization and dependency. We expect tech holders to keep it up-to-date so that it can be used as a reference during Daily Stand Up Meetings.

Tech holders will use the DSUM to:

• raise alerts as soon as possible so that we have time to find solutions
• give the team some visibility over the project progress
• remind which deliverable are due at the end of the day

Ensure the development flow is smooth

Tech holders work with their team’s product managers at keeping a good Jira hygiene. They might assist them if they’re unavailable or overwhelmed by the QA.

Tech holders will regularly look at the Jira board to:

• add tickets or split existing ones when relevant
• make sure all required informations are present in tickets before they’re assigned
• guarantee rhythm and make sure tickets do not stay stuck in the same column without a valid reason

We try to limit tickets lifecycle to 3 days, from the moment a developer starts working on it to its release in production. Bigger tickets should be split.

Be available

A tech holder is not a superhero and is not supposed to be the top contributor of the team during the project. What we expect is proactive communication with both developers and product manager:

Tech holders must:

• be available to answer questions they may have, or point them to the right interlocutor if you don’t know the answer
• pay attention to every developer to make sure they’re not stuck on a ticket
• explain as clearly as possible any constraints the team stumbles upon to the product manager and work on a solution together

Actually, as a tech holder, there are chances you’ll have a better impact by helping your team members than by coding.

Foster help within the team

The fact you have a budget to stick to does not mean you should prevent your team members take some time to learn and grow.

It’s important that tech holders:

• make sure everyone takes time to review pull requests
• leave some room to pair programming in their timeline
• lead by exemplarity and raise their heads up from their keyboards regularly

You really want to balance velocities so that “1 = 1” is as true as possible

A word on responsibility

This is what we expect from tech holders. Note that even if they are responsible for the project’s delivery, it is the Engineering Manager who is accountable for it, so if the project runs out of budget, there’s a chance the EM failed as a coach.

All in all, remember that, as a tech holder, you’ll never be blamed for a project shift at Doctolib. Showing your involvement, doing your best to fulfil your role, being aware of your budget and having the will to stick to it is crucial though.

Did you like this article? Go subscribe to our tech newsletter for more!