Motivating Maintenance Programmers

Interesting conversation today with one of my application managers. As we move into the new year, we’re doing some “spring cleaning” of the older projects in our PMO. Two from last summer had languished – efforts to develop simple web front ends for order inquiry and dealer information – and I asked my lead web developer to audit them (make sure we’ve got source code under version control, check out the tech architecture for the supporting database, etc.) before “closing” – putting them on hold until later.

The application manager took some exception; they had been involved in the design and execution of the project, and were surprised when I asked someone else to close out the project. My intentions were good, as the app manager is currently swamped with maintenance programming, simple query requests, & operational support, and did not have time to deal with the administrivia of cleaning up the project. At the same time, this person is continually proposing new projects and initiatives on their current platform, seemingly determined to maintain the viability and long life of the underlying application. When, exactly, are we supposed to do “new” work on other platforms?

It is possible to provide a “path to the future” for so-called “legacy” platforms and application support; success, however, depends on deliberate planning as well as the open minds of the maintenance programmers themselves.

It’s the Developer’s Responsibility / Task / Duty

Actually, this zen is more along the lines of existentialism and keeping the open mind – life is what you make it, etc.

If you feel like management isn’t moving fast enough, why wait? You have a lot more control than you might think, but one of the biggest mental blocks to get through is the need to Let It Go. You can’t work on the new stuff unless your finished with the old stuff (good quote embedded here). Typical technical mentality is to make yourself irreplaceable – job security. The expectation/desire is that IT management will take you out of your boring maintenance work, and give you something “fun” to work on. Problem is – who will take on the boring stuff?

Heck, why make that the manager’s problem? Why wait around for somebody else to take on the Thankless, Joyless Work. Force the issue by Eliminating the Thankless, Joyless Work. In a very real sense, you need to work towards eliminating your job – and no, I’m not saying this because I like it when staff makes it easy to lay them off. Quite the contrary: the real value of the internal IT group should be based on their knowledge of the business and their ability to translate that to technology – any technology, not COBOL or RPG or BASIC.

It’s the Manager’s Responsibility / Task / Duty

The “deliberate planning” approach – there are many ways to use organization and process to enable the “path to the future”.

One specific example from our group – we manage all support / programming requests in our PMO, and aggressively review and prioritize the requests to make sure we’re only working on the critical stuff. Programming is not always the answer – just because you can do something doesn’t mean you should. We stress simplification, sticking to standard product and process in our big ERPs, and justifying all programming requests with a clear business case. No, it doesn’t prevent all the questionable requests from getting through, but it helps.

Another specific example is the use of staff augmentation and contractors. The danger with business-sponsored projects is the managers want results as fast as possible, and invariably feel its faster to RAD for the business requirements with consultants who know the technology. The other option, more friendly to the tech aspirations of the internal developers, is to train existing staff in the new technology, and use contractors to backfill the maintenance work.

Caveat: The basic question (easier to train someone the business or the technology) does not always get the same answer. Some new technologies are true conceptual and architectural leaps for developers on different platforms. Still, this is an area where the developer can tip the scales in their favor by proactively, on their own time, get involved with new technology. It’s incredibly easy – this entire site is constructed with technologies that do not exist in our shop.

So, back to my application manager. How did I resolve the concerns?

The key messages were to make sure we kill the backlog and reduce the amount of maintenance work that is currently swamping us. I’m not talking about working 90 hour weeks to deliver every program request – we’re stressing the prioritization approach. In addition, we do pitch the backfill approach for contractors on projects, and stress the business knowledge of our internal staff to the project sponsors involved.

Was I successful? Yes and no – this application manager needs to concentrate on the Let It Go message, to develop the self-confidence that the company appreciates their longevity and their knowledge. It can be tough to coach people on how to think.

This Post Has 0 Comments

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Related Articles

James MacLennan

... is the Managing Partner at Maker Turtle LLC, a digital consultancy focused on creating value in ways that align with your strategy and drive engagement with employees, customers, and stakeholders. He is an active creator, providing thought leadership through on-line & print publications, and public speaking / keynotes.