Radical Delegation, and Tech Leadership Groups at MYOB
Outcomes first: In the span of six months, we stood up three practice leadership groups in MYOB. The groups were managed at first: in order to provide people with the tools to be able to assemble and produce decisions. A year later, they remain incredibly active and autonomous — providing the org with a couple of nice things:
- Clear direction and consistency of technical approach across 12 (and counting) teams.
- Empowered developers with clear ways to surface issues, concerns, and things they deem to be necessary.
- Gave people opportunities to flex, practice, and grow technical and non-technical skills.
- Chilli memes (I’ll explain later).
All of this was done within the spirit of empowerment, and a belief that people will always do the best job they can with what is made available to them.
This is how we did it.
Problem statements.
Why do technical leadership groups exist?
Technical leadership groups (TLGs) are usually stood up reactively as a fix to a problem. In a lot of cases, the problem it tries to solve is practice inconsistency — once you hit a certain number of developers, you tend to suffer from pattern bifurcation which makes cross-team integrations difficult. E.G., Team A wants to talk to the services of Team B in a certain way, but Team B has an existing pattern with Team C, so what do we do?
This is further compounded by the autonomy-indexed, team-first development paradigms of the current era. Silos form, practices drift, so let’s get a couple of people together to talk about it. What’s the worst that could happen?
“Well, maybe we should have a technical leadership group,” someone would say. “And then they could collaborate and decide on these things.”
To a degree, I agree with the above sentiment: most of the above is a communications problem. And yet…
Why do technical leadership groups (often) not work?
…and yet, we find ourselves in the position where technical leadership groups decay or become ineffective over time. Because even as the problems that TLGs attempt to solve are critical, TLGs have several decay paths — they can become inert, they can become blockers, or maybe the group composition becomes divorced from the on-the-ground development work.
I hope to unpack the many pitfalls and how we’ve tried to avoid them.
Foundational principles and establishment.
“Real location, real thing.”
I am a big believer of things like Genchi Genbutsu and Distributed Command — themselves are a distillation of the idea that the person who should be empowered to make decisions are the persons who are doing the work and are present. After all, they have the most context on the problem, right?
This is especially true for large organizations: I submit that it is simply impossible for any human being to maintain fine-grained context over so large a domain. You need the people on the ground. And so we stood up the first group, as an experiment, having delegates from every team that contributed to the software platform.
The group would be facilitated, meeting twice every month for an hour, to surface concerns, improvements, or things that are pertinent to everyone.
Why was it facilitated?
First off, definitions: when I say it was facilitated, I was mainly in the position of running meetings and asking for status updates — but with an active, conscious avoidance towards any decision making. The group owned their domain. I was not a member of the group as much as I was say, a butler.
The reason for an active choice towards dedicated facilitation was twofold:
a.) To be able to inspect the effectiveness of the group as it moved forward.
b.) To (hopefully) avoid the many, varied decay paths of TLGs.
Forming, norming, storming.
One of the first things that we realized was that TLGs were a team as much as any group of people working toward a common goal is. And just like with any software delivery team, TLGs need to form, norm, storm, before they perform.
Useful discussions.
Because of this, expectations were set from the beginning that the first few cycles wouldn’t be as meaningful. Coupled with the constraint that we were to only meet twice every month, this meant that every meeting had to be useful — after all, one of the reasons TLGs decay is because the members start to find that it’s a waste of time.
We formed some collaboration stencils as a result:
a.) The twice-monthly meeting would be an hour-long lean coffee where members can surface cross-cutting concerns or talking points.
b.) And sometimes we’ll find that we need to produce a decision that requires spikes or investigation, parties involved can work together on an options document that outlines pros, cons, risks, and unknowns.
c.) Out of that lean coffee, sometimes we’ll surface discussions that are “big” (e.g., What’s should be our testing strategy) — these conversations would be broken off into a separate meeting, with only interested parties involved. The outcomes and conclusions for these discussions are then merged back to the mainline group.
The thing that’s important here is that every single use case has a corresponding engagement pattern: Not everything needs everyone. Lean coffees are useful for raising talking points that’s pertinent to everybody. Long-form discussions should be dedicated. Things that require thinking or research are best async. And so on.
Rules of engagement.
Of course, not everybody agrees on the path forward, and that can introduce friction points. Alignment is tricky: and while it is one of the drivers for forming TLGs, we needed to make sure that exposing those potential friction points is, well, frictionless.
Ground rules
The ground rules are pretty textbook: they’re also reiterated and enforced for every meeting. Basically:
- We all work from the assumption that everybody does the best job that they can with the time available, what they know during the time, and the resources at hand. This means that discussions never highlight personal mistakes — but rather, investigate the systemic issues that could have caused problems.
- Everybody’s time is important. That means we make the conscious decision to be concise, and give other people a chance to say what they think is pertinent. TLGs tend to have long-winded discussions that are overtaken by a minority of loud voices — another decay path — which can cause inclusion problems. This makes sure that everybody gets the space to speak.
“What’s the deal with all the chilli?”
You may have noticed a couple of references to peppers or spiciness. It looks like a bit of a meme, but it’s more of a conscious decision to reframe discussions.
Put into context: disagreements happen a lot in the software development world. Some people loathe these, some people love it, and some people like specific helpings of it: much like chilli.
Framing these discussions as “spiciness” accomplishes two things:
A.) It removes the negative connotations associated with technical discussions, because dammit, tough conversations are how we get better.
B.) It defocuses on the person driving the discussion (e.g., “Gosh Mark is being difficult again about bundle sizes…”) and frames the discussion by itself in a way that’s isolated (e.g., “There’s a spicy discussion around bundle sizes…”)
Formalizing things.
But who does the work?
Well, that’s an interesting question. After all, development teams are beholden to delivering value to their customers — and the type of work that TLGs raise aren’t the ones that are seen as priority. Another decay path of TLGs is that they either end up creating a lot of backlog work that never gets done, or the members do work out of band.
And so it became incredibly important that there was a “pipeline” that led from the TLGs to the development teams. Members of the TLG could still do the work, but they can also opt to have members of their own team execute: this gives people a chance to work on things that have an architectural impact. It looked like this:
Empowerment.
It was also important that the group had ownership — in that they had a significant input organizational direction. These were the people who had context on how software development happened, they had context of the problems and concerns.
There are three classes of authority: positional (hierarchical), expertise (domain knowledge) and relational (influence). As the TLGs proved themselves with organizational improvements, they showed themselves as a group who got things done (expertise), and became the go-to for producing technical decisions (relational), which led to the authority being officially recognized (positional).
Membership and inclusion.
Another decay path of TLGs is that as people achieve seniority, the group starts to be composed of people divorced from the work. This is referred to in software development orgs as the “Ivory Tower”.
And so we formalized engagement models against the TLGs. It’s pretty straightforward:
A.) TLGs have an open door, should you find yourself curious about how decisions get made.
B.) Individual developers can join in and surface their concerns if they see something that can be an improvement, or if they need advice or a decision on a technical concern that affects multiple teams.
C.) TLG representation for teams does not come with requirements of seniority: only that you can represent your team’s concerns. This makes membership liquid, and opens it up so that developers can practice and grow their skills.
The importance of letting go.
The most important part of distributed command is acknowledging that a lot of decisions are better made by the people doing the work. But the second most important thing is knowing when you should step away: sometimes, insisting on being present or being an active part of a thing can hold people back. Give people space to own things. Let them be autonomous, and steer their own boats.
On “Some Kind of Monster”, Metallica members eventually find harmony, work through several issues, and find a space where they are finally comfortable with themselves. Phil Towle, their performance enhancement coach that got them there, insists that he is part of the band, and that he should write some songs. Things turn gnarly.
In the hope that I don’t make the same mistake, as momentum mounted and the teams started functioning well, I slowly divorced myself from the decision groups. Now that the groups are formed and they have all the tools they need at their disposal, the last thing they need is another engineering manager to step in and tell them what to do.
And hey, so far it’s going well.
Special thanks
Special thanks for special people: Kitson Kelly and Ken Scambler for the candor and support and doing a lot of work to stand this up. Jordan Tan, Mohamad Maarouf, Thiago Campezzi, Li Loh, Dil Afroz Karim, Frank Ross, Craig Sullivan, Geoff Speirs, Justin Feng, for forming the foundations of this.
