AstroColossal Blog



“If you’re not embarrassed by the first version of your product, you’ve launched too late.” — Reid Hoffman



Me Talking

Hey, I spoke at the DevRelTokyo conference. Here are my slides with notes.



Because maybe that's your thing.

I built this for a technical guide, so even if you don't do CI, you can use this for custom cron jobs and other things that Pantheon doesn't do out of the box. This example uses a Digital Ocean Ubuntu droplet, with my pre-installed ssh key.

Make sure Java is installed

Install Jenkins

ssh root@<your ip address>

  • wget -q -O - | sudo apt-key add -
  • echo deb binary/ | sudo tee /etc/apt/sources.list.d/jenkins.list
  • sudo apt-get update
  • sudo apt install jenkins composer php7.0-fpm zip unzip php7.0-zip php7.0-curl php-parser php-xml -y

Setup Jenkins User

As root:

  • usermod -aG sudo jenkins
  • passwd jenkins (set new password)
  • Generate/Add/SCP an ssh key for that user to /var/lib/jenkins/.ssh
  • chown -R jenkins:jenkins /var/lib/jenkins/.ssh /var/libjenkins**
  • chmod 0700 /var/lib/jenkins/.ssh /var/libjenkins**
  • chmod 0600 .ssh/authorized_keys or chmod 600 /var/lib/jenkins/.ssh/id_rsa; chmod 600 /var/lib/jenkins/.ssh/
  • In a ~/.ssh/config file, add these two lines:
     Host *
         StrictHostKeyChecking no

Test by logging in as jenkins user and verify you can sudo su

Install Terminus, etc.

As the jenkins user, from the user's home directory (probably /var/lib/jenkins/):

  • curl -O && php installer.phar install
  • add `export PATH=$PATH:/var/lib/jenkins/vendor/bin` to a ~/.profile file you create and restart the terminal session
  • run "terminus" to verify you get output
  • restart jenkins so it knows the new path: sudo /etc/init.d/jenkins restart
  • composer global require -n "hirak/prestissimo:^0.3" (makes Composer run in parallel, less glacial)
  • composer global require -n "consolidation/cgr" (makes `composer global require` safer)
  • composer  require drush/drush "^8"
  • mkdir -p ~/.terminus/plugins
  • composer create-project -n -d ~/.terminus/plugins pantheon-systems/terminus-build-tools-plugin:^1
  • composer create-project -n -d ~/.terminus/plugins pantheon-systems/terminus-secrets-plugin:^1

Setting up Jenkins

Visit <your ip address>:8080

  • Unlock by getting the default password which is located at the path indicated on the web page.
    • cat /var/lib/jenkins/secrets/initialAdminPassword
  • Paste results and log in
  • Install all the recommended plugins at the prompt. You will install more in a few steps.
  • Create an admin user and password. if you lose this, it's a pain in the ass to get back in, so save this UN/PW somewhere and set up the next security steps carefully. Don't monkey around here.
  • Jenkins will automatically log you in as that admin user.

Enable Security

  • Manage Jenkins > Configure Global Security
  • Use Jenkins own database.
  • Use Matrix-based security.
  • Add your new user and enable all permissions for this user.
  • Verify you added the new admin user and enabled all permissions.
  • Verify you added the new admin user and enabled all permissions.
  • Give anonymous users overall read permissions.
  • Save settings. If you suddenly find yourself locked out of Jenkins, you thought I was being hyperbolic.
  • In Configure System, add your git username and email .


  • From Manage Jenkins, Add plugins. Click the "Available" plugins tab. Install these plugins too:
    • Required for the guide: Github Pull Request Builder, Environment Injector,  Conditional Build Step, Run Condition. Be sure to install the latest versions, which have addressed various security issues
    • Makes life easier: Rebuilder
  • Go back to the top page after install

Jenkins User's Pantheon Access

Your Jenkins user should be able to push and pull to Pantheon, so create a user for it on Pantheon (call it Jenkins or Integrations or something), generate a private key on the Jenkins server and add the public key to that user's Pantheon dashboard. Check it by doing a git clone from Pantheon to the Jenkins $HOME dir. If you don't get prompted for a password and it successfully clones, you are good to go.

Let me know if you find an error in this doc.


Building a great support or customer success team is often a complex and delicate process, full of adjustments and lessons learned. Often, as the product evolves, so do the skills needed to support it. The first several years may be involve more high-touch interactions, when fewer customers are using an immature product and your team is learning the ropes. As new and varied user personas jump onboard, their goals will vary accordingly.

