[Remote] Leading Engineers To Water: The Art, Science, and Culture of Technical Coaching

Software engineering may be difficult, but fostering a working environment that enables skilled engineers to perform their best can sometimes seem downright impossible. Every day, many engineering teams are battling a messy whirlwind of forces like unmovable deadlines, imposter syndrome, psychological safety issues, personnel/leadership conflicts, fierce technological preferences, and more. With teams more distributed all over the world than ever before, cultural differences can exacerbate many of these difficulties.

In this presentation, I’ll discuss tips, tricks, and techniques that technical leaders and managers alike can utilize to better coach engineering teams, including concepts like the definition of empathy (and, more importantly, what doesn’t count), the trust-influence relationship model, introducing new technologies in a meaningful and consumable way, and a 5-step process to provide teams confidence to own their new solutions moving forward.

** 日本語版もあります。

 
 

Outline/Structure of the Talk

  1. Introduction 自己紹介
  2. The Engineering Mindset 開発者の考え方について
  3. Problems Engineers Face in the Workplace (Tech problems are often people problems too!) 開発者の仕事にある問題について
  4. Purpose of a Technical Coach コーチの目的
  5. Change Agent: The Most Important Role of a Technical Coach コーチの大切なロール「Change Agent」について
  6. How to Introduce Change 「変わること」を紹介するコツ
  7. Trust-Influence Loop by Mike Cottmeyer 
  8. 5 Step Process for Problem Ownership 

Learning Outcome

After attending this talk, participants will understand the role of technical coaching and tips and tricks they can apply in their day-to-day work when mentoring engineers, whether in a management or technical leadership capacity.

Target Audience

Engineers, Managers

Prerequisites for Attendees

No Prerequisites.

schedule Submitted 1 month ago

