[drewbug01]

So I think you are scratching at something interesting here - as a (senior) engineer who values communication intensely, I also try to “read between the lines” and extract what someone meant and not just what they said.

And so in that sense, I agree with you - from the perspective of the engineer in this example, yes: try to figure out what they meant and don’t get lost in the details. It’s a good example of not trying to control things that are fundamentally out of your hands.

But the other side is: this blog post (and the linked one explaining the “kernel” idea more deeply) is written from the perspective of the CTO! And it’s framed as a strategy - “encourage your engineers to learn how to intuit what you mean, and not what you say” (paraphrasing, of course).

I think that’s where it rubs me the wrong way. It subtly puts the responsibility for effective communication the receiving end. If we are considering it from a pragmatic standpoint, it’s just far more efficient for the CTO to say what he means from the get-go.

I mean, honestly even with the example: how much harder would it have been for the CTO to say “is it possible to go faster with something off-the-shelf rather than build our own?”

[calderwoodra]

Communication doesn't scale and there are many examples of that. It's not possible to convey complex topics to a large audience, well, at all times. The audience has to do some work too.

[drewbug01]

I don’t disagree with you, but I don’t really think I implied that all the effort should be entirely on one party or the other.

In any case though, you’ve managed to nicely illustrate both of our points, so kudos on that.