Every day I come to work, and I open my Visual Studio to develop yet another plugin / javascript / SSIS package / SSRS report.. And, then, an email comes in from a user who does not know how to do “this and that” in Dynamics, and we talk, and we get back to what we had been doing before (although, either the user knows, now, how to do “this and that”, or I have a new feature request in my backlog). And, then, a project manager shows up and asks if everything is going according to the plan, and I explain that, apparently, not quite, though we may still be able to pull it off.. And, then, I create a workflow to do something quickly.. And a new custom entity.. And a bunch of new fields.. And I don’t normally do business rules – they really feel cumbersome more often than not.
But, with all that, I absolutely hate when somebody calls me a Dynamics developer. That I’m formally on the team that’s doing “development” does not make me a developer. In my mind, I’m a Dynamics Consultant, and, so, I can pick and choose the tools which fit best in every particular situation. Sometimes, it can be a workflow. Sometimes, it can be a plugin. And, quite frankly, I don’t care that much about what the Architect (if there is one on the project) is going to tell me since, more likely than not, we will have to discuss our options once I look into it anyway (but that’s why I prefer to be the Architect.. rather than to give that much authority to somebody else)
So.. This post is going to be much less technical than most of the other posts here, and, actually, it has a lot to do with the discussion Ben Hosking started recently:
The problem is right there..
Apparently, somehow there is a separation between “consultants” and “developers”. But, where I would agree that not every developer is, also, a Dynamics Consultant, I would really disagree with anyone telling me that you can be a Dynamics Consultant without knowing anything about the XRM capabilities.
However, if you know about those capabilities, you’ll be able to make a conscious choice when asked about the most appropriate technique to use in each particular situation. That’s, basically, what makes you a Dynamics Consultant – your ability to advise the client what the options are. Of course, you might not be that strong on the technical side to develop a plugin from scratch.. But, as long as you understand the options, and as long as you can explain them to the client, you are a consultant.
So, getting back to that screenshot above, I do think that Dynamics Consultants are supposed to be able to choose which technique is best, and that includes development techniques as well. Some consultants might be better developers than others, but it does not mean that any consultant can completely ignore the “development” side of Dynamics.
The reason I hate being called a Dynamics developer is that it sort of pushes me into the corner. Developers are supposed to develop, that’s not my case at all. There is so much more I’m supposed to do on the Dynamics projects – business analysis, solution design, software architecture, pure coding, users training, pure configuration, maintaining the server, opening support tickets with Microsoft, maintaining the backlog, providing support to the users.. this list can go on and on.
This so-called “Dynamics developer” role is really quite peculiar and there is so little difference there is from a consultant. If you are a .NET developer, your work is focused on the development. But, if you are a Dynamics developer, you have to understand the product first of all – otherwise, your opportunity plugins will be conflicting with the out of the box price calculations, your validation plugins will be missing some unusual scenarios, and so on. Once you get there, you suddenly become a consultant, and, at some point, you will find yourself saying “well, I think it should be done with a workflow.. or, wait, it would be even easier to just configure a parental relationship.. although, how about this OOB workaround?”. But, when it’s called a “developer” role, that sort of implies certain things about what the person is supposed to be doing, and this is where things can easily go wrong because of the incorrect expectations on both the client and the “developer” sides.
So, call me all you want, but don’t call me a developer.. despite all the development I do every day. Dynamics Consultant would be just fine by me, although, if it’s a Dynamics Solution Architect, it’s, probably, even better.. since that gives me a bit more “authority” in terms of making decisions.
Alex,
I believe it depends which region of globe you are working.
Central europe – do not distinguish between Tech.Consultant, Func.Consultant, Architect, Developer. Everything does the same person.
US – Difference in Tech.Consultant and Developer is hazy. Think it depends on end client understanding and the naming convention
UK – there is a big difference. From my experiance – Consultant meet face2face with client, gather requirements. Do oob customizations. Developer – does development, controls, provides estimates for quotation, also works as architects. And espacially in UK tech.Consultant and developer behaves like in Ben’s post.
Awesome post Alex !
I agree to all the points you made. Even I would say there is no role like just a “developer” for Dynamics. A technical person working on a Dynamics project has often to do much more than just development (And actually that’s what makes this role so special !). Hence I like to call myself as a Dynamics CRM Technical Consultant.
My thought process is – If you hire me for a technical role on a dynamics CRM project, then leave all kinds of technical implementation to me. I am not just a plugin coder or just a form customizer. I am a package !
Not every recruiter understands this part well. They think I can just customize CRM by changing form fields and configuring workflow. Plus, now they get more confused as they say I don’t know Dynamics 365 ? (as I haven’t worked on a client project which was on Dynamics 365 version).
Absolutely agree, Swaroop.
With the note that Technical Consultants are still expected to have quite a bit of overall Dynamics knowledge (which makes it more a specialization thing than “techincal” vs “functional”.. A functional consultant may take a somewhat broader approach.. such as better knowledge of third-party products etc.. a technical consultant may focus on the technical capabilities.. but, as far as Dynamics is concerned.. both are supposed to know how to configure Dynamics and what can be done through the “code” customizations)