Feedback Sieves
Further reflecting on what I’d posted recently about giving 360º feedback (and on how to give good feedback after all), I came across a simple tool that is widely referred to as “Sokrates’ three sieves” but appears to have a different background.
In a nutshell, when you want to say something (or: write feedback for someone), apply these three tests to what you want to say: Is it true? Is it good? Is it necessary? If it fails any of these three tests, don’t say it.
Truthfulness is both obvious and a bit subtle. While it is correct that “your mileage may vary”, and coming to a shared objective truth may be hard, it is also correct that feedback should be based on observations, rather than on interpretations thereof. So the truthfulness stems from what the observer has seen. Facts can’t be disputed.
The “good” part is harder, especially if the word is taken literally: how can I possibly give negative feedback if what I share has to be “good”? The key here is to understand “good” as a short form of “good-willed”, or benevolent. Both positive and negative feedback, if constructive, have that aspect. Remember radical candor.
Finally, necessity. It is safe to assume that feedback given to improve a weakness or amplify a strength is “necessary” in that it ultimately has the recipient’s growth as its intent. It’s fair to call that necessary.
It would serve us well if we all could take this to heart while practicing giving feedback.
Tags: work
Trolling People With Tech
I recalled a time when a gentleman on LinkedIn started a brilliant thread on technology. The theme was “What’s a technology from your career history that, if you showed it to a tech newcomer today, they’d think you were trolling them?” It’s a wonderful collection of tech that’s accumulating there. I can relate to many of the sentiments. Of course, I chipped in with APL.
Tags: the-nerdy-bit
Some Tips on Writing Performance Feedback
Having read a decent amount of 360º feedback across multiple performance review cycles in various workplaces, I’ve seen a large number of useful and helpful comments. These can be praise or criticism - the ingredient that makes them helpful is that they have enough substance to follow up on, work with, ponder, and discuss. Even if they don’t give away who wrote them.
Some givers of feedback sign their comments. While that happens out of the best intentions and is a sign of trust, it is important to bear in mind that it can actually reduce the anonymity of everybody else. By exclusion, more precise guesses about the identity of the authors of anonymous comments can be made. This is especially important to keep in mind if the number of feedback givers is small.
I’ve also come across a pattern that I find unhelpful. It’s when someone’s feedback is not directed at the receiver, but at one of the receiver’s coworkers. Such comments can, for instance, praise receiver R for their patience with an inept colleague C. These comments effectively say more about C than about R. Honestly, such feedback should be directed to C directly. It has no place in R’s feedback. It’s badmouthing C behind their back.
We should be better than that.
Tags: work
Project Management Force Fields
Project management takes place in a field with three forces: the number of people available to do the work, the scope of the work, and the time available to do the work. Similar to the CAP theorem, it is usually not possible to satisfy all three in a way that avoids all constraints, and one of the three needs to be compromised on. To deliver the expected scope with the available people, more time is needed. To deliver in the expected time with the existing team, the scope needs to be reduced. To deliver the expected scope in the expected time, some more people have to be added to the team. More often than not, the three forces are not exactly within the control of the team in question.
There is a fourth force however; one that the team usually has a great degree of control over: the team’s ways of working. Scope as such can’t be reduced - how do we think about the scope? Can we find a way to deliver the intended value with reduced effort? We can’t take more time - how do we use our time? Can we use the available time with more efficiency and effectiveness? The company can’t hire more people - how do we collaborate? Can we improve our interactions to put everyone’s skills to the best possible use?
This isn’t easy: it involves consciously saying no to things, and to courageously cut the right corners. It is a kind of art. It requires a considerable degree of self awareness and understanding of operation at the team level. In the agile framework, retrospectives are a great tool for moving towards that kind of awareness, and for implementing conscious changes.
Tags: work
On Leaving
There is that special kind of saying that is just obviously nonsense but somehow keeps being repeated because it’s, I don’t know, culturally engrained or something. But that doesn’t make such sayings cultural wisdom, simply because they’re not wise at all. They just sound catchy. The following is a verbatim quote of a thing I blurted out on LinkedIn some time ago.
Since I’ve come across another example of the “employees don’t leave companies, they leave their managers” trope today …
Generalisation and simplification don’t cut it, in most cases there’s quite a bit of nuance involved.
Sure, blame it all on the managers. Or read on.
How about someone interested in significantly improving their financial situation for whatever reason finding another company that simply offers more than the current one possibly can? Not leaving the manager.
How about someone discovering they would like to apply that special knowledge they built in their spare time that just isn’t applicable in their current company but elsewhere? Not leaving the manager.
How about someone having collected enough money to finally start that travel year? Not leaving the manager.
How about someone who realises that the company culture is changing in ways they really don’t appreciate? Not leaving the manager.
And so forth.
If I may offer myself as a sample of one: of the six or so job changes I’ve done, only one was “leaving the manager”. The others were mixed, and more often “going to” than “going from”. I’m not implying statistical significance, but the “not companies, but managers” thing just reeks of simplistic nonsense with garlic on top. (I like the garlic.)
Addendum: At the time of this writing, I’m looking for a new job. I’m not leaving a manager, no reason for that. In a way, I’m leaving a company, because my current employer is liquidating itself. That’s not at all intentional on my part. In the context of the above, make of this what you will.
Tags: work
Sea Salt & Paper
Sea Salt & Paper is a card game. Players collect cards in their hands to build scores. They can also play certain combinations of cards to have beneficial effects, such as stealing cards from other players, scavenging cards from the stacks, and so forth. The game is fun to play and makes for some interesting challenges, but is not too special as such. What makes it stand out somewhat is the artwork: the cards are all designed in a minimalistic maritime origami style. They’re simply beautiful.
Tags: games
Levels of Insight
Once upon a time, there was an issue at work with having overlooked SSL certificates that were due for renewal. Once discovered, that was a quick fix, however we missed that the same certificate covered several subdomains, so more breakage was discovered and had to be fixed. In analysing what had happened, we discovered important insights and learnings at different levels.
The obvious one was more of a confirmation: the team understood the technology and issues we had been facing, so that those could be addressed quickly. This was good: we had small knowledge gaps at worst in the technology area.
There were two more levels of insight where we had to pay attention.
The first was the level of infrastructure and process. This covers things like dashboards, automated alerting and reminders, validation, documentation, and inter-team collaboration. These things hadn’t gotten the right attention - or there hadn’t been time for them. Both of these reasons weren’t acceptable, and we worked on fixing this.
The second level was that of plain old behaviour, or culture. It had, unfortunately, come to light that we had, on some occasions, not learned from failure: several of our subdomains had been affected by certificate issues across several subsequent days. Now, failures happen, so that’s “OK” - as long as we learn from them. If the same failure happens again, that’s a problem, because the learning didn’t happen. If the same failure happens yet again, that’s absolutely not OK by any means, because the insight that the learning didn’t happen wasn’t taken seriously.
As a bottom line takeaway, we had to learn that thinking in failure classes sounds plausible and even kind of obvious, but it takes the doing and awareness of the possibility of there being “more issues of a similar nature”.
Fixed.
Tags: work
Latency, Visualised
Here is a beautiful interactive visualisation of how long things take in and around computers, from L1 cache references to an IP packet roundtrip from the Netherlands to California and back. Each duration is a bar that’s proportional in length to all the others. That gives you a sense of relations. What’s even more fun is that you can also go back in time and observe how performance has evolved during the years.
Tags: the-nerdy-bit