29

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.

1
  • 2
    Comments are not for extended discussion; this conversation has been moved to chat. – Neo Dec 19 '20 at 15:55
6

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.

1
  • 1
    This is a very well written answer, with lots of great suggestions. I'll make some notes for when I can get back to the office and start connecting with people again. In some cases, the things I created were significantly faster than the desktop programs they are intended to replace. This is a big plus for users here. Maybe 5 seconds versus 30 seconds for a data inquiry, or one minute versus 4 minutes for a long running process. So there is a natural 'sell'. – user123220 Dec 19 '20 at 1:21
129

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.

16
  • 69
    "Maybe old desktop programs are good enough?" <-- THIS. Did you talk to any users to find out what their problems were? – Philip Kendall Dec 17 '20 at 19:13
  • 24
    @AnonymousFroward It's hilarious to me that the company is paying you to work on software without clarifying this first. Something is deeply wrong in how your position is set up, and I would strongly encourage you to make it a priority to fix this. Because if the company discovers that most of the stuff you write is not only not used, but potentially not even necessary, you will find yourself on a redundancy list faster than you can say "but nobody told me to do something different". – xLeitix Dec 18 '20 at 11:51
  • 6
    Experienced people have learnt the complexity and often get annoyed when options are removed. Have you asked them what they want, Note that you comments so for would incline me as a user to tell you to go away and stop annoying me. An expert is an expert because they know what they are doing. Also it is easier to any highlighting on a desktop app than in a web page, the programmer has more options. Desktop programs are usually faster as they use local and more powerful controls – mmmmmm Dec 18 '20 at 17:53
  • 4
    +1, though I think an important related factor is buy-in. Even if the OP is already building exactly what his/her customers would want, having these conversations with them -- i.e., listening to them -- will increase their sense of involvement, and hence their willingness to try out the results. – ruakh Dec 18 '20 at 21:30
  • 3
    @Anonymous Froward: "I think that some of the desktop programs are a bit 'overdesigned'..." But you forget, YOU AREN'T THE ONE USING THEM. All too often, I've seen some smart-ass designer produce crap that they like, which I find less usable that what it replaced. (Case in point, the stupid "hamburger menu" that has taken over all too many apps.) – jamesqf Dec 19 '20 at 2:04
22

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.

8
  • Thanks for the thoughts. As we know, software gets old, and eventually it takes more effort to maintain. I was mostly trying to do 2 things: use an updated programming method, and move things from desktop to browser. These are not glamorous objectives though, and people might not see the need. Until... someday, when this really old thing in some obscure language needs work. The programming method I am using now is already a decade behind, but I thought it would be more understandable and more widely known than the newest methods. – user123220 Dec 18 '20 at 17:15
  • I'm still maintaining a Classic ASP application that's almost 20 years old. It's a lot easier to maintain it than create a new, modern website. – Snow Dec 18 '20 at 17:18
  • 1
    Perhaps this is the crux of the issue. I can usually build something that is "better, stronger, faster" than what we have without a lot of effort. So then it is a judgment call whether the improvement warrants any attention. I've been slowly building a 'system' with features that make it much simpler to add more than to start from scratch. And we end up with a uniform appearance that is easier to change and easier for people to grasp than separate ad hoc programs. I'm not sure if these advantages are apparent to decision-makers at the moment. – user123220 Dec 18 '20 at 17:38
  • 2
    Computer software are notorious for being made to run MUCH longer than expected. This is why the Y2K problem even happened, and will continue to happen. You have to be solving business problems and not technical problems (just for the sake of it). Translate technical problems into measurable dollars, and then they can wrap their heads around it (e.g.: Old system costs 100 times more money to add a button than new system). – Nelson Dec 19 '20 at 7:27
  • 1
    @Nelson That argument works for your boss. The more effective argument for users is, we're not adding your requested feature or bugfix to the old system --- IFF your boss will back you up, of course! – employee-X Dec 19 '20 at 7:45
