How Many SharePoint Developers Are There Really?

By this time, everyone has heard the news that Microsoft is buying Yammer for $1.2 billion. And dammit, my offer was $1.1 billion, they just beat me to the finish line.

As part of their marketing of the wonders of the deal (and the jury is still out on a number of issues), Microsoft built a nice infographic to show what the union of Yammer and SharePoint would mean.

(I need you to click that link to view the infographic because I can’t determine whether the terms of use actually allow me to republish it, so I’m assuming I can’t)

Here’s one message, though. SharePoint currently has 66,000 customers with 125 million licenses sold. That means on average, each customer buys close to 2,000 licenses, which seems a bit odd to me, but hey, I’m not the source of the numbers so don’t shoot the messenger.

What’s very odd, though, is that Microsoft claims there are 700,000 ‘developers building on the platform’.

With these numbers, that means that for every SharePoint customer, there are over 10 developers.

Read that again: For every SharePoint customer, there are more than 10 developers.

I have no idea where Microsoft gets these numbers, nor what they define as ‘developer’, but it’s a very scary message to send out.

It can mean one of two things:

  1. There are far too many developers out there and a lot of them are unemployed. Good for businesses, if true.
  2. SharePoint is a platform so complex that you need to pay, on average, ten people to do nothing but develop on SharePoint. Bad for SharePoint, if true.

SharePoint Developer Shortage Over?

So why is it that the phone is ringing off the hook for most skilled SharePoint developers? Why is it that when I posted that I was available for work this summer, it took 40 seconds before I got the first firm contact?


I’m either a fucking genius whom everyone wants to work for them no matter what, and there’s an army of people just waiting in line, monitoring my activity to detect if I am available, or, more likely, there is still a shortage of SharePoint developers.

No, don’t take that as false modesty, I’m still a fucking genius, but I’m also still hearing similar stories from other people in the community.

Oh, and don’t take anecdotal evidence as more than casual rumor. Jump over to and do a search for SharePoint, you’ll find thousands of available SharePoint jobs, several hundred SharePoint Developer jobs, and over a hundred SharePoint Developer jobs paying more than $100K.

Work is still abundant, even though there are, according to Microsoft, on average 10 developers hired by every SharePoint customer.

During SPC09, Steve Ballmer mentioned that Microsoft predicted there will be 1 million SharePoint developers by the year 2013. That’s ten times as many as they predicted in 2007. Which is good, I mean, I’m in the business of educating these developers so a ten fold increase in customer based is great news.

Is SharePoint Really that Complex?

However, there’s still option #2, that there is something in SharePoint that’s so complex that you need to hire 10 people to get it to do what you want.

Let’s take those numbers and look at what they mean for a bit.

If the average SharePoint developer is about half the genius I am and only costs $100 per hour, that means that on average, every SharePoint customer pays $1,000 every hour, every day, to keep SharePoint running. Assuming a 1,900 hour work year, that means an average SharePoint customer pays $1,9 million for their SharePoint people.

$100 per hour is too much, you say? Think again. Keep in mind that salary is not the only cost of an employee. Even with a salary of $50 per hour, roughly the median salary of a semi-seasoned developer in the US, the cost of benefits, support staff (all SharePoint developers should have personal masseuses), insurance, office space, power and utilities, and, in the US, attorney fees for litigation protection against someone banging their head on the DVD player, the actual cost of that employee is rapidly approaching $100.

What could possibly be so complex that you’d need to pay your employees on average close to two million dollars just to sort it out?

The numbers puzzle me a bit, but may be simpler than you think. First, Microsoft marketing are idiots and use old data. C’mon, 66,000 customers? That sounds way too few, but let’s accept it at face value. I’m mean, it’s not like Microsoft would hold anything back from us, right? That would only be silly and hurt both SharePoint and the community.

Second, 700,000 SharePoint developers? Technically, and this is important, they said “700,000 developers building on the platform”. If you flip that around and say “someone who is building on the platform is a developer” then anyone who does any kind of menial task like setting up a few lists, libraries, or content types, may be dubbed a developer.

