Abstracting over people

An underperforming piston

Imagine that there's a team of four: Mark, Tim, Noah and Sarah. They are software engineers, working together and building digital product.

They all have different skills, experiences and personalities.

Turns out that during "a performance review", a project manager discovered that Tim is underperforming.

"We have underperforming piston in the engine", he said.

Underperforming? What does it actually mean?

Well, based on number of lines, number of commits, number of solved tickets in Jira - of course.

All other people are dilligently taking tasks from the backlog and finishing them.

Well, Tim takes the courage to suggest improvements to the process - working together and finding a way to have a sustainable pace.

But missles of feedback have been launched and now Tim knows that he need to improve.

Money

The same team is doing their best to bring the best feature of all time - users are impatiently waiting to get their hands on it.

Thanks to applied feedback, now Tim takes more work on his shoulders and finishes things on time.

Even though the digital product has numerous users (both private individuals and businesses), growth rate went down, slightly.

Management is not happy with that.

Even adding an aid of the archtecture team didn't help.

Decision is there: "we need to cut costs".

Sarah, the team leader, costs the most. She's really experienced with the product and also technically skilled.

"A cost is a cost", a project manager says.

She's asked to do a handover with all of her leadership duties to the project manager and let others ask all the questions regarding the product ("because it's all about technical stuff, right?").

A replacement

Turns out that couple of weeks after "cost cutting", the team is not doing well.

Somehow the work isn't getting done - "the engine" is not working as expected.

"But we had all those architectural meetings and metrics in place...", a project manager was thinking silently.

The decision has been made - "we need a team leader".

Countless hours of interviews, discussions and meetings later, a new team leader is contracted: Keith - a person with a lot of IT experience.

The team got this information in a form of an email - a day before Keith's first day.

"He is just a replacement for Sarah - you will love him", a project manager said.

Keith is a nice person, but he's not Sarah.

He does not understand the product, and actually, doesn't want to learn the domain - "somewhere down the line, it's all about the code, right?", he once said.

A perspective

How the hell one can abstract over people?

What does it actually mean?!

You might be wondering, dear Reader, if I am playing with you by using trickery of software design concepts - like "abstraction".

Turns out that it's yet again about looking at the subject from a different perspective, using various lenses.

We are trained in finding patterns, creating models and pulling abstractions out of the domain so that we can fight back with the complexity that unmercifully nibbles us.

Sometimes charging at us like a hungry, invisible lion.

It's tempting to state that we were trained through the evolution to build abstractions - to survive.

Even if we might not do it consciously, we abstract over people.

Modeling people

I hope dear Reader you know that I really like definitions - not because I am a fan of dictionaries, but because they provide a common ground for the discussion.

One of the simplest definition of "an abstraction", I like to use, is the following:

It comes from the latin etymology of the word "abstractio" but still it conveys a general meaning.

So in a way we "abstract over people" by taking away the details of a humane aspect - a specific person "ceases to exist" in favor of an abstraction.

And as we all know, abstractions help us taming the complexity.

But sometimes we want to deal with this complexity - we want to understand the person, not the abstraction.

It isn't rare that people are abstracted into "isolated pistons" in the engine, subconsciously leading our thinking to the conclusion: "a system is the same as the sum of its parts".

Easily interchangeable, easily measurable.

Which leads into another level of abstraction - a replacable cogwheel.

Even if we can "model" people as resources, especially when talking about their availability, we should remember it is just an abstraction.

Its main function is to help reducing the complexity of the designed system so that we can think about it differently (or at all?).

We couldn't tame the depth of each human being, the same as we cannot comprehend the complexity of the world we live in.

So it is not about know-how (how to abstract over people, what abstractions or metaphors we can use) but know-when (when to use abstractions).

Modeling teams

As soon as we jump onto another level of abstraction, we no longer deal with people, but with another "grouping" concept - a team.

How do we think about such a concept?

The most common is that there's a group of individuals, taking tasks from the backlog, exchanging status each morning and sprinting through sprints - a typical description of a team, right?

There's a great ambiguity of team work - all stemming from used abstractions.

Words have power - they carry the context with them, along with implicit, invisible rules.

Do we build our teams?

Assemble them from parts, excuse me, poeple?

Or maybe we grow teams, letting the maturity to happen, through blood, tears?

I know, it's just "a language" and it for sure does not affect the way we operate and see the world.

Everything has its place and everything is on its place

Don't get me wrong, dear Reader, I do not claim we should never abstract when "dealing" with people.

As it is with other tools (abstractions are tools too!), we should use them wisely.

When it comes to knowledge working, things get complicated, or even complex, really, really fast.

"Handovers" do not work, coordination meetings are full of wishful thinking and "cost cutting" looks more like a "cutting the roots".

At the time of writing, I do not hire people and I do not pay their salaries - so it might be easy for me to say so.

But I do work with people, I do talk with them, I do listen to them.

I know that we build Systems: by, with, for people.

When one is "modeling" people as isolated, replacable, costful cogwheels or pistons, the attention is placed on the very specific plane: optimizing for work.

Leading to constant thinking about the utilization, the efficiency and the performance - totally missing the goal.

"All models are wrong (=imperfect), but some are useful"

Knowing that we can be "modeled" as "a cost", how can we use that knowledge?

What about focusing on the things that really matter - deliverying value to the stakeholders and users, and not performing next round of cargo culting?

Then, maybe our energy will flow into optimizing for outcomes, not for outputs.

What is with the goal of "the engine" - to make each piston perform at its best, risking some of them getting locally "better"?

Or maybe the goal is to get the car from point A to point B, because the user wants to book a reservation for their life trip?

Interestingly, the closer we apply the abstractions to the humane aspects, the more we might get into the realm of metaphors.

Are metaphors same as abstractions? Perspectives that one can have on the same thing? Looking from various angles?

This might lead us to the very powerful expression, that can be found in The joy of abstraction: "There is a context in which...".

And as always, undeniably, the context is the king.