“Don’t pass that stress to the team” — how Toqio’s IT avoids overcommitment

The CTO vs Status Quo series studies how CTOs challenge the current state of affairs at their company to push it toward a new height … or to save it from doom.

Why not roast tickets together?

Daniella proves that logic and emotional intelligence combined are what you need to combat overcommitment, one of the top three ongoing delivery issues for CTOs (2020-2023, The Global CTO Survey).

Logic is for asking if an external request is a priority for engineering — or is it aligned with the commercial strategy.

And the department members’ emotions are what a leader needs to embrace. You can’t keep dodging them forever.

Sure, it might be reasonable to shift priorities or make a last-minute scope change.

But no sense of urgency ever helped IT build something stable. So, don’t let them “go nuts”, as Daniella likes to say.

She was kind to reveal:

• why Toqio’s engineers prefer to review ASAP requests and estimations as a collective,
• the vicious cycle of urgency, a workaround, and the unavoidable refactor,
  
• what mistakes engineers make that get them stuck and frustrated.

About Daniella & Toqio

Practices and tools

Eric Ignasik: Thank you for joining us, Daniella. So the first question is quite easy — how do you measure engineering productivity at Toqio?

Okay. So this is quite tricky. It’s usually very difficult to measure productivity. We follow reports from Jira to measure the team’s velocity or defect rates.

But this requires the estimations to be correct. Then, you can see proper metrics.

We run internal surveys biweekly within each of our squads to review other types of productivity metrics. 

We compare all metrics to the “team health” KPIs we have set for each of them. There’s a big review each quarter.

I know that many tools and frameworks help you measure engineering productivity. But sometimes, they don’t work for people, and it’s easier to adapt to what the team needs. 

Some people do it manually, some use an Excel sheet, and some have a dedicated tool.

We could use Jira’s report function, but that required developers to log in time. Some take it as micro-management, so you must be careful.

I adapt to what best fits the team. It might not be automated, but we can still monitor metrics and keep the team comfortable.

What is your way of reviewing all of your department’s workflow to notice bottlenecks?

We detect bottlenecks while reviewing the product and engineering roadmaps. If things aren’t done on time, we know there’s an issue somewhere. 

Our infrastructure team deals with many bottlenecks that come from added requirements or tasks that weren’t identified before their project started.

We can also have bottlenecks that come from a specific squad or person.

But at Toqio’s engineering, we talk a lot with each other at catch-ups, dailies, or weeklies, and we flag many issues during these conversations.

Then, we match what we find against those two roadmaps to reveal problems.

Michael Sols: What examples of such engineering bottlenecks could you give?

When you usually define a requirement from the product side, the tech team is involved.

The infrastructure team might not be involved in product development conversations and be kept in the background, like a shadow. 

There’s a high chance someone forgets to list tasks for them.

Maybe they need deployments or to prepare the infrastructure for a new change.

So, if engineering and product prepared a new service for deployment, the project team might realize: “Oh no, we need to deploy, but we forgot to save time for infrastructure work.”.

Because of this, our Infra team could drown in requests that don’t fit into their own roadmap. Unfortunately, we’ve encountered this before.

Another thing that happens a lot, probably in many places, is that someone with the most knowledge about the platform can become a bottleneck.

So if that person isn’t there, what will you do then?

Eric Ignasik: Could you give examples of development workflows your team automated and saved time on?

Our releases were purely manual before, which was quite time consuming for the team. We automated some parts of it around code management and pipeline work to reduce our deployment time.

We are now using Sonar for code quality, which we execute automatically, and Datadog that automates testing during pipeline executions.

Toqio also relies on Datadog to monitor alerts and logs and to detect issues before our users do.

Previously, someone had to stay seated for ages to dig up information when we found an issue.

We recently added Terraform to our stack. It’s basically infrastructure as code, and it also cuts out a lot of manual work.

Our DevOps team started rebuilding Toqio’s infrastructure to introduce new pipelines faster through Terraform.

They also created a new command-line interface designed to reduce the time needed to onboard a new team member. You can install it with all the components quickly, and it strengthens compliance.

The department also looks into Copilot AI, which really improves team and development velocity.

We are careful about it because Toqio must meet multiple PCI and compliance requirements as a fintech company.

But it’s super-powerful for our engineering and QA, and I hear a lot of companies introduced it.

Where overcommitment comes from

