SharePoint Community: What Motivates You?

It seems like my post on “What’s Wrong with the SharePoint Community” triggered some reactions, to say it mildly. Not only did it spark a flurry of great comments and community debate (proving to those still in doubt that the SharePoint community is not dead, only in peril), but it also broke every record in reads and visits, as this graph from Google Analytics shows.

That’s fine and dandy, and I’m thrilled the community shows its value and commitment but I’m left with several important questions, chief of which is what actually motivates the community participants.

What Motivates Me?

I’m not going to ask you to disclose your personal motivations without disclosing mine first, and although I think I’ve let most of this slip in earlier posts, I’m gathering it here so you can know what drives me.


First, I’m not motivated by money. Although it’s a long story why, I’ll tell you about the experiment I did to examine whether I would be more or less motivated if I got paid at all. While studying at University of Phoenix, I wrote a paper on extrinsic motivation and how rewards can actually kill creativity but I would like to experience first hand what it meant.

So, in short, here’s what I did. In Q1 2006 I figured out what Norwegian welfare would pay me if I did nothing. Now, Norway has great welfare, but it wasn’t much, and I was quite used to a comfortable living from the salary I made. Next, at the start of every month, I took what exceeded the welfare payments and gave it away to charities or organizations to which I belong.

Then, every day, I kept a journal where I wrote down my thoughts about work in the morning and in the evening and scored a grade of 1-10 of how much I wanted to go to work the next day. Actually, after a few days, I got tired of writing to myself and just kept the score, but it was still astonishing what I discovered.

On average, and I don’t recall the numbers exactly, my desire to work increased throughout the experiment. Starting out at just over 6 on a weekly average, I ended up well over 8 by the time I was done. Not just that, but I enjoyed the experiment because it forced me into learning new ways of doing things and saving money.

The tasks I did were fairly similar too, so I’ve summarily ruled that out as a factor.

I realize that there are plenty of flaws in the methodology, but at least to me, it showed surprisingly that I wasn’t actually less motivated to work, even if I was not paid to do so (I was paid, but not more than I would had I just sat down and played games all day).

Want to know how much I’ve earned from my community participation? So far, I’ve sunk over $150,000 into USPJA, not counting the countless hours I’ve spent writing content and managing the operation. The USP Journals break even for pure expenses, but I don’t make a dime myself. This blog probably earns me monthly almost enough for a tank of gas in Norway.

So no, money is no motivating factor for me.


I’ll happily admit I love making noise, as I so fervently discourage in the community post. I absolutely love doing pranks like the one Joel and I and the speakers at SPTechCon Boston 2011 did. If you didn’t catch what was going on, check out this post.

However, those things are for fun. They’re done not because neither Joel nor I really need the attention but rather because it served a purpose in clarifying Joel’s ‘retirement’.

Yes, I write to be heard and because I want people to read what I have to say, but if you follow this blog, you also realize that I can go quiet for months if I don’t have something relevant to say. When I write, it’s usually because I think that both you and others will gain real value from it. I’m not writing for you to come visit me or remember me, I want you to read the message.

In fact, I have been pondering starting a new blog and writing under a different name, just to prove that point at least to myself. That way, I would personally not gain any benefit, but the message would still be heard.

I haven’t done that yet, though, simply because I’ve come to a point now where people want to read what _I_ write. If I started writing as Joe SharePointer, nobody would listen until the clout grew enough. Also, people would probably recognize my style rather quick.


No, the main thing that motivates me is knowledge. I adore knowledge, worship it even. I want to learn something new every day, otherwise I feel I’ve wasted that day.

I guess that’s what increased my motivating during the poverty experiment too. I was forced to learn to live my life on a shoestring budget and I learned how to shop smarter, to conserve food and resources, and to make the most of every single dime.

Here’s a big secret, known only to virtually all the ‘experts’ in the community: We don’t actually know that much. Most of us know very little.

No, really, we’re not oracles. I, for one, however, thrive on figuring things out. When I undertake writing a new USP Journal issue (like now, when I’m writing the SharePoint 2013 Beta series) it’s because I want as much to learn the stuff as the readers.

Of the 18 or so books and journals I’ve written, only one or two were on material I knew well. I write in a way that makes me learn, first and foremost, but it seems to work well for others too. I’ve made it into a method that allows me to combine learning for myself and telling others what I’ve learned. It’s a win-win situation as far as I’m concerned.

So, there you have it. Not money, not prestige, but learning. It shouldn’t be a huge mystery why I chose to start a SharePoint university and that I’m so passionate about teaching and acquiring new knowledge.

My question still remains, though. What motivates you to participate in the SharePoint community? Don’t be shy, feel free to be anonymous (but at least make up a nickname so I can address your comments).


Found this article valuable? Want to show your appreciation? Here are some options:

a) Click on the banners anywhere on the site to visit my blog's sponsors. They are all hand-picked and are selected based on providing great products and services to the SharePoint community.

b) Donate Bitcoins! I love Bitcoins, and you can donate if you'd like by clicking the button below.

c) Spread the word! Below, you should find links to sharing this article on your favorite social media sites. I'm an attention junkie, so sharing is caring in my book!

Pin It

Why SharePoint Development Tools are Bad for You!

