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.
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
Once upon a time I was speaking to a software developer who was explaining why he wasn’t taking the kind of care in his work that he would have liked … Continue reading The chisel stage and the sandpaper stage
The other day I was reading Patrick Lencioni enthusing about Myers-Briggs Type Indicator (MBTI) personality tests. He gave examples of various situations where a clear description of someone’s biases and … Continue reading Don’t confuse silhouettes with x-rays
I was reading an article the other day about the dangers of making one-sided judgements about risk (tl;dr: always consider risk and reward together) and in the comments underneath someone … Continue reading Goals that show success, but don’t define it
I’m due to have a conversation with someone about an ambitious startup-type idea they’re seeking to run within an established company. They have an idea—it might be a great one–and … Continue reading The bell curve of project versus business
Over the last 12 months I’ve been speaking to people about leadership. Sometimes this is with technical people who are progressing up a career ladder into managment roles; sometimes it … Continue reading Erring on the side of direction