Looking back at your career, which decisions usually led to a development crunch?

Workarounds, for sure. Developers rarely like to do them.

Still, any business urgency almost forces you to use a workaround, and then, the platform fails. That is not something that will ever change.

It’s because workarounds aren’t scalable, or they lead to a new issue that stops work. So, while the team could have made the best decision then, there can be a price to pay now.

Workarounds lead to bugs that need fixing or refactoring, and that causes crunch.

For example, Toqio’s customer might require a new functionality to be adjusted to them. 

An engineer might think: “That requires a new microservice. I don’t have time for that. I’ll do it in the same microservice.”.

As a workaround, they load functionality where it shouldn’t be, which creates a bottleneck for requests.

Maybe it’s okay if only one customer uses that microservice. But suddenly, you could have two more customers doing the same, and that can create a new product requirement.

If 10,000 new users come through Toqio’s platform, that microservice used by three businesses won’t manage all those requests.

It works for a brief moment and then stops suddenly.

How do you handle ASAP requests for engineering?

From my point of view. I think we all know the theory. It’s just difficult to follow.

I ask if this ASAP request creates more business value than the project my team is doing. 

What are the wins and downfalls of it? And the impact? Does it even make sense?

If the answers are positive, then okay, let’s squeeze it in. If not, it has to wait.

Sometimes, you can’t apply this logic because of other factors that come from business.

Still, questioning ASAPs is the usual approach for Toqio’s engineering. Otherwise, everyone would go nuts.

So you’re willing to examine ASAP requests, but it all depends if they are meaningful?

Yeah. Let’s say you’re working on a specific requirement related to payments. 

After you’re done with it, you expect to have six customers on board and a revenue of 300,000 euros.

Someone else comes in with a huge requirement. 

One of the current customers wants to manage company cards from the platform.

Okay. How much will we gain from that customer? 100,000 euros max. Then I’m sorry, but it’s not going into the roadmap.

This additional request will break apart what we’re doing right now.

You recognize that business decisions should drive engineering work.

At the end of the day, all departments should work on the same commercial goal.

As an engineer, you should understand what the business requires of you. Somehow, you need to have the same product growth mindset that a leader has.

In fact, most requests IT deals with aren’t about library updates or technology selection, which is what developers tend to focus on.

When product or business want something, it irritates them unless you tell them why it makes sense for the company. Then, it will be easier for them to refocus.

We often ask how leaders can help teams become productive. But what are the non-productive behaviors that engineers engage in?

People do multiple things at once, which is always a mistake that just happens everywhere.

You start your career as a coder with a large map of technologies to learn. 

You want to move from CSS and HTML to Docker and Kubernetes, but there are so many options that it gets you distracted.

Developers who are just starting out want to get to the end of the map so badly that they skip over critical lessons.

I also used to jump from one side to another, get overloaded by all this chaos, and not achieve anything by the day’s end. Chaos.

Now, I note my priorities and only move to the second one after I have dealt with the first one.

Avoiding getting distracted.

I also spoke about people as bottlenecks earlier. Sometimes, you think working alone is quicker, but that limits your team’s access to knowledge. So, solo work is not productive at all.

You have to learn to rely on the resources and the team you have. Then, when the time comes, someone will step in for you.

Michael Sols: Majid — one of the CTOs we spoke with — said something unforgettable.

He wants to be sure that if a bus hits him, the engineering department will carry on.

It really made me believe in documenting processes and ensuring people know how to step in.

Engineers — or rather — everyone hates documentation. But I still believe in it.

I was anxious before my first maternity leave, wondering: “Oh my God, what will happen to the team?”.

But our documentation helps them stay independent, and that bottleneck can be improved.

I am not anxious about my department becoming chaotic if I need to go on leave.

I for sure wouldn’t like a bus to hit me, but I feel where he’s coming from.

Eric Ignasik. And how does Toqio do estimations? Obviously, bad estimation lead to overcommitment. At The Software House, we have a company-wide framework for request assessment.

How to estimate is another hot topic that I always found tricky.

We currently use story points based on a definition that assigns one point to a specific amount of hours.

As usual, each development task has a number of story points.

When we do a sprint plan, the ticket assignee estimates a ticket, and the rest of the team needs to challenge the result.

We also have a rule to log time into the ticket to compare it with the original estimate. 

But not everyone logs their work. Some people think it’s micromanaging.

