How can I get my programs to be used where I work?

Question

I mostly work alone as a programmer in a small department, within an organization of about 500 people. I have been creating web-based applications for the internal network, mainly to replace old desktop applications. I have mostly been choosing what to work on myself and accomplishing it. I am told that the work I do is good.

The issue is that the results do not get reviewed and used by the organization. I move from one project to the next, and things largely sit unused. It is a small department, and new software is not a high priority compared to other things going on, but what I have created would be useful, if it was released.

How can I get the web applications I create to be used? Other options than "leave" or "nag your Manager", please?

(later) I see that this question "needs more focus". I was surprised at the wind of reaction against using newer tech. I can't 'out' my organization, so have been vague. But the fact is, the rug is going to get pulled very soon and we will have all new PCs, OS and browser, and all production work will shift to a browser-based system. I have been urging that we begin testing.

I don't really see this as self-serving on my part. My limited contribution was to move existing processes to the org's intrAnet so that some progress could be made.

I was feeling stumped, and your many considered answers have helped me. It is really a question about social / political movement rather than technology. Thus I asked here rather than on a more tech-oriented forum.

Answer 1

This might be hard right now (because pandemic) but this was another thing that worked for us when adding new useful-but-not-mandatory applications:

Arrange to shadow your users while they use your application. Aka form a personal connection with your users. Aka if your users won't go the application then you must bring the application to your users. Other people have mentioned things along these lines but I have a little bit of a different take on it.

For us a lot of the problems were getting people over the hump of even starting to use the new stuff. Most of the time switching to a new application got put into the "later" bin which became the "never" bin. (Once our users did start using the new stuff and got past the initial friction of things being different they did admit that they overall liked the new stuff better. I guess it helps that the old stuff was objectively terrible.)

One way we were able to get individuals over that hump was to schedule time for them to use the new stuff. You can do training sessions and that's OK, but it was much more effective to have it being used in real situations. And having it used in real situations with us there was the best.

1. It keeps your users on task with using the new stuff because you're there watching, they won't just switch back to the old stuff if they have a hiccup.
2. Their supervisors give them a little leeway for working slower because it's a clearly scheduled training/shadowing, so the users don't have to worry if there's overhead time spent learning.
3. If they don't understand something you can help explain it.
4. You get to see what parts are difficult to understand, what features are missing, you will often get very honest feedback.
5. You will come up with the best new features from working directly with the users. (Our management keeps trying to force all user-developer interaction to channel through business analysts which is the dumbest thing ever. All of our best improvements have come from mixed groups of developers, users, and business analysts working together.)
6. You can form a personal connection with your users. This is actually huge. They will feel much more comfortable reporting problems with the new stuff in the future if they know you. And any time you can reconnect with them (not nagging) it will be a subtle nudge to remember and use the new stuff. Especially if you can send e-mails like, "I fixed problem X that you reported, can you tell me if it's working now?" or, "I implemented feature Y that you requested, can you tell me if that does everything you wanted?". They will be much more likely to respond to personal request than to mass e-mails.

One problem we had was this was that we have more users (tens of thousands) and our users are geographically spread out so we could only do this personal interaction with a handful of users in a handful of locations. But in the locations where we did this it expanded beyond the users that we directly interacted with, as the users we trained started teaching the people around them--not in a planned manner, but just by being visibly faster using the new stuff. We also were able to do most of our work with users who were leaders in their group, like floor/shift supervisors who worked hands on, the kind of people that everyone else went to when they had questions or needed help, so those people had the biggest impact on converting other users.

Answer 2

How can I get the web apps I create to be used? Other options than "leave" or "nag your Manager", please?

You are looking at the problem the wrong way. Don't build something, then try to force people to use it. Instead, figure out what they need, then deliver it.

Talk with the people who you expect to be using what you develop. You can do that individually or in a group meeting.

Ask them what they need and would actually use. Get their commitment to work with you, try a pre-production version of the system, provide feedback, etc. Then build that.

Once you start delivering applications that people want or need, they will likely make it a priority to start using it.

Answer 3

We all have projects that get shelved or turn out not to be needed (because business plans do change over time), but this shouldn't happen all of the time.

Before you start work on a new project, understand what the business needs are and why the business needs this new piece of software. If you don't think that the new project significantly improves how the company works or earns revenue, then ask questions.

Typically, developers work with business analysts or users within the business to further understand needs. Do that. If the users aren't engaged, or don't see the point of the proposed software, then report back.

If you're told to carry on anyway, then just carry on as before - at least you've said your piece.

Answer 4

I know you asked for answers other than "leave", but the real answer here is, in fact, "leave". Here's what I see happening:

• You are working on projects that nobody cares about
• You are working in a position that has no oversight and nobody cares to give oversight
• You are being given generic "is good" feedback from others without that feedback actually meaning anything in terms of actionability

It sounds to me like you've been sidelined; you've been prevented, for whatever reason, from working on projects that are actually of value to the company, and for whatever reason you haven't been fired, probably mostly because you've been forgotten about by people who care, and your manager (whoever they are) don't care enough to fire you. However, if you are not working on anything important, that means:

• You have lost the trust of everyone of relevance in your company in terms of their faith in you to work on anything important
• You are first on the chopping block to be fired when layoffs come around, because you are providing literally zero value to the company

