Engineered Eloquence

Planned Obsolescence, A Leadership Strategy

The following was written in preparation for a talk given at the 2025 IT Professionals Conference on May 29, 2025. Some information has been changed or updated to accommodate a text-only blog format.

I have been an IT Manager with the Libraries on campus for just over 11 years. I lead a technology services and support unit within the Libraries called the End User Computing Team, which is made up of four wonderful permanent staff and ~65 highly capable student staff. We manage services across four service points and support technologies in every library space across campus.

And today I am here to tell you that I am taking a vacation.

For context, this vacation has been almost 6 years in the making. It started when I submitted the paperwork for my Italian citizenship in 2019. I have three young children and we love to travel, so we had trips planned for Denver, Puerto Rico, and then finally Italy. The final destination allowing our kids to go on their first international trip. You may know where this is going.

Our Denver trip was planned and paid for, wheels up on March 28, 2020. As you might expect, none of those planned trips happened and our trip kept getting pushed back for other things.

But we are finally taking the trip to Italy and because of how long it has taken for us to finally get it on the books, it is going to be five weeks long.

Jay! But what does this have to do with Planned Obsolescence, leadership, or the IT Professionals Conference?

Today, I plan to introduce you to the connection I see between the concept of Planned or Perceived Obsolescence, the leadership strategy that bore out of my own personal desire for variety in my work, and the practical application of these ideas to better serve those around you as you or they move through life's big (and not-so-big) moments.

Planned Obsolescence

So let's make sure that we have a shared understanding of the concept of Planned Obsolescence. There are plenty of variations on this, but I am specifically thinking about this in terms of the modern conversations around technologies that have perceived degradation timelines regardless of the reality.

Our chat icebreaker question on zoom helped get the creative juices flowing and I appreciated the responses there.

What are some things that come to mind when you think “planned obsolescence?” Can planned obsolescence be good?

What is the first device that you think of when I say the words Planned Obsolescence? Anyone in the room that wasn’t involved in the chat can feel free to shout out their first thought.

I am going to assume that at least some of you thought of this device or something similar. (iPhones)

You might have even thought about this screen. (iPhone comparison chart on Apple.com) Year-over-year incremental changes a for-profit company wants us to care about.

Everyone here works in technology or in an adjacent field, so I am also going to assume that we are all in agreement that generally Planned Obsolescence (in this context) isn't strictly real. Technology ages, technology needs change and older pieces don't keep up, modern software moves beyond the capabilities of old hardware; these are natural things that come with the pace of technology these days.

The perception that they are done intentionally by capitalistic corporations ignores the fact that there are naturally occurring changes in the industry and the world at large that impact a technology's ability to stay fresh. (Recent case in point is AI, but I’ll get to that later)

Also note that the iPhone is now almost two decades old. And the capabilities of these devices were unfathomable to the people who worked on the first one.

Any thoughts on an item whose obsolescence is in fact planned by design? Few people think of smoke detectors when I say Planned Obsolescence.

And yet, smoke detectors use systems and components that inherently become less effective over time, a timeline of give or take ten years. But no one claims that this is a capitalistic ploy to get everyone to buy new or more smoke detectors. Technically, if true, that would be a ploy of the legislature through building codes and policies focused on public safety. Another great example of this is car seats.

Point being, it is natural that things change, through the passage of time, adjustments based on current context, or the cascading effects of a complete fluke of science.

Leadership

Planned Obsolescence as a leadership methodology started for me when I was working at the Art Institute of Indianapolis in the early 2010s; I was working in desktop support and had taken the job over from technologists that were grinding away at problems each day, punching the clock, but as an Engineer in background, I wasn't interested in solving the same problems day in and day out.

