Systems: by, with, for people

System?

Imagine that you are working on a software product that is supposed to conquer the world with its innovation and ingenious possibilities.

Maybe such experience is a bread and butter for you, dear Reader, and each day consists of similar feelings.

We like to dive into details, either technical or "domain" ones.

It releases dopamine.

It transfers into "the zone" where we don't feel the urge of time.

But eventually, what is the meaning of this software product?

Yeah, of course, we can say it must make money (either by saving it due to costs reduction or by increased revenue) through value delivery.

That's just one of the views, isn't it?

We design the product to, actually, why we do so?

The sooner we realize the answer is "people", the more design forces we might take into account.

By people

Believe me or not, software products are imagined, designed and grown by human beings.

This means that a system is being produced (please not I do not scope it only to "software" system) in the context of all biases humans are accounted for.

We might be tired, frustrated, happy and motivated - this all affects the way we do our efforts.

Either we want it or not, we seem to be far less logical and rational than we think of ourselves.

Many intelligent and observant people already found out that we suck at complexity exposure, as a whole.

Hence, we need to put things within imaginary (also known as "logical") boundaries to manage it - the complexity.

Of course, it matters, if we do so in order to pump up our ego so that we can think of ourselves as "highly skilled professionals".

But let's face it - we should look through the utilization and check the benefits that some ways of organizing stuff gives us. (wayf of organizing stuff? you might be interested in The ambiguity of software architecture)

We are getting paid thanks to the system that grew - either in experience points or in money.

Probably, one could imagine that as at least one human being is involved in the process of growing the system - this system carries the echo of its author.

Easy becomes complex and as an author of a system, you should take care of future yourself and spend time wisely leaving breadcrumbs and tracks on why some things were organized in this way (whether we talk about names of the concepts/abstractions or variety of software components).

So your design might reinforce, amplify and contribute for better understanding and loading "the model into the head" so that the system can grow more "organically".

Certain structures (think of them as "communication structures") attract certain attributes and qualities, so don't be scared by the cost of modeling.

With people

You probably not work alone, dear Reader.

There are other IT folks that try to keep the ball running, either by growing the systems from inside or by trying to help from outside - either by operating it or by selling it, or by doing any other activity that makes the system "live".

It would be great if all share the understanding about the "whys", the goals and the limitations of the system.

"The code" does not solve all problems and sometimes a piece of documentation might be good fit for making other people's life easier.

The perfect match would be if "the code" bakes the documentation, but hey - there's no free lunch.

Sometimes shouting out on your-favorite-communication tool regarding the isse you found makes it easier to bear the harsh part of the system's reality.

It is tough or even impossible to state "the best practices" about keeping other people, involved in working on and with the system, updated with all the nitty-gritties.

But it's worth keeping that in mind constantly - whether you write your class or a new function - there is another human being that will read it and he or she will try to comprehend - "what did the author think?".

This does not mean that we can't introduce new ways of thinking (= mental models), but at least have the empathy to "warn" fellow team mates about it.

Have a chat, or discussion, or a zoom call.

Put things visually.

Show it and stop making it being invisible.

This means that how we design the system matters for the people that are impacted by - those who stand in the first, second, third and further lines from the "system's center".

With all the automation, tooling and fancy stuff one aspect of design does not change - empathy.

For people

Intentially left as a cherry on top of the cake - the end users, the bussines stakeholders.

People that would eventually benefit from the running system.

Some human beings had problems that our system is trying to tackle - and yet again, "the code" does not mean to be an answer all the time.

Sometimes an innovation comes with the process which might be slightly "accelerated" by composing it with software.

Constantly having this group of people in mind unblocks and gives substantial perspectives on why we are putting some structures in place.

And this does not mean that everything must be pixel perfect from day 0 - ugly looking page, reducing a customer's employee time by days, so that it take hours if not minutes, delivers infinitely more than perfectly organized software components.

The primary attribute of used software is that it's going to be a subject of change.

And it is going to be used by, wait for it, people.

Business stakeholders would probably like to feel the confindence while demoing the product.

And feel pride when selling it to the next customer.

Getting delightful opinions about the system is also one of the way we might "get paid".

Flattering words do not pay bills - of course.

Still, somehow they strangely attract the money.

User-centered design shapes the system in the so profound way that none of the dead architecture diagrams would ever do.

Of course, all the focus and the obssession on the people we deliver software for, shouldn't discard the professional attitude toward our work.

We are hired to use our technical excellence so that "things happen" - but not to satisfy the ego of oneself.

Communication

Systems we build, grow and operate, are consequences of the communication.

The communication between the people.

And with empathy, with egolessness and with psychological safety, it thrives and blooms like a flower.

Don't make other peoples think - here meaning - assume.

Clarity is what we we all need.