Here's the thing: Let's say, hypothetically, you were to be fired. Now you have to go job hunting. Your interviewer says to you, "How much of an impact did you make at your previous company?" What's your answer? "I made a bunch of really good webapps that nobody used" is not a particularly flattering answer, and you don't want to have too much of your career history be that.

Start searching for a new job now and get out of this company ASAP before they fire you; leave on your own terms, not on theirs.

Answer 5

Your first priority is to find out why your work isn't being used.

Things that come to mind:

Your software may be solving the problems.
Find out what people actually need. Talk to them, alone or in groups. Alone is better initially to get unbiased feedback (but you yourself may be a source of bias).

Your software may be underexplained.
If it's complicated to use, people will want to use it but never quite find the time to get the complications under control

It may be hard to get the relevant information out of you.
If you fail to understand why somebody is having a problem with your software, or if you perceive your user as, ah, mentally challenged, or there's some similar problem:
Whatever the education problem: you can't change your user base, so you have to train talking to people who're not at your level.
Usually, they aren't dumb, they just aren't trained in the things that you take for granted. Though dumb users do exist - but if you want to talk to them, you still have to find a way to reach them.
And you have to completely switch off the "they are dumb" thinking: Your nonverbal communicaton will betray that thinking. Even if you know it's unhelpful. You can try switching it off just for the meetings, but very few people can fully suppress their true feelings, usually enough will leak that the other side will at least notice something is odd.
I know it is really to change one's beliefs about one's peers. Usually it's easier to find something that you can respect about your users: Talk to them, listen to their situation, try to understand what their motives are and what's making them tick like they do; usually, there's something of worth to find.

It may be hard to get the relevant information out of you (type 2).
You might have difficulties explaining yourself, resp. your software.
The only thing that helps here is gathering experience, accepting failure as a way to identify what to improve.

You may have been sidelined.
Not necessarily by any fault of your own.
E.g. sometimes companies hire people just because they know they need them six months later. Sometimes that six-months-later timeline gets extended.
The risk for you is if the company did so because of some management mistake, and as soon as they find out, you'll get fired, and the responsible person has a big incentive to find some reason to blame you. (You should ignore the blaming, it's about the person's standing in the company, not about you - you won't get a glowing reference, but your next employer will know that such things can and do happen, so even a bad reference isn't necessarily a dealbreaker.)
You can try to find out if that's the case - try to find somebody who's interested enough in your department to know what happens but disinterested in stakes anybody might be having.

The nasty variant of sidelining is that somebody is setting you up as a scapegoat.
Tricky situation to handle, tricky to detect in advance.
The best approach I know about that is to not assume anything but be prepared for everything. It's not a good approach because it will color your day-to-day interaction with your colleagues (and this can become a self-fulfilling prophecy). Your options in this scenario depend heavily on interpersonal communication skills.

Answer 6

We had a similar problem to this where we wanted people to start using a new application that was being rolled out incrementally but we couldn't turn off the old application.

What someone (not me, but I wish) came up with was to add a new feature that people really wanted/needed to use...only in the new application. So they were free to use the old application as much as they wanted, but to do X they had to switch to the new application. Once they had the new application up and opened to whatever they were doing it was easier to just keep using it for a while. Over time they got used to the new application and preferred it to the old one.

So you need to find someone who wants something new that doesn't exist in the old applications and implement it for them in the replacement. It doesn't have to be entirely new as long as it can't be done correctly in the old application, in our case it was something that had been a simple checkbox in the old application that was replaced with a much more detailed form in the new application.

If you can find a manager that wants something new to be mandatory then even better, in our case the new feature was mandatory for about a quarter of workflows in that application so our users were exposed to it a lot and since it was imposed by above in terms of being mandatory the supervisors were highly motivated to make sure that it was done. If you can't find anything mandatory then something new and useful is still good, but you may have to keep gently reminding the users of the idea that they could be doing new and useful thing in the new application.

Answer 7

Keep doing your job

I think it is too easy for people to assume more than exists in some of the other answers. As I read your question, I simply understood you to have been given a task and have simply made an improved toolset for that task.

You have gone above and beyond when you were not asked to. This is a common temptation that we all experience.

My first IT job was to frob someone else's program to transform payroll data to state new hire reporting electronic submission formats. His program was so completely broken that it would never work.

So I wrote a test program that actually worked, and would only need a little time to polish, then presented it to my boss.

He didn't care. See, I had not been asked to do that. Ultimately the company fired the other programmer (because all his stuff was garbage) and continued using their existing processes. It wasn't in their interest, for reasons unknown to me and totally irrelevant to me, to continue with it.

I had another job typing up strictly repetative reports as a temporary assignment. To reduce carpal tunnel I wrote a small program where I just typed in variable strings of initialisms that would be parsed and formatted to perfection.

People were impressed with my output -- but no one cared about how it happened. When I left that program stopped mattering.

Ultimately, you can show it off (be a salesman and show how it will be easy and useful to your team) but don't be upset if your unasked-for work is not appreciated.

Just make sure not to trade off more time messing with it than it is worth to produce the required results, otherwise the company may be upset that you are working on your own stuff on company time, which will not end well for you.