CTO day 6: Building bridges with a "Week of little things"
Tags: cto, management, teams
Published: 2021-07-30 09:26:12

---
title: CTO day 6: Building bridges with a "Week of little things"
published: true
tags: CTO, management, teams
canonical_url: https://danlebrero.com/2021/06/10/cto-dairy-building-bridges-week-little-things/
description: Giving the steering wheel to the rest of the organization. 
cover_image: https://danlebrero.com/images/blog/cto/day6/week-of-little-things-media.jpeg
series: CTO diary
---

We spent the second quarter of the year building bridges with [“adopt a developer”](https://danlebrero.com/2021/05/26/cto-dairy-building-bridges-adopt-a-developer/#content) (which worked well enough) but before settling for it, I wanted to try another experiment to bring the development team and the partnership team closer.

With the aim to fight:

> Feature/Bug X is obviously the most important thing in the world, but the Dev team never has time for it!
<cite>Everybody outside the Dev team.</cite>

The following invitation was sent to the partnership VIP people:

## A week of little things

![little things](https://danlebrero.com/images/blog/cto/day6/week-of-little-things.jpg)

> To celebrate those little things that bring joy to our lives, this summer the development team wants to contribute to your joy by fixing the most annoying bugs, long-standing issues or obvious improvements to our products that you have always been clamouring for.

> Instead of the dev team deciding what is the most important for you, we would like our partnership team to bring a list with the 10 most important little things that you would like to be fixed now.

> But those things have to be small enough to fit in a week. Unfortunately, the dev team will be the ones deciding what is small enough.

> Feel free to involve anybody else that is not in the CC list.

> Hope it brings a little bit of joy,

> The dev team

> Rules of engagement:

> 1. One list per product.
> 1. 10 items in each list in priority order. Not more, no less.
> 1. Hubs/Team leads/Partnership team need to agree on that one list. Not one list per hub or per person.
> 1. Each item in the list has to come with an owner. That owner must make himself available that week for the dev team for questioning, interrogation, feedback, QA and sign off.
> 1. Dev team will start just the items that they estimate can be done in a week. If an item is estimated longer than that, it will be skipped.
> 1. Item owner will be notified when an item is skipped or started.
    Lists should be available on July 24th 10am CET.
    Send the lists to Anthony and Jana directly.
>
> **Does this replace support?**
> 
> Nein. Support stays as it is.
>
> **It is just bugs and/or feature requests?**
>
> Little feature request are also welcomed.
>
> Documentation, help, training, advise, cooking recipes, … also welcomed. Our time is yours.
>
> **Will the whole list be done? If not, what happens with the items that where not implemented?**
> 
> Dev Team will finish anything that gets started, but it is unlikely to do all the items in the list.
> 
> Honestly, I do not know what will happen with the items not implemented, but at least they will be more visible to the dev team.
> 
> Depending on the feedback from both dev and partnership team, we will make this a recurring activity.
> 
> Again, this does not replace your usual support, bug report or feature request channels, but it short-circuits the priorities.
> 
> **Just 10 things? I have a thousand things to be fixed!**
> 
> Apologies but let's start small.

## Priorities

Aiming to spend again ~10% of the Dev budget for the quarter, the experiment will give the partnership team full control for a week of the Dev team’s time, so they can decide what is the most important thing without the filter or control of the Dev team. A very direct and obvious input into the products, plus a greater sense of ownership and collaboration.

The partnership team will have to get together, organize themselves and agree upon their priorities for the products.

The Dev team will not get involved at all in the process, so that different teams within the partnership team (of which there were at least 6) will be more aware of each other's priorities and will need to negotiate between themselves.

I had the hope that this will build some empathy towards the Dev team prioritization headache of the thousand things that the thousand stakeholders were continuously asking for.

## After-Match

### Product Managers and their product

Before getting the lists from the partnership team, I asked both Product Managers (PMs) to try to guess what the contents of the list will be.

I was very happy that our PMs guessed correctly the top priority item for their product. Hurray!

Both PMs had their reasons to not have implemented those items yet, but this week they will follow the direct orders of the partnership team, making the partnership team more listened to.

Still, some items surprised the PMs and would be implemented after the “week of little things” as part of the regular roadmap.

### Again, how long does it take?

Unsurprisingly, the majority of items in the list were not small from the Dev teams' point of view, even if the items were "*just*" ...

![It is just](https://danlebrero.com/images/blog/cto/day6/it-is-just.jpg)

Each "*just*" hides a hundred "*but*" and a thousand exceptions to the rule. The perfect vs good enough. The optimistic "*this will never happen*" vs the pessimistic "*I have seen it all*". Today’s development pain vs possible future support pain.

But not only: our ageing codebase helps nothing in our development speed.

### Feedback

The Dev team managed to finish ~35% of the items, and the feedback that we received after the week can be summarised as:

![tumbleweed](https://danlebrero.com/images/blog/cto/day6/tumbleweed.gif)

This time around I did not explicitly ask for feedback from the partnership team, but hoped that it would naturally happen, and it did not.

I failed to ask, and I regret it.

## Next

The lack of feedback from the partnership team discouraged me from repeating the experiment or making it a recurring event. Probably spending that 10% of the time paying off our technical debt to allow us go faster would have made the partnership team happier.

Additionally, even if I asked the PMs before planning the experiment, it was an intrusion on their responsibilities.

Not a wasted week as we still fixed the most annoying issues for the partnership team, the Dev team enjoyed the change in pace and there was some extra interaction between the teams.

[“Adopt a developer”](https://danlebrero.com/2021/05/26/cto-dairy-building-bridges-adopt-a-developer/#content) was a better way of building bridges, but in the last quarter of the year I decided to spend that 10% of the budget on the [“Lucky Lotto”](https://danlebrero.com/2021/06/30/cto-dairy-lucky-lotto-chaos-engineering-for-teams/#content) ...