I’ve been busy lately making the shift from “hands-on engineer” to “hands-off manager”; it’s been tough, because I’m not accustomed to stepping away from a problem and letting someone else figure it out. Even though I’ve got an education background, and have been (inconsistently) involved in technical communities helping other people solve problems, I’ve never had to balance the responsibility of making sure that a job gets done with the responsibility of allowing someone to “learn from their mistakes”. It’s harder than I thought.
As part of my management training, however, I’ve been focusing on laying out principles and guidelines rather than specifics; for example, instead of saying something like:
We need to make sure that John Smith has limited access to that database; can you do that for me?
I’m trying to say something like:
Our databases need to be secure, and that includes differentiation in access based on job roles. Can you verify that all accounts are set up using that model? If there are exceptions, can you document why?
The idea is that a) I need to trust that the people that work for me know how to do their jobs, and b) I need them to start aligning their practices with the principles that I think should drive our work. I realize that last statement sounds a bit tyrannical, but in reality, I trust my team to help me develop those principles. However, it’s my job to provide the direction, and their job to keep the boat afloat.
As part of this exercise, I’ve begun to realize that I’ve had a worldview for several years that I’ve always fallen back on when it comes to solving problems. I’ve never thought of it as a mantra before, but the truth is that the following statement sums up my approach to most problems.
Simple is best.
When I encounter a challenge, and am forced to figure out a solution, I always fall back on the thought that a simple solution is usually the best one. When I’m face with deciding between option A and option B, I’m usually going to lean toward the one with the fewest moving parts, even if it doesn’t address every possible outcome. I’m a big fan of things like the 80/20 rule, and Occam’s Razor; it’s far easier for me to tackle problems in bite-sized chunks. It’s the first principle by which I evaluate any solution that my team presents; if it’s not simple, it’s not manageable in my opinion.
Not everyone I work with is oriented toward simplicity; one of my best friends (I’ve worked with him for 9 years) often chooses beautiful and thoroughly complex solutions to problems. I don’t know if could express what his mantra is, but I’d bet it would involve something about slicing and dicing problems into small pieces. I also work with another guy who loses me in jargon in every discussion; he’s very passionate about writing code that covers every scenario, even if it takes 6 months to a year to do so. I have a tough time thinking like that.
Mantra’s can be positive or negative. For example, two of my former managers had different mantras that they relied on; one manager used to say:
Never make a person do what a computer can do for them.
That helped guide us when making a decision on work priorities; if you’ve got someone cutting-and-pasting information from your application so that they can send an email, and they have to do that on a consistent basis, then you probably need to write some sort of hook into your application to let them use their email program from your app. If you’re hiring staff because of the uptick in workload, then you should probably figure out ways to reduce the amount of work using computing power.
The other manager (different company; different time in my career) used to chant:
Whoa, whoa, whoa; that’ll delay the project.
which made us all think that that the project was more important than actual details. It was a joke; the slightest interruption or shift in perspective would tip the entire apple cart. His inflexibility was legendary, and ultimately led to the loss of his entire staff (before he was eventually sent packing).
What’s your mantra? Do your teammates or employees know it? Does it contribute to the work effort, or has it become a tired joke among your colleagues?