I got this email comment from a reader of USP Journal (reposted with permission of the reader):

Hello and thank you for creating this great journal! I just finished “Professional SharePoint Development” and I recently implemented a project where these methods could be useful (they’ve already started changing themes and things just after release to production).

I know you like the VS2008 dev tools for SharePoint better but I think it would be appropriate to put a bit more work into adapting the article to VS2010. I wasn’t real familiar with the new toolset either but my company requires that I use the “latest and greatest” stuff so I found myself struggling to complete the steps of the project in VS2010.

I’m very determined to figure out the new tools and how they contrast with WSP Builder stuff and was eventually able to find equivalent steps in VS2010, however, others might be put off by your neglect of the tools that Microsoft is clearly pushing. Are the VS2010 tools used in VS2012 and SP2013 as well?

I get this question a lot, and I’ve written about my sentiment previously, but I’d like to once more bring the issue up because it is important and affects a lot of SharePoint developers.

Don’t Be a Tool!

Tools in any trade are there to make a known task easier. In other words, you need to learn and master the underlying task before you start using tools to speed up or ease the task. If you don’t master the underlying task first, you become just a tool user, not a task master. You know how to use the tool but not how to perform the task because you let the tool do the task for you.

Your situation is a perfect example of why understanding the underlying tasks are vital. You’ve just found a great method to build maintainable solutions, but you can’t use them because you understand many tasks from a tool perspective only. When I explain these techniques to master SharePoint developers, the quickly grasp the concept and are able to start utilizing them almost immediately, and we don’t even mention what tools we use.

In fact, I’ll go as far as saying that tools make idiots and that a lot of the crap we hear today about how one should avoid using custom code in SharePoint is because of idiots that have learned development using the brain dead out-of-the-box Visual Studio tools for development. Those tools create those idiots, and now Microsoft is paying the price by having a great development platform they have to recommend people don’t use. You don’t create great developers by giving them a point-and-click adventure game, and that’s about the most positive thing I can say about the Microsoft tools for SP development.

During my Beginning SharePoint Development courses at USPJA, the students spent the first three of six weeks without using any tools at all. The only tools allowed were Notepad and Makecab (I think I later allowed them to use VS just for editing but not for building) and they had to build their first taxonomy solutions using Notepad and Makecab only. Then, and only after proving that they knew the tasks like the backs of their hands, were they allowed to use any tool they liked, WSPBuilder, VSeWSS, STSDev, and I didn’t really care which one they chose because they were able to solve their problems with any of those tools.

I strongly believe that tools are completely irrelevant to a SharePoint professional. I have used the Professional SharePoint Development techniques on every platform (2007, 2010, and 2013, both WSS/Foundation and Server) and using virtually every VS tool and version there is, including the god-awful Microsoft ones (aka the ‘latest and greatest’). I just got contracted for a job where I’m required to use VS2012 against SP2010 and that’s completely irrelevant to my ability to perform the tasks. It does affect my efficiency to some extent because I have thousands of hours of practice using WSPBuilder and have only done a few major projects using the Microsoft tools.

Many clients with whom I work are initially very concerned with what tools I should use to do my job. Usually this is because they already have someone who knows how to do a task using a specific tool only, and sadly, this usually means that Microsoft thing. If they need to maintain your solution and they only know one tool, well, then you need to use the same tool as they.

That makes about as much sense as telling your doctor what pills or medicines she should use to treat you, or your carpenter what brand of hammer he needs to use to fix your leaky roof, based on the fact that you want someone else to continue treating you later, and they only know how to work with Tylenol or that your cousin needs to maintain the roof and he only has a Craftsman 16 oz. curved claw hammer.

After a few weeks, though, most clients realize that the tools are irrelevant to anyone but novices on wrong paths and let me focus on doing my job using the tools that make sense for the task.

So yes, the techniques taught in Pro SP Development work with any tool. I show examples using WSPBuilder because I’ve found I’m 2-3 times more productive with that as opposed to the Microsoft thing. If someone can’t understand the techniques based on not knowing the tools I used, then that’s a problem to solve rather than having to create two (or five) versions of the same document to show examples to people who only learn the tools, not the tasks.


Pin It

USP Journal Issue SPInvoice Explained Now Available

SPInvoice Explained is an advanced developer issue that focuses on teaching good SharePoint development concepts to experienced developers.


The solution SPInvoice is a training solution only, built to teach these concepts, using a mock but realistic software product.

In this issue, you’ll learn advanced SharePoint development concepts such as

  • Building solutions that upgrade across SharePoint versions
  • Understanding custom configuration options in SharePoint
  • Developing advanced user experiences with delegate controls and state management
  • Building rapid taxonomy solutions
  • Creating advanced user interfaces using jQuery and SPServices

You can check out a preview video of the user interface of SPInvoice here:

In addition to these concepts, SPInvoice Explained covers supporting techniques such as

  • Solution structure and organization
  • Property bags and other configuration features
  • Configuring features and solutions with feature receivers
  • ASP.NET development, including custom controls and in-line code
  • Migrating traditional HTML layout to SharePoint

SPInvoice Explained is now available for purchase. Included in the package is the 120 page issue and the full source code for the solution. The solution source files are also available from

You can purchase right now here 🙂


Pin It