What’s the Difference Between an "IT Pro" and a "Dev"?

2 minute read

Someone at Microsoft asked me whether I was an “IT Pro” or a “Dev” the other day in an official capacity, and I got a bee under my bonnet to figure out what the two terms actually meant. For a couple of years I haven’t really understood the terms, and since I figured I was the only one in the dark, I just kept my mouth shut about it. After all, I don’t *usually* like to look like I don’t know what’s going on. [Insert your joke about me knowing what’s going on here.]


I had always thought that the terms were Microsoft-driven, as I had never heard them (that I could remember) prior to becoming as Microsoft-focused as I have been the last few years with all of my SharePoint work.

I was surprised at the answers I got. They fell into several camps, which I would synthesize down to:

  • The terms are bogus and they annoy me
  • There is too much overlap to be meaningful
  • Please let me know when you figure it out

Here’s a smattering from the stream that my question generated. Note that there are some links to useful reading embedded in some of the tweets. If I missed something *you* said, and you’d like me to add it, please let me know.




The post to which Natasha referred is SharePoint: What in the world is an ITPro? on NothingButSharePoint.com‘s IT Pro channel.









Sure, it’s totally unfair to ask people to define two confusing terms on Twitter, much less one clear one. But it still was interesting to me how little real consensus there was.

I think that the most cogent answer I got in 140 characters on Twitter was from Diane Golshan at Microsoft, who runs the @msuspartner account:


I didn’t particularly like that answer, either, because it included “build” twice. When I pointed that out, Diane responded that they “build” different things. Fair enough.


So what conclusions did I draw from all of this? Well, primarily that these artificial distinctions don’t really make sense to many people, that there’s not a clear common understanding of the terms, and that I definitely am not either. Or I’m both.

