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.


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.