If you’ve played bards from role playing games, they often have party buffs. The bard has weak combat skills and offensive magic capabilities. You don’t use the musical adventurer to one-shot a wight from existence with a burst of sunlight. Instead, you use bards to augment your team. If your team has 8 units, a +10 attack on everyone is an extra 80 damage. This is significant.
Why am I bringing up bards and how does that relate to engineering management?
About 20 years ago (when I was in grade school), I read a children’s book called Wizard’s Hall. The protagonist was a wizard who had no talent with classic magical feats. He botches spells, causes mishaps and doubts himself. He can do magic but he’s not sure what he’s really good at. I remember a scene where he attempts to cast a snowball with the other students and creates an avalanche. Not what anyone intended.
At the end of the book, his entire school faculty and students lose duel after duel against an evil wizard who wants to conquer the school. The penalty for losing is they’re all absorbed into a giant cloth beast. Each patch on the beast is a unique color pattern of the wizard defeated. My best friend in Vancouver would be a ginger square.
Our hero uses his unpredictable magic at the final showdown against the evil wizard. Surprisingly his magic is super effective because he tries. He puts in more effort than any other mage and then tries really hard on top. He saves the day and learns he’s an enhancer, a wizard capable of amplifying other wizard’s magic. Positive or negative energy.
As an engineering manager, I focus on enhancing engineers. I don’t need to be a Javascript ninja. I don’t need to be an expert in compiler magic or understand the grace of Haskell monads to improve my engineers. Before I pour more skill points into Bolt of Ruby to level my individual contributor skills, I need to make my engineers more effective.
Enhancements could include:
- Investing in the team
- Removing annoyances
Investing in the team
I believe in encouraging my engineers to continuously learn. When I was at a small company, hiring for talent was extremely difficult. The best option is to grow skills internally.
Everyone should send out articles on promising new technologies. I talk relentlessly about the future – what we could be doing and how we could do it with available open source projects. I give everyone leeway for experimentation. Whenever there’s a major fire or outage, we talk about what went wrong and how we fixed the issue. More importantly – how we can avoid creating the same mistake in the first place.
I want the engineers to look back 6 months later, and say “Wow, I’ve learned so much since then. What was I thinking back then?”
Removing annoyances
What bothers my team? Whether the disturbance comes from a co-worker, crappy wi-fi, or lack of a continuous delivery system, I don’t want my engineers feeling disgruntled. Every annoyance removed means my team never has expend mental energy to think about that again.
Issues like having an engineer restart a system every time the memory spikes out is bad for productivity.
I won’t magically get more done if I had a larger team. Given the team I have right now, I think of ways to expand our productivity.
[1] Pretty sure that’s a samurai, not an ninja
Leave a Reply