Let me tell you the story of Billy. That’s not his real name. In my life, Billy is actually our cat. He’s a lovely cat, and he’s very fond of chicken. He’s agreed to have his name used in this article to protect the guilty.
So, Billy was brought in as a Director of Software Engineering. He sat in his office, went to other Director-like meetings, and occasionally had sessions with his engineering teams.
Billy was a danger to public health, and it was excellent that he left the organisation before too much of the talent in his department gave up and quit. The biggest danger Billy caused to health was the number of migraines he caused through excessive eye rolling.
Billy would either stand in front of stake holders, with his technical team present, and make them unrealistic promises. Or, and this was the worst to endure, would mansplain to his technical team how the technology that they used could do things. I say mansplain. That’s kind. He’d tell them things that he felt they should know, but they didn’t know them because they weren’t correct.
His team knew how things REALLY worked, and Billy made every single one of them hate working for him by proving to them, on a daily basis, that he didn’t understand what they did. Worse than that, he was actively trying to direct something that THEY were the experts in, from a position of very little knowledge.
What’s the point in hiring experts if you’re going to drown them in your ignorance?
That was Billy.
I didn’t work for Billy.
Maybe Billy never even existed…
… except he did… and does… and he may even be you.
Ask yourself whether you’re empowering your team to develop their expertise and solve problems for/with you? or whether you’re smothering them in whatever knowledge you have, at the expense of them developing and taking ownership.
Watch for the eye rolling. If it’s common, then change something.
In respect of the title… DON’T!
The Coding Craftsman 