Abstractions: Business Processes

The only way to play politics with integrity is not to play it all. Be oblivious to it. I don't mean be unaware of it, but act as if it isn't there at all.
As we simplify complexity through understanding our capacity increases as the burden of our previous knowledge is reduced.
Note: this article is a follow on from The Craft of Software Engineering: Abstractions and Processes. There is a follow on from this article: Software Engineering Abstractions: Design and Testing.
In a tech company there is one team without which you don't have a tech company. The engineers of course. Technically every other team is disposable as the company could continue running and their function could be absorbed elsewhere. It might not be as good, but you still have a tech company. Obviously that puts the engineers in charge, but don't worry we're a smart bunch and we'll work with everyone to work out the best way to run a company. That means everyone has a valuable role as the things you're good at we don't particularly like doing (because we're not very good at them).

Obviously this is a ridiculous thing to say and is meant in fun. The serious point I'm trying to make is that there ins an engineering mindset. The mindset is different from the role, many of those currently in a role labelled engineer may actually be more appropriately called technicians or scientists. Conversely the engineering mindset is a useful way to see things in many areas beyond the role conventionally labelled engineer.

Engineering is about the solving of real world problems, which are usually inherently complex and difficult, through the creative application of science (in our case computer science) with understanding. That approach is useful in many situations. What can I change to improve things, how do things work? Real life and real problems are inherently complex, so an important part of the role and function of the engineer is to manage and organise inherent complexity, whilst spotting and eliminating unnecessary complexity. It can be quite an art. As engineering is the application of science I see engineering as the practical application of the abstract whilst the science is the development of the abstract. But thinking about engineering, understanding abstract principles about it, is itself the science of engineering and therefore science. So the lines are blurry even aside the accidental science we may do, creating and finding new abstract principles, along the way of solving real world problems.

One of the aspects important to an efficiently running company, moving as a body of many members, is clear visibility. Visibility of processes between and into departments. This way the business unit, which must still lead and drive the company as money is the lifeblood, can see into the development process and allow the customers to engage and understand it enough both to set expectations and get the most useful interactions and engagement with customers possible. Similarly, through the business or customer engagement team the developers should have a clear sight of the problem domain and how customers are actually using the product, and more importantly able to see what customers actually need rather than what they think they need.

Providing this kind of insight is one of the most valuable jobs some companies do. It's wise to ensure payment before you spend too much time helping your customer define and understand their own needs. This is why garages will sometimes charge to give you a quote to fix a car. Working out exactly what is wrong can be very hard work.

However, if your company is built on dubious business practices, like bamboozling customers into paying for things they don't need, or if you have individuals pursuing empire building, then visibility becomes the enemy. In this way bad business practices become the enemy of good engineering practises. Clearly the converse is true, bad engineering practises will become the enemy of good business practises.

A more common enemy of visibility is fear. People don't realise that almost everyone feels like they don't know what they're doing and everyone around them is smarter. Because we don't realise it's normal to feel like this we keep people out and try and make sure no-one realises we feel like this. Difficult or hidden processes and arcane knowledge, unnecessary complexity, start to seem appealing. As always, difficult is not the same as smart and being simpler can often be very hard indeed.Actually processes and implementations that are open and honest are less of a burden and more efficient. This includes acknowledging when you don't understand, because that is both an opportunity to learn and a possible indicator that things are excessively complex.

Within a business, processes should not be an imposition of how things should be but instead a process should be a clear understanding of how things happen through normal human interaction and relationship. Your business abstractions encoded as processes only make sense in the context of normal human behaviour, since the low level operation of these processes happens through normal human behaviour.

So if your instructions don't operate very well on humans, or aren't even aware they're intended to run on the human operating system, then they will be bad processes. Human operating systems executing instructions designed for machines makes for unhappy humans. Things that make people unhappy we generally call bad.

To run a business efficiently we need to undertand how humans operate efficiently, since a business is actually an abstract entity (it doesn't really exist) and its corporeal form is as a bunch of human individuals. Therefore (and clearly anyway) the actual behaviour of a company is comprised solely as the sum behaviour of all those individuals as they act in the name of the company.

So the way a company changes is through normal human interaction and relationships, since that is what a company consists of.

A company is self-aware to the extent that the roles and processes within it are visible. A company that can see itself, can understand itself (the reality of itself not just the ideal of itself) is able to change.

"The last phase of process automation, when the process is described in terms of automation but still done by humans, makes for really tedious work."

Popular posts from this blog

The Jesus Army and the Independent Inquiry into Childhood Sexual Abuse

Commentary on Brexit and Thoughts on Patriotism

The Bible: The Good Parts