What can make this a less risky process for a manager is building a team that can realistically grow and adapt. What skills does your ideal team possess? And after you compile this list, consider this: are you giving the people, your users, what they want? For example, in the customer success world, one of the most sought-after traits in CSMs is empathy. But does having a team of empaths translate to happy users? Of course not. Product knowledge, domain knowledge, and other soft skills all matter.

What’s the right mix? According to a recent HBR article, what managers desire in a support team isn’t what your users say they want. For this study, support engineers were grouped into several personas: “Accommodator," “Empathizer," "Hard Worker," “Controller," etc. An Empathizer approach their job focusing on understanding the customer’s viewpoint, and are “wired” to solve other’s problems. Accommodators look to compromise and meet customers halfway, and so on.

Managers and customers were asked what type of support person they look for when hiring, and Empathizers came out on top. However, when measuring performance across a balanced scorecard, which included customer surveys, Controllers came out ahead. Who is a Controller? A controller cares about the feelings of the customer, but mainly to the extent of solving the problem as rapidly and efficiently as possible. Controllers tend to take charge of the situation. They may not follow the playbook, instead opting to take the most direct route to resolution.

During my years in the service industry, it was often said, “Run the bar, don’t let it run you.” One of the best bartenders I met would refuse to make the drink ordered if he thought the customer was making a poor choice. He was revered by customers.

Isn’t there someone on your team, or on a past team like this? Someone opinionated, measured, and willing to say the difficult things?

Customers certainly appreciate a customer success managers that is "always there for them," but if they can’t solve the problem, empathy and fifty cents will buy you a doughnut (SF residents price-adjust the metaphor accordingly). If every complex issue needs to be escalated past the empath, or if time it takes to solve a problem is spent understanding a customer’s situation, opinions about support quality will drop. Customers want their problem solved. They didn't want to ask you in the first place.

This doesn’t mean that hiring very technical support engineers will solve the problem. A better goal is to look for problem solvers. Yes, I know: during an interview, who isn’t a problem solver, right? But a problem solver doesn’t necessarily have a long customer service history or a emote any particular passion to help customers. But given a problem, she or he looks for the most efficient way to solve it.

The moral of the story with this survey, is that what you think your customer wants may not be what is really best for them.

Need help building a great team? Let me help! I am super-controlling.


Organic growth doesn’t really mean a user base expands in a tsunami of adulation and advocacy. What often powers growth are attractive improvements to the offering. With complex products, reducing the adoption curve through education, through externally maintained and contextual (in-product) documentation, is vital. 

Here in Japan, as well as in many other countries where English is not the preferred language of users or decision-makers, the best intentions and countless hours spent in documentation offer no succor to users trying your product, right now. Japanese people in the tech community often say the same things to me about their biggest hurdle for adoption. For engineers, it is native language documentation; for stakeholders, it is relevant data: collateral, case studies, sales enablement, etc. They can’t use the product, and they don’t know why they should.

Support comes up, but usually not as a blocker. Neither is lack of localization a deal-breaker. Of course, there are hurdles (payment, compliance, SLA, etc.) to delivering a SaaS product globally. But building an MVP or an initial user base needn’t be arbitrarily hard-wired to English-speaking countries. Don’t make going global a massive undertaking.

This is where you should say, if only there was a company who offered a simple way to get native docs, collateral, and enough marketing to get the word out. To that I would say, click this.


The Jerry Lewis interview is manna from heaven if you enjoy awkward situations as much as I. Anyone who has been on the other side of a prickly interaction with a customer can empathize (with a large helping of schadenfreude) with the reporter, as he keeps digging a hole.

Some non-complementary behavior might have helped. Tense situations often devolve into a feedback loop, and the best way out of it is to break the cycle. It’s also the hardest thing to do in the moment, witnessed in how he continues with his list of banal questions that just makes Jerry angrier. If the car is headed towards a cliff with no brakes, why keep plowing ahead?