15

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.

12
  • 13
    I think there is validity in this answer...though perhaps the solution should be not to just leave, but attempt to find out why the OP has been side lined/forgotten, try to change that, then follow the rest of this advice...an honest attempt to change the situation before leaving might be more helpful – morbo Dec 17 '20 at 16:42
  • @morbo Speaking for first-hand personal experience, once you're sidelined, especially for as long as OP seems to have been (he says he's built multiple of these apps nobody uses so I'm guessing it's been a while), it's so unlikely to get un-sidelined that it's hardly even worth it. – Ertai87 Dec 17 '20 at 16:54
  • 2
    I don't think it is personal. Perhaps it simply doesn't matter if we use web apps or desktop programs: it has no effect on the work that is done. – user123220 Dec 17 '20 at 18:59
  • 12
    So, how would one get themselves into a "sidelined" position like this? /Asking for a friend/ – psaxton Dec 18 '20 at 4:11
  • 2
    Note that there is very important distinction between customers and consumers of software. OP concerned that they tools don't have consumers (aka no one using those tools), but I don't hear that there are no customers who pay in one way or another for that development. It is very possible that someone in the company think that it is brilliant idea to have those tools and OP is really highly valued by everyone in top levels of the company... – Alexei Levenkov Dec 18 '20 at 4:31
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.

4
  • Thank you. In many cases the web version is similar or simpler than the desktop version, so I don't think people have trouble understanding. The biggest blocker seems to be getting the new versions to be reviewed and accepted. That depends on the overall priorities of the department and a few other people. – user123220 Dec 18 '20 at 16:57
  • @AnonymousFroward, if the people in charge aren't reviewing or accepting your work, start bugging them to make it a priority. It may feel like you are becoming a bother, but sometimes people just need some nudging to actually schedule things to be worked on, and sometimes you are a bother. The thing about you being a "bother" is that you are being a professional bother, so you can go through channels to talk to their boss and see how to get things done anyway, even if you don't make friends along the way, but this is work, not the playground. – computercarguy Dec 18 '20 at 23:03
  • 1
    Also, remind people, especially managers, your software saves time and money. They don't care about languages or tech, they want their people to be faster, more efficient, and make fewer mistakes. Show them how your software does that and they'll start taking notice, even if it's grudgingly. And make sure they know you are open for bug reports. They may be reluctant to report problems if you don't take feedback well, and that might also be why you don't hear anything, even if it's only a perception and not reality. – computercarguy Dec 18 '20 at 23:06
  • 1
    @computercarguy Good advice, I will try to interact more with people soon. It was tough in a year where I brought my plants and even my desk phone home with me. (The phone just plugs right in to my home router, it is so strange!) I'll look for opportunities to 'bother' people in a constructive way. – user123220 Dec 19 '20 at 1:17
4

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.

2
  • This is a good strategy, nice suggestion. The overall workflow is currently mostly desktop and terminal, but will switch mostly to web based soon, so then there will be more perceived value in the web versions I have created of existing desktop programs. It will be great to stop having to manage desktop software. Telework is easier when web-based also. – user123220 Dec 18 '20 at 17:01
  • 3
    @AnonymousFroward Related: The areas that were adjacent to the new-version-only thing definitely had more of the bugs ironed out by the time the old version was finally shut off, but we did find out that a lot of people who had run into problems with the new version didn't report them, just switched back to the old version any time they had a slight problem. So the final transition was still a bit rocky--even after incremental development and roll out over SIX YEARS. – user3067860 Dec 18 '20 at 17:48
0

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.

1
  • These are helpful ideas. Most of the times I created something, I stopped with a demonstration version and showed people. I was hoping for interest. Some projects I finished and urged on people anyway, and others I came back to later to make them fully usable. At this point, everyone has other priorities on their minds, but soon perhaps web tools will seem more useful, when we switch to browser-based software for main production work. – user123220 Dec 18 '20 at 17:07

You must log in to answer this question.