Meet the Person Behind the Blog
I'm Sadhan Chandra, a Senior Technical Advisor and support engineer who has spent the last five years working with Microsoft technologies.
My work involves helping administrators and users troubleshoot issues across the Microsoft ecosystem. Microsoft 365 is a broad part of that work, and my current focus is Dynamics 365. Over the years, I've also worked with other Microsoft products and gained experience with areas such as Active Directory and Windows 365 Enterprise.
One thing that has remained consistent throughout that experience is the process of understanding what a platform can accomplish with the tools it already provides.
Before introducing another dependency, service, or third-party solution, I like to understand how far the native capabilities of the platform can take us.
That philosophy is one of the things that eventually shaped this blog.
Why I Started This Blog
Working in technical support changes the way you look at documentation.
During troubleshooting, I've repeatedly encountered situations where the information needed to resolve an issue either wasn't documented in enough detail, was difficult to find, or didn't quite reflect what happens in a real support scenario.
At the same time, support conversations reveal patterns.
When administrators and technical support teams from different organizations encounter similar problems, recurring issues become easier to recognize. When a solution emerges from one of those situations, that knowledge can be valuable beyond the original incident.
I wanted a place where I could document those experiences.
Not simply as a collection of solutions, but as a way of explaining what happened, why it happened, how it can be addressed, and what someone else can learn from it.
That's the reason Support Engineering Blog exists.
From Software Engineering to Support Engineering
When I started my career, I originally wanted to become a software engineer.
Instead, I found myself working as a support engineer for Microsoft products.
What initially wasn't the path I had imagined became the career I've now spent around five years building.
Support engineering taught me something that isn't always obvious from documentation alone: knowing how a product works is only one part of solving a problem.
You also need to understand how people actually use it, where things can go wrong, how to isolate a problem, and how to explain the solution clearly enough that someone else can apply it.
This blog is, in part, an attempt to document that experience as it continues to grow.
Who Is This Blog For?
The primary audience is Microsoft 365 Global Administrators and support engineers working with Microsoft technologies.
These are people who often need an answer quickly, but who also need to understand the reasoning behind that answer.
The blog also covers areas that are useful to project managers. My experience working with Microsoft's project management products, including Planner and Project, has given me an interest in helping project teams understand how they can make better use of the tools available within their organizations.
And for people entering support engineering, I want the blog to provide something that traditional documentation often cannot: real-world scenarios.
Some articles will explore a technology or concept in depth. Others may be designed as an immediate troubleshooting reference where the goal is simply:
Follow these steps and get the problem resolved.
Both have their place.
From Blogger to Support Engineering Blog
The first version of this blog began on Blogger.
That choice wasn't accidental. I had already used Blogger for a personal project back in 2008, when I was still in school. I developed an appreciation for text-heavy websites that could organize information clearly without unnecessary bells and whistles.
That philosophy stayed with me. I started the blog with Blogger's Essential Light theme, one of my favorites, and gradually personalized the structure to make the site feel like my own.
Blogger actually took the project surprisingly far. I could get a lot from the platform's native capabilities without having to build everything from scratch. That suited the way I like to work: understand what a platform already provides before reaching for something else.
But as the blog grew, so did the ideas behind it.
I began thinking less about individual pages and more about how the entire collection of technical information should work. How should readers discover an article? How should related information be connected? What should someone know before investing ten minutes in an article? How could the site help someone find an answer quickly when they were already dealing with a support issue?
Those questions eventually led to features such as structured article metadata, categories, technologies, search, related articles, references, reading time, and Learning Paths. Each was added because of a real problem I had encountered while reading or working with technical content.
The limitations of Blogger also became more noticeable. Its older XML-based template structure made deeper customization and maintaining new functionality increasingly difficult. More importantly, I wanted the website itself to represent the way I think technical information should be organized.
So we made the decision to rebuild it from scratch, no pre-made templates.
Astro became the foundation because it gave us the control we were looking for without forcing the site to become unnecessarily complicated. We could keep the content at the center while building a proper structure around it — from content collections and metadata to search, RSS, sitemaps, related content, and Learning Paths.
The result is not simply a new version of the old blog. It is the result of gradually discovering what this publication needed to become.
Why the Site Is Structured This Way
Every part of the site exists for a reason.
That reason comes largely from experience as a reader and as a support engineer.
I've seen well-written technical content get overlooked because the intent wasn't clear at the beginning. I've also encountered articles where the information needed to solve a problem was buried somewhere deep inside an otherwise useful piece of documentation.
When you're working through more than twenty support issues in a day, time matters.
You shouldn't have to read an entire article just to determine whether it contains the information you need.
That's why the site emphasizes things such as:
- Clear article descriptions so the purpose is apparent before reading.
- Key takeaways so the important points are immediately visible.
- Categories and technologies to provide meaningful ways to explore related content.
- Reading time to help readers decide how much time an article requires.
- References to make the supporting material visible.
- Related articles to connect one problem or concept with another.
- Learning Paths to turn individual articles into structured learning journeys.
- Search to help readers find information when they already know what they are looking for.
The goal isn't to add features for the sake of adding features.
The goal is to reduce the time between a question and useful information.
What I Want This Blog to Become
Ultimately, I don't want Support Engineering Blog to be just another technical blog.
I want it to become an almanac that people can depend on.
Something that a Microsoft 365 administrator can return to when they need to understand a problem.
Something that a support engineer can use when investigating a scenario.
Something that a project manager can consult when trying to make better use of Microsoft's project management tools.
And eventually, something that someone beginning a career in this field can use to understand not only what to do, but how experienced support engineers think about problems.
The technologies will change.
Products will evolve. Features will be renamed. Services will be retired and replaced.
The purpose of the blog, however, will remain the same:
Document useful knowledge. Explain it clearly. Make it easier for the next person to solve the problem.