Managing by Maxim

I'm a big fan of maxims, adages, anything that sums up an important, and possibly complex point in a sentence that can convey, if not the whole point, at least a conversation starter. The main challenge for a technology manager is communication, particularly with those who are uninterested and/or threatened by technological terms. I live and breathe this stuff, but I understand that I'm in the ten percent, the ten percent of people who like and are completely comfortable with technology. The rest of the world ranges from averse to highly competent, but not gaga over it all, like I am. Remembering that, and approaching each project and decision with that in mind, has helped me accomplish significant things for people who aren't necessarily bought in to all of my ideas on first listen.

My current favorite maxim is Users own functionality, techies own platforms. This encompasses a couple of key concepts. First, technology isn't owned by IT or the people they serve; it's owned by both those who install it and those who use it. Therefore, technology can't be evaluated and planned for solely by one group or another. But I've seen lots of cases of both - IT rolling out a fundraising database or point of sale system with no input from the people who will base their revenue goals on the systems' capabilities; and staff rolling out equally complex systems with little or no IT guidance. Both situations are likely to be a big waste of funds and effort. Second, the breakdown is clear - IT might be wowed by the cool, Ajaxy interface on that web app, but if it doesn't have the reporting capabilities that the users need, they might be better served by something less flashy. That's for the users to decide. But IT will have a better read on how sound a database structure is for querying and reporting, or what will integrate successfully with other key systems. So IT should have sway over the technologies used, to a large extent.

If you build it, they won't come is another favorite. Unlike some cinematic baseball greats, techies can't build huge systems in anticipation of user's needs and expect them to be adopted, no matter how great the systems are. Clearly identified needs and ample amounts of input and involvement are required for home-grown system development. At my job, I am pushing agile development, which includes user testing and input from early on in development. This means that I'm teaching my staff how to let go a bit, and be more open to feedback, as I'm teaching the non-techie staff how to evaluate functionality in unfinished, and possibly somewhat ugly systems. It's not as much training as it is imploring all parties to have some faith in each other.

In business communications, you haven't said anything until you've said it three times in three different mediums. This one was taught to me by one of my greatest mentors, an ED at a commercial law firm that I worked at in the 90's. It boils down to the terser rule of thumb: Assume that they haven't read your email. The biggest mistake that we all make is thinking that we've made our intentions and priorities clear by sending a memo or an all staff email. The truly important initiatives that you're pushing through should be reiterated and the message diversified, to reach people who may not respond to your favorite medium. And, as Paul has well-pointed out, at least one of those mediums should be verbal, and hopefully in the same room.

What are the maxims that you manage and survive by? Leave your best ones in the comments.