Here are some suggestions, for when we find ourselves living in awkward times:

  • Acknowledge the tension. “Jerry, this is so tense. My interviews aren’t usually this tense. I was so interested in talking with you. I don’t want to do battle with you.”
  • Be creative. During one heated exchange, I forlornly remarked that it was my birthday and it sure was going really poorly so far. It broke the tension. Something out of left field can de-escalate. Proceed with caution, though.
  • Create/recreate the human connection. Show that you understand the customer’s emotional reaction. Show that you are as upset, nay, even more upset with a difficult situation. Did anyone else feel the interviewer was onto something when Jerry started talking about Dean Martin? He couldn't keep it going, and I doubt I would have fared much better.
  • Start with non-complementary behavior. “I want you to know that I have spoken with my bosses already. They are familiar with the situation, and I am completely empowered to make sure that you end up in a good place, as soon as possible. Let's figure out how to get there.” Suck the toxicity out of a room before an ugly tone is set.
  • Stop. Take Five. There is no email that can’t wait a few minutes, or be sent in the morning, after a night’s rest. Meetings can be pushed back. Go reset.

If you want to change your counterpart’s behavior, don't "make" them change it. Change your own first, and give them options to react differently. Did that cheer you up, Jerry?


robot human grip

If your customer-facing employee training works well, your team is gaining not only product knowledge, but also your vertical's best practices, and an understanding of the issues and goals of your various types of customers. If your company has this mastered, don't create a separate onboarding experience for your users. What your users need to know is generally a subset, and it’s a bigger subset than you probably think. This means that your Support team shouldn’t be front-line.

Every resolved support, Customer Success, or onboarding issue has a teachable moment. In a typical SaaS example, support is on the front lines, doling out answers based on accumulated knowledge. This is backwards. When there is a technical question, it should be posed to a training team, preferably well-versed in Customer Success fundamentals. If the training team understands the user and the appropriate user journey, the trainer can determine if the answer is provided in a training resource, or it can be added when necessary.

Then as questions arise, the dynamic is different. A training mentor provides answers via a constantly improving set of documentation, as well as a comprehensive answer: next steps, common pitfalls, and fundamentals key to understanding the reason for the design of the product. Support, rightly, works best with a limited scope: solve a problem. 

Feature requests, bug reports, when applicable, should be routed before they ever get to this point. If these non-support related issues account for more than 5% of incoming support requests, it’s probably time for a deeper look. The workflow can vary, but the more complex the product, or the more difficult adoption is, the more up-front training opportunities should be.

Customer Success is responsible for understanding user motivations and challenges. Customer Success needs to build a framework where the training team and the support team are well-leveraged. Emphasizing the scalable parts of great customer experience — creating a product which supports itself first, then providing great self-guided training, then ultimately human help, allows for the scalability to make other human interactions largely positive and reinforcing.


1. Give them the backstory.

Often, the reason behind a new product or feature never flows down to Support or other customer-facing teams. When they understand the internal motivation: the use cases that warrant a feature's creation, the potential benefits to new or existing customers, or internal factors which necessitate a change, they are able to perform engaged support, and provide better answers. Just because you know the feature is worthwhile, doesn't mean the front lines do. When someone puts a stack of work on your desk, don't you like understanding why?

2. Let them buy the customer a figurative drink.

As a waiter in my mostly-forgotten twenties, I had some great managers. They had enough trust in us to know when to buy an upset customer a dessert, a drink, or comp the whole table's meal. They never questioned us, and we never abused it. Setting the parameters to allow your support staff to say, "I know that must have sucked," will go further than "I see you are frustrated, I am very sorry." A one time credit, a temporary upgrade, or other small gesture turns a negative experience into a relationship-building one.

3. Support your product's documentation as well as your product.

Docs are aren't the answer to all technical issues, but they are a common destination. If a feature needs a doc, and that doc doesn't get the user up and running, why bother writing it? Ask for Support's guidance regarding documentation and training to insure people are using the product and the documentation the way you think they are.


Relevant customer journey data used includes drip click throughs, content A/B tests, actual user testing, e.g. watching the users using your product. Financial data helps build a balanced scorecard: lifetime value, upsell, churn, etc. Data from support and engagement interactions is also important.

But, looking at the data often leads to a single question, “Why?” Why did customer A visit your site and buy, when customer B didn’t. Agile use of surveys help answer these questions and iterate and make decisions based on these results.

Oh, I can help you solve your user’s mysteries.


Most Customer Success frameworks are built on customer journeys: the idea of following your users through single or multiple paths of using your application, and identifying areas causing friction. But what is a Customer Journey?

Think of Agile Project Management, where you have stories and epics. A story is a short goal: A user I want to successfully create an account. An epic is a collection of stories: I want to go on vacation using your service (create an account, select a flight, purchase a flight, be allowed onto the plane, have the hotel expect my arrival, have a great vacation).

Make sure you are thinking from the perspective of the customer. Their objectives are probably different than your sales, marketing or product vision.