本記事は、Engineering Manager Advent Calenderの１日目です。 はじめに エンジニアリングマネージャ(EM)と呼ばれる職務を設置する企業が増えてきました。 私たちの主催したイベントEOF2019でも700名近い方に参加していだき、また多くの方にご協力いただき成功裏に終わることができました。 EM Meetup/EM.FMなどのムーブメントの中心の一翼を担わせていただき、その高まりを感じる一方で不安も感じます。このエンジニアリングマネージャという職務は非常に多岐にわたるケースが存在していますし、必要だとされるスキルもまちまちです。そして、多くの場合、その企業のステージや状況ごとに求めるものは違います。また、求めていることを明文化することすらされていないケースも存在します。 このことから、エンジニアリングマネージメント自体が一時的な潮流として消費され、消えていっ
チームのマネージャーが、自らの責務をジョブディスクリプションとして明文化することは難しい。職務内容や権限を、断片的にしか書けないかもしれない。もしそうなるなら、実務も断片的になっている可能性がある。 チームマネジメント（組織マネジメント）という活動は、個々のマネージャーの経験や関心によって、断片的になりやすいように感じている。断片的とは、マネジメント活動が、責務の一部の領域に偏ってしまっていたり、問題を検知してはじめてその領域がマネジメント範囲であることを知る、といった様子を指している。 このような状態になる背景は、マネージャーにとって、マネジメントが、日々の実務を通して蓄積された経験に基づく活動になっているからではないか。マネージャーは孤独だ。ひとりでその責務を担う。エンジニアとは違い、チームで協働するわけではない。だから、形式知として言語化されず、個人の経験として暗黙知にとどまる。その
企業でWebアプリケーションエンジニアとして働き始めて2年と4ヶ月ほど経ちました。様々な仕事を経て、自分が向いていることや楽しく感じることが徐々に明らかになり、数年後になりたい像がぼんやりと浮かび上がってきました。そして、その将来像が世間的には「エンジニアリングマネージャー」（以降EM）と呼ばれていることもわかってきました。この記事では、EMについて自分が周囲から受け取った知識を整理するとともに、そこに向けてどんな戦略を取ろうとしているかをまとめてみます。マネージャーというとネガティブなイメージも拭えませんが、EMは年を重ねて吸い込まれるものではなく、積極的に取りに行くに値する面白いポジションであると思います。この記事を読んでEMに魅力を感じる同世代の仲間が増えると嬉しく思います。 EMについての理解 エンジニアリングマネージャーという職務についてのオーバービューは、広木大地さんによるエン
社内のSlackや打ち合わせで、今年に入ってから「どうやって本を読んでいるんですか？」と聞かれる回数が複数ありました。これを機にブログポストにまとめておこうと思います。これまでに色々な読書方法＋メモを試してきましたが、2022年時点で行き着いた方法という感じです。 前提 電子書籍（私の場合はKindle1）が販売されている書籍の場合は、電子書籍で購入します。電子書籍が販売されていない場合は、物理書籍を購入します。 電子書籍を優先する理由は次の2つです。 あとでまとめるときに楽なため スマートフォンがあればどこでも読めるため 特に1つ目の「あとからまとめるときの楽さ」を重視しています。（理由は後述） 読み進め方 電子書籍と物理書籍で読み方が多少異なります。そこで、電子書籍と物理書籍とで共通する部分を最初に示して差分を説明します。 電子書籍、物理書籍共通 高速で読み流し どちらのタイプの書籍で
はじめに エンジニアリングマネージャーとは? メンバーのサポート・育成・評価 メンバーの状態観察 目標設定・人事評価 後進の育成 日常の労務管理 開発 プロダクトマネジメント エンジニアリングのリーダーシップ 採用・採用広報・アドバイザーの招聘 採用 採用広報 アドバイザーの招聘 他社との情報交換 終わりに はじめに 今流行りの Meetyを使って社外の方とお話しする機会を作っているのですが、「エンジニアリングマネージャーとしてどんなことをしているのですか?」という質問を何度かいただいたので、自分の整理のためにも日々の具体的な行動・活動をまとめてみます。 私はRetty株式会社でtoC Web開発/toB Web開発 両方をみているエンジニアリングマネージャーであり、この記事を書いた2021年9月時点では20名弱のマネジメントを務めています。エンジニアリングマネージャーとなってからは2年が
こんにちは。askenでエンジニアリング戦略や組織づくりを担当しているやすにしです。 マネジメントを中心にしておりまして、せっかくなのでブログでもマネジメントについて書いてみますね。 私はこれまでVPoEとしてエンジニア組織のマネジメントや、様々な会社でマネージャー向けにコーチング 1 をやってきました。そこで接してきたエンジニアリングマネージャーに共通しているのは「キャリアに悩んでいる」ということです。 例えばこのようなことです。 コーディングをしなくなり、技術的に取り残されて、エンジニアとしてやっていけなくなる感じがする 自分でやらないから成果が見えない。やっている感じがしない。 マネジメントをどうやればいいか、どう学べばいいかわからない。 マネージャーのキャリアで自分は定年（？）まで生きていけるのか？ 共通点は、色々理由を言葉にしているものの、どれもしっくりきている感じではなく、「な
この記事はEngineering Management Advent Calendar 2022の7日目です. 今はエンジニアリングマネージャ(EM)としてエンジニアリングマネジメントの4領域(プロダクト・プロジェクト・テクノロジ・ピープル)すべてを見ていますが, それ以前は長い間テックリードをやっていました. その経験を活かして, 最近は後進を育ててテックリードあるいは「弱いEM」*1をできる人材を増やそうとしています(これ自体がピープルマネジメントの一環ですね). テックリードを育てるためにやっていることの全容を詳細に書くと本が1冊書けるくらいになってしまうと思うので, その中でも再利用可能そうな(と言うより再利用可能にしたいと目論んでいる)「テックリード養成講座」について紹介したいと思います. Memeplex.appで生成した, テックなリードが養成されるイメージ 経緯 僕自身は,
前回の転職エントリから3.5ヶ月、すなわちトヨタに入社してから3.5ヶ月が経ちました。 3.5ヶ月間とても気持ちよく働けたので、振り返り記事を書いていきます。座右の銘は「後ろを振り返らない」だったのに、歳を取ると振り返りがちになるんでしょうか。 インターネットの向こうの皆様にもぜひ弊社に興味を持っていただきたいので、弊社の良いなと思うところを書きます。嘘で興味持ってもらっても誰も得しないので、嫌だなと思うところもちゃんと書きます。 目次 前提: 所属とか経歴とか よかったこと1: 機会がめちゃ多い よかったこと2: 分散データ処理屋にとっては最高の戦場では？ よかったこと3: 伸び伸び研究開発させてもらえる よかったこと4: 偉い人はすごい びっくりしたこと1: 同じ会社に知らない部署がすごいある びっくりしたこと2: 組織をまたいだディレクションがすごく緩い ﾁｮｯﾄ嫌なこと1: コミュ
2023年2月〜3月頃に、私が執筆した書籍『エンジニアのためのマネジメント入門』が発売になります🎉 本稿では、発売に先立って「書籍について」と「執筆のきっかけ」、そして、書籍の「目次」と「各章の内容」を紹介します。 書名: エンジニアのためのマネジメント入門 著者: 佐藤大典 出版社: 技術評論社 発売日: 2023年2月〜3月頃（追記: 2023年3月9日発売になりました） 書籍『エンジニアのためのマネジメント入門』について 本書は、タイトルのとおりエンジニアリングマネージャーの入門書です。 本書のポイントは、エンジニアリングマネージャーの実務よりも、基礎となる知識の体系化を図ったことです。 この一冊で、エンジニアリングマネージャーの基礎的・基本的な知識と技能を学べます。 ハウツーではなくマネジメントの原典を基にした本なので、エンジニアリングマネージャーの入門者だけではなく、経験者の方
Platform チームの@deeeeeeeetです． Platform チームは2年前にMercariがMicroservicesの移行を始めたときに一緒に立ち上げられたチームです．Platform チームはMicroservicesを動かすための基盤や開発や運用のためのツールセットなど提供しています．立ち上げ時は自分を含めて2-3人で始まったチームですが2年が経ち10人を超えるチームにまで成長しました． チームのメンバーが増えるほど1チームとして動くには限界がきており，またMicroservices化が進めば進むほどチームの負う責任範囲も広くなりCognitive load (認知負荷) も高くなっていました．これらの課題を解決するために組織変更を行い，Platform チームを複数の専門性に特化したチームに分割しました． 本記事ではチームのデザイン，チームが分離しても独立性を保ちつつ
エンジニアリングマネージャーの最初の学び - このロールは何なのか - yigarashiのブログ
2023/6/16付の人事異動で正式にエンジニアリングマネージャー（以下EM）になりました。2021/8に「エンジニアリングマネージャーを目指す若者の戦略」という記事を書いて明確にEMを目指し始め、2022/12には「EMキャリアを切り拓く「最強の現場リーダー」という働き方」という記事でEMに近づく様子を書きました。さらにそこから半年余り、ついに会社からも正式にEMと呼ばれることになりました。実際には3ヶ月ほど前から強くEMを志向した動きにはなっていましたが、やはり正式な職位は特別なもので、キャリアにおける重要な実績をひとつ解除したと感じています。 これほどEMというロールを志向し色々とやってきたのですから、EMとしての振る舞いもさぞスムーズに立ち上がるかと思いきや、実際にEMとして動くのは非常に難しいことでした。書籍やブログ記事を読んで頭で理解したEMという働き方と、自分がチームでEMと
はじめにこれはEngineering Manager Advent Calendar 2023 25日目の記事です。 毎日良質な記事がアップされて、完全に俺得な一ヶ月でした。ご参加いただいたみなさんありがとうございます。 最終日の記事では、EM Advent Calendarを俯瞰しながら執筆している私のEMキャリアをふりかえり、結局のところEMとは何なのか、ということを考えてみます。 Advent CalendarにおけるEMの多様性と共通点LLM時代におけるEMという、実に2023年的な切り口から始まったこのAdvent Calendarには、実に多様なコンテンツが集まってきました。 新任EMの方の奮闘の記録、手を動かしてなんぼという考え方、スクラムとの接近、プロジェクトマネジメント的アプローチ、オブザーバビリティのEM業への援用、キャリア論・・・。 共通しているのは「マネジメント対象
最近テックリードのロールを手放し、働き方がEMに近づいた。折に触れてEMになりたいと言ってきたが、だからと言って最初からうまくできるわけもなく、ここ1ヶ月くらいは悶々としながら過ごしている。特に今回困ったのは、自分の現在地がぼんやりしていて漠然と据わりが悪い感触に苛まれている点だ。もう少し課題や方向性を精緻にして、自信を持って前進できる環境をつくりたい。その一環としてマイスキルマップを作ってみたので紹介する。 マイスキルマップへ至る思考 自分が大事にしている心構えのひとつに「練習していないことはできない」というのがある。十を知るには十を聞き、繰り返し実践することでしか一人前にはなれないという、ごくごく当たり前のことだ。この心構えでひとつひとつ丁寧にやっていくのが、ここ5、6年の自分の強みだと思っている。 しかしこの心構えを維持するのは簡単ではない。何かができるようになると、自分の能力のイメ
Q: I’ve noticed quite a bit of similarity between staff engineering roles and engineering management. What is your take on the similarities and differences?An interesting observation is how many leadership roles in Big Tech and at high-growth startups begin to utilize overlapping skill sets after a while. At these companies, everyone working in engineering or product is technical, meaning they hav
ペパボのエンジニアリングマネジメント一問一答 / engineering-management-q-and-a-in-gmo-pepabo
EOF2019にて、GMOペパボでのエンジニアリングマネジメントについてのQandAセッションを行いました。
はじめに Rettyでは2018年から組織的な改善活動を数多く始めており、その一つにエンジニアフィードバック（以下、フィードバックはFBと省略します）制度があります。 本記事はRettyのエンジニアFB制度への取り組みの紹介を兼ねた、これまでの改善活動の振り返り記事となっています。 （2018, 2019年のアドベントカレンダーの小迫の記事に組織的な改善活動についての紹介がありますので興味がありましたらご参照ください） engineer.retty.me engineer.retty.me エンジニアFBは今なお半年の評価ごとに継続的に改善を繰り返していて、今は4回目の改善サイクルとなる2020年上期のエンジニアFBが終わった頃となります。 対象としたい読者 下記のような項目にピンと来る方に読んでいただけると嬉しいです。 会社のエンジニアが評価に対して不満を抱えており、他社の評価制度の取り
ミクシィのマネージャーは悩んでいる / mixi's manager is in trouble
EOF 2019で発表した資料です。
エンジニアリングマネージャーに関する以下のアウトプットを見かけて、現時点での自分の思考のスナップショットも取っておこうという気持ちになりました。 エンジニアリングマネージャーを目指す若者の戦略 - yigarashiのブログ テックリードの抱えるプレッシャとキャリアパス - 貳佰伍拾陸夜日記 ウェブ業界でしか働いたことがないので、ウェブ業界に限定したことを書きます。 状況認識 エンジニアリングマネージャーとは何なのかというと、業界としての具体的な合意はまだ形成されておらず模索中という認識です。 なので一人一派のエンジニアリングマネージャー像を持っており、個人によって理解に大きなブレがある状態と思います。 そうした前提の中での最大公約数的な理解に関してはやはり エンジニアリングマネージャ/プロダクトマネージャのための知識体系と読書ガイド - Qiita にまとめられたアンケート結果が役立ちま
Engineering Managerをやっていた間の振り返りとまとめ - masartz->log(type=>'hatenablog')
TL;DR; Engineering Managerを降りることになりましたので、振り返りとまとめです。 ※会社は辞めませんので、退職エントリではございません（別チームへの異動です） 時系列 2017/10頃: SREのチーム内において会社のReport Line上にはプロットされないリーダー的なポジションをやりはじめる この時はまだManagerではない。採用や評価に対するResponsibilityがないのがマネージャとリーダーの簡単な違い 2018/04: SREのEngineering Managerに登用される 当時 Microservices PlatformはReport Line上はまだSRE内に包含されていた気がする どこかのタイミングで Report Lineとしても独立して、2チームを兼任する形で引き続き担当していた 2018/10: 2チーム兼任からMicroser
Platform Engineering on Kubernetes を読んでCloud Native の現在地を理解する - じゃあ、おうちで学べる
はじめに 近年、Kubernetesの採用が進む中、複数のチームが関わり、複数のクラウドプロバイダーへのデプロイを行い、異なるスタックを扱う組織では、その導入の複雑さが新たな問題となっています。本書 『Platform Engineering on Kubernetes』は、Kubernetes に登場しつつあるベストプラクティスとオープンソースツールを活用し、これらのクラウドネイティブの問題を技術的に組織的にどのように解決するかを示してくれます。 learning.oreilly.com 本書では、Kubernetes上に優れたプラットフォームを構築するための要素を明確に定義し、組織の要件に合わせて必要なツールを体系的に紹介しており、実際の例とコードを交えながら各ステップをわかりやすく説明することで、最終的にはクラウドネイティブなソフトウェアを効率的に提供するための完全なプラットフォーム
この本は大きく前半と後半にわかれていて、著者によるStaff Engineerの職務内容・昇進・会社選びなどに触れた前半、”Stories”と章立てされたStripe・Slack・FastlyといったTech企業で働く14人のインタビューを掲載した後半の構成になっています。私は前半を読みおえ、後半のインタビューを2人目まで読んだ状態です。 本書にかかれているスタッフエンジニアの職務内容や求められるものは良い意味で私のイメージしていものとは違いました。 これまで私が想像していたのは「所属する組織が使うOSSにコントリビュートして技術的な優位性を保る」「社内のツールを開発して組織全体の生産性を上げる」のような一言で言えば凄腕のエンジニアでした。 しかし、本書で紹介されるスタッフクラス以上の職務を自分なりにまとめると「チーム間・全社的な技術面でのマネジメントを行い、経営上のゴール達成に貢献する」
2022年昨今のEngineering Management(EM)界隈を見ていて、1つトレンドもしくは兆しがあるなぁ、と思っていることがあります。端的に言ってしまえば、EMを専門職種として切り出して、人（や組織）のマネジメントに専念させるパターンが出てきている、ということです。 もちろん、以前からこのような形態をとられている企業もあると思います。しかし、おそらくは専門性を高めている社員がキャリアラダーの1つとして、プレイングマネージャー的にマネジメントに携わるケースが多いのではないでしょうか。 プレイングマネージャーとして人のマネジメントに関わることの問題点は、2点あると考えています。ひとつは、プレイングしている内容（開発者であれば技術的なこと、デザイナーであればデザイン的なこと）と、人（と組織）に向き合う内容とのいずれにも注力できずに、どちらも中途半端な状態になるということです。結果と
人生初の転職エントリです。お手柔らかにお願いします。 2021/09/01付でトヨタ自動車株式会社に入社しました。 大手町オフィス というソフトウェアエンジニアが多く集まる場所で、自動車のデータ収集から分析まで、エッジ（自動車）からクラウドまでの研究開発をやっていきます。 目次 転職活動の軸 業務内容（やりたいこと）について なぜトヨタを選んだか 終わりに 転職活動の軸今までの1回の新卒入社と2回の転職ではほぼ直感でズバズバ決めてきたのですが、今回の転職では自分なりにきっちりと転職活動の軸を決めて臨みました。 必須要件 年収: XX円以上（ストックオプションなどを加味して減額することあり） 業務内容: ミドルウェア以下の自分が好き＆得意な領域の研究開発 嬉しい条件 一緒に働きたいと思える 人 よい 事業内容 業務内容（やりたいこと）について「ミドルウェア以下の自分が好き＆得意な領域の研究開
Philipp Hauer's Blog Engineering Management, Java Ecosystem, Kotlin, Sociology of Software Development Posted on Sep 9, 2019. Updated on Dec 18, 2022 Maintainable and readable test code is crucial to establish a good test coverage which in turn enables implementing new features and performing refactorings without the fear of breaking something. This post contains many best practices that I collect
At most technology companies, you'll reach Senior Software Engineer, the career level, in five to eight years. At that point your path branches, and you have the opportunity to pursue engineering management or continue down the path of technical excellence to become a Staff Engineer. Over the past few years we've seen a flurry of books unlocking the engineering manager career path, like Camille Fo
※ (2020-07-12 追記) 2020年6~7月の求職活動に伴う募集は終了しました。 令和2年6月1日より、ソフトウェアエンジニアとして"求職活動"を開始します。職務経歴書 (CV) を以下のページで公開していますので詳細はそちらをご覧いただければと思います*1。興味をお持ちいただけた方はCVに記載のメールアドレスにご連絡いただけると嬉しいです*2。 ohbarye.github.io ※英語版はこちらです: https://ohbarye.github.io/en/cv/ *3 ※ (2020-06-03 追記) メールでの返信には~3日を要しています。Twitter DMは本記事公開以前から無法地帯となってしまっているため確認しておりません。 ※ (2020-06-12 追記) 2020-06-12 21:00 JST 時点までに送られたメールについて、すべて一次回答はさせていた
Philipp Hauer's Blog Engineering Management, Java Ecosystem, Kotlin, Sociology of Software Development Posted on Oct 14, 2019. Updated on Jun 12, 2022 Putting a fat jar into a Docker container is a waste of storage, bandwidth and time. Fortunately, we can leverage Docker’s image layering and registry caching to create incremental builds and very small artifacts. For instance, we could reduce the e
Kyashにサーバサイドエンジニアとして入社しEM、VPoEを経て今年からCTOになりました。早いもので2021年も半分がすぎ、つまりCTOになって半年ですが、取り組んだことをざっと書き出してみました。ただ正直言えないことも多いので、半分くらいしか書けていません プロダクト プロダクト戦略やプロダクトの方向性に対する納得感を醸成出来ていないという課題が1on1や雑談の中で聞こえ始めたので、戦略の背景や以前の戦略との違い、施策の目的などを説明する機会を増やしました。会社として四半期ごとに戦略発表は行っていたのですが、1回言うだけでは伝わりきらないこともありますよね。何度も言うの大事です 2020年10月に事業譲渡したKyash Directのシステム移管が完了。システム移管はキャリアの中でも初めてだったので良い経験でした マネジメント リスクマネジメントやシステムセキュリティ、情シスのキャッ
An AnandTech Interview with Jim Keller: 'The Laziest Person at Tesla'
Topics Covered AMD, Zen, and Project Skybridge Managing 10000 People at Intel The Future with Tenstorrent Engineers and People Skills Arm vs x86 vs RISC-V Living a Life of Abstraction Thoughts on Moore's Law Engineering the Right Team Idols, Maturity, and the Human Experience Nature vs Nurture Pushing Everyone To Be The Best Security, Ethics, and Group Belief Chips Made by AI, and Beyond Silicon A
DirectXの作者の一人であるEric Engstromが死去した。これにことよせてD言語のWalter Brightが思い出話を書いている。 I've known Eric since around 1985 or so when he came to work at Data I/O. Our fr... | Hacker News Ericは1985年から知り合いだった。Data I/Oで働いていた頃だ。次第に疎遠になっていったが、あいつは常に特別なやつだった。 今となっては私しか覚えていないであろう思い出話をひとつしてやろう。いつ思い出しても笑えるし、まさにあいつらしい話だ。 あいつが1991年か92年あたりにMicrosoftで働いていた頃、問題を抱えているマネージャーがいた。アセンブリ言語で書かれたプログラムがあった。5万行ほどのサイズだ。プログラムには修正すべき不具合があっ
今年のLayerXの取り組みについて書こうとも思ったのですが先日下記の記事でまとめてしまったので、今回は開発生産性に大きな影響を与える不確実性についてのポエムを書いてみようと思います。 いうのも最近はプロダクト開発そのものよりも、複数の事業をより遠くからサポートしていく事が多くなりました。そのため具体的な取り組みよりも、その根底にある戦略が正しくあることをサポートすることが多くなりました。 この視点から開発生産性について書くことは多少普段と違う見方をEngineering ManagerやProduct managerの方へ提供できるのではないかと思っています。 特にプロダクト戦略面における不確実性は具体的な運用のHowより大きな影響を開発生産性に対して与える事が多いため、戦略と開発生産性ということについて触れていきます。 戦略と開発生産性我々が開発するソフトウェアは前提として顧客に価値を
100. A Philosophy of Software Design (1/3) w/ twada | fukabori.fm
MP3ファイルをダウンロード 内容紹介 twadaさんをゲストに、A Philosophy of Software Designをテーマに色々と語っていただいたエピソードです。 出演者 話したネタ 書籍：A Philosophy of Software Design, 2nd Edition 資料：“A Philosophy of Software Design” を30分でざっと理解する 記事：ソフトウェア設計についてtwada技術顧問と話してみた 〜 A Philosophy of Software Design をベースに 〜 記事：【続】ソフトウェア設計についてtwada技術顧問と話してみた 〜 A Philosophy of Software Design をベースに 〜 本書籍の翻訳は出ない？ Working Code isn’t Enough ストラテジックアプローチ と タ
「問題が発生しないよう努力すべきと誰もがわかっているが、短期的な利益を優先した結果大きな失敗を導いてしまう」という組織のワナ
何かトラブルが発生し、必死に時間をかけてそれを解決に導いた場合、多くの評価と称賛を得ることができます。しかし、そもそもトラブルを事前に予測して未然に防いでいた場合、トラブルの脅威が顕在化しないため高い評価を得られないことがあります。トラブルが起こらないように努力する方が良いと誰もが理解しているにもかかわらず、トラブルが起きたら対処する方向に進みがちで結果大きく不利益を生んでしまうというビジネス上の矛盾について、マサチューセッツ工科大学の研究者が解説しています。 Nobody Ever Gets Credit for Fixing Problems That Never Happened: Creating and Sustaining Process Improvement https://www.researchgate.net/publication/3228201_Nobody_Ev
この記事は前任 EM の yuya-takeyama の記事へのアンサーソングであり、 blog.yuyat.jp Engineering Manager Advent Calendar 2021 その2 2日目の記事として寄稿します。 qiita.com 背景 僕は引用記事の SRE チームの Software Enginner でした。ひょんなことから前任が別のミッションを担うことになり、このチームの後任としてどうか、となり 2021年10月より同チームの Engineering Manager をやっています。 以下、引用したりしなかったりしてこの2ヶ月の心境などを語っていきます。 Engineering Manager として置かれている状況 先ほど言った経緯に引き続き、情報的な話でいうと 自分含め7人のチーム もともと中途採用をしていた会社でもあり、自走可能なメンバーで構成されて
An Elegant Puzzle: Systems of Engineering Management を50分でざっと知る / Learn roughly "An Elegant Puzzle: Systems of Engineering Management" in 50 minutes
NTT Communications の社内ランチ勉強会 (TechLunch) で講演した資料です。
エンジニアリングマネージャー（EM; engineering manager）にまつわる最大の課題はなんだろうか、それはエンジニアはそのキャリアにおいて、別にマネジメントをやりたいわけではないということだ。実際、トッププレーヤーであることとマネジメントを両立するのはほとんど不可能である（プロスポーツの世界を考えればわかる）。 これはエンジニアリングマネージャーの採用はエンジニアの採用よりも難しいというさらなる困難も引き起こす。マネージャーは必要ない？エンジニアリングマネージャーがいない状態とは、それはエンジニアではないマネージャーがエンジニアを管理している状態だ（これはおそらく望んでいない事態だろう）。 エンジニア組織のデザインを考えるとき、こういう話は避けて通れないが全くやりようがないわけではない。本稿では、いくつかの典型的な組織のパターンとともにこの問題を考えてみよう。 Pure hi
Staff archetypes
Most career ladders define a single, uniform set of expectations for Staff engineers operating within the company. Everyone benefits from clear role expectations, but career ladders are a tool that applies better against populations than people. This is particularly true for Staff-plus engineers, whose career ladders often paper over several distinct roles hidden behind a single moniker. The more
Product Engineering Managerの募集をスタートしました - LayerX エンジニアブログ
こんにちは。松本（@y_matsuwitter）です。 最近はひたすら干し芋を齧っています。 昨日、新たにProduct Engineering Managerという、Engineering Managementに加えてProductも一体的に見ていくべくセットしたポジションについて募集を開始しました。 今回はこのポジションの募集に関して、将来を見越して何を狙っているのか簡単に書かせていただこうと思います。 https://herp.careers/v1/layerx/t_g55EhgE6oLherp.careers Engineering Managementの重要性 様々な企業でEngineering Manager（以下EM）が募集される様になって久しいと思います。 開発組織のPeople Managementに責務を持って行動することがEMの主たる責務となります。 その延長としての
この記事は Engineering Manager vol.2 Advent Calendar 2019 の 4 日目の記事（代打）です。 はじめまして。メルペイでBackendのEngineering Manager（以下EM）をやっている@keigowです。 Merpay Advent Calendar 2019 の初日で行われた、メルペイ VPoE による2019年の振り返りを受けて、メルペイのEM目線でもエンジニア組織を振り返ってみようと思います。 はじめに 振り返り VPoEの入社（2018年4月〜） PM/EM/TL体制の導入（2018年7月〜） リリースに向けた開発（2018年10月〜） メルペイ1stリリース（2019年1月〜） 大型キャンペーンと組織体制の変更（2019年4月〜） 技術負債の返済と採用（2019年7月〜） 成長とクオリティの追求（2019年10月〜） おわ
メルカリ・メルペイCTOとエンジニアが明かす「今だからこそ面白い」課題と挑戦 ＃BoldChallenge | mercan (メルカン)
プロダクトの開発や改善に伴い数値や成果に追われるなか、どうすれば納得感や達成意欲を感じながら働いてもらえるのだろうか。現場のエンパワメントやマネジメント、経営と現場のシームレスなコミュニケーションは、多くの組織にとって課題となり続けてきました。それは紛れもなく、メルカリグループも同様です。 9月24日に開催されたイベント「Mercari Bold Challenge ~CTOとエンジニアが赤裸々に語る 変化と挑戦~」。メルカリ、メルペイそれぞれのCTOや、現場のエンジニアを統括するEM（エンジニアリングマネージャー）が登壇。メルカリグループがエンジニアマネジメントにおいて考えていること、苦労していることや試していることなどを「赤裸々」に話しました。メルカンでは、3時間にも及んだイベントの様子をダイジェストでお届けします。 メルペイは、単なる「サービスの普及」を目指していない 第一部では、メ
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
エンジニアリングマネージャ/プロダクトマネージャのための知識体系と読書ガイド - Qiita
エンジニアリングスキルで捉えるチームマネジメント - mtx2s’s blog
エンジニアリングマネージャーを目指す若者の戦略 - yigarashiのブログ
色々試して行き着いた読書方法
エンジニアリングマネージャーとしてどんなことをしているのか？ - tuneの日記
なぜエンジニアはマネージャーになるのに不安を覚えるのか - asken テックブログ
テックリードを再生産可能にする - テックリード養成講座をやっている話 - 貳佰伍拾陸夜日記
トヨタの3.5ヶ月のソフトウェアエンジニア（研究開発）生活を振り返る
書籍『エンジニアのためのマネジメント入門』を執筆しました - STEAM PLACE
どのようにPlatformチームの組織変更をしたか | メルカリエンジニアリング
結局のところ、エンジニアリングマネージャーとは何者なのか｜dora_e_m
マイスキルマップでエンジニアとしての己を見つめ直す - yigarashiのブログ
Engineering Leadership Skill Set Overlaps
エンジニア評価制度の取り組みを振り返ってみた - Retty Tech Blog
エンジニアリングマネージャーの私的解釈と実践 - 下林明正のブログ
“テックリードという役割”のその後 — Will Larson “Staff Engineer”
EMのトレンド？もしくはその兆し (2022年)
トヨタ自動車に入社し、自動車データの収集〜分析基盤の研究開発やっていきます
Modern Best Practices for Testing in Java
Stories of reaching Staff-plus engineering roles - StaffEng
ソフトウェアエンジニアとして求職活動中です - valid,invalid
Don't Put Fat Jars in Docker Images
CTOになって半年の振り返りとこれから - ymzkmctのブログ
Walter BrightによるEric Engstromの思い出話
プロダクト拡大と開発生産性｜Matsumoto Yuki
SRE チームで Engineering Manager になって二ヶ月経っての心境など - ツナワタリマイライフ
エンジニア組織のデザインパターン｜Ryota Yokote @ミラティブ
メルペイのエンジニア組織をEMとして振り返ってみた | メルカリエンジニアリング