In any case, I’m pretty sure this isn’t the last time I’ll discuss this.



  1. I don’t know, I think they’re pretty clearly different.

    I tend to think of IT Pro as an sexed-up name for an ‘admin’. There’s probably a good reason for that – the world and his wife seem to be ‘admins’ for something, and it was maybe diluting the status of software administrators.

    So what do they do? Well, look at the SharePoint certifications. The IT Pro stream is more about installation, configuration, and operations (i.e. keeping it running!) The App Dev stream is more about creating solutions, and caring little about the ongoing operations.

    Now, with both I said ‘more about’ – there is a lot of overlap. SP Admins, at least, need to know Powershell these days, and you can’t tell me that isn’t coding – traditionally more of a ‘dev’ activitiy. And Developers need to understand installation and configuration so that their software can be, um, installed and configured. And then they’re usually gone in the night, which is why operations doesn’t tend to feature so much on the Dev side.

    But the focus is different, even if good IT Pros or Dev are actually good at both.

  2. I fall under both categories, I do both traditional “IT Pro” and “Dev” roles on a daily basis, as I think you need to be able to do with SharePoint as a “Developer” (I think that is in my title somewhere). I think your first clkassification would be “Dev”, and to be a good SharePoint developer, you also need to have a strong focus on “IT Pro”, as you will understand the technology better, and to develop solutions within SharePoint without re-inventing the wheel. SharePoint gives us a pretty big and feature rich wheel to start out with.. Just my $0.01 cent. I’d give my $0.02 cents, but I spent the other cent already. Sorry :(

  3. Marc,

    IT Pro, as in Information Technology Professional, can mean anything and is a vague term. I think that if one needs to separate something from the ‘developer’ term, it would be as we’ve done in USPJA, to call them ‘administrators’ when they manage stuff, and ‘developers’ when they build stuff.

    In SharePoint specifically, many, if not most, handle parts of both these disciplines. A developer needs to know at least something about managing and maintaining their solutions, while an administrator will need to know at least something about the development process, if nothing else to build management scripts.

    For most professionals, it is imperative to have at least capability knowledge of both disciplines, and even what we call ‘business user’, meaning soft skills like project management, feasibility analysis, and so on.


    • b:

      If I were to do a follow up post on this, I would talk about the SharePoint professional idea we espouse at the Academy. You and I are on the same page on this, in that we agree that for someone to be truly good with SharePoint, they need to cover at least a decent chunk of all three disciplines.

      Note that I left the “Business User” role out of this discussion so far. However, no SharePoint developer or admin worth their salt isn’t also a “user” of SharePoint. We all need to understand the three legs of the tripod upon which SharePoint succeeds. Oh, and by the way, those darn “users” are the real point, not “IT Pros” or “Devs”.


  4. I think it’s fairly clear.

    IT Pro = Administrator… this guy has the keys to RDP to Test and Production and looks after Infrastructure for Developers too sometimes.
    Developer = Developer…guy has their own environment and works in Visual Studio 2010 all his life. hopefully has no access to Test and Production!
    End User = End User…this guy spends their time in the web UI and SharePoint Designer.

    Lots of people will cross multiple roles. But it’s a nice way to break down into particular streams.

    Geoff…you owe me 0.02 cents!

    • Jeremy:

      I think those are the “traditional” distinctions, but with a platform like SharePoint which is both an application and a development environment, it blurs mightily. I, along with a large crew of other people, do what I’d call dev. But by your definition, I’m not a Developer because I choose not to crack open Visual Studio. I’m not buying that. You can have End Users writing script in CEWPs and for that reason, I’d call them Developers for that work which they do.

      Where it really breaks down for me is at conferences and in Microsoft’s marketing where there are almost velvet ropes at the door guiding each person down a specific “track”. SharePoint just isn’t that simple (actually, many technologies aren’t these days).

      BTW, your definition sounds very Microsoft-y, as they usually do when I see them, and that’s probably why I always took them to be Microsoft terms. (There’s no Visual Studio is you work on a LAMP stack.)


      • I agree, a developer doesn’t always have to make use of code to alter a system — this can come by simply using out of the box capabilities. I have a co-worker that feels very strongly that he is NOT a developer — however, many of the solutions he’s provided clients by clever usage of SharePoint out of the box capabilities rivals some of the “developed” solutions the client was already using.

        I am also seeing more emphasis on out of the box capabilities by the Microsoft Access Team that are not traditional “developer” projects. The projects they have been demonstrating make use of Microsoft Access features published to SharePoint 2010 and harnessing Access Services to deliver some really compelling applications build by end-users.

        By limiting a developer to code only, I think we miss the point of a developer — someone who builds solutions — and this can be done by anyone that is empowered to do so.

        • The definition of a developer seems so bluntly obvious to me that I find it strange that people need to define it down to using a particular program, and even a version of that program (Jeremy’s VS2010 reference). I’m using VS2008, so clearly I’m no developer, by that definition.

          If you call someone a baker, it is usually because they bake something, not because they only use a particular flour, yeast, or batter. If you call someone a developer, it is usually because they develop something, not because they use a particular program or methodology.

          I can see the need for someone to brand themselves with a particular title and ‘defend’ that title. However, for anyone else, who doesn’t care squat about the ego of individuals, ambiguous terms are the plague.

          You see the problem in job ads, where people want a ‘SharePoint developer’ to include managing everything from first tier development, through SPD, to Visual Studio, PLUS being able to manage and operate any sized and laid out farm.

          If you want a title for your Visual Studio 2010 development job, call it a “SharePoint Visual Studio 2010 Developer’. If you call yourself a SharePoint developer without qualifying it, at least to the tier level, I’ll call you stupid, because you clearly don’t understand your job, and should be dubbed ‘SharePoint apprentice’.


          • I think “you’re picking peanuts out of poo” picking me on my version of Visual Studio I quoted ;-) But I know you like to heckle and argue.
            Just in general if you’re writing managed code, you’re a developer.
            Yes I know there are others out there that are writing JavaScript client side code and CSS gurus and in the industry these are called “Web Developers”. I agree that as a “SharePoint Developer” we often have to use SharePoint Designer and the Web UI to get things done as the imperative approach is exhausting at times. I guess from Microsoft’s perspective they just didn’t want 50 roles for the SharePoint ecosystem. So IT Pro, Developer and Information Worker (End User) are the buckets they use.
            I would say that the Web Developers would be in the Developer bucket over the End User one in my opinion.

            • Jeremy,

              In addition, you also have what we call ‘business users’, meaning the soft skill SharePoint professionals. These include analysts, PMs, and people who know capabilities without knowing technical details. In short, anyone who is a SharePoint professional but doesn’t focus on the technical aspects at all.

              The problem Microsoft has in defining these terms for us is that the eco-system by its very nature expands beyond what fits into boxes, especially boxes designed by a committee.

              SharePoint is too complex and vast to fit into traditional software categories, simply because SharePoint spans far beyond software. It’s just as much and perhaps even more about business and users than technology.

              So far, we’ve only even talked about the ‘traditional’ SharePoint usage, but what about mobile developers or client software developers who do nothing but consume SharePoint web services and expose them through PHP or Java?

              I’ll still argue that whatever you develop, whatever tools you use, you are a developer. If you program, you’re a programmer, which is somewhat more specific, but still vague.

              In the end, though, the people who pay the bills will just say ‘Just build the damn thing and send me the bill’ not caring for our egos and need for titles.


  5. I think the water gets a little bit murky with the term IT Pro — let’s face it, if you work on information systems at any level as part of your day-to-day job role, you are a “professional”. I don’t know any organizations that hire IT people becaue this is their hobby and they like to tinker with various information systems — they hire “professionals” who have demonstrated competency through education and experience. This leads me to think of all developers, administrators, architects and to some degree, business analysts as IT Pro’s.

    Perhaps a better distinction is administrators, analysts and developers. Each of these can be more clearly defined. Administrators maintain the day-to-day operations of information systems and the infrastructure necessary to support those systems. Analysts look to strategically apply solutions to business problems with information systems. Developers build solutions by making alterations and customizations to the information systems, many times to meet the needs that an analyst has identified — not all developers have to be intrenched in code. All of these individuals are IT professionals because they are looking to support the business using information systems.

    I find that very few IT Pro’s have the luxury of being completely dedicated to administration, analysis of development. Most play various roles within the business and become vital to the business only as they are able to apply their knowledge to the business problem. Working with SharePoint, I often play the role of administrator, analyst and developer depending on the context of the business problem — I’m sure other information systems also find themselves in the same situation whether it is Exchange, SAP, SharePoint, etc.

    • The “Pro” part is probably the part that irks me the most, Chris. It implies to me that Devs and End Users aren’t professional. Now, I know many who aren’t (that’s a whole different discussion – professionalism in the workpace) but I’d say that people who commit themselves to their profession and strive for excellence are professionals.

      It used to be that only doctors and lawyers were considered professionals for whatever reason (rpobably just elitism). That doesn’t hold water for me, either, and thankfully that thinking is in the past.


  6. Drawing from a v. nascent stock of tech vocab, I would say that a developer creates the architectures that an IT Pro will tinker with, deploy and manage. IT deals with administration, maintenance, security; dev deals with constructing solutions. One is a personal trainer and one is Pygmalion.

  7. I don’t know how to separate what I do according to those terms any more than I can separate the solutions we’ve built by the categories Microsoft defines for SharePoint (Sites, Composites, Community…spare me). I usually break things down in terms of “the stuff I do that my boss understands” and “the stuff I do that he only expects me to understand” – unfortunately, “IT Pro” and “Dev” both fall into the latter category. Furthermore, I do development work in Visual Studio, but for desktop solutions, not for SharePoint. Am I still a “Dev” or am I one of those dreaded “IT Guys?”

    I want to be considered a part of the team who can be counted on to find a way to make our company’s investment in technology pay off. SharePoint is one of those technologies, and making it work requires, as several have already said, understanding the technology, being able to develop solutions and understanding the business professionals we are trying to help. As far as I know, my boss is only concerned with the end product, not what hat I was wearing when I built it. Microsoft? Seriously, I think Microsoft only cares about the fact that I am a “paying customer!”

  8. I tend to agree with Jeremy on his definitions. What I would really like to see is some additional strucure in the area of End Users. There are so many different types of end users. When people are typically doing End User tasks (as defined above as anything out of the box) it can be difficult to find all the information needed for the advanced tasks. This will then cause me to dig into both IT Pro content and Dev content.

    I also fall into the group that I dont really care what you call me :) I do what I do and don’t really need a title or my own grouping. But would like it to be easier to find the type of resources that are relevant and focus on what I do.

  9. A lot of great points here! I tend to agree as much as possible with everyone. I look at it from a different viewpoint because I don’t really care about my title as long as I do what is needed to get the job done. I can be a developer an end user or anything in between and I always try my best to be professional.


Have a thought or opinion?