To be perfectly honest, I had never heard of or understood the ‘PFE’ role at Microsoft until I moved away from Redmond and into the subsidiary. That was one of the traps of being in the product team on campus – by not being on a customer site every day, it was very easy to forget about the “real world” and lose your perspective. With my role as a Program Manager on the TFS team, I had the unique position of being a “internal consultant”, so I still got the face time with customers, they just happened to be mostly other teams at Microsoft.
When I was considering a move to PFE, I came across this PFE recruiting PDF and video (warning: its very geeky/boring & doesn’t represent the reality that PFE in Australia is mostly Proactive work), but the bit where the receptionist makes him wait (2:10) made me chuckle.
- PFE are the main delivery mechanism for Premier Support
- PFE deliver Proactive (workshops, health checks, risk assessments) and Reactive (on-site support, troubleshooting) engagements
- PFEs are highly skilled engineers with deep technical expertise in a given technology
- Team Foundation Server Health Check (TFSHC)
- Visual Studio TFS Essentials Workshop
- Visual Studio TFS Testing Tools Workshop
- Risk and Health Assessment Program for Microsoft SQL Server (SQLRAP)
- Risk and Health Assessment Program for Cluster Server (CSRAP)
- Risk and Health Assessment Program for Microsoft SharePoint Server (SPRAP)
- WorkshopPLUS - SQL Server Performance Tuning and Optimization (PTO)
- WorkshopPLUS - Windows Server Deploying and Managing Failover Cluster
What I like about being a PFE:
- Customers buy and pay for a Premier Support agreement up-front. They work with the Technical Account Manager (TAM) to come up with a Service Delivery Plan (SDP) and agree on a number of hours to purchase for the next 12 months. By shifting the payment up front and planning a year’s worth of work, it makes life more predictable and reduces overheads (pre-sales, contract negotiation, invoicing, etc).
- Technical depth and troubleshooting experience is mandatory. All you have to do is take a quick read of the Canberra PFE blog to understand that these guys (and gal, now) know their stuff. For example, got an AD problem? Guys like Jimmy or Chad are who you want on your team. Steve’s your Lync guy. I feel that I can have the greatest impact in PFE with my TFS skills and experience.
- Certification is taken seriously. Even though I wrote the book on TFS, I still had to perform a ‘reverse shadow’ of a TFS Health Check with another TFS PFE (Hi, Micheal Learned!) before I was allowed to deliver one by myself. This is just one of the mechanisms in place to ensure that the quality of PFE deliveries stays consistently high.
- All those “extra” things I do are not only valued, but encouraged and I can allocate work time to prepare them. For example: TechEd/TechReady presentations, User Groups, blog posts, product team feedback, etc. (Not book writing , that’s covered by the moonlighting policy with agreement from management).
- Variety and Scope/length of engagements. For a ‘transactional’ PFE like myself, the longest ‘dispatch’ is typically 5 days. Yes, this means that I’m literally working at a new place every week. I thrive on the entropy of different customers, it keeps me engaged (because everything is new) and it keeps me focussed (because its a short timeframe).
- I control my calendar. Not only do I control, but I have a responsibility to keep my availability calendar up to date for 6 months in the future. I can block time like ‘Local visits only’ (if I need to be in Canberra) and I can block time to study for exams/certifications, or to prep/ramp-up on a new workshop before I get certified to deliver it.
Hopefully this post helps you understand what a Premier Field Engineer is and how we might be able to help you. If you have any questions, feel free to contact me via my blog or your local Microsoft office.