I’m a big fan of openness and transparency; hiding things creates extra work, and showing others what’s going on in our world can allow them to help us, or at … Continue reading Tweaking the variables of transparency
A while back I wrote about how to conduct a discovery exercise in an incremental manner. This is where we have some idea of what we want to do but … Continue reading Expressing the results of a discovery exercise
We often have good ideas about things to improve and how to improve them—introducing a new tool, changing the way we do something, adjusting a procedure, and so on. But … Continue reading State the problem for any solution
Last week The Verge published an article about brewing discontent at Signal, the company behind the secure messaging app. The company doesn’t have plans in place for what happens if … Continue reading The morality of technology
We may claim our organisation has a culture of this or that, but how can we be confident? What is the tangible evidence? Our organisational culture is a mix of … Continue reading Embedding apprecation
Quite often I have to write down rules or guidelines about what’s considered acceptable for some situation. These might be bullet points in a job advert (characteristics we want candidates … Continue reading Creating guidelines using reverse engineering
A couple of years ago a colleague sat me down to have a “difficult conversation”. He was unhappy with something I was doing, and wanted to tell me about it. … Continue reading Supporting difficult conversations
I used to work with a content production team. Every day they would write and source various articles, and every day they would publish a good deal of material. Then … Continue reading Determining success criteria
Some time ago I was discussing the use of a centralised software system that had various configuration options (naturally), one of which would allow us to force employees to follow a certain process. The process was already company policy, so people should have been doing it, and it seemed natural to configure the system to make sure that was indeed happening. But one of the IT managers expressed a dislike of the idea. “Embedding a process in technology allows people to forget why the process was introduced in the first place,” he said.
This was a good point. We don’t just want people to follow rules or processes “because I said so”. There are (or should be) reasons behind those rules, and if people are convinced (rather than forced) to follow the rules then it’s more likely they will factor the reasons into other elements of their work. Or to put it another way, they will act in the spirit of the rule rather than merely to the letter of the rule.
Another reason to not embed a process or rule in technology is that, as long as the process is relatively lightweight, a technological solution will be much more difficult to adjust than a human, manual solution. Many people I know much prefer sticky notes to track their team’s work simply because it’s more flexible than any software. (Although that was before the days of enforced remote working due to Covid-19.) Often a spreadsheet is much easier than a custom database, even for fairly large volumes of work, because it’s just much easier to tweak.
Software is so-named because it can be changed. But very often a rougher, more rudimentary system allows us to do our jobs in a much more human manner.
Many, many years ago I held the pager for my company. This was long before cloud computing, long before devops, and long before infrastructure as code. Mostly the pager fired … Continue reading Learning by doing… in rehearsal