I used to joke that my job was to continually make myself obsolete. In the current atmosphere of anxiety surrounding the threat posed by AI to job security, that old quip now sounds like an odd position to adopt. However, I think there’s a lesson to be learned. In spite of my best efforts to render myself useless, I was never able to reach my goal of quietly sitting back with nothing new to do. It turned out that my relentless pursuit of automation and the creation of software that offloaded my efforts didn’t end my job, it just changed it.
Instead of tending to ETL processes or building boilerpate applications, I had time to experiment and explore. My job became more focused on ideas, architecture, and mentorship and less on process and maintenance. I taught others to become the tenders of processes and how to build simple pieces of software that can be re-used. In the end, my usefulness and utility actually increased. There was no pink slip waiting for me.
 |
|---|
| Lots of obsolete CRT monitors |
As my job transformed I evolved into more of a leader - albeit a reluctant one. Instead of tending processes, I tended people. This brought with it new challenges. Being good at solving technical problems and building good software requires a markedly different set of skills than being a good leader. I was lucky to have good examples to follow and was given the time to grow, and, with time, became effective and competent. What allowed me to succeed was not a promotion, it was my years of foundation building that equipped me to impart on others the lessons of automation, obsolescence, and inevitable change.
Laurence Peter satirically wrote about what he called the Peter principle. He observed that employees tended to rise to “a level of respective incompetence” as a result of their successes in prior roles which led to their promotion into new roles where they would often be less effective. When I was becoming more of a leader, I felt this way constantly, even telling others that I had been “forcibly promoted”. To succeed in my new role, I had to be deliberate in my efforts to acquire the new skills I needed to be both a manager and a leader.
Adoption of AI assistants threaten to disrupt journeys like mine, circumventing the years I spent in search of my own obsolescence where I built the foundation I still stand on today. They provide the automation, but not the architecture. It makes employees immediately more responsible without affording them the time to learn what having that responsibility really means. To a degree, giving an employee an AI assistant is like promoting them to a mini-manager. Similar to managing a junior role, AI assistants require guidance via the provision of abundant context and what they produce requires review. If we shortcut the career pathways of junior developers and make them mini-managers, we should consider what their foundations will be built out of.