Find Your Tribe: Leadership Lessons From the Citrix Community

Find Your Tribe: Leadership Lessons From the Citrix Community

I’ve been recently reflecting on some formative experiences that made me who I am. One of those experiences developed through a phase of my career where I gave my primary attention to one particular technology platform: Citrix. As I’ve come to look back, it’s not the technology itself, but some surrounding elements that really contributed to my career development.

Circa 2000, Citrix released a technology product called MetaFrame. It’s the great-grandfather of the current generation of the product, called Citrix Virtual Apps & Desktops. That’s a nice descriptive name, but I kind of like MetaFrame better. It has a classic tech ring to it, doesn’t it?

The company I worked for at the time was bringing this technology into the environment and they need an engineer to learn it and run it. I stuck my hand up really high, as I covered in this blog article here.

I became proficient in the technology in a hurry, and quickly earned the trust of my company that I knew how to run and manage the platform. That’s not all that remarkable. What’s remarkable, happened next.

While I spent a good eight years of my career steeped in Citrix products, I cannot say that Citrix, the actual company, contributed much to my success. They made the product, but did little to support or educate me. In my search for colleagues and resources, I quickly stumbled upon a community of engineers from around the world that were filling this void in the marketplace.

Brian Madden, at the time, was a blue-haired 20-something that was an absolute wizard on the Citrix platform. I was 20-something too, but well on my way to my current state of baldness. Brian’s skill wasn’t the impressive part. He was a community-builder. He called himself a blogger and industry analyst, but I still think of him as a community-builder.

He and his group put on vendor-neutral tech conferences that connected people from around the world to work on solving technical challenges. I attended those conferences, called Briforums, many times over the years. I even got to be one of the speakers, twice.

Here’s what I learned:

To be a hacker and a maker

Citrix made a commercial product that could be installed out of the box and ran. However, it ran much better with mods, hacks, templates, 3rd party extensions, and the like. These came from the community and much of it was openly shared. I made my own and shared them freely with the community. We had our own tight-knit, open source community and it was grand.

To be leery of tech marketing

Citrix and other companies in the space put a lot of spin and shine on their products. The community put the tech through the paces to see what worked and what didn’t. I learned to be very suspect of the technology marketing brochure from any company. I learned what questions to ask and tests to perform to get to the truth. I wish we lived in a world where you can trust everything in the marketing brochure, but we don’t. I learned how to avoid becoming a victim.

To challenge the status quo

The Citrix community was filled with futurists and rebels. We embraced a mobile-first world long before enterprise technology existed to make that a reality. We talked about desktop as a service in the cloud ten years ago, and it’s still a ways away from mainstream adoption. I realize this is ironic. After all, Citrix exists to support legacy desktop applications. If all enterprise apps were web-based, Citrix would be gone by now, but alas, the people I hung out with were all futurists.

To speak in public

Briforum gave me my first significant public audience. This was a huge deal for me. I wanted desperately to be a good public speaker, and Briforum gave me a platform to practice. Not only that, I developed my own public speaking style based on what I observed at these conferences. I noticed that the best presentations were funny, irreverent, image-rich, and aggressively challenging of common wisdom. If you are wondering where I developed my style, it was in this crucible of learning.

To blog

The first blog I ever read on a regular basis was brianmadden.com. It still exists, although, the website’s namesake now has a leadership role at VMware. I learned some of my blogging techniques and writing styles from reading this blog every day, many years before the first Zach on Leadership blog was ever typed.

Find your tribe

It’s interesting to look back at what shaped us. I’m not a Citrix engineer any more. We have that technology at CHS, but it is one of many platforms I’m responsible for leading. However, I can say with absolute certainty that my experiences as a Citrix engineer, and specifically my participation in the broader community, really shaped who I am as a technology leader today. Brian Madden has moved on to bigger and better things, as has many other influential members of the community. They made their mark on my career in a big way. I’ll mention a few by name: Brian Madden, Gabe Knuth, David Stafford, and Shawn Bass. All of you rock.

To my readers that have absolutely no knowledge of Citrix or any of the people I’ve been writing about: Here’s a lesson for you: Find a tribe. Embrace it. Learn from it. Contribute to it. Let it shape you. These are formative experiences that far transcend any particular piece of technology. One day, Citrix will be in the pages of history, but these experiences will have forever shaped my path.

2 thoughts on “Find Your Tribe: Leadership Lessons From the Citrix Community

  1. I’d love to hear more about how you “learned what questions to ask and tests to perform to get to the truth.” From working in sales I’ve learned that what marketing doesn’t say is often more important that what it does say but it would be interesting to hear you unpack it from an IT standpoint.

    1. Aidan, it’s very common that sales and marketing materials are focused on tech executives and the business people, not engineers. The engineers need to evaluate technology from a technical perspective, irrespective of the business value. They are often looking for things like, does it work as advertised? Does it scale? Is it supportable? Is it secure? Is it compliant? Is it resilient? Can it integrate with everything else we have? Typically theses aren’t questions that can be answered by reading the marketing brochure, sales deck, or website. Engineers need to do a PoC to see for themselves how the tech actually works. The formality of this process typically varies based on the organization and the importance of the technology decision.

Leave a Reply