Illegible perception

Good ideas are worth disagreeing with. Sean Goedecke posits that organizations implement process to have legibility – a very interesting idea. However, I see it differently.

It is not about legibility but it is about perception of legibility. Does the CEO look at burndown charts in your project management tool? Maybe, but highly unlikely. Does the head of product look at the key user flows that are getting implemented? Maybe. Does the EM look at the backlog of technical debt and prioritize items out of that backlog? Maybe, but if the organization is small enough and the EM is hands-on and smart - they “just go and do things”.

In nearly all the situations I’ve seen, the implementation of processes targeted at legibility were actually optics in disguise. We are now writing user stories because the person who became the CPO wants to establish that practice. We have a this-or-that process because the executive – or the key stakeholder – wants it implemented in a specific way. Or - because they do not care

I am not discounting the shared perceptions either! For example, it might be that multiple stakeholders want to have the perception that an incident reporting process is in place. They will not track whether people can actually learn anything from the incident reports, but they will hold the impression that it is in place.

Many introduced processes I’ve seen in software organizations were the result of someone’s perception being carefully managed, with the objective outcomes (if there were any) ranging from suboptimal to problematic.

Users can’t login into the application for 3 hours. Yet, because the CTO has the perception that the incident is carefully managed (he sees people pasting things in Slack about the issue) they do not register that what is actually needed is working access to the production system, which is only available to a select 2 people in the organization. One is on holiday, the other is swamped with other work. But because they overfocus on the perception that things are going well – they truck on. 3 hours turn into 4, then 5. Once things are finally fixed, another process rule gets instated - that there be an alert on failed logins.

A mistake one can make is that in this case legibility is not being achieved. In actuality, what is happening is exactly what the organization and the stakeholders wanted - the correct perception has been created that makes stakeholders feel good.

Operating on perception is natural

Humans are very visceral creatures. Two-system thinking is absolutely a thing and there is one very particular property: deep thinking – the “slow thinking” approach to finding solutions or answers – is expensive. It takes a lot of time, and since humans don’t really operate in parallel - but operate concurrently - it pushes a lot of other important tasks back onto the queue. Therefore, most people not only operate on feelings, hunches and perceptions - it is actually demanded of them. When you have an incident or a peculiar humans problem in your organization, you are not expected to say “I will go into seclusion for 3 days and come back with a plan” - you are expected to provide your instinctual response as soon as possible, ideally within the few minutes.

Grasping onto a perception - your understanding of the environment which makes you feel good – is absolutely natural in this case. Moreover: since it gives you a sense of completion and a dopamine hit (“I know how to sort this!”) – other people know too that it makes you feel good and will play to that. A cardinal rule of corporations is to not upset your manager and to not make them look bad – but that is basic competence. Skilled professionals know to take this a step further, and do so effectively – they make their manager feel confident.

Proposing a process which makes you, as a decision maker, perceive your organization is becoming more legible is a very juicy thing to do for a midlevel manager who reports to you. They know that it is very hard to actually evaluate the outcome of increasing legibility - you could make metrics on the output (“now 85% of work is tracked in JIRA”) but you can’t make them on the outcome (“now every engineer knows where to find the feature briefs”, or - for second-order effects - “now developers spend 20% of their time managing the JIRA process, and that time was previously dedicated to building”). Note the present tense here – it is deliberate. But the goal - making you feel good - has been achieved. You now firmly believe that the person has introduced something good – mission accomplished. This naturally has positive effects on the person’s promotion opportunities in the future.

The issue is that a huge JIRA installation with a multitude of projects does not make the organization more legible – or, maybe it does – but you never check. The goal was not making the organization more legible, the goal was creating a perception with you.

If you are in a position of authority it is wise to track all the “proposals” of such “legibility increases” with some additional vigilance. Some processes are good, and they do increase legibility and visibility. But many processes will be proposed to create optics of something, or – to advance careers by making you feel confident. And this may be fine as well – just don’t expect there to be real legibility improvements.

It is a balance

I’m not trying to say that it’s all optics, smoke, and mirrors. Process improvements very frequently bring good with them. A well-prepared improvement with a good definition of progress (and legibility) can free up hours of work, which can then be used for something more profitable for the organization. Other improvements can fix the completely broken processes and deliver you a story similar to The Unicorn Project and some improvements are so apparently useful that there can’t even be a discussion about them being “fake” or “pretending”.

Just a few examples:

• It is likely that having feature specifications will make stakeholders demanding those features more responsible
• It is likely that shortening the time-to-live for deployments is going to allow the org to deliver faster
• It is likely that having incident reports will make it more transparent - both to stakeholders and to line employees - where the system’s weak spots are

The challenge is gauging how much of a particular initiative’s output is going to be perception and how much is going to be legibility and being honest to yourself about it. Both on the initiating end and on the executing end of the initiative. And what’s in it for you and what goals are relevant for you once the process gets installed / improvement gets made.

Being honest with yourself is usually a good thing, and if you don’t project outward too much - it won’t even impact your career advancement.