Yup, I’m stealing the main part of the title from Dan Antion’s (@dantion) SharePoint Story for this week. Why? Well, because the story is about the two days I spent with Dan and his team talking about developing in SharePoint’s Middle Tier. I don’t usually like to crow, but when someone like Dan comes up with a cool title like that, I steal it.
Dan summarizes the work we did well, but let me give you my slant on it.
Dan and I started talking about getting together in some fashion back in February. Dan and I had met briefly a couple of times at conferences, but I really didn’t know that much about him or his company other than what I read on Twitter and his blog, both of which I really enjoy.
Dan and I exchanged quite a few emails. We had lunch when Dan was here in the Boston area and talked at great length about his approach to development, the skills within his team, the type of business his company does, and where he wanted to expand all of that. We exchanged lots more emails and we set up a session for late March.
Then the earthquake and tsunami happened in Japan, and suddenly it wasn’t such a simple time to be in the nuclear insurance business, so we postponed things.
That gave us the opportunity to exchange even more emails and hone what we were going to do, tweak who would be in the room, and what we were going to cover.
I’m not outlining all of this to make it sound onerous. I enjoyed every bit of it. The reason I talk about all of the steps is to point out that Dan and I were taking our own little SharePoint journey together. (Yeah, I’m alluding to the Microsoft SharePoint Journeys thing.) Everyone needs to arrive at new ways of accomplishing things by taking the right path for themselves, and Dan and I were figuring out what that might look like for him as we went.
Even after all that, I’m not sure that each of the people in the room (there were five or six of us there for most of it) knew exactly what they were in for. One clear key ingredient for success to me was to be extremely flexible. That meant that I wasn’t walking in with some big pile of slides which I was going to force Dan and his folks through.
The two things I decided were the most important, and which I stressed to Dan throughout our conversations, were to:
- Show some of my favorite demos in the beginning to demonstrate some of the possibilities. The demos would be abstract, in the sense that they wouldn’t be about Dan’s business at all.
- Build something real with ANI’s data so that Dan and his team could see how things might work in their own environment and to make these techniques their own.
But most importantly, to go with wherever the conversation led. I hadn’t met this group and I didn’t really know what made them tick, just what Dan thought made them tick.
Some of my most valuable learning experiences came while I was sitting around a Harkness table at Exeter. I’m a crude hack next to the fantastic teachers I had leading me there, but I aspire to bring some of the same fluidity and conversational style to the table (pun intended) when I teach. So whether it’s a quick session at a conference, two days with a client like this was, or a six week course at the USPJ Academy, I like to let the group lead the way. Sure, there’s always material to cover, but there are also always huge swaths of ideas which come up which I could never predict. Sometimes it’s the tangents which become more important than the originally intended path. I find that is the fertile ground where most of the “Aha!” moments come. They are unpredictable, impossible to plan, and invaluable.
So that’s what we did. As it turned out, I did far less demo than I thought I would and we spent far more time working with Dan’s real data. We spent more time talking about the philosophy behind building a great User Experience (UX) than probably either Dan or I would have thought. We talked about how to make the code modular and reusable, but not as much as I might have expected, since the team wasn’t focused on that part of these techniques yet.
All in all, as I said in my comments on Dan’s post, I truly enjoyed myself. I walked away feeling that Dan and his team know a little more than they did before I arrived and that they were going to build better solutions with what they learned. Maybe they will call me back to help, but if not, they know that I’m always available to help answer questions and give quick advice.