ABB is a large international hardware company. ABB makes electric power systems, including a lot of the large electrical hardware at many Tesla Supercharger installations around the world. ABB restructured parts of their company, some of the product engineering parts and some of HR and other areas, to give the engineers more authority. The leader said they wanted real agile, where engineers don't wait to be told what products to build, but proactively try products in the market to find what helps customers and grows the company. That was 3 years ago. They wanted to re-energize the staff. They requested me to give a shocking, exciting, inspiring keynote about engineers as product leaders to reduce waiting and increase innovation. They joined from offices in Italy and Switzerland and I joined remote from Japan. I am so so grateful the ABB sponsors then let me share the recording publicly.

So, how is everyone else getting real quality and fact checking done? I asked grok to help me learn a Japanese kanji and it started making its own kanji. I hoped AGI would, you know, be higher quality then a middle school student.

I have been playing freebase for 30 years now. squid.org/freebase.html

We are firmly in the era of AGI. However it seems I still have to unplug and plug back in my router periodically.

Engineering is an excellent benchmarking tool. For humans or AI.

This is a perfect example of why every other company I have been in feels like they are moving in slow motion.

This is exactly my experience as a Tesla employee.

😌☕️✨

Business is not complicated. If it looks complicated, it’s corruption. Very nearly 100% of business world wide is not sweating to make the best products. They are instead sweating how to protect and grow their corruption. So buy from, work for, and be a fan of the very few that are simply, honestly, directly, sweating to make the best products and services.

RT @orangebook: Raising your standards about yourself and being bolder with your ambitions, that's actually the therapy most people need.

You can only be a gentleman if you are first a man, then choose to be gentle. What then defines a man? Probably being able to murder / death / kill anyone within a 10 meter radius, at any time. Then be gentle. Choose gentle. Hold doors open for everyone instead. But keep your eyes up while you hold the door.

In ancient times, the Greeks farmed the surrounding settlements. They made a brutally successful game they won for generations with their physical and mental discipline. In the AI era, what will be farmed? What will be the new “noble attributes” and resulting “fair moves”?

Are you curious about your potential? Spend 45 minutes to 3 hours on it per day for six months.

The problem with “good” vs. “evil” is Clean data, true and clean data is the prerequisite to assess good or evil. Good luck finding that. I just watched an hour of MSNBC- no idea what was paid placement, fact, or wishful thinking.

Q: スクラムマスター自身が 『変革を 焦り、 チームや 組織を 誘導しようとしすぎている』と いう 罠に 陥った際、 ご自身が それに 気づき、 立ち止まる ための セルフチェックや 内省の 習慣が あれば 教えてください。 Please share any self-check or self-reflection habits you have that help you recognize when you, as a Scrum Master, have fallen into the trap of “rushing the transformation and trying too hard to steer the team or organization,” and that help you pause and reassess. A: Is the Engineering KPI improving faster then before? For example, if my team exists for improving server security, have our automated security tests improved and has our score on those tests and the legacy tests improved? How fast has it improved and by how much? This is all I need to know. Then, I check what transformative actions I need to earn support to implement that will improve that KPI more and faster. You can think of your teams like a race car. Find your most important KPI, like lap time in seconds. Then transform all available resources to improve your laptime by as much as possible as fast as possible. It starts with an engineering goal which is your KPI.

Q: 業務で AI駆動開発を 実践しているのですが、 AI駆動開発での 改善点が 山積している 状況です。 それに プラスして ステークホルダーからは AI駆動開発の 実践に 対する 知見の 共有や 変革の アウトプットを 求められています。 こういう 場合の 優先度と しては チームの 課題を 解決が 先でしょうか？ それとも 組織の 変革の ための 知見の 共有や 課題共有が 先でしょうか？ We are currently implementing AI-driven development in our operations, but there are still a mountain of areas for improvement in this approach. On top of that, stakeholders are asking us to share our insights on implementing AI-driven development and to provide outputs that support organizational transformation. In a situation like this, should our priority be to solve the team’s challenges first? Or should we prioritize sharing insights and challenges to drive organizational transformation? A: The priority it always increasing the pace of innovation, and by that I mean engineering. Always. This is how your team will learn what is worth sharing. And, the sharing can be automated by the AI's participating with your humans in engineering. If the AI's understand the work well enough to meaningfully accelerate quality engineering, they understand the work well enough to summarize and share the most important insights.

Q: これだけいい 取り組みなのに、 日本で 広がらない 根幹は 何と 思いますか？ （文化？ 人間性？） Given that this is such a great initiative, what do you think is the fundamental reason it hasn’t caught on in Japan? (Culture? Human nature?) A: CIO's and CSO's are typically empowered to reform engineering teams around specific problems to solve instead of grouping them by skills. The other structural changes required to increase the speed, quality, and value of releases, such as employee incentives, also often require CIO or CSO level understanding and mandate. In Japan, most CIO's and CSO's are not active engineers. And, culturally, Japan values calmness and flow, it has the least sense of urgency I have ever experienced in engineering, so the pressure to change is not there, even as the division goes bankrupt.