Two and a half years of writing for Not Just Bits. Career frameworks. Sprint patterns. Hiring playbooks. Sleep and leadership and the first 90 days.
I am closing it. Every post is at alexdimango.com/blog now, and every old link redirects. But that is not why I am writing.
I am writing because between 2024 and now, something more important happened than any of the topics I covered. Software engineering reset. The engineering leaders I have been talking to for the last year are managing the old version of the work.
What reset
The artifacts of software work changed first. A junior engineer ships in a day what a mid-level engineer used to ship in a week. A senior engineer reviews three times the surface area. The bottleneck moved from typing code to understanding what needs to be built and whether it works.
Then the org chart changed. Teams of five do work that needed twelve. Roles that existed because of routine work disappear. Roles that existed to scope, review, and decide became more valuable, not less.
Then the customer changed. Boards that used to ask “how is the team” now ask “how is the team plus the AI.” If you cannot answer the second question, you are not answering the first either.
What did not change
The fundamentals. Trust between teammates still takes months. Calibrating estimates still takes practice. Onboarding still takes deliberate work. The career path still needs intentional design. The OKRs still need check-ins someone runs.
Everything I have been writing about for two years still applies. It just applies on top of a different substrate.
The part hard to ignore
Every leader I have spoken to in the last six months faces the same question. From the board. From customers. From their own engineers. “Are you getting the AI thing right.”
Most of them cannot answer it. Not because they are not using AI. They are. License counts in those companies are high. Dashboards show hours of usage per week. They cannot answer it because they have no method to say what changed in the business.
License plus dashboard is not an answer. Activity is not the same as impact.
What I did about it
I pulled the method out of advisory engagements and made it open source. It is on GitHub now as the AI Adoption Playbook. Runs inside Claude Code. Two stages, twelve skills.
Stage one. Diagnose. Where adoption is stuck. Where the workflow changed and where it did not.
Stage two. Defend. Numbers a board will not roll their eyes at. The structure for a quarterly update with real evidence.
It is for you. The engineering leader who has been carrying that question for the last twelve months and has nowhere to put the answer.
github.com/adimango/ai-adoption-playbook
If running it yourself is not the call
I am turning the quarterly report into a productized service called Talon. Same methodology, packaged. Useful when you have the diagnosis but not the time. alexdimango.com/talon
A small ask
If the playbook is useful to you or to someone on your team, star it on GitHub. That is the whole ask. It surfaces the work for the next leader who needs it.
Thank you
Two and a half years of an audience that stayed quiet but kept showing up. Every reply. Every conversation that started with “I read your post on…”. I noticed.
Alex