Some of my consulting lines are all about context. Let’s just jump right into a project kickoff meeting with an architect and a few developers:
The Conversation
Me: “So, what pains is this SQL Server having?”
Phil I. Buster: “When I first started out here, we had SQL Server 2005. The app only had a couple of users back then, so as we added functionality, we decided to keep the business logic in the database. It wasn’t too bad at first – ”
Me: “Ballpark, when was this?”
(The rest of the employees in the room give subtle winks at each other and elbow each other, knowing that Phil is getting ready to tell the application’s life story, and you can tell they’ve heard it a million times.)
Phil: “2005. And about six months into the project, we lost the key architect who’d initially designed the stored procedures. Here’s how the database looked in 2006 before we decided to rewrite it.” (Phil walks over to the wall and points at a Visio diagram taped together from tens of yellowing pieces of paper.)
Developer: “I’m not sure this is really the best use of Brent’s time…”
Me: “No no, Phil, keep going.”
What That Line Does
Put your pen down, because otherwise this line will make you want to jam it into your ears.
It’s really tempting to remind Phil of your hourly rate, or try to aggressively steer him back toward your original question, or playfully ask if everyone else wants to take a bio break while Phil brings you up to speed.
But here’s the thing – there are some people who really need to share their scarred emotional history on a project before they can face the current problems. Sometimes they want to make sure it’s clear that they’re not to blame for the issues, or that they were doing the best job they could, or that they’ve tried everything in the book over the last few years.
If you try to cut Phil off right away during the beginning of the relationship, it sets the tone that you don’t care about Phil’s work, input, or feelings. You have to let him get his story out and trust that eventually, his story will arrive at the present day.
What Happens Next
You listen attentively and patiently, and you never roll your eyes at the other attendees. (You don’t have to – they’re going to understand that you’re a patient saint, even if you don’t give them the slightest verbal clue that you’re just as frustrated as they are.) Whenever Phil mentions something that might be relevant to today’s pains, you write that down, but otherwise, encourage him to keep right on going.
Eventually, Phil’s going to arrive at the present day.
And your psychiatry work probably won’t be over, either. During your first couple of meetings, as you open up various parts of the system’s problems, Phil’s going to see something that sparks his memory and makes him want to tell you another story. At that point, you can take a slightly different tactic and ask that we put this story in the parking lot.
Another common variation of Phil is The Guy Who Wants to Demo Every Piece of the Software Before He’ll Show You The Problem. He has to show you his application because you’ve surely never seen anything like it, and he’s doing something that no other data professional could ever have conceived. Be patient with this guy too – and sometimes, he’s actually doing something cool.
If you enjoyed this technique, check out more of my favorite consulting lines.
7 Comments. Leave new
Of course all depends on the situation. If you are on an emergency project to fix an outage, that is very different from a project to enhance an app that is still online.
But in general, I think you should consider yourself lucky if someone is willing to err on the side of giving you more background than might be immediately needed.
In my own work, I don’t think I’ve ever felt that the “locals” were providing too much information. In fact almost always the other way around, and I need to make all kinds of assumptions, or play 20 questions for weeks with numerous different parties, to get adequate understanding of the situation.
ken
Ken – yeah, generally when we have an emergency and we’re trying to fix an outage, I don’t consider that a “project.” Understood though!
I love this post Brent. The part that resonates with me is the patience part. Flipping the moral, instead of “patience is a virtue” we have “impatience is a problem”.
And even during an emergency to fix an outage (especially during an emergency), impatience can be really bad.
Even Mr. Filibuster probably understands the urgency and so when he begins with “At my last job, we encountered this issue and …” he probably has a point to make.
Michael – thanks sir! Yeah, I used to think impatience – especially during meetings – was a virtue that helped me get to the root cause faster. It worked, but … sometimes I’d go back months later, and the situation was even worse because I didn’t let someone fully tell their story. They’d feel like they hadn’t been truly heard, and that I’d missed an important detail, and that’s why they should put the database shrink job back into place. (sigh)
I’m really digging this series. I’m getting a lot out of it, and I also think that it is really good for the community. As IT professionals, we become so results focused and “learning the latest skills” focused, that we forget that it is some of the soft skills that make us valuable – especially as consultants. Personally, I’ve consulted in lots of areas – from SQL Server to SharePoint to Drupal and PHP web development. What has kept me in those roles is not an innate knowledge of the technology (although it helps). What keeps you there is the ability to communicate with the business, navigate your way through meetings (whilst dealing with guys like Phil) and become a likable and productive member of the team – even if it is just for a short time. The soft skills will be just as important when it comes to your next contract extension as knowing the technology that got you the job in the first place.
Paul – thanks, glad you’re enjoying it! I Have a blast writing these.
Great series, Brent. I think there’s another aspect to this issue, too: you’re the consultant, therefore you don’t know everything about the systems/business/history.
You might well hear something in that hour-long ramble that tells you something important you need to do your job effectively (such as “we recommended a system upgrade 4 years ago, it was shot down for budgetary reasons by VP S. Ken Flint, and we’ve had to siphon off DBA resources to tune the last bleeding performance morsel out of our existing hardware).
It’s all about getting your head out of the technology. In order to do the technology.