How do you classify Level 100-400?

We all have varying levels of experience and skillsets. And “experience” is relative. Perhaps I’m considered to be an “expert” in Azure Site Recovery (ASR), but that doesn’t mean I’ve worked with ASR in every configuration scenario possible (case in point, I haven’t used it for on-prem to on-prem replication). Does that make me less of an “expert”? Some may say yes, but I feel it just means I haven’t experienced that scenario yet.

Levels

Commonly, when you attend a conference, there may be a tag, label, or indicator to the depth of the material. Sometimes it may be called “Beginner”, “Intermediate” or “Advanced”,  but other times it could be classified as “Level X”.

From a skill assessment perspective (ie. your experience with something), here’s an example of “levels”.

[table id=8 /]

But, if you look at sites like aka.ms/Learn, or the Microsoft Ignite Session catalog, you will see there is no consistency.

MS Learn – Levels Filter

MS Ignite – Session Levels Filter

 

The big question

In my new role as a Cloud Solution Architect – Azure Apps & Infra, I am called upon to deliver Technical Briefings, Technical Deep Dives, Architecture Design Sessions, etc. But, when a client/customer/partner asks for a “Level 200” presentation on, say Azure Backup and Azure Site Recovery (ASR), how would you determine which information is “Level 200” versus something deeper?

For designations like “Foundational” or “Level 100”, I estimate these as very high-level (though not just “salesy”), on what a technology is, and it’s position/use-case, etc.

So the question for the audience is: What criteria do you use when determining either a skillset level or presentation level?

Trading MVP Blue for Microsoft Blue

To All Those That Read My Blog,

I want to say thank you to everyone that follows/subscribes to my blog. I’ve been running my own blog since 2013, and before then I was an active contributor (and moderator) to the www.Windows-Noob.com forums. I’ve always strived to share quality vs quantity information, drawing largely from my real-world experiences. And I’ve even obliged by writing on topics that my followers (and clients) have requested.

My MVP experience

The goal of my blog was never to obtain the Microsoft MVP award. But, on January 1, 2015 at 10:38 AM EST, I was honored to receive a very special email, informing me that I had been awarded the MVP award in the System Center Cloud and Datacenter Management category. I still remember that day. I still remember reading the email, and thinking to myself “this must be some type of new year’s joke.” I could not believe that I had received the award. It was a real privilege and honor.

Since then, I’ve continued to do what I love, learning about technology, and sharing those experiences. Over time, the award category dropped the “System Center” part of the name and became “Cloud and Datacenter Management” or CDM for short. And also, over time, my career focus began to shift from System Center to Azure. All throughout that time, my focus on writing blogs, presenting at conferences or User Groups, etc. has not been to obtain the MVP award the following year; it’s always been to share knowledge and experience. Because, really, if no one took the time to write about how to fix problem X, or how to configure Service Y, we’d all be stuck repeating the same things/steps over and over and over again. There would be no progress.

In the 5 years since I originally received my first MVP award, I have been privileged to be re-award each year, making this year my 5th consecutive year as a Microsoft MVP in the Cloud and Datacenter Management category. And every year, I have had the fortunate opportunity to attend the annual Microsoft MVP Summit (hosted at Microsoft HQ in Redmond), where we are given the unique opportunity to interact directly with the Product Groups, learn about future roadmaps, and provide valuable and direct input into the products and services that we all use. Every year I attended the MVP Summit, I took notes during all the sessions I attended (I still have my notes from 2015, which is interesting to go back and read to see how far things have come). In fact, I became so proficient at it, that the level of detail in my notes became dare I say, legendary (ie. who needs a copy of the slides when I have them transcribed ;-)).

There are so many amazing memories that I have from the MVP Summits, especially the friendships made with other MVPs in the CDM category (and other categories) from all over the world!

[flagallery gid=1 name=’MVP Summit Pics’]

Resigning as an MVP, the honorable way

Once you become an MVP, it’s sort of addictive. The access you get, the preview features you learn about, etc. Of course, people’s lives change, and sometimes they aren’t able to contribute as much to the community as they once did. In those cases, they may not be renewed as an MVP, but Microsoft lovingly has an MVP Reconnect program, sort of like an alumni for former MVPs to stay in touch.

It’s been said by some, that the only “honorable” way to loose your MVP status (because you can “dishonorably” lose it by violating the NDA), is by joining Microsoft (because, Microsoft employees are not eligible to be MVPs). And so, I am excited to announce that today I honorably give up my MVP status, as I have joined Microsoft! I will be taking on the role of a Cloud Solution Architect (CSA) – Apps and Infra, based out of the Microsoft Canada headquarters. I am very excited for this opportunity, and to see what the future holds.

