Being a Great Technical Evangelist Means Being in the Right Room

Question: Are you ‘in the right room’?

As a part-time practitioner and technical evangelist, one of the most important questions I can ask myself is just that: “Am I in the right room now?”

If our ‘room’ is a conversation with the right customer, then read on.

What is a Technical Evangelist?

Simply put, an effective technical evangelist is an advocate for customer success in ways that map to and multiply organizational values.

I recently had an opportunity to depart my full-time position as a developer evangelist at an enterprise-focused company. In search of a new fit, I find that one of the things I miss the most is ‘being in the room’ on major sales opportunities and product strategy sessions. Insider information about what’s going on at [name your target customer] is the life-blood of an organization. It grounds your understanding, your point of view, and your stories.

Evangelists that simply ‘blah blah’ are just like practitioner-turned-circuit-speaker. While they might have important insights collected along their journey, the time spent talking to crowds ultimately reduces time for other things like checking in code, being on customer calls, and advising product teams.

You can tell who the fakes are too, just provide your email to TechWell, BZMedia, or any major tour conference and you’ll see the same names pop up over and over again like clockwork. In search of people-as-content, these kinds of marketing-driven machines ultimately produce a Gaussian distribution of hit or miss value to actual practitioners, no matter how hard everyone tries.

A technical evangelist isn’t just a mouth, they are a statement of what your organization cares about. Revenue? Your latest product? Community? It can all be assessed by looking at how people, particularly your evangelists, advocate for your customers.

What Makes for a Great Technical Evangelist?

Really good technical evangelism is only 10% talking. You have to know what’s really going on with your customers, what they’re struggling with, be an exceptional and inquisitive listener, and constantly improve your relationships with folks in your organization. To do that, you need to be a great listener.

What’s the goal of a technical evangelist? Summed up it is:

‘Advocate customer success in such a way that it creates inbound to you and to your organization.’

Why? Without successful customers, chances are your product is vaporware. Slinging a crappy, useless product will always come back to bite you, personally and professionally; and without inbound (people wanting you), you yourself may as well be vaporware too.

What’s Involved in Really Great Technical Evangelism?

Some of the best technical evangelists I know exhibit the following behaviors:

  1. Align field activity (anything in your influence sphere) to the vision of a product that you believe truly helps people
  2. Ruthlessly listen to customers and relay important insights to product strategy owners
  3. Provide insight publicly by facilitating others’ (internal and external) voices
  4. Know where your competition fails to satisfy customer’s needs and make sure that your org doesn’t do the same thing
  5. Engage customers via established channels (sales, marketing) and find new, even more effective channels of engagement
  6. Collecting information about process, technologies, and problems that customers use to improve

Why Is ‘Being In the Room’ Important?

I’ve had the opportunity to work with companies that have varying degrees of repeatable success selling to everyone from enterprises to startups. What I’ve found is that people who are worth their weight in gold are regularly requested to be part of conversations on product strategy, organizational changes, customer success, and especially sales prospects.

I’ve been out of the full-time evangelism track for only two months (an eternity for me) and I’m jonesin’ for a good, old-fashioned customer visit. There’s only so much you can glean from 3 month old curated stories from Capital One on The New Stack, or from GotoConference on Youtube. I’ve seen speardsheets on how [dominant payroll ISV] organize their test strategies to pinpoint and eradicate poorly performing dev teams. I’ve build lead-gen tools based on elaborate maturity models from [enterprise ticket vendor] organizations. It’s like crack for growth nerds like me.

But you have to earn your right to be ‘in the room’. You have to provide value to multiple people. Sales needs you to advocate for their success on the deal. To do that, you need to translate product impact and vision to customers that they actually need. And you need to bring learning back to product strategy.

You also need to be involved in an important area of research beyond the needs of your current company…which is why I’m a contributing member of the IEEE 2675 working group on a formal standard for DevOps. I used to think that bodies like ISO and IEEE were bureaucratic bullshit; now I understand how important speaking the same language about healthy and necessary behaviors are, be it ISO/IEC/IEEE 29119, IEEE 1012, or in continuous revision of these resources as the industry evolves.

Case-in-Point: The Natural Evolution of an Evangelist to Product Owner

I think that a great technical evangelist has multiple career paths, provided they constantly improve and collect artifacts of their improvement over time. I’m currently working to be ISTQB certified, implementing the crap out of Docker in a mobile app delivery pipeline, working on retainer as a contract load tester, and studying to take my scrum certification. Personal vision dictates your cultivation of options, and focus is just a muscle to exercise with tactics.

