エンジニアと1on1をするときの事前面談シートテンプレート - $shibayu36->blog;
はてなのチーム横断のエンジニアメンター制度 - Hatena Developer Blog で紹介していますが、はてなにはチーム横断のエンジニアメンター制度があります。僕も最近までメンターとして5~6人ほどのメンティーを持っていました(今は事情があってメンターをやっていないのですが)。 メンターとして1on1をする時には1on1ミーティングに備えるアンケート - しるろぐを参考にし、事前にメンティーに面談シートを書いてきてもらうという工夫をしていました。その面談シートは改善を少しずつ加えながら運用していたのですが、一度知見共有も兼ねて最近使っていた面談シートテンプレートを公開してみようと思います。 面談シートテンプレート 以下のようなフォーマットで書いてもらっています。1on1の前にメンティーに1on1用Google Docsに追記していってもらっています。1on1用Google Docs
Joy, Inc.を読んで、幸せなチーム作りを考えてみた - Unknown Error
私は日々、幸せな組織を作りたい、と思っています。幸せな組織とは、笑いに満ち溢れ、物事について真剣に議論し、困難なことも前向きに取り組んでいる組織です。自分の見ているチームメンバーが、主体的に動いて課題を解決していく姿を見ると、うれしくなります。逆に、モチベーションが下がって暗い表情を浮かべている人を見ると、チームに何か問題があるんじゃないか、何も言えない雰囲気になってしまっているんじゃないか、やらされ仕事になってしまっているんじゃないか、といろいろ考えてしまいます。 これまでの経験上、良い状態のチームと良くない状態のチームをまとめると、以下の通りです。 良い状態のチーム お互いを尊敬出来ている 特定の人物が特定の機能を担当していない 助け合いが出来ている、困っている人を積極的に助けている 現状に甘んじない メンバー同士でタスクの進捗に対して突っ込みを入れている 自分たちでタスクを定義してい
Team Refactoring -強いチームをつくる技術- #dotsconf
2016年2月27日(土)Dots Conference Spring 2016にて。 「Team Refactoring -強いチームをつくる技術-」。
CTOがチームマネージメントじゃない方向に向かう時に何をするべきなのか - トレタにおけるmasuidriveの役割 2017年版 - トレタ開発者ブログ
トレタ CTOの増井です。 トレタは創業して3年半、エンジニアも2名から13名に増え、私の役割も変わってきました。 当初は一人目のエンジニアとしてアプリの設計やサーバサイドのコードを書いたり運用全般を行っていました。 人数も増え、2年を過ぎたあたりからエンジニアリングの中で私が率先してやる必要のあることがほぼなくなってきました。むしろ海外展開で出張が増え、連続した時間がとれずに進捗を遅らせる原因になってしまうこともありました。 最近の論調では、メンバーが増えるとCTOはマネージメントや組織作りに移行して行くみたいですが、私はそっちに興味が全然なく、向いているとも思えませんでした。そもそも私は上司を持ったこともないし、決められた環境の中で働くのがとても苦手なので。 私が「組織を作って管理して行く」のは無理というのはトレタ設立当初から分かっていたことなので、メンバーを増やす時は「自分で目標を作
リモートワークの勘所と限界について1年くらいの感想、組織にとっての選択肢作りの話
1年くらいリモートワークを続けてみた感想 まず当然ながら「リモートワークは生産性が高い！これこそ未来のワークスタイル！」のような感想はありません。 生産性やコミュニケーションに関連するメリット、デメリットをうまく相殺しきれれば、生活の自由度だけ向上してハッピー、と考えています。 今は自宅かレンタルオフィスのいずれかを作業場として開発などを行いつつ、本社がある渋谷には1泊2日の出張を月2回するようなペースで仕事をしています。基本は Slack でテキストチャットによるコミュニケーションをメインとしつつ、必要があれば MTG に Hangout でビデオチャットで参加します。 生産性は大して上がらない 期待していた生産性は、それほど向上することはありませんでした。 東京にさえいなければ気軽に MTG に呼び出されることもありませんし、開発に充てることが可能な時間は若干増えています。通勤時間が長
20151020_Selenium勉強会@サイボウズ
2015年10月20日のSelenium勉強会@サイボウズの発表資料です。 http://connpass.com/event/20779/
Tech Lead（TL/テックリード）の役割 - サンフランシスコではたらくソフトウェアエンジニア - higepon blog
Tech Lead（TL/テックリード）の役割。聞きなれない名前かもしれない。リードプログラマやテクニカルリードと呼ばれることも。過去にいくつものチーム（最大で10人以上）の Tech Lead をやってきた自分の経験を踏まえて書いてみる。 Tech Lead の主な役割 Tech Lead はエンジニア班長と言いかえるとイメージがわきやすいかもしれない 顧客に提供したい価値（プロダクトゴール）を正しく理解する エンジニアチームの生産性を可能な限り最大化。プロダクトマネージャ・デザイナと顧客に価値を提供する Product の Launch に責任を持つ Product の Launch 後のメンテナンスに責任を持つ エンジニアを過負荷から守る ときにはマネージャ、プロダクトマネージャのアイデア、スケジュールに NO を言う。代替案を提示する チーム内のテクニカルデザイン、採用技術などに責
How GitHub Works
In 2011, I wrote a three-part series called How GitHub Works. I wanted to detail how we planned ideas, built them, and shipped them. GitHub no longer works like this, electing instead to institute a hierarchical, manager-driven, top-down, geocentric organization. I’m going to keep these posts up, though, because I think they address extremely important aspects of how good technical companies shoul
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
組織をシステム化するReactiveManagement
エンジニアがプロダクトマネージャーに進化すると何が起きるのか