Last night I was catching up on the day’s Twitter exchanges when I can across a conversation between two Microsoft employees.
One of the participants was a member of my team and another was member of the Microsoft “field” DPE organization.
The “DE” was telling the guy on my team that “whether he liked it or not, he working in a marketing role”.
I thought, man, if that DE was so clueless about what my team does, then tons of our customers don’t know what my team does either.
I suppose it makes sense. For years it was just me and the team owner (Simon Muzio). It’s only been in the last year that we became a full blown team.
The confusion in the aforementioned conversation might start with the fact that a DE (Developer Evangelist) IS a marketing role. A DE’s job is to drive awareness and adoption of Microsoft Developer Tools and Platforms. Their salaries and activities are primarily funded by a marketing organization.
They do this, for the most part, in very concise geographic areas. For example, there are New England DEs who focus exclusively on developers and customers in the New England geography. (Though there are some “Corporate DEs” who focus on specific technologies with no geographic restriction.)
Now, the DE role has changed in recent years and continues to do so. DE’s are no longer measured on sales impact; they don’t track their revenue impact, etc. But their role is to be expert in Microsoft’s Developer Technologies, to engage customers in their geographic areas, primarily in 1-to-many activities and increase the adoption rates of Microsoft’s products as well as increase the satisfaction levels f our developer customers.
That’s not what my team does.
We don’t really have a team name as yet, though internally we are sometimes refer to as ScottGu’s Secret Ninja Army ☺
Simon Muzio manages my team and apart from our general charter we have the agility to do what Scott Guthrie thinks is important on a week-to-week basis.
My team consists of the following folks:
• Joe Stagner (Me) – Focusing on Web Technologies with specialties including Security, Scale and Performance, Non-Microsoft Web Developer Technologies, interop, and relative business issues.
• Jesse Liberty – Focusing on Slverlight
• Tim Heuer – Focusing on SIlverlight (Tom and Jesse divide up areas of Silverlight)
• Steven Walther – Focusing on ASP.NET MVC
• Scott Hansleman – I’m actually not exactly sure what Scott does but he moves between technologies and focuses a lot on unreleased technologies.
• We have a collection of great support staff that does things like media production and web site management.
So, apart from each of our technological specialties, WHAT do we do and how do we differ from “Developer Evangelists”.
First, we are actually ON The product teams, our salaries are paid from R&D not sales and marketing. This means that our focus is different than that of Developer Evangelists.
Yes, we also do a lot of 1-to-many activities, but to a different end than driving sales and adoption
Our role is two fold.
1.) To communicate product details and strategy (and thereby catalyze real and full understanding of the technology’s intent) directly from the folks who design and develop the products
2.) To ACTIVLY solicit feedback from developers, to aggregate that feedback and present it to the product feature teams and thereby by shape the developer products that we are developing today and that we will develop tomorrow.
The 1-to-many activities that we do are, in large part, simply the vehicle that we employ to connect with many, many developers in order to gather the data we need to positively affect the product our teams build.
While all Microsoft employees are interested in customer satisfaction and adoption, my team’s positive results in these areas might be thought of as by-products of the ongoing conversations that we MUST have with customers in order to bring much needed data back into the development process.
They are not the end target result of our activities.
While both teams are important to the Microsoft Developer community, I think this difference is very important, both for developer customers to know, and for DEs to understand.
DE work primarily with the product that we release.
Our team’s role is to help DETERMINE what those products should be.
Anyway, that's what our team does (I think :) - might be different next week.
Questions ?