Over the past few weeks and months I’ve been contemplating putting together a post that describes what I do – partly as a reference to others (to answer that oft-asked question), partly to inventory my own activities and interests, and in no small part to get myself thinking about what lies ahead. I also expect this will be something that gets updated periodically and thus won’t be a snapshot of a particular time in my career (I hope, anyhow).
Why here? Well I thought about making this my LinkedIn summary but I’m not sure if it’s really the appropriate place. Maybe parts of it will make their way in there though. So here goes…
Current / Typical Activities
On any given day you might find me building SharePoint farms (either for testing purposes or for customers of my employer, Navantis). In fact, I build a lot of farms. Or perhaps, more appropriately, AutoSPInstaller does. That’s the PowerShell-based scripted process (which I created over 4 years ago and still maintain regularly) that hundreds of folks across the world have downloaded and used to help build their own SharePoint farms – kinda cool.
But before you build a SharePoint farm, you need to plan, size and architect it. So I also spend a fair amount of time meeting with customers to discuss their SharePoint infrastructure requirements – with a business angle as much as possible. It’s all well and good for a client to say “oh, we want everything turned on” as far as features and service apps go. But that’s akin to saying you want a 12-bedroom house for your family of 4, “in case we ever grow”. You might be able to afford that large house, but can you afford to heat, cool & maintain it? Similarly, now that you’ve turned on every single available SharePoint service (Lotus Notes connector, anyone?), those things consume memory and resources – and if nobody’s using them (yet, if ever), they’re costing you in terms of server resources.
If all goes well, the outcome of these planning and requirements gathering activities is a good solid SharePoint architecture design, which then feeds very nicely into the afore-mentioned scripted installation procedure.
It’s not all net-new builds of course. I find myself doing SharePoint health checks more and more these days, which quite often transition into either remediation mini-projects or full-blown farm re-builds, depending on the results of the health checks. I expect these types of engagements to increase in frequency as all those on-premises SharePoint 2007, 2010 and 2013 environments out there age and, as is unfortunately typical, don’t get the TLC they deserve.
With regard to SharePoint/Windows operations and management, well I also create and maintain some scripts for that, too. Mind you, I certainly wouldn’t say I do proper software development or coding; however, having worked with and supported developers for most of my career in IT, I have a good understanding of the development lifecycle and the peculiarities and challenges faced.
Otherwise, I do a fair bit of estimation and project management ‘lite’: How long will this particular SharePoint deployment take, based on number of farms, servers, service apps being provisioned, etc.? What’s the anticipated project velocity, given the level of knowledge the customer’s own resources have, their change management processes, overall policies, and other intangible environmental factors? Finally, what are the assumptions we’re making, and the associated risks if our assumptions are wrong or not met? Experience has led me to a fairly robust personal process for gathering all of this information, which I refine with each engagement. You might even catch me fussing about in Microsoft Project to collect a lot of this information, too.
What I’m passionate about
I love automating mundane tasks, templating, and all-around maximizing re-use. I also have a knack for (and get energized from) solving tough technical issues, digging under the covers, taking a step back (or several steps back) when required and methodically walking through an issue - and realizing there’s no such thing as dumb questions along the way.
Applying best practices – a frequently-used term that’s actually tough to nail down (e.g. as defined by whom? And for whom?), though luckily within communities like SharePoint there appears to be consensus on most so-called best practices, blessed by those with ample field experience, with backing evidence. I like to count my own experiences among those, which gives me that additional confidence and personal satisfaction.
New technology! I’m an early adopter (to a fault sometimes). Phones, tablets, laptops, servers, I love reading about news & advancements on all of these. However, as much as I’d like to, say, install that Windows 9 preview on my work laptop, experience (age?) has taught me that sometimes it’s best to hold off. But then again, here comes technology to the rescue – I can run it in a local virtual machine :) which I do frequently with a lot of new tech. I consider it almost a duty to test out new SharePoint updates for example – at least so far as how they install and integrate.
What I want to do more of
Knowledge transfer (fancy consultant phrase for teaching)… Standing up in front of individuals and audiences and presenting my perspective on how things should be installed, should run and be maintained/operated, etc. This could involve travel to different cities for brief stints (conferences, yay), although admittedly that’s tough at the current point in my life with 4 young kids (including 3 under age 5). One of my regrets in life is that I didn’t catch the speaking bug earlier in my career – would have loved to travel to conferences around the world speaking on the topics I’m passionate about. Hopefully as things get easier on the home front this dream will become more of a reality.
Teamwork is unfortunately something that seems to be getting more and more rare in my current role. Seems I’m a bit of a lone wolf – most projects don’t have the budget to support more than one of me! While there may be several developers, business analysts, etc. I tend to be the only infrastructure architect. So I actually (gasp!) look forward to meetings where I can interface with the other team members and share my thoughts and advice.
What I want to do less of
Documentation for documentation’s sake. Yes, I get it, it’s a big part of a consultant’s job. But there are two problems as I see it. One, I consider myself really slow at writing documentation because I’m a perfectionist. I’m constantly correcting and re-correcting my writing to the point where a paragraph seems to take forever to put together. Second, so much of the documentation us consultants write seems to end up in a black hole, or filed off in some file share (document library) somewhere where it quickly grows old and obsolete before anyone really reads it. To me, the time spent writing these pages upon pages could be better spent teaching, scripting (yay), actually doing, or worst case, writing concise, quick-reference material that’s both easy to read and easy to keep current.
In fact, much of the motivation behind AutoSPInstaller was to replace the long series of screen caps & instructions found in typical SharePoint “build books” with something that would not only help someone rebuild a SharePoint environment, but would do so in the most automated and error-free way possible. I get a great sense of satisfaction telling customers “There will be NO build book…
Extreme multi-tasking is another thorn in my side. Sure I like to be busy – way more than I like having idle time. Being busy on a handful of tasks while feeling they are all moving forward is one thing, but being busy trying to juggle tasks, where a lot of effort is spent just switching contexts does not amount to a lot of productivity and just leaves me feeling bewildered and like I haven’t accomplished anything.
Work environment
Delivery-based work – in other words, being given the autonomy as a seasoned IT pro to make the call about where I can best be productive given the type of work I’m currently engaged in – be it a coffee shop, library, home (though not likely with 2-4 kids in the house at any given moment!), the client site, or maybe even the office (!) I want my (prospective) employer to say (implicitly or explicitly) “we don’t care where you work, as long as you get it done”. Mind you, if the “it” is something like “gather requirements” then obviously that won’t work nearly as well from the comfort of my own basement than it would in the same room as the customer. The point is, *I* can make (and have consistently made) the right decision about the where, and luckily these days it seems more and more employers are realizing the direct benefit of granting their staff the same degree of flexibility.
Further to my earlier claim as a lone wolf of sorts, I enjoy work environments with a healthy social component. Anyone who’s subject to my social media posts will attest to the fact that I love to (over)share my various exploits and experiences, but nothing beats human interaction – be it a pub night (SharePint!), sporting event, or casual lunchtime conversation. Work environments that promote this type of collaboration are tops in my books.
Summary
This concludes a brief bit of insight into the life of a consultant, architect & IT pro, currently working in the SharePoint space. Again, this post is really more of a self-inventory - a fulfillment of a promise to reflect on and record my professional activities, attitude and interests. Hope you found it useful, or at least mildly interesting…!