Public Feedback

  • Yasunobu Kawaguchi
    By Yasunobu Kawaguchi  ~  1 month ago

    プロポーザルの投稿ありがとうございます。
    トピックのカテゴリーをよりわかりやすく再構成しました。
    本プロポーザルのトピックにも反映しております。
    Thank you for submitting proposals.
    We have reorganized the topic categories to make them easier to understand.
    This is also reflected in the topics of this proposal.


  • Woohyeok Aaron Kim
    keyboard_arrow_down

    Woohyeok Aaron Kim - Roll your Product with Kaizen Culture(Let's 'Tech' the initiative (Renewed for 2021))

    45 Mins
    Talk
    Advanced

    Jeff Sutherland氏、Martin Fowler氏、Taichi Ohno氏。世界の業務プロセスに変革を導いた彼らは共通的に「カイゼン」について強調しました。

    彼らの本を読みエンジニアとしての道を歩んできた私たちにとって、「カイゼン」は第一の価値として認識されていると思います。

    皆さんは、今日より良い明日のために何に力を入れてますか?毎日が忙しすぎて、何かを改善するどころかストレスだけ溜まってたりはしてないでしょうか。

    楽天のランキングサービスグループは開発と運用、いわばDevOpsを実践していますが、そのプロセスに対しいくつか問題を抱えていました。開発の段階で発生するボトルネック、効率的だとは言えない運用環境。

    何よりも問題だったのは、こういったボトルネックにおいて改善の文化が定着しにくいということでした。せっかく良いアイデアを思いついても、そのボトルネックから発生するコストの問題で後回しにするしかなく、そうなればなるほどチームの改善力はどんどん下がっていきました。

    私たちランキングチームは2つの解決策を決め、それを同時に進め相乗効果を発生させることでこの状況を乗り越えようとしました。

    ランキングチームが挑戦したトライアルそしてテクニカルな変更によるチームカルチャーの変化。またその後1年間の運用ストーリーまで!

    より安全で良いサービスの提供のために、日々工夫を重ねているあなたのために、私たちのお話を特別に公開します。

  • クリス Chris Lucian
    keyboard_arrow_down

    クリス Chris Lucian - Mob DevOps & Mob Programming

    45 Mins
    Talk
    Beginner

    Currently in our environment of 27 developers we have no manual tests for the software to deploy to production. We practice continuous integration, and continuous delivery. All infrastructure is written as code. Bugs and defects are top priority with no bugs most of the time. Team members treat each other with psychological safety. We have a 2-hour value stream for our cloud based IOT product. This means a customer can receive changes to the software within 2 hours of the start of the feature.

     

    How did we get to this point? By working collaboratively and practicing Mob DevOps and Mob Programming! In this session we will review the status of the team and how you can iterate toward a similar environment.

  • Michael Migliacio
    keyboard_arrow_down

    Michael Migliacio - [Remote] Beyond the Brain Teaser: Technical Interviewing with RESPECT

    20 Mins
    Talk
    Beginner

    "How would you move Mount Fuji?"  

    Great question, but does an engineer need to know the answer in order to write great code?  No?  I don't think so either.

    The technical interview is one of the most controversial, challenging, and stressful parts of an engineer's career. The more senior the engineering position, the  less relevant the brain teasers, algorithm quizzes, and puzzles that make up these interviews are to the evaluation of a potential candidate. And although this interview style first became famous at large tech corporations like Microsoft and Google, it has propagated across the industry to the point that courses are springing up in college campuses and bootcamps showing candidates exactly how to "crack" these interviews.

    In the past, I’ve worked at a number of companies as a lead developer and in that role I spent a lot of time interviewing folks for technical positions. We weren’t allowed to choose our own process and had to follow the company’s rules. In that time I learned a lot about what works, and what doesn't work, for judging technical aptitude in an interview setting.

    In this presentation I will talk about the difficulties of technical interviewing from both the interviewee and interviewer's point of view, and provide several helpful tools using the acronym RESPECT to improve the interviewing experience across the board.

    ** 日本語版もあります。

  • Yuya Kazama
    keyboard_arrow_down

    Yuya Kazama - DevOpsの組織におけるテスト活動の在り方

    Yuya Kazama
    Yuya Kazama
    QA Engineer
    BizReach Inc.
    schedule 1 week ago
    Sold Out!
    45 Mins
    Talk
    Beginner

    ここ最近、私の周りでは、テスト活動の範囲が広がっている事例が出てきているように感じます。

    例えば、テストマニフェストでは、「ずっとテストし続ける」「品質に対してはチームが責任を持つ」と示しています。つまり、テストとはQAやテスターだけの取り扱いではなく、チーム全体でテストを常に考え続けることを表しています。

    20200418161646.png

    また、Dan AshbyのDevOpsにおける継続的テストの図では、実装前であるPlanの部分から本番環境適用後のMonitorまで、あらゆるところでテストができることを表現しています。

    model-2.jpg?w=820

    この継続的テストの図のうち、画像の左半分、特にPlanやBranchといった部分や更に前段階のIdeaの部分にテスト活動を持っていくことをShift leftのテストと呼んでいます。一方、画像の右半分の部分にテスト活動を持っていくことをShift rightのテストと呼んでいます。

    私は今まで、RSGTやScrum Fest Osakaでの発表を通じて、Shift leftの事例を紹介していきました。また、書籍『Agile Testing Condensed』にもShift leftのテストを行う方法が多く紹介されています。

    一方で、Shift rightのテストはどうでしょうか?実は開発者やSREチームではFeature Flagといった手法を用いることによってShift rightのテストを行う準備ができているかもしれません。ですが、Feature Flag部分に対するテストをどうすれば良いかまで考えている人は少ないかもしれません。

     

    そこで本発表では、書籍『Agile Testing Condensed』と書籍『Testing in DevOps』を参考にして、Shift leftおよびShift rightのテストについてご紹介します。

    また、我々の組織で行っているShift rightのテストの事例もご紹介できればと考えています。

  • Shigeru Tatsuta
    keyboard_arrow_down

    Shigeru Tatsuta - Kubernetes 導入から始める DevOps について

    Shigeru Tatsuta
    Shigeru Tatsuta
    Senior System Engineer
    SoftBank
    schedule 1 month ago
    Sold Out!
    20 Mins
    Talk
    Beginner

    我々の所属するソフトバンクの IT 本部は、主にキャリア事業を支える IT システムの開発、保守、運用を担っています。キャリア事業はユーザーの生活を支える重要なインフラであるため、堅実なキャリア品質のシステム構築として、自社のデータセンターのオンプレミスな環境で稼働するシステムを数多く開発してきました。一方で、近年ではビジネス環境の変化に伴い、Agile や CloudNative な開発にも積極的に取り組んでいます。

    現在、全国のソフトバンクショップではスマホアドバイザーというスマホに関するあらゆる相談に対応するスタッフが在籍しており、スマホ教室などの様々なサービスを提供しています。スマホアドバイザーの業務を支援するシステムにおいて、自動化機能を可能な限り活用して、運用担当者の負荷の軽減を目的として、クラウド、Kubernetes を採用して、システム開発、および運用を行ってまいりました。当初は DevOps を目的としていたわけではありませんが、クラウド、Kubernetes によって、それまでの運用作業の質が変化し、結果として、開発と運用の組織の垣根を越え、運用の在り方、開発と運用の協業等、我々なりの DevOps を考えるきっかけとなりました。

    このセッションでは、我々のスマホアドバイザーのシステム開発において、クラウド/Kubernetes を導入して、1 年程度運用してきて、得た知見、たどり着いた我々なりの DevOps、およびこれからについて共有できればと思います。

  • 藤原大
    keyboard_arrow_down

    藤原大 - アジャイル・DevOps時代におけるテスト・品質保証の未来

    藤原大
    藤原大
    Agile coach, Engineering manager
    N/A
    schedule 1 month ago
    Sold Out!
    45 Mins
    Talk
    Beginner
    この10年は多くの変化がありました。
    ソフトウェア開発プロセスにおいては、アジャイル開発の普及が進み、さまざまな現場でスクラムが活用されるようになりました。技術面では、コンテナ技術やその管理の自動化が進み、システムはどんどん複雑になりつつあります。
    
    一方で、テストや品質保証はどのように変わってきたでしょうか?
    
    私はアジャイルコーチとして10年活動してきましたが、最近話題の「DX(デジタルトランスフォーメーション)」の影響か、開発に速さがより求められるようになってきたように感じています。そして、その影響もあってか「テストがボトルネックになりがち」や「マニュアルテストのチームがコストセンターになってしまった」という相談をよく受けるようになりました。
    
    このセッションでは、アジャイル・DevOps時代における開発プロセスについてお話させていただきます。そして特に、「テスト・品質保証」について、現状と課題や求められる要件を整理し、未来のあるべき姿を、国内外の事例をもとに解説させていただきます。
  • Jumpei Ito
    keyboard_arrow_down

    Jumpei Ito - 「お客さん怒ってるから謝ってきて」から始まったWhole-TeamアプローチとAgile Testingマインドセットの改善物語

    Jumpei Ito
    Jumpei Ito
    QA Engineer
    WingArc1st Inc.
    schedule 1 week ago
    Sold Out!
    45 Mins
    Talk
    Beginner

    QAに携わる人は一度は品質問題でお客様から怒られた経験はありませんか?
    私は最近経験しました。

    突然、マネージャーや経営陣に呼ばれて、
    「品質問題起こしてるサービスあるから、品質が語れるQAとしてお客さん先に行ってきて」
    と言われました。
    もちろん今まで自分が担当したことのない製品でした。

    お客様と会話し、開発現場のプロジェクトにどっぷりとハマり、
    見えたものは、お互いが主張するギャップでした。

    このトークでは、QAが開発現場に入って、
    チーム全体でデリバリーできるようなチームビルディングと、
    品質にフォーカスした開発を行うAgile Testingマインドセットを実践し、
    徐々に品質を改善したストーリーを話します。

  • Kohsuke Kawaguchi
    keyboard_arrow_down

    Kohsuke Kawaguchi - 開発環境、共有のススメ

    Kohsuke Kawaguchi
    Kohsuke Kawaguchi
    CTO
    CloudBees, Inc.
    schedule 1 week ago
    Sold Out!
    5 Mins
    Lightning Talk
    Intermediate

    開発チームの生産性は、コードを書く周辺の様々な作業に大きく依存しています。この発表では、direnvやBazelを活用し、スクリプトなどの共有を一段と推し進めることで、小さな生産性の向上をチーム内で共有できるような環境を作った事例を紹介します。

help