12 - Velocity & Allocation

As self-explanatory as the above sentence is, it shouldn't be taken for granted. This little tale stems from a bit of miscommunication I recently experienced on a first week back following the New Year. But first lets define the title:

Velocity: Meaning developer velocity or the ability to accomplish meaningful work.
Allocation: The way in which we assign people to projects or work streams.

So what was the problem?

For the past ten months I have been working on a specific new domain defined in my company. This gave me the chance to greenfield a fresh service, integrate new flows within our existing platform, and play with some fancy user facing DX ideas. All good fun!

While attempting to get acquainted with a new set of requirements and their subsequent features for the start of 2025, I started envisioning what needed to change in the wiring we already had between the above mentionned service, new event-streams, and data sources/sinks.

Up to now, all good.

In an attempt to derisk the upcoming work, I mentionned in a thread that we may have a risk due to prior coupling on legacy flows. This is when a stakeholder intervened and mentioned that this was not the case.

To my surprise, he was right! The legacy flow in question had been decoupled during the past month by a member from his team.

Wait I'm still not seeing the problem...

So what's the issue? This is a net positive right?

Correct.

Yet here's the thing: our ICs who maintained the consuming service had never seen a pull-request or a Slack notification of this change.

Naively, I mentioned this in said thread. And the paraphrased answer received in turn was We had recently chatted about this change multiple times. Interesting... so this wasn't a breakdown of responsibility from the team applying the change, but a breakdown of communication internal to our very team.

Our sister team had done their due-dilligence yet we failed to keep everyone informed of this.

How did we get here?

The team I operate on is currently composed of roughly 8 engineers split across largely two work streams. These two works streams are then divided into a plethora of smaller feature sets.

The feasibility of the feature sets are individually investigated by different team members in order to derisk, plan timelines, break down vertical slices of work, etc. When it comes to communicating with other teams that maintain upstream domains we consume data from, it is not expected that the entire team gets pulled in for a conversation.

Pros of the above:

Folks can dive deep and discover the edges of a domain.
It favorizes autonomy in discovery.
It permits individual networking with stakeholders and external colleagues.

Cons of this way of working:

There is an expectation that individuals report all information back to the team (async).
The mental models in peoples heads may start to skew.
Not everybody is up to date with the current state of the world and what needs to be prioritized.

That last bullet point is the most harmful one in my opinion.

Example scenario

5 regular ICs are expected to maintain a single service.
2 Staff+ engineers are off having higher level conversations with stakeholders.
A manager or two are acting as the glue between all these people.

The difficulty of this resource allocation is the amount of conversations that need to occur to keep everybody in the loop.

flowchart
    A
    A<-->B
    A<-->C
    A<-->D
    A<-->E
    A<-->F
    A<-->G
    A<-->H

    B
    B<-->C
    B<-->D
    B<-->E
    B<-->F
    B<-->G
    B<-->H

    C
    C<-->D
    C<-->E
    C<-->F
    C<-->G
    C<-->H

    D
    D<-->E
    D<-->F
    D<-->G
    D<-->H

    E
    E<-->F
    E<-->G
    E<-->H

    F
    F<-->G
    F<-->H

    G
    G<-->H

Every individual becomes a node in a fully connected graph with 7 edges where conversation can flow. Not all these links are necessarily operating at the same frequency due to personal preferences for relationships or collaboration. Nonetheless, that is a LOT of room for error. There's no way to prove that the conversation held between A and G produced the same understanding or mental model as the discussion between C and F.

The second you add in conversation from a stakeholder or dependency as an additional edge external to this graph, that information gets warped.

This is where Velocity gets impacted. To reach a common understanding, meetings to get everybody aligned quadruple and design documents become more verbose.

Other impacts on velocity

Safe to say, conversation becomes messy. By proxy though, work splitting gets even messier when there is overlap of people working on slightly different yet coupled logic.

PRs take longer to review to account for individual mental models.
Code conflicts waste development time.
Inconsequential details are scrutinized by more people, making it longer to ship larger chunks of work (does the length of your variable name matter to the business?).

Too many cooks in the kitchen?

Most likely. My observation when cross-comparing with prior workplace experiences is that reducing Allocation of engineers on a project to 2-3 contributors can produce a healthier understanding of the world and a more involved workforce.

They are better positioned to communicate any domain changes externally.
They are better suited to collaborate and move in a unified direction.
They are easier to manage.
They get changes out quicker.
They spend less time in meetings to sync.
They create a less fractured internal ecosystem.

Of course there must be downsides

Yea, maybe on-call rotations become tighter. Team members leaving to seek other opportunities have a larger impact. Vacations and PTO have a similar effect yet in the short term.

Guess there's maybe no perfect solution?

Slowtime Personas