I think one of the hardest parts of my role at various jobs as a tech advocate is convincing people that not every tool or best practice will or should be simple.
If you want to leverage the cooler powers of git, you're going to have to leave Visual Studio's Team Explorer and learn some command line flags. If you want amazing chatops, you have to acclimate to a team chat tool, then build and iterate on chatops. If you want good baseline accessibility, you'll have to remember to add some markup.
There's a consistently strong resistance specifically around learning tools. Tools should, apparently, slot right into the spot where there's a problem and fit seamlessly into the ecosystem people are already using (e.g., Visual Studio) and require only a few mouse clicks to work.
All "what if" and "how does this relate to" questions should be completely answerable before inviting usage and the answers should be simple and require no additional tools or change.
Sounds nice, right?
And yet, to build tools that might fit a team's needs so perfectly is judged not worth the time and is recognized to be too niche -- what if the team's processes change down the road, after all?
I am *undoubtedly* not the best tech advocate, even though I keep trying. These arguments are the important part of an advocate's work and yet can be infuriating to me. It brings me the closest I get to judging people as "lazy", which is both cruel and inaccurate.
I think the real work might be in raising a team's baseline tolerance for learning/changing with tools being the mechanism for that. Train the team, get helpful tools in place by happenstance.
I don't know how to do that, tho.
I recently declined to apply for a team lead position for exactly this reason. The team is generally great, but their sheer *inertia* made me leave the Microsoft Ignite conference feeling depressed instead of inspired when I thought of bringing home the cool stuff I learned.
How do you move a team to deeply believe that things outside of programming are important? I want them to be as driven to learn ways to improve our deployment process as they were to learn the nuances of Entity Framework.
@melissaaveryweir Hear, hear. From the engineer/software dev side, I've always been a big advocate for improvement on all fronts.
You can't impose improvements by command, right? (Well, you can but it's neither durable nor self-improving.) You have to quietly convince people to want to improve, then set the tools / systems / skills in front of them and show them how it will help them accomplish what they already want to do.
The convincing part takes a lot of social skills, capital, and work.