AstroColossal Blog

2018-11-05

■多くの会社が選ぶ海外進出の手法
ある会社の事業がうまくいってきて、いよいよ海外に進出をしてみようとするとき、だいたい次の2つの方法のどちらかを取ります。1つは相手の国のやりかたに合わせる方法です。もう1つは自分の国のやり方をそのまま使う方法です。もし、あなたが自分の会社の支社を海外に作ろうと思ったら、どちらの方法を選びますか。
私からすると、この2つのやり方はどちらも極端で、お勧めできません。相手の国に合わせようとすると、自社の強みを発揮できないし、反対に自分の国のやり方でいこうとすると、知らず知らずのうちに本国スタッフと現地スタッフの間に上下関係が生まれてしまいます。そうすると、現地のスタッフは指示待ち人間になり、また、現地の文化にそぐわない振る舞いがあったとしても、味方であるはずの現地スタッフはそれを指摘してくれない可能性さえあります。
実際に海外進出をしようとするとき、きっと誰かが上述のようなやり方を勧めてくるでしょう。でも、3つ目の方法もあるのです。

■コラボレーションが新しいアイディアを生む
まず、他の国で自分の会社の製品を展開させたい時、今ある製品をそのままコピーすればいいという考え方は捨ててください。コピーは繰り返すほど画質が悪くなっていきます。コピーをするのではなく、新しいチームで新しいものを生み出せばいいのです。言葉と文化がちがっても、製品に対する価値観が同じなら、それはチームになります。たとえば、アメリカの会社が日本に進出しようとした場合、日本はやっぱり他の国とは違うから、日本独自のやり方に合わせたほうがいいと思うかもしれません。ですが、日本とアメリカの両方のやり方を混ぜて、そこから新しい戦略を生み出すこともできるのです。
まずは両国のスタッフが顔を合わせ、ブレーンストーミングや創造的なミーティングを繰り返してください。
そこから、新しいアイディアや戦略が生まれます。それはもしかすると、今まで誰も考えつかなかったアイディアや戦略かもしれません。その過程で、両国のスタッフはチームになり、話し合いを重ねれば重ねるほどそのチームは強まるでしょう。上下関係ではなく、対等な関係を持つことができるのです。

外国に作る支社を「子会社」だと思わずに自由な「子供」だと思ってください。子供はみんなが無理だと思うことに挑戦してみて、大人の知らないところで育っていき、その個性が花を咲かせるのです。そのとき、そのやり方は本社でもきっと応用できるでしょう。
海外進出を考えている時、決してその国の人に全部を預けないでください。

2018-10-29

新入社員と新米上司という組み合わせは悲劇を生む可能性があります。有能な人は初めてする仕事でも、たいていよい結果をのこしますが、マネージャー(管理責任者)という役割を与えられたとき、それもうまくできるかは別の話です。仕事ができる人がよいマネージャーになれるとは限らないのです。

もし、あなたの会社の中で、原因がわからず離職率が高い部署があったとしたら、その部署を管理するマネージャーに問題がある可能性があります。特に仕事ができる人がマネージャーになると、自分のやり方をそのまま部下に押し付けがちです。パワハラなどはそういう状況から生まれます。

もしあなたが新しい役職を手に入れたばかりのマネージャーだとしたら、最初にやることは命令ではありません。まずは自分は黙って、そこにいるメンバーたちの意見やアイディアを聞くことから始めるべきです。他の人のアイディアや考え方を受け入れようとするのです。そうすれば今後仕事をしていくなかで、メンバーたちに意見があれば、すぐに口に出せるようになります。またメンバーの一員がもし失敗をしたとしても、その原因について話すことができます。メンバーの考えをじっくり聞く姿勢を見せれば、そこにいるメンバーで一つのチームになることができます。

新米上司は「自分がすべてを決めなければならない」と強く思いこんでしまいがちです。でも、そんな強いプレッシャーの中では誰も生きていくことはできません。ポイントは「コンセンサス(意見の一致)」です。互いにコンセンサスが得られるように対話をすればいいのです。

新入社員が入社後、様々な研修を受けるのと同じように、初めて人がマネージャーになるとき、やはり研修が必要です。そうしなければ、有能な部下たちを失う恐れがあります。

2018-10-08

突然あなたの頭に誰かの役に立つようなアイディアが浮かんでから、それを具体化し、世間に公開するまでの期間はどのぐらい必要だと考えますか?

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

誰に見せても恥ずかしくない状態にまで仕上げてから、その製品の販売を開始するのでは、すでに遅すぎるのです。あなた自身が完璧を目指して作り上げた製品は顧客にとって完璧なのでしょうか。あなたにとって完璧な製品が顧客にとっての満足とは限らないのです。
1つでも誰かの役に立つ点がその製品にあるのなら、その時点で人の目に触れさせるべきです。技術者からすると中途半端な状態でリリースすることは信じられないことかもしれませんね。でも、早い段階で公開することによって、その中途半端な製品はそれを手にした人によって、人々の望むように改善され、成長していき、結果、多くの人に必要とされ、役に立つ製品になるのです。

このことは製品だけに限りません。目に見えないWeb上のサービスにも当てはまりますし、これから様々なコンテンツを提供しようとするスタートアップ企業にも当てはまるのです。
 

2017-07-30
Me Talking

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

 

2017-06-19

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 - https://pkg.jenkins.io/debian/jenkins-ci.org.key | sudo apt-key add -
  • echo deb http://pkg.jenkins.io/debian-stable 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/id_rsa.pub
  • 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 https://raw.githubusercontent.com/pantheon-systems/terminus-installer/master/builds/installer.phar && 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 .

Plugins

  • 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.

2017-03-19

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.

2017-03-17

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.

2016-12-21

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?

Jerry

2016-11-16
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.

2016-10-18

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.