Don't be the Only One

Don't be the Only One

TLDR: If you are the only one that can fix something, DON'T IMPLEMENT MAJOR PROJECTS IN THAT STACK (YET).

When I got my started my role as a SharePoint Architect, there were a lot of people who were excited to use SharePoint, including me. This was my first time being an administrator (and designer) for a SharePoint environment and I wanted to prove my skills and the software's usefulness. When the Contracts & Proposals team were looking for a new system, I quickly offered to "build" a system for them.

At the time I'd had about 4 months as a SharePoint Admin. Let's fast-forward 3 and a half years later.

 

That system underwent a couple rebuilds and countless hours of debugging, troubleshooting, and hand-holding. While I can say the system I built holds information for millions of dollars of business, the amount of technical-debt I took on left me as the maintainer of that software beyond my tenure for that team. I became the only one in the company that could fix it when it breaks (yay, Job Security?).

I know that it's always cool introducing a new stack to your team, but remember, if you are the only one that has experienced in that stack, it will be your responsibility, when something breaks. 

Solution

Build smaller things with the stack and let your team get used to using (and troubleshooting) the software. As you all continue to learn, the area of responsibility and coverage will grow beyond just you.  

How to Establish a Good Coding Routine

End of Productivity in Tech Podcast, The start of something new!!