Interesting meetings, discussions from last week; as a former consulting partner once noticed, my calendar in Outlook usually looks like a game of Tetris, with back-to-back meetings, double bookings, etc. It was actually quite energizing for me last week, because the meetings were on wildly divergent topics covering lots of areas.
Side note: This scheduling style means I seem to be a few minutes late for each meeting – but then again, so are the other folks, so I guess flexibility is a good general rule (but it’s still not a good thing to do regularly).
- With the tech team … two separate cases of push-back from the group on issues, purely on technical considerations. However, my counter-arguments are typically along the lines of “there is a billion dollar project on hold for want of this feature / flexibility”, or “critical commitments have been made to management / customers / supply chain”, or what have you. When the argument against is that it’s technically the “wrong thing to do“, or “it’s long term maintenance expense” – man, you are losing the forest for the trees. The ongoing struggle is to get tech folks to see the overriding business reasons why we do what we do.
- Running a meeting with “lively discussion” … I like to preface meetings by apologizing for my (soon to be) abrasive style, for comments yet to be said that might be potentially embarrassing or offensive – and I also offer the prediction that the meeting will end with an edict from me, not a vote. Sounds combative, but the apologetic style usually works, and I’m trying to make sure the folks in the room really feel that we can all speak freely, question each other’s approach, and drive down to the best resolution for the issue(s) at hand. Also, I make sure to end the meeting with an apology again, and a quick follow-up chat with one or two that I know might have been “offended”. They usually aren’t, but it’s key to aggressively balance a drive-to-results style with real respect for peoples’ feelings – some day you’ll have to ask that person to run a gauntlet, loyalty goes both ways, etc.
- Requirements gathering meetings I … my favorite method is playing dumb (note: more “apologizing” for “dumb questions”), but this allows me to ask truly basic questions, real 5 whys stuff. I love asking the ultimate dumb question – “Why are we doing this task at all? What is the objective / point? What if we don’t do this activity? Note that you shouldn’t just ask how they do these steps, drill into the why – if there is no reason to do xyz, then don’t (and then we won’t have to automate it). (Corollary: the good programmer / systems developer is often lazy … more on that for another post …)
- Requirements gathering meetings II … Also, one effective way to manage scope / expectations is to lay down levels of functionality. For any report / query / program, establish a bare minimum bit of functionality, then go for a slightly nicer to have description, and so on. Note – early in the process, you should keep the “home run” super feature possibilities under your hat, at least until you get a proof-of-concept working … don’t want to set expectations to high (under promise, over-deliver).