Even with everything we have set up, I find it difficult to judge if an estimation is accurate. It’s only possible if we review how they changed over time.

We also have this task estimation method called “t-shirt sizes.”. 

Engineers use story points to judge work by its duration. I know story points should describe the effort, but we tied them to hours.

It’s difficult to imagine the switch from effort to time, but that’s what we’re trying out now.

We then calculate the velocity in percentages based on the time.

Estimation really depends on the developer doing the task. Maybe the team lead evaluated the task correctly, but a junior will do it slower.

Michael Sols: One area of improvement would be introducing practices that would help engineers estimate better. 

Perhaps that improvement could scale up and make estimations more accurate. Do I get that correctly?

Yes, but it would still be a challenge, even in that case. You need to grasp the code and the business logic behind it.

You might have some practices in place and still won’t get the estimate on point.

It could be your poor understanding of the code base or the impact that your solution will have.

But for an engineer who is completely confident in their code, timing work is way easier.

They can think, “This microservice will be a blocker, and it relates to this script as well. I need to take that into account.”.

Because some dependencies might not be considered, that’s why it’s critical for us at Toqio to do estimations together as a team.

Challenging estimations is one practice that helps us get them right.

Connecting departments

Eric Ignasik: Neil Mountform, who is the CTO of Habito, recently told us the relationship between management and engineering is often dictatorial or collaborative.

Which practices could a company introduce to improve that relationship?

I’m very protective of my team. Having a tight bond with them is key. 

I understand that companies have different sizes and interpersonal connections can be tough to arrange.

Being able to have one-to-ones with engineers regardless of their position is what I value.

If a manager is too disconnected from the team, there’s no ground for trust. They have to give orders or have someone manage it for them.

You sometimes see a manager on video and recognize their position within the company, but you know nothing about who they are or what they do.

So, if a leader includes themselves in daily operations, they can break the barrier between management and engineering on opposite sides.

It doesn’t mean you need to be friends with everyone. Learn to listen and build that connection by being there as a human. We all work towards one purpose.

Eric Ignasik: Have you seen that relationship between management and engineering mature at Toqio or anywhere else?

Yes. We started at Toqio with four people. It was a small family, and it was easy to bond.

As the company hired more, the bond weakened slightly, and the distance between some employees became visible.

At one point, there was no working relationship between product and engineering. Now, we’re doing a lot of customer-centric exercises with these two departments and the business.

These creative meetings naturally create new relationships and improve understanding.

Because Toqio still has only around 80 people, we can easily connect at the many events we organize or at our office.

Good to remember

What are your three golden rules for other Technology Leaders to help them become a better mediator between business and engineering?

First of all, understand the business requirements and translate them into a language your team understands. 

Get everyone on board with one goal. That should work for all levels, from management to engineering.

The second point, which I think we haven’t mentioned before, is to handle any chaos coming from management on the leader’s level without disrupting your engineering teams.

They can know there’s a priority, an urgency, or whatever, but don’t pass that stress to the team because it breaks relationships.

My third point is that the bond with engineering must be strong. Of course, we all work for business, but we need to care for our own department.

Without engineering, you don’t have a product that earns revenue. So, if we keep them happy, all the company will benefit.

Resources

Which books, courses, or podcasts would you recommend for the managers among our readers?

I get this question a lot. “Team Topologies” by Skelton and Pais is my number one recommendation. I’m sure you’ve heard about it before.

A friend recommended this new book, “The Engineering Leader,” by Cate Hudson, which I have yet to read, but it sounds great.

I’m also a fan of Medium and follow writers there. It’s one place for many provoking perspectives.

There’s also this boss-level interview series called CTO vs Status Quo. I don’t know if you’ve heard about it?

Anyway, I also belong to the CTO Craft community on Slack. Many C-levels, VPs, and IT experts are there, and they are kind enough to answer any type of concern or question.

What’s next? Three actions for CTOs to take

If engineering shares one philosophy for handling requests, that’s a good start.

Daniella also confirms that IT’s lead should be like a coach. 

One that protects their people but also translates business requests into perfectly calculated priorities.

To follow her advice:

1. encourage developers to help you uncover workload bottlenecks through many solutions rather than something enforced,
2. ensure team members include unobvious requirements in estimations by reviewing them in a group
3. involve yourself in the department’s inner work to shield it from any stakeholder tension and keep it at ease when projects have to change

Also, have you read “Team Topologies” yet?