After building a hiring framework to then downsize the Dev Team, next on my agenda as newly appointed CTO: the Hub Manager’s meeting.

The Hub Manager’s meeting is a yearly event that for a whole week brings together Akvo’s senior management for strategy building, alignment, and planning the year ahead.

The group is formed by the Management Team (4 people), the Head of HR, the Head of Marketing & Comms, and the Hub Managers, aka the heads of Akvo’s offices around the world: Mali, Burkina Faso, Indonesia, US, and Kenya.

Of that grand total of eleven, I was comfortable talking with two of them, and I have never talked with six.

Five days of 8-hour meetings (plus breakfast, lunch, and dinner) with complete strangers, and no possibility to argue about Vim vs Emacs.

Hell for an introvert.

The memo

To make sure that I felt welcomed, the Hub Managers had written a nice memo about how they saw the Dev Team.

Some of my favorite highlights (out of a one-page memo):

• The partnership and developer team have come to work too far away from each other.
• Software development remains a black box.
• Certain feature requests are not taken up seriously enough.
• The pace of our software development is too slow.
• Slow development of the tools and solutions.
• Too many issues with software bugs.
• Why is the pace of software development so slow?
• Are we working efficiently and effectively?
• Why are we not able to stick to deadlines?

Nothing new under the sun for an old enough software developer:

We are attracted to software that we don't know enough to dislike.
Zachary Tellman, Elements of Clojure

The memo was not completely unfair, but not the most comforting read for my already large enough bundle of nerves.

Shit-uation

The Dev Team session was midweek. By then I was more comfortable as I have had some positive contributions outside my field of expertise, I introduced "funky ideas" so that it would be safe for me to suggest silly, wild, or inappropriate ideas, and I adopted the war cry "Is it all about priorities!".

Also, the carefully planned agenda had been wrecked by the real agenda: the organization was in a deep shit-uation that had to be confronted and addressed.

This shit-uation meant that the state of the Dev Team was not THE issue but one of the multiple concerns.

Misery loves company.

The state of Dev session

From the memo, one of the main questions to be answered was: "Is the Dev Team slow?"

Lead time and working queue

One side of something feeling "slow" has to do with the work’s Lead Time: if work takes five minutes to do, but it is queued for six months, the owner of the work still feel it took several months to be done, not five minutes.

To fight this feeling, give some perspective on the Dev Team workload, and reinforce that "it is all about priorities", I started the session with:

Our product managers: Jana Gombitova and Mr. Low-internet-profile-please-change-my-head-for-a-dog holding our "done" list.

That was the printed list of all the GitHub issues closed so far in the year 2019 (~10 months) taped together.

Before the session, I folded it like an accordion and, as the closest hub manager started pulling from the five meters long list, I explained what it was.

As the list unfurled, I asked the hub managers to imagine their piece of work sitting somewhere on that list.

As the list spread across the meeting desk, I challenged all to prioritize that list in such a way that everybody would be happy and felt listened to.

And as the list finally stretched out completely, I revealed that our to-do list was already twice the size.

Oh, the drama! I could instead have just stated that we had closed 900 work items and that we were very busy, but seeing the 900 items printed, being able to touch them, scanning the meters of paper for an item, …

Making the work queue physical did wonder to make hub managers and management more empathic with the Dev Team headaches.

But, is the Dev Team slow or not?

Are 900 items per year fast or slow given our team, context, and legacy? Should we be doing 1000? 2000?

I would not dare to answer that question, but I can certainly answer a different one:

Because if today is the fastest that you will ever go, it means that you have nothing else to learn. And that is something that I know is not true.

Problem-solving leaders have one thing in common: a faith that there’s always a better way.
Jerry Weinberg, Becoming a Technical Leader

That is not to say that the way we work today is shit. Today can be good, but we will learn, and next week it will be better.

Still, I wanted to show if we were improving. The best that I could think, given the data at hand, was:

That is a plot of the yearly investment in the Dev Team vs the number of Github closed issues per year.

Not a lot of data points, and who would ever use GitHub closed issue as a productivity metric?

Still, the graph gives a warm feeling that even if the investment was going down, the output was not massively affected, which must mean that the Dev Team has been improving.

Software development remains a black box.

I have seen our previous Head of SW development trying to explain what developers do for a living by using some example from Roadmap, but by the looks of the unacquainted’s faces, he sounded like:

I could try harder than my predecessor, but I opted to show how it feels to work on an old codebase (with sound!):

A humour attempt to finish the Dev Team session.

Lessons learned

It was an intense and very draining week, but I learn a lot.

Feelings

I wish I had data (tons of it!) so that instead of working with feelings to counterbalance other feelings, we could have a rational discussion around facts.

Since then, we have started tracking the four golden Accelerate metrics to know if we are actually improving.

That said, I have a feeling that a data-only approach is never going to be enough, and like it or not, feelings are part of the work.

Hub managers

I started the week very defensive, expecting all fingers pointing at me for the shit-uation.

What I found was a bunch of caring, understanding, and open people that were worried, and wanted to move out of the shit-uation.

As our Global Team Lead constantly remind us:

Feedback is a gift
Anita van der Laan, Global Team Lead at Akvo

You need to see past what, in your eyes, looks like criticism. Even it if is, what good is to cling to any bitterness?

Build bridges, be constructive.

Business problems & software problems

It was mesmerizing listening to the business problems:

• Fixed scope, fixed cost, fixed time contracts.
• Project teams and planning headaches.
• Too much upfront design or no design at all.
• Issues that could never happen happening.
• Long feedback loops.
• Little QA.
• Handovers pains and bottlenecks.
• Multitasking.
• Poor communication or miscommunication.
• Shared "resources" (aka people) contention.
• Unbalanced workloads for the existing skills.
• …

Let me repeat: this is the list of problems when executing their part of the work. Nothing to do with the Dev Team problems.

How come it all sounded soooooo familiar? Here is when Jerry Weinberg's Second Law of Consulting finally sank:

No matter how it looks at first, it's always a people problem.

Software development is a social activity. Software development problems are people problems.

And if business problems are also people problems, can modern software development principles be applied effectively to the business side?

A line of work that a very technical CTO can walk.

Dramatic lesson

Last, but not least, an important lesson from the leader that I aspire to become:

Never underestimate the power of a dramatic entrance
Po, The Dragon Warrior