Things have been rather quiet on this site lately—deceptively quiet. So much has changed and happened these past few months that it’s been a struggle to slow down, focus, and trickle out even the slightest stream of updates. Perhaps the new year will bestow upon me a fresh discipline that will motivate me to maintain a steady rhythm of posts.
For now, however, I’ll start with the biggest news I have: I’ve hung up my independent consulting spurs for now and joined Cvent, working in their Tysons Corner, Virginia headquarters.
After returning from a fantastic gig consulting with Schibsted Products and Technology in Barcelona (and across Europe) this summer, my friend Ramez Mourad—who I’d met during DevOpsDays DC 2016 and who nudged me to produce The Rainbow of Death for DevOpsDays Baltimore 2017—made me an offer I couldn’t refuse. Consequently, on September 5, 2017, I joined his Site Reliability team within the Research & Development branch of Cvent’s Technology team as a “Senior Site Reliability Architect.”
I know what some of you may (should!) be thinking: What a joke title! I’m with you on that. I was never an SRE, though I cherish my experience having worked with some great ones back in my websearch infrastructure days. I’ve also never been much of an “architect” in the traditional sense. For these reasons, I continue to identify with one and only one title only: that of Instigator, which you’ll find proudly emblazoned at the top of this blog as well as my LinkedIn profile.
That said, the title was the best we could choose at the moment, and it also affords me a lot of freedom to do the kind of Instigating that Ramez and David Johnson (“DJ”), the head of R&D, hired me to do.
To be clear: I almost did refuse the offer. The job title was one off-putting factor. Others were:
- The dominant backend language is Java, which I’ve largely managed to avoid for most of my career. My aversion has less to do with the language itself as the excessively verbose programming style it encourages and the enterprise-y (i.e. verbose and complicated) frameworks that’ve sprouted around it like mushrooms.
- The standard frontend framework is based on React, which itself is a product of the company whose influence contributed significantly to my decision to leave Google, and that I consider to have a profoundly negative influence on society.
- The reliance on the Microsoft Office suite rather than Google Apps. Ugh.
- The commute. Granted, it’d be an easy move from Alexandria, but I like my neighborhood too much to leave it. So I knew I’d have to suck it up and deal with either the Metro or the beltway.
- The CCAT, which at the moment remains a prerequisite for the on-site interview.
In addition, there were reasons not specific to Cvent itself that made the idea of switching away from independent consulting difficult, the most significant being that I’d have to sacrifice some degree of autonomy.
Despite my independent streak, I’ve always thrived more in a team environment than as a solo practitioner. While I had a great experience with Schibsted this summer, all I did was give a bunch of great people an excuse to do what they largely wanted to do already, contributing only a few ideas and a boost of energy to get them into their groove. (Luis Peralta recently told me that the Schibsted Testing Grouplet just held their second Fixit!) What Ramez offered me with Cvent was the opportunity to something similar, but without having to travel as much, and without having to drum up gig after gig on my own—self-promotion has never been an interest or priority of mine, let alone a forte.1
And I knew Ramez wasn’t just blowing smoke, because I got to learn a lot about him and Cvent itself through our continued contact since DevOpsDays 2016. He impressed me as not only highly technically competent, but as someone who understood the value of integrity, communication, and leadership. His continued interest in how the Testing Grouplet did what it did to change the culture at Google, to the point where he commissioned The Rainbow of Death to explore it more deeply, indicated an understanding that what can’t be measured still must be managed. And the fact that Cvent granted Ramez the autonomy to serve as one of the organizers for the local DevOpsDays conferences not only spoke volumes about its investment in Ramez, but also clearly indicated that DevOps practices, in-person knowledge transfer, and career development of its employees are priorities for the company, whether aspirational or realized.2
The respect that Ramez, DJ, and Cvent had earned from me over the course of the year, and my desire to work with them to solve the kind of problems they know both need solving and are well suited to my skills and experience, ultimately outweighed my minor technical and commuting reservations—as well as the major personal reservations I had about working for a company again rather than with it. That respect was even enough to motivate me to just get the CCAT over with in order to proceed with the interview, rather than turn the opportunity down on principle—which I certainly would’ve done for anyone else from any other company I hadn’t the chance to get to know as well.
So what is it, I would say, I do here?3
It’s basically half and half: The first half involves learning the Cvent tech stack in order to gain technical depth and credibility and to make material contributions to software development objectives. Clearly this is necessary to speak with authority on technical issues as a “Senior Site Reliability Architect”—but even moreso as a so-called automated testing “expert” who is tasked with improving testing practices across the company. In a sense, I’m not just learning Java and the frameworks in use at Cvent, I’m learning the Cvent software development language, in order to deeply understand the issues at play and to better communicate my own ideas regarding how to improve.
The other half: Groupleteering. Telling people the technical steps behind better automated testing practices is a walk in the park; Java has a different ecosystem and set of conventions than I’m used to, but the fundamentals of good coding and testing practices apply just as easily to Java as any other language. But it’s teaching people the language of good coding and testing practices that poses the challenge, and effective language acquisition requires a robust community effort to create the space necessary for understanding to take hold, and subsequently, for behaviors to change.
I’ll have much more to say about this language metaphor in the future—I just stumbled upon it during a conversation with Fabyanna Eriksson at Schibsted this past summer—but suffice it to say that I think Grouplets are one of the most powerful (and underutilized) mechanisms for effecting culture change thanks to their ability to spread language throughout an organization.
For the most part, I’m really very happy at Cvent thus far. Accepting the opportunity was the right move—it’s been a great fit, and it’s exactly what I need in my life at this moment. There’s a lot more I want to say about Cvent, and how my repect for the company and its work has only grown during my first few months, and about all the specific things that I’m doing and that the Grouplets are doing…but all of that will come.
That said, if any single short-term outcome is indicative of my satisfaction, it’s this: Now that I’m learning the tools and idioms and ecosystem, and beginning to make productive contributions, I can’t say I’m starting to like Java, but I’m starting to hate it a lot less!
I’ve received a bit of unsolicited, unappreciated feedback regarding the poor aesthetic appeal of my blog; hence you may’ve noticed some minor style changes, and may notice more in the coming months. The point is, though, that if superficial self-promotion was a priority, I’d’ve invested effort long ago to prevent my blog from being a magnet for such pretentious, condescending judgment. ↩
One thing you eventually learn after going to enough conferences is that most presentations are portraits of early successes presented as widespread internal practice, when in reality they’re merely indicative of how the presenters hope their respective companies will evolve. The presentation, then, is often an instrument intended to generate feedback into the culture it presumes to represent: a form of gentle pressure encouraging it to live up to its idealized image.
And there’s absolutely nothing wrong with that. It’s a form of holding, as ‘twere, the mirror up to nature; to show virtue her own feature. Some aspects of culture change may be scientifically managed, but the bulk of it remains an art, and likely shall always remain so. ↩