My current career goal is to eventually own a significant revenue stream. Revenue is what organizations, growing or otherwise, understand as value. To accomplish this goal, I’ll eventually become a product owner. But on my way, I’ve been learning the various dynamics and tactics of how to scale a technology firm, namely how to interface with sales, marketing, and product strategy.

Product Managers and Owners who are actively engaged in sales and customer success engagements with customers have a line of sight to exactly what they need. Also, their job title (often earned) can often act as a carrot for sales to dangle when the opportunity is…more complicated…than the usual deal. The value they often bring is to quickly drill in to the most pressing issue that the customer faces and align the prospect to how the product enables them to overcome that challenge.

Sales Professionals (i.e. ‘account managers’, ‘customer representatives’) who are really good follow a simple mantra: ‘don’t waste anyone’s time’. In the past year, I’ve witnessed a global SVP of Sales perpetually inspire an organization to this end; countless sessions and references to learning materials like Grit, Let’s Get Real or Let’s Not Play‘, and other resources that ruthlessly focus on efficient, productive conversations.

Marketing…what can I say: in an world inundated by information-overload, finding the most effective path to (each of your) audiences is an important part of exercising your Product Owner muscles. Yes, I want to work more directly with development teams, but code is only one component of getting people to use and love your product. Orchestrating go-to-market strategy connects me to everyone: product owners, developers, documentarians, strategists, customers, sales, and leadership. It is a nexus I accept and apparently do well in.

Should You Hire (or Become) an Evangelist?

I’m biased, but definitely yes. If you want to close deals, look awesome, increase influence, drive revenue growth, understand your customer better, grow personally and professionally, and ultimately make people so happy that they write great things about you on their own time, then yes, find a good technical evangelist and embed them in the middle of your business.

If you’re looking for one, you can find me on all the usual channels.

A Jenkins Pipeline for Mobile UI Testing with Appium and Docker

In theory, a completely Docker-ized version of an Appium mobile UI test stack sounds great. In practice, however, it’s not that simple. This article explains how to structure a mobile app pipeline using Jenkins, Docker, and Appium.

TL;DR: The Goal Is Fast Feedback on Code Changes

When we make changes, even small ones, to our codebase, we want to prove that they had no negative impact on the user experience. How do we do this? We test…but manual testing is takes time and is error prone, so we write automated unit and functional tests that run quickly and consistently. Duh.

As Uncle Bob Martin puts it, responsible developers not only write code that works, they provide proof that their code works. Automated tests FTW, right?

Not quite. There are a number of challenges with test automation that raise the bar on complexity to successfully getting tests to provide us this feedback. For example:

  • How much of the code and it’s branches actually get covered by our tests?
  • How often do tests fail for reasons that aren’t because the code isn’t working?
  • How accurate was our implementation of the test case and criteria as code?
  • Which tests do we absolutely need to run, and which can we skip?
  • How fast can and must these tests run to meet our development cadence?

Jenkins Pipeline to the Rescue…Not So Fast!

Once we identify what kind of feedback we need and match that to our development cadence, it’s time to start writing tests, yes? Well, that’s only part of the process. We still need a reliable way to build/test/package our apps. The more automated this can be, the faster we can get the feedback. A pipeline view of the process begins with code changes, includes building, testing, and packaging the app so we always have a ‘green’ version of our app.

Many teams chose a code-over-configuration approach. The app is code, the tests are code, server setup (via Puppet/Chef and Docker) is code, and not surprisingly, our delivery process is now code too. Everything is code, which lets us extend SCM virtues (versioning, auditing, safe merging, rollback, etc.) to our entire software lifecycle.

Below is an example of ‘process-as-code’ is Jenkins Pipeline script. When a build project is triggered, say when someone pushes code to the repo, Jenkins will execute this script, usually on a build agent. The code gets pulled, the project dependencies get refreshed, a debug version of the app and tests are build, then the unit and UI tests run.

Notice that last step? The ‘Instrumented Tests’ stage is where we run our UI tests, in this case our Espresso test suite using an Android emulator. The sharp spike in code complexity, notwithstanding my own capabilities, reflects reality. I’ve seen a lot of real-world build/test scripts which also reflect the amount of hacks and tweaks that begin to gather around the technologically significant boundary of real sessions and device hardware.

