CTO day 5: Building bridges with "Adopt a developer"

One of the things that stuck with me when meeting the business was the following statement in their memo:

The partnership and Dev team have come to work too far away from each other.

We have previously sent developers into the field, not only to see how our tools were used, but also to experience first hand how our tools improved the life of communities in development countries. The work that Akvo facilitates is one of the job’s biggest perks. Unfortunately, given the financial situation plus the COVID-19, this was not an option.

Talking with the product managers, support people and UX folks, it seemed that we were doing the usual stuff to connect with the partnership team: sharing roadmaps, monthly catch ups, quarterly newsletters, user interviews, … but this didn’t seem enough.

Instead of creating more meetings that nobody will attend, writing more documentation that nobody will read, or composing more emails that nobody will remember, why not bring our developers into the projects and pains that our partnership team was having?

Adopt a developer

After gauging the interested in the development team (8 out of 11 signed for it), the following invitation was sent to the rest of the organization:

Have you ever thought about putting a developer in your life?

You have seen them hiding behind a cup of coffee. They are shy, quiet, afraid of human contact and very opinionated. Too opinionated.

But they are longing to be adopted by Akvo peers!

At the Product Development Shelter we have a bunch of developers that would love to spend more time outside their cosy and comfortable bubble to learn about other parts of Akvo, to understand better how our tools are used, to see the impact that we are having in the world.

We are looking for Adopters!

This is an EXPERIMENT. The aim is to learn if developers collaborating directly with other parts of Akvo will make for happier developers and better products. Maybe even happier Adopters.

Rules:

1. Adopters can be Hubs, Teams, Projects or Individuals.
2. Developers will work 2 days a month with the adopters.
3. It will be up to the Adopter-Developer pair to decide how to distribute that time over the month.
4. Adopter and Developer will work together on whatever they agree upon. Some activities that I expect to see are:
   1. Fix some “low priority” bugs.
   2. Build a proof of concept.
   3. Give technical advice.
   4. Give technical support.
   5. Attend partner meetings.
   6. Contribute to training material.
   7. Learn about projects, impact and countries.
   8. Learn about WaSH, Agri and/or PMEL.
   9. Review proposals.
   10. Do some business specific R&D.
   11. Others …
5. This is NOT a chance to get your favourite product feature implemented. It can be a chance to get a Fifth Column member that understands it and maybe even do a PoC.
6. Adopter-Developer relationship is not a Master-Slave relationship but a Peer-to-Peer collaborative one.
7. After 3 months we will evaluate how the experiment went and decide if we want to continue, tweak or stop it.
8. There is zero budget for this.
9. Adopters do not need to find billable hours for the developer. It is “free of charge”. Donations are welcomed. Coffee is always appreciated.
10. And please:
    • Don’t get them wet.
    • Don’t expose them to bright light.
    • Don’t feed them after midnight.

If you (Hub/Team/Project/Individual) are interested on becoming an Adopter, you need to:

1. Reply to this email. DO NOT REPLY ALL!!!.
2. Send the possible plan for your adoptee. It doesn’t need to be very specific.
3. Please include the probable timezone.
4. Please include who the Adopter is.
5. Send your proposal before the 28th February.

In the first week of March, Developers will choose which Adopter they want, and the Adopter-Developer experiment will start.

Note that it is the developer the one that chooses the Adopter. Make your proposal interesting!

Please let me know if there are any questions, suggestions, or you need any help with your proposals.

Thanks in the name of all adoptees,

Dan

The response from the Partnership team was fantastic. We got more adopters than adoptees, including HR and the Finance teams!

After-match

The “adopt a developer” experiment showed that people are happier when working across departments, or that is how I interpret that more than 80% of participants wanted a second adoption round.

The second objective, to build better products, did not happen. Given the allocated time, I was not expecting anything in this area until at least the second or third adoption round.

Still, a few improvements landed on the products, we built some automation for the Finance team, and the developers’ “different way of looking at problems” was greatly appreciated.

For the main objective, to build bridges between the Dev team and the rest of the organization, worked pretty, pretty well.

Obviously, there is no impediment for people within Akvo to go and talk to each other, but being an official initiative gave people the time, the contacts and the blessing to make it happen.

The Dev team got a little closer to the rest of the organization!

Priorities

The main impediment that people reported was “real work”: only 3 out of 8 developers managed to use all the allocated time, while the others spent on average ~50%. This was not only due to the Dev team priorities, but also the adopter’s priorities.

Is it all about priorities! Me, all the time.

As I had no control over the adopter’s time, there was really no point on trying to make it top priority, so a best effort one was good enough for the first adoption round.

there is no such thing as "high" priority. Remember, that the priority of a task is always relative to the priorities of the other tasks.

Time, money and investments

Even if two days a month for the experiment does not look like much, it is 10% of an employee’s time.

Even if 10% does not seem like much, if:

• your team is working at 80% (due to our financial woes),
• spends 10% on paying of technical debt (of which we have plenty),
• 10% on support (at least!), and
• 10% on meetings and admin stuff (I wish!)

then spending yet another 10% on top becomes a very significant amount.

It was on deciding if 10% was too little or too much when it sank in: in my new position as CTO, I had the responsibility to decide how and where to spend the Dev team’s time.

And once you start caring about budgets, time becomes money, so from this point on, any work (mine or from others) would become an investment, and I will always ask myself:

What value do we get out of investing $$$time * cost$$$ in this work?

Next

This is an experiment that we will repeat in the future, adding some structure to the time spent so that other priorities will not trump it.

In fact, the experience was so positive that making the adopter-adoptee relationship a permanent one (in one shape or another) does not seem crazy.

But first, I had another different experiment in mind for building bridges…