So, What is a Developer and Why Aren’t There 700,000 of Them??

By developer then, I mean someone who actually has any kind of real developer background, and not some random idiot who has learned to put together a SharePoint Designer workflow on the monkey see, monkey do principle. I mean someone who at least can spell source control, who know the difference between a class and an object, and who can see, with a bit of debugging, whether a loop is safe.

Here’s what I think: Microsoft is full of crap. There aren’t anywhere near 700,000 SharePoint developer. I don’t even think there’s half that. I think that, having utterly failed to reach their goal of a million real developers, rather than admit that they change the definition of the goal.

Another indication of community size is my USP Journal sales. From 2009,the first year of operation, to 2011, I’ve increased sales around three times, with far more issues available and current.

During SPC09, Steve Ballmer said there were 125,000 SharePoint professionals, including everything. Even if you set the number of developers versus other disciplines to 2:1 (meaning two developers for every other discipline professional) this means that by the end of 2009, there were around 82,000 developers. Multiply that by three, and you get just shy of 250,000 developers.

Of course, this assumes we completely ignore the increases in number of issues, any improvement in marketing, and any other factors that would increase journal sales at a different rate than the number of developers.

I can also look at my blog stats. Over the previous three years, the number of page views have increased about three fold. My RSS feed subscribers are a bit over double what they were in 2009.

I’m not saying that my journal sales or blog stats must accurately follow the development of the community, or are in themselves even an indication of that size, but when there’s absolutely no correlation with the presumed size of community, at least I’m suspicious.

I think that, even if these numbers and factors are highly speculative, Microsoft is nowhere near even 200,000 developers, partially because I assume that even the 125K professionals in 2009 was also bloated.

How Many SharePoint Developers Are There?

Occam is a great principle here: The simplest explanation, or at least the one requiring the fewest assumptions, is most often the right one. The simplest explanation here, accounting for both the still high demand for SharePoint developers, the fact that no one actually pays on average $2 million for their SharePoint developers (which would be a really, really bad thing for SharePoint), and the fact that my sales and blog increase is ‘only’ around three times, is that there is just three times as many developers now as there were in 2009.

Not 700,000. Not 350,000. More likely, there are 180-200K SharePoint developers, and that’s why you still can’t find a decent SharePoint developer available for hire.


PS: If you have a blog and have numbers as far back as 2009, why not tell me what your increase in readership has been over the previous years? No need to post actual numbers, and to all, keep in mind that these numbers are anecdotal only.

Update: I was actually full of crap myself. It wasn’t Steve Ballmer that said a million developers, it was Kurt DelBene, a then senior vice president of the Office Business Productivity Group, now president of Microsoft Office Division.

Adding to the confusion, however, is that he also claimed in November 2009 that Microsoft had sold 100 million licenses (compared to 125 million licenses now) to 17,000 customers (compared to 66,000 customers now). In other words, the latest 50,000 customers only brought in 250,000 new licenses, an average per customer of 5 licenses, compared to the claimed 7,400 per customer pre-2009. See why I’m suspicious of these numbers?

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

Paul, You’re an Idiot – The Dark Knight of SharePoint Rises

Dave Rubinstein of BZMedia asked me whether I would answer some questions about my role in the community. I said yes, he asked, and I answered. The resulting interview is published in the latest (at least at the time of writing) SPTechReport called “’The Dark Knight’ of SharePoint”.

Note: Incidentally, ‘The Dark Knight of SharePoint’ is a name Joel Oleson gave me some years ago, but he only calls me that when we’re alone and have romantic dinners. Just don’t tell his wife.

Of course, as soon as my name comes up, some idiot needs to rush to the scene to slander and lie about what I do. This time, the fella calls himself Paul (and I do suspect I know who it is), commenting as such:


(screenshot taken from

For those with image problems, here’s a play-by-play:

Paul: While his commentary is interesting and honest, the “freely available” information he references is covered by a non-disclosure agreement that participants in Microsoft’s preview program must agree to be bound to be in the program.

Bjørn: No, the information is not covered by an NDA. You are a blatant liar (at least I use clear words to say what I really mean).

Paul: Based on some limited reading I’ve done of Bjorn’s material, he has made it clear he does not believe he or those from whom he may get his information are bound by that agreement.

Bjørn: I’m glad you are able to comprehend what you read. It just proves that you’re very stupid or selective (or lazy) with what you read and form opinions not based on what you read and can research but what you stubbornly believe.

Paul: Apparently, he has a different understanding of what it means to give your word to be bound by rules of good conduct.

Bjørn: Because your assumption of guilt is false, that statement simply doesn’t make sense. You’re winding on about lies and how those lies prove I’m not showing ‘good conduct’. Here’s one statement, equally stupid and based on just as much fact as your claims: Apparently, Paul, you’re molesting goats for sexual pleasure, and based on that you’re a bad person not showing good conduct.

Paul: He’s made clear that he doesn’t appreciate MS need for the NDA, but should we then condone what he does and pay to subscribe to information he publishes on the beta because he doesn’t agree with it.

Bjørn: No, you shouldn’t, not anymore than we should listen to you because we condone your attitude towards goats. First, you shouldn’t, because any sensible person wouldn’t stick by their false assumptions when they’ve been disproven time and time again. Second, and most of all, you shouldn’t because what I do has nothing to do with any NDAs.

I published a comment on the SPTechReport article too, but I strongly suspect that Dave is too modest to publish it. However, when people like Paul show up with blatant slander like this, I don’t shut up. 


Pin It

SharePoint 2013 Upgrade or Not: 5 Strategies to Help You Decide

Over the previous few months, there have been a number of online articles telling you how to prepare for the next version of SharePoint (SharePoint 15 or SharePoint 2013, depending on who you believe).

Some of that advice is sound, but a lot of it is also rubbish, often coming from authors who have a vested interest in how you choose to upgrade and even prepare to upgrade.

Regardless of what others choose to say, however, I do have a few recommendations for how one should prepare for the next version.

1. Have a Problem? Fix it Now!

Look, a new version of SharePoint isn’t going to change your business problems. You won’t get new problems that only SharePoint 2013 can solve, simply because the new version becomes available.

SharePoint’s greatest feature is its ability to help solve your problems. No, not the problems that everyone face, but the problems that are unique to you. It can be everything from a cumbersome onboarding process, to inefficient handling of invoices, to how you do your performance reviews.

If those are problems you face right now, you should start solving them right now. If your biggest problem right now is not having an Education tracking module in your intranet, then sure, SharePoint 2013 may indeed be your salvation, but most likely your business won’t change come November.

Remember, it wasn’t a year ago when SharePoint 2010 was the perfect tool for solving any problem you may have had, it was shiny and great, and everyone knew it was the absolute best. Those voices will be saying the same thing about SharePoint 2013 in three years, and a few months later, everyone will rush towards SharePoint 2016.

Underneath it all, however, your problems remain largely the same, and you can and should solve them right now, regardless of which version of SharePoint you have.

2. Hang On, Don’t Rush It!

SharePoint will be here next year, and the year after. And yes, there will be a SharePoint 2016, which will be so much better, and you should probably wait for that to arrive because it’s going to truly outshine SharePoint 2013.

If, right now, you don’t have a problem that SharePoint can help you solve, then most likely, you won’t get those problems in November either. In other words, Microsoft releasing a new version will not give you new problems.

You see, the value of SharePoint isn’t in having the latest and greatest version of the platform. The most profitable solutions I’ve made are built on SharePoint 2007. As late as October last year (2011) a client approached me to build a brand new solution on SharePoint 2007 to solve a critical need they had, and that’s five years after the platform came out.

There were absolutely no benefits to upgrading to SharePoint 2010. When the client did decide to upgrade early this year, it was primarily because Microsoft was shutting down mainstream support, not because there was actually a set of features the client just had to have, or that even brought additional value.

Mainstream support for SharePoint 2010 isn’t scheduled to end until late 2015 and for a few extra bucks, you can extend that to at least 2020. You have plenty of time until then to evaluate whether upgrading actually benefits you.

3. Have Money to Spare? Sure, Upgrade Immediately!

When SharePoint 2013 hits the shelves, about 50 people in the world will know how to harness its new features. Everyone else will, with regards to experience with the new features, be essentially as blank as you are yourself.

Those people who do have experience will be massively expensive if you can even find them. Even the people who know a bit about the new version will lack the experience that SharePoint 2010 developers have, so they will likely not be very efficient, increasing the risk, time, or errors of your projects.

Your cost for doing anything on SharePoint 2013 in the early months will be massive, if you can even find someone who can do it.

You think I’m exaggerating? From October 2012, I start on a contract that was booked almost a year ago (summer of 2011). The client was willing to enter into a contract for a substantial amount of money over a year in advance just to ensure that they had available the people they need.

My point is this: rushing to get the latest and greatest isn’t historically a good strategy from a cost perspective.

4. Want to Get Rich? Don’t Wait!

If you are, like my client, in the business of knowing things early, then starting now is a better idea than it may seem. An example may be consulting companies or developers who wish to harness the wave of new technology that will dawn in a few short months.

First, as I’ve mentioned, the need for those that do know a little bit about SharePoint 2013 at launch will be massive, far greater than it was during the SharePoint 2010 boom. Back then, you couldn’t spit on the street without hitting someone looking to hire SharePoint people.

As a career move, or if you are in the consulting business and want to make a lot of money, moving to SharePoint 2013 early makes a lot of business sense.

Second, the lifespan of SharePoint version-specific knowledge is short. With a three-year product cycle, anything you learn about SharePoint 2013 today will start being stale in two years. The sooner you start, the longer you have to capitalize on your knowledge.

Consider this: it’s just two years since SharePoint 2010 hit the shelves, and we’ve already been talking about SharePoint 2013 for almost half a year. Had you started learning about SharePoint 2010 when it first came out, perhaps spending six months getting up-to-speed, you’d only have one year of benefit before everyone was talking about the next version.

5. Have Existing Custom Apps? Wait!

If you’ve developed custom solutions for SharePoint 2007 or 2010, then you should know that there is a high chance that those solutions won’t work with SharePoint 2013. I’m not just talking about .NET developed solutions here; anything that involves custom development has a risk.

Why? Well, with the extremely limited information Microsoft has given us, especially concerning programming interfaces, we simply don’t know whether there are breaking changes in the object model, CAML specifications, or even infrastructure, which may affect your custom solutions.

Microsoft are masters of backwards compatibility. They spend huge amounts of resources to ensure you’re still their customers, especially when they launch new versions of their software. It’s good bet that they have done their utmost to ensure that applications and solutions built for earlier versions as well as knowledge gained among the thousands of SharePoint professionals will continue to both work and be relevant.

Still, even the most carefully crafted solutions will have a chance of changes in features or definitions affecting or breaking them.

For example, we know that SharePoint 2013 will run on .NET 4.0, which includes a completely new workflow engine. If you’ve built custom workflow solutions in earlier versions, they may simply not work in 2013, at least not as they were designed.

As such, if you’ve done heavy customization or development, don’t rush onto a new version, but wait until you understand the upgrade requirements. After all, if your current solution solves your problems, why would you even need to upgrade?

Should I Stay or Should I Go?

Well, as with all things SharePoint, the answer is: it depends.

The risk of starting an upgrade process, whether on the technical bits or your knowledge, is high. The technical risks are that you start out on a platform that few understand and that most likely will be very expensive. The knowledge risk is that you tend to forget things you don’t do often and if your clients don’t move with you, then you’re learning something that you won’t use for a long time.

However, the rewards are also amazing. Early adoption means a longer time to reap returns. It means you’ll be a highly coveted employee or consultant. If you want a reputation in the community, knowing early is a great benefit.

What you should choose depends greatly on the risk you’re willing to take and the rewards you want from your efforts. Don’t fool yourself: upgrading won’t be as easy as you expect, neither on the technology end or the knowledge end.

Remember that with a completely new version, you also need to retrain your users; it’s a cost often overlooked.


Pin It