A great walkthrough on how to set up a Jenkinsfile to do some of the nasty business of managing emulator lifecycles can be found on Philosophical Hacker…you know, for light reading on the weekend.

Building a Homegrown UI Test Stack: Virtual Insanity

We have lots of great technologies at our disposal. In theory, we could use Docker, the Android SDK, Espresso, and Appium to build reusable, dynamic nodes that can build, test, and package our app dynamically.

Unfortunately, in practice, the user interface portion of our app requires hardware resources that simply can’t be executed in a timely manner in this stack. Interactive user sessions are a lot of overhead, even virtualized, and virtualization is never perfect.

Docker runs under either a hyperkit (lightweight virtualization layer on Mac) or within a VirtualBox host, but neither of these solutions support nested virtualization and neither can pass raw access to the host machine’s VTX instruction set through to containers.

What’s left for containers is a virtualized CPU that doesn’t support the basic specs that the Android emulator needs to use host GPU, requiring us to run ‘qemu’ and ARM images instead of native x86/64 AVD-based images. This makes timely spin-up and execution of Appium tests so slow that it renders the solution infeasible.

Alternative #1: Containerized Appium w/ Connection to ADB Device Host

Since we can’t feasibly keep emulation in the same container as the Jenkins build node, we need to split out the emulators to host-level hardware assisted virtualization. This approach also has the added benefit of reducing the dependencies and compound issues that can occur in a single container running the whole stack, making process issues easier to pinpoint if/when they arise.

So what we’ve done is decoupled our “test lab” components from our Jenkins build node into a hardware+software stack that can be “easily” replicated:

Unfortunately, we can no longer keep our Appium server in a Docker container (which would make the process reliable, consistent across the team, and minimize cowboy configuration issues). Even after you:

  • Run the appium container in priviledged mode
  • Mount volumes to pass build artifacts around
  • Establish an SSH tunnel from container to host to use host ADB devices
  • Establish a reverse SSH tunnel from host to container to connect to Appium
  • Manage and exchange keys for SSH and Appium credentials

…you still end up dealing with flaky container-to-host connectivity and bizarre Appium errors that don’t occur if you simply run Appium server on bare metal. Reliable infrastructure is a hard requirement, and the more complexity we add to the stack, the more (often) things go sideways. Sad but true.

Alternative #2: Cloud-based Lab as a Service

Another alternative is to simply use a cloud-based testing service. This typically involves adding credentials and API keys to your scripts, and paying for reserved devices up-front, which can get costly. What you get is hassle-free, somewhat constrained real devices that can be easily scaled as your development process evolves. Just keep in mind, aside from credentials, you want to carefully managed how much of your test code integrates custom commands and service calls that can’t easily be ported over to another provider later.

Alternative #3: Keep UI Testing on a Development Workstation

Finally, we could technically run all our tests on our development machine, or get someone else to run them, right? But this wouldn’t really translate to a CI environment and doesn’t take full advantage of the speed benefits of automation, neither of which help is parallelize coding and testing activities. Testing on local workstations is important before checking in new tests to prove that they work reliably, but doesn’t make sense time-wise for running full test suites in continuous delivery/deployment.

Alternative #4: A Micro-lab for Every Developer

Now that we have a repeatable model for running Appium tests, we can scale that out to our team. Since running emulators on commodity hardware and open source software is relatively cheap, we can afford a “micro-lab” for each developer making code changes on our mobile app. The “lab” now looks something like this:

As someone who has worked in the testing and “lab as a service” industries, there are definitely situations where some teams and organizations outgrow the “local lab” approach. Your IT/ops team might just not want to deal with per-developer hardware sprawl. You may not want to dedicate team members to be the maintainers of container/process configuration. And, while Appium is a fantastic technology, like any OSS project it often falls behind in supporting the latest devices and hardware-specific capabilities. Fingerprint support is a good example of this.

The Real Solution: Right { People, Process, Technology }

My opinion is that you should hire smart people (not one person) with a bit of grit and courage that “own” the process. When life (I mean Apple and Google) throw you curveballs, you need people who can quickly recover. If you’re paying for a service to help with some part of your process as a purely economic trade-off, do the math. If it works out, great! But this is also an example of “owning” your process.

Final thought: as more and more of your process becomes code, remember that code is a liability, not an asset. The less of if, the more lean your approach, generally the better.

More reading: