Communicating value of position outside of “new project” cycle to management [duplicate]

Question

This question already has an answer here:

• How to gain visibility when overloaded with less important tasks? 4 answers

I work in an environment that has mainly been "new project" based since I started. There seemed to be an endless well of opportunities to create new software to solve problems and this situation has sustained for the past 5 years where I now have about 10 applications I'm responsible for, written solely by me.

However I fear the well is drying up, as new projects are becoming more infrequent. Of course this was inevitable that after solving so many problems with software, there weren't many problems left to solve. And this creates a new problem, which stems from my inability to communicate other aspects of my value aside from solving new business needs with new software which I, and management ,have grown accustomed to.

Of course everything I've created needs attention, code needs to be refactored, things can be improved, etc. These are project in and of themselves. But knowing the mindset of upper management, I'm afraid not being attached to new opportunities could result in a devaluation of my position. However these fears may be ungrounded, but I need to discover if they're real.

How best to communicate a software engineers value while they're not in the constant "new project" cycle anymore?

Answer 1

You're right that management may soon find some developers redundant as new projects dry up. And thus you need to educate them as to what the "next step" in the evolution of these projects might be.

Write a report on what you envision the challenges of the software development team will be going forward. Keep in mind that you're addresing it to a (I'm guessing) non-technical crowd.

Do's:

• Describe how modifying certain projects can add value to the company. For example, porting some applications to be web based, and thus accessible on mobile devices.

• Could the data your current applications collect be used to generate useful reports for the management team? Developing those and providing interested parties with a portal to view them even from home might be desirable.

• Speak to the users of various applications. Get a list of features which they would like implemented. What more could you automate / include in your program? Write a list of improvements for each application, and the benefits of implementing them.

Examples: user notifications of critical information to mobile devices. Web-available reports which can be saved as pdf's. Automatically refreshing information on certain pages in order to avoid misunderstandings. Better security. Mobile versions of certain apps. Portals for customers to view certain account pertinent info. The list goes on.

Very specific example: a senior dev at my old company developed an internal wiki so that each department could store certain internal knowledge and procedures. It improved inter-departmental communication and information flow. He saved uploaded screenshots/pictures as encoded strings, which allowed him to store them directly to the database, and save a ton of HDD space. It went over well with management that less space would be used, and thus server upgrade costs would be reduced.

• Are these systems fully integrated with one another? Is there anything you could do to improve the availability of information from one application to another? What about making some systems faster, or more responsive?

• In some situations you may point out that new technologies have been released in the past years which might allow your certain critical applications to perform even better. Do Not use justifications such as improving the code for the sake of easier to read or maintain libraries - see below.

Don't's:

• Don't go into technical details such as that you used ADO in your code, but implementing an Entity Framework approach would be oh, so much better because it would improve code readability. Management only care if the program works. Changes which do not bring tangible improvements won't interest them.

• DO NOT attract attention to the fact that you're writing this report because you feel your job is threatened. Don't write something like:

"Because new project opportunities have been drying up I've come up with a list of things to keep us busy!" <- Career Suicide

Instead, come across as eager:

"Over the years our team has developed many useful, and even critical applications which have brought value to their end users, and the company. While very proud of my/our work, I see several ways in which some of these systems could be further improved so that they will increase in value to our organization, and improve the productivity of their users. <- Great Employee

• Keep in mind that refactoring code, while very useful and even critical to a developer, does not necessarily matter to the end user. Especially an end user who pays your salary. They want bang for their buck.

Good Luck.