I was interested in finding ways to solve those problems one time and either have it stay that way or automating the solution or delegating it to student staff such that I would only have to worry about escalations (which would indicate a new problem or variation that my solution didn't account for).

At the time, I jokingly referred to it as "making myself obsolete."

Now, I will admit, that this initially comes off as inherently selfish. And initially, I would say that the intent was. I didn't want to have to do the same work over and over again; instead, I wanted to find efficiencies, automate, and move onto the next interesting query. In fact, you probably heard what just came out of my mouth: "I, I, I"

It was all about me, but it allowed me to change the dynamic in that work place to give me some space to be more strategic in my thinking, get my graduate degree, and empower those around me to depend on me more as a partner and escalation point instead of the sole provider.

Over time, I came to realize that this was a way to think about the work for the betterment of everyone, to focus on building better teams, better systems, and empowering people with growth opportunities, all while allowing myself to work on solving bigger, more strategic problems because I had "made myself obsolete" in solving the previous ones.

In 2014, I came to UW-Madison. A whole new set of problems to solve, a whole different group of people to support, and a whole new set of circumstances to navigate, but the goal remained the same: solve problems, make myself "obsolete" while building up other people to do good work, move onto the next problem, lather, rinse, repeat.

What about job security?

But in addition to this being potentially selfish, there’s another problem with this framing.

The methodology may come across as being counter to the expectations of work as we know it:

Longevity and loyalty within a workplace comes with job security. You know and do more, have more institutional knowledge, and hoarding all of it will lead to opportunities and advancement.

Why would I want to make it seem as though I am unnecessary? Especially in our current context of cost cutting and consolidation?!

Naturally, over the course of the last eleven years, I have had the opportunity to see people retire, move onto other roles, go on vacation, start a family, participate in hobbies that take them away from work. These are natural things that should be normal, encouraged, celebrated, and planned for.

Thinking about all of this through the lens of obsolescence opens up the possibility of engaging with the work at more strategically valuable levels, using that institutional knowledge and understanding and leading with it, instead of holding it and dealing with the burdens alone only to have things change out from under you eventually anyway.

Some reasons for a person’s departure are more permanent than others, but at each turn, it should be natural for us to think through what it looks like to continue the work even if the person who started it (or the fifth person in line to support it) isn't around: me or my supervisor, my reports or my student staff.

Admittedly, I think about this as a leader and manager, planning for the natural churn of student staff and early career professionals, but I believe that everyone can use this idea as a lens through which to view their work.

The Components

So as I was working through the practical components of this talk, and what I wanted all of you to take away from this, I started thinking about pithy acronyms that could help get the point across. I came up with a simple list of 16 components that delightfully spelled "ADDICTIVE PEPPERS", but that seemed memorable only as a joke and it would have taken too long to get through them all, so instead my educator wife said stick to what's important: the components themselves.

Inform and Enlighten through Documentation

I thought I would start with documentation because it is the most straightforward of all the elements here. Documentation should be a part of everyone's work and a part of every leaders' toolkit. It is much easier to approach problems as they arise with historical context, common frameworks for problem solving, and a coordinated knowledge management process. There’s also a bit of set it and forget it involved. For stable systems and processes, I’m able to write the documentation down once and then use it to accomplish the process or to train others to do it.

My team uses the campus knowledgebase for all our documentation needs and attempts to ensure that we create connections to better facilitate the problem solving process, but whatever tool you use, make sure that it is stable, logically organized, and shared amongst the team.

Documentation allows me to not only record procedural information for future reference, but enables the team to stay informed on past context and recent developments, while creating informed decision-making methodologies, especially as more information becomes available about a given problem.

Additionally, my understanding of these ideas no longer belongs to me and as an approach changes to meet modern needs, the documentation can become a shared effort. I may still have to teach a procedure or provide specific historical context for why a policy or procedure is the way it is, but I can also focus my own efforts on more strategic parts of the question without discounting the task or need at hand. And I can also still complete the task myself, if necessary.

Note that documentation is not always straightforward; there may be aspects to your work that aren’t easy to put into words, but that doesn’t mean you shouldn’t try.

Share the Burdens and Rewards through Collaboration

Collaboration is all about how you can share the burden (and relatedly the reward) of the work with others in a mutually beneficial way. The InfoLabs program and Technology Circulation, Active Learning Classrooms with the Center for Teaching, Learning, and Mentoring (CTLM), the formation of DesignLab with the CommArts department; the Libraries have a long history of this approach through partnerships to achieve common goals, so why not include this as a leader in your daily work.

My team is able to approach partnerships internally due to the common reference point of our external partnerships that we are actively engaging in every day. No single person on my team is the sole provider for a service nor are they expected to be the only person who understands a specific process (because it is documented and I encourage them to use their vacation time).

As mentioned before, we are a small team of permanent staff who have a broad range of responsibilities, so each time I had to fill a role in our structure I attempted to maximize each role’s flexibility and modeled the behavior of shared ownership. Real world examples of this shared ownership model include student supervision, ticket management, documentation, and public services, among others.

Although the responsibility for planning and prioritizing the work within a system may rest in one person's hands, the organization and implementation of the work falls to multiple people, if not everyone on the team. We have also created a culture wherein we all see what is “owned” by a single person and seek to understand more about it through cross-training and open dialogue.

A few caveats with what I just described:

Organize and Prioritize through Delegation

As a leader, delegation should always be a part of the toolkit. Delegation comes in different forms and can be approached in multiple ways. My current approach to delegation comes from my eleven years in my role and my time with MOR and Associates for the IT Leadership Program (ITLP).

During my tenure, I have amassed a lengthy list of responsibilities organically, as you do. Thankfully, most of the things in my portfolio make sense to be there, which I know is not always common. But as I have taken on more, I have needed to either deprioritize or stop doing tasks along the way; that act has not always been approached intentionally.

The ITLP helped me to consistently make these moves with intention and to focus on those things that could be democratized. I refer to it now as moving something “down stack”. How can I free space to think more strategically while empowering those in my portfolio to learn something new, develop further with a stretch goal, take ownership of an important task the team needs to prioritize, and make progress toward their own career goals in the process?

Delegation is easy then, right?! But one aspect of delegation that I became well acquainted with was the grief of giving something up that has become a part of your work identity. Going back to job security, the idea that something I have staked my claim on—that I have built into my personal historical context—can be given up may seem anathema. So delegation comes with loss and is a process, but it also is an exercise in trust and team building.

Once those around you know how you operate in this regard, the process can be normalized. We take something on, we document it, we learn more about it and document it some more, the larger context changes, deprioritization happens, we pass it along to the next person who can prioritize it again (now with a fresh perspective and the desire to take it to the next stage of its evolution).

Think about delegation by asking a few questions of yourself:

Standardize and Automate for Efficiency

Efficiency is the hardest one to discuss for a number of reasons, not least of which it is mostly a subjective trait when working in technology support.

In an ideal situation, a team is running efficiently, but people are messy and this part of the lens may highlight things that aren't comfortable, such as when the team isn't efficient or effective in the work and failures occur.

However, it is relatively easy to use efficiency more objectively through questioning our intentions when making decisions: "it has always been done this way" or "this is so-and-so's responsibility" become shorthand for the sense that a given task can in fact be done differently—potentially even more effectively—if not for ideological disagreements or structural inadequacies within the team.

Also, a leader can approach any situation with the curiosity needed to clarify an intent:

The most straightforward example of this in my team is the approach to patron-facing computing within the library context. We have been able to work closely with DoIT's System, Endpoint, and Application Management (SEAM) team, along with our connection to the InfoLabs program, to create common approaches on both the front and backend.

The computing and printing experiences for patrons are the same regardless of the ownership of a piece of technology and the imaging and management approaches enable more efficient use of resources within those systems.

Empower

One of the connective threads that I see through each component is that of empowerment. Empowerment comes from a place in which you want to see the people around you succeed by taking ownership of a task, project, or service. And especially as a structural leader of a team, my aim should be to assist in the long-term development of those around me.

By taking the four components and creating a personal practice around them, we can help others build their experience and work toward new levels of expertise, confidence, and independence.

But even if you don't lead a team in the traditional sense, a rising tide lifts all ships. We have an opportunity to empower those around us for the betterment of all.

If you take nothing else from this talk today, take these components as a starting point for your journey of planning for your personal obsolescence (even if it's temporary).

What about AI?

As you might expect given the timeline I mentioned earlier, I have not factored in the role of AI into this methodology, but I would be remiss not to mention it.

I will note that as a library employee and information professional, I still see AI as a tool, a starting point for problem solving and not as a solution, so the methodology and its parts don’t change, but perhaps gain additional clarity. It’s a lot easier to explain automating a process in a general context if your AI assistant can spit out working code or salient suggestions to set you on the road to success. Documentation is an important part of any process, but AI enables quick work of templatizing documentation layouts or summarizing the most important points for a TL;DR section.

Lastly, though, AI solidifies my point about planned or perceived obsolescence because it may make it seem that a company like Apple is purposefully obsoleting old devices with the introduction of AI, but they also were found flat-footed in their support of it.

Conclusion

In the end, this is not something particularly novel; leaders in administrative or managerial positions should be succession planning and preparing the people around them for the day when they leave. What this methodology does is create a lens for those leaders anywhere in the organizational chart at any time in their leadership journey to approach prioritizing these components in their work, so that they can rest assured that the work will continue on regardless of their presence or active stewardship.

We need to be able to let go of the notion that sharing a given burden will make us less secure in our jobs; let go of the possibility that giving something up to empower someone else will somehow make us weaker; and let go of that thing holding us back from taking time off for our vacations or hobbies.

If you take small steps to make yourself a bit obsolete, it will benefit you in the short term and those around you in the long term.

A Personal Story

As a final aside, I have another story related to planned obsolescence that I thought I would share. As noted at the beginning, I am a father of three. I have noted over the twelve years of having that role that it jives with this notion as well.

One of my goals as a parent is to be somewhat obsolete to my children at some point. I know that ideally they will still want me involved when they are adults, but along the way, my purpose is to teach and guide them to need me less and less as they age.

I had to push them along in a stroller or carry them on hikes when they were young. By teaching them to walk, run, bike, unicycle (no joke), and eventually drive a car, I am subsequently making myself obsolete, but again, very few people would balk at that framing.

My point is that there are areas in life and society where we naturally take this stance of planning for a time when we are no longer going to be around and lifting those around us up to prepare for that inevitability. I wanted to share this perspective because as I have grown older, I have noted that this is not inherently a bad way to think about such things, no matter the context.

Work should be a part of life, not life in itself. Thanks again for listening to my stories and I hope this will be helpful as you walk your own path in your leadership journey.