What about your blog?

Some of you may be wondering what will happen with my blog. Let me be clear. My intention is to still run it, and share real-world experiences and information as much as possible. If you have any thoughts/suggestions for topics, my email is always open.

When I gave notice to my (now former) employer, the outpouring of support, and the comments that many have made about how I’ve affected/helped them, were truly touching. I’ve had many people comment that they appreciate my Exam Resources study guides, my Technical Book Reviews, and my go-to list of resources for learning Terraform for example.

And so, I will continue to maintain and operate my blog, contributing when I can. There may be periods of reduced posting from time to time, depending on how busy I am.  But, I am still very much committed to sharing with the community at large, as they’ve shared so much with me over these years.

 

In closing, I’d like to share some words of advice that I left my co-workers with:

Treat everyone with dignity and respect. Show others appreciation and that you value them/their input. Even if the individual may be newer, younger, less experienced than you, or in a role/position lower than yours, everyone has value. Everyone brings something to the table to share and contribute. Personalities may clash at times, but we need to be able to look past that, and see the bigger picture of how we collectively contribute each other.

And one more thing, don’t forget to connect with me on LinkedIn and Twitter. I’ll see you on the Internet.

This is Adin Ermie, former 5x Cloud and Datacenter Management (CDM) MVP, signing off.

Whiteboard Architecture – Why Experience Matters

I’ve worked in IT a long time. Well, maybe not too long depending on who you compare me to. But throughout my career, there’s always been one thing that’s been a top goal for me to obtain. Experience.

Reading only gets you so far

If you know me well, I love to read, which is proven by my many Technical Book Reviews. I remember talking with a client’s team, in which I told them I finished reading a “short” 200 page book in a few days. They laughed at the fact that I considered 200 pages as “short”. But considering that I “grew up” on reading all of the SAMS Unleashed System Center Books, some of which were 1500+ pages, picking up a book that’s 500 pages or less doesn’t feel as overwhelming.

But reading only takes you so far. Sure, you can take your time, re-read something if it’s not clear, etc. And it’s good to read to keep up to date. I’m constantly reading the updates posted on the Azure Blog, and Azure Updates sites.

Why experience matters

But think about this. If you are in front of a potential client, what do they always ask? “Have you done this before?” Do you have the experience.

Hands-on experience is by far the most important thing. Why? Because it means you’ve taken something you read/learned, and actually implemented it. It’s practical and applied knowledge. Even if you only do this in a lab or as a Proof of Concept (POC), that hands-on experience makes a world of difference.

How many times have we been following some official technical documentation, only to find that it does not match what the real experience actually is? It happens all the time, because technology is constantly changing (and it’s hard to keep documentation up to date). You could read the entire documentation on a topic, but actually experiencing it is far more valuable.

How this applies to architecture

As a Cloud Solution Architect (CSA) it is especially important to still have hands-on experience. I worked with someone once that was drafting a Statement of Work (SOW) for a client, and in it they stated we would simply create an Azure Resource Manager (ARM) template to deploy some piece of infrastructure (say, a Domain Controller). But when multiple infrastructure pieces were needed, they assumed we would/could just make a second template to deploy object #2, or make some changes and re-apply the template. Now, technically you could do that, but that’s not the most efficient method. You also have to think about static IP addresses, reconfiguration of virtual networks to use the new DNS servers, etc. My point is, it wasn’t as “simple” as they may have originally thought.

In this scenario, that individual was also estimating how long it should take an individual with X skill level/experience to complete the task of creating these templates. It was shocking to find out that they had never created an ARM template themselves! So how could they possible accurately estimate the level of effort required?

In the real world, if you’re estimating how long something should take to do, or architecting a technical solution, the value of having actual experience is immeasurable. This is why, when someone asks for my help in estimating something, I will be up-front about if I have actual experience with it or not. If I don’t have experience, I’ll take the time to read the documentation to get a better understanding on what is potentially involved, but I’ll be clear that my estimate isn’t as accurate as could be due to my lack of hands-on experience.

Conclusion

Anyone can draw concepts on a whiteboard. You can easily read the documentation, and say “this is how it should work.” But experience means that you’ve been through that “simple” step, and found that it was not as simple as was thought.

Whether you’re a Cloud Solution Architect, a Technical Architect, or anyone responsible for estimating work effort of others, it is imperative that you have some level of hands-on experience with what you are solutioning, for without it, you’re asking those that have to implement your solution to do the impossible, while you receive all the credit.