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
Most people think of risk management as stopping bad things from happening. But ideally it’s really uncertainty management. That does cover reducing the chances of bad things happening, but it … Continue reading Risk management – helping good things happen
I was speaking once to the CEO of a small company, saying how valuable I found it to have small user stories for teams to work through. Not only is … Continue reading Small user stories: The gift that keeps on giving
Last week I wrote about how traditional risk “scoring” doesn’t translate easily to the way probability is best described, which is a probability density curve. Those are things like bell … Continue reading A different way to score risk
A couple of weeks ago I said that, although I think it’s a mistake to “score” risk events in terms of simple likelihood and impact, it’s not entirely devoid of … Continue reading Translating risk scoring into probability density distributions
A colleague once needed some help with a work-related problem, and she spoke to a large number of people to see how they had tackled similar problems in the past. … Continue reading Advice doesn’t have to agree
