I create new programs for internal use within my workplace of over 300 people. I largely work alone and pretty much have carte blanche to create or improve anything. My boss and other superiors have been happy with my work so far.

The issue is that in my small department, we don't have a process for testing new work, approving it and putting it in production. Our previous Senior Programmer has left and I am effectively the replacement. In the past, not a lot of new applications were created, but I have been developing new things for years.

I was waiting for my boss to review and accept things, but over time I've just started putting new applications on the production intranet after I tested them. There they sit, because no one knows they exist. I am uncomfortable sending email to "all personnel", but did that recently when someone suggested it.

Do I need to be proactive in pushing things out to everyone at my workplace?

  • 8
    Did your manager give you any expectations regarding these topics? Have you talked with your manager about your current concerns? It could be that doing these things may be totally fine. Or maybe it could depend on criticality of the app. Commented Jan 11 at 7:25
  • 50
    "There they sit, because no one knows they exist.", who's asking for these applications to be created, where do you get your specifications from, how do you determine what to build?
    – Matthew
    Commented Jan 11 at 15:13
  • 33
    If your "applications" are not solving somebody's real problem, then don't put them out. Find someone with a problem and solve that.
    – David R
    Commented Jan 11 at 15:24
  • 7
    Not wanting to sound smart, buuuut: what did your new manager say when you talked to them about this first? Commented Jan 11 at 22:36
  • 8
    @HappyIdiot modernizing, also called "changing things for no reason", isn't really a good thing outside of tech circles Commented Jan 12 at 0:10

8 Answers 8



Should I push my fledglings out of the nest myself?

No. You should find like-minded people who are invested in your applications to help you nurture and support them throughout their entire lifetime :-)

Long Answer

If no-one knows your applications exist, you might want to ask yourself why do they even exist in the first place? :-).

Making a software product successful (even in internal one) isn't just about writing code that works - when you get an idea for a new tool you should maybe have a discussion with the owners of the relevant business area or process it's aimed at improving and find a user champion amongst the target staff base before you spend any time writing it.

You can talk to them about what benefits the application might offer (e.g. improved productivity, new business capabilities, better governance, etc), and they might be able to make suggestions on how to refine or improve it.

Or better yet, solicit ideas from your user base about what applications would provide the most value for time and effort spent writing them - they might even suggest a completely different tool that has more value to them right now. They'll also have the relevant business contacts and subject matter knowledge, and will be able to suggest the best way to connect with the target users and organise training.

In short, instead of flying solo in a vacuum, try to build small informal working groups or project teams for each application who are invested in making it a success. You might still be the only developer on the project, but if you can recruit other stakeholders from your audience you'll possibly find they get visibility and adoption a lot quicker.

You might need to get your boss on-side with this first, but if they see it helps you make tools that are more valuable to the business and raises the profile of their team as a side-effect you should be able to get them on board pretty easily.

Personal experience

A long time ago I was a solo developer embedded in the Marketing Department of an international investment bank, responsible for development of a set of add-ins for the Microsoft Office suite that provided interactive corporate branding and page layout tools for internal documents and client pitch books.

Although I did pretty much all the technical work, that was only a small part of the project - over time we built up a large network of international stakeholders who informally helped us outside their regular duties, including regional desktop support teams to deploy the system and troubleshoot end-user issues, trainers to produce manuals and training sessions (including one presented to all new global starters as part of HR induction), and a team of trusted early-adopting users who did testing and gave feedback on updates before we released them, as well as creatives / brand designers, and product enthusiasts / evangelists at multiple levels of the corporate hierarchy from analysts and secretaries all the way up to endorsement from C-level board members.

It was effectively an informal "shadow" startup (think SkunkWorks) within the main organisation - it was totally a team effort, but we were able to get recognition for our work within the company well beyond our official status and the system ended up being installed as part of the standard build for about 10,000 corporate workstations worldwide as a result and used by hundreds of people every day.

If you compare that to what would have probably happened if I'd just uploaded the add-in to the corporate intranet and sent out an email, you can see that perhaps you shouldn't just "push your fledglings out of the nest yourself" - you should find like-minded people who are invested in your applications to help you nurture and support them throughout their entire lifetime:-).

  • 1
    It makes a lot of sense to involve other interested people, I will see about finding a way to do that. I am not in the same location as my coworkers though, so it is not as easy. I was asked to produce many of these projects but there was a management change. Commented Jan 11 at 21:11
  • 5
    @HappyIdiot I imagine you've had a conversation with your new manager that went along the lines of "The old manager asked me to work on X. It's finished, but he was supposed to review it before I pushed it out. Do you want to review it, do you want me to handle it myself or is the work simply no longer necessary?" Provide options, let them pick, problem solved.
    – Mast
    Commented Jan 12 at 12:11
  • 1
    @Mast this sounds like a good approach. Thanks for the concise formulation. Commented Jan 12 at 15:40

You should be careful of putting things into production if your manager/superiors haven't already approved them, because:

  • a bug/issue could have significant repercussions for you or the business
    • Consider this: a tool you've created starts hogging memory or gets stuck in a loop and crashes the IT infrastructure in your business, your boss gets a call and finds out it was some tool they've never heard of, they find out it was your tool and they hadn't "signed off" on it (either verbally or written), that could cause friction and you could end up being reprimanded in some way
  • your manager could (either randomly, because of ego, stress, bad day, etc.) take issue with the fact they haven't been involved and weren't consulted
    • again that could make it difficult for you at your workplace Of course there's any number of reasons I could put here and I'm not saying these things would necessarily happen, but they're possible outcomes... With these points, the blame would ultimately fall to you if the manager hadn't reviewed or signed off on the tools use - ultimately though, you need a process to protect you/the business at the very least; at the end of the day, if there's a problem you would be able to say "I followed the process, but there was a mistake and that mistake was missed during the process", so the process would take the blame and would then need improving and so on.


I would instead encourage you to consider proposing this process/framework.
You mention that the previous Senior Programmer left, making you the de-facto go-to; proposing the new process would be the sort of initiative that would bode well for you:

  1. Experience in the software development lifecycle, and implementing new process in the workplace would look great on a CV
  2. It would raise your profile within the business by making you look like a proactive member of the business/team
    • this could even boost your chances of being promoted to the Senior Programmer, which in turn would mean that the business would pay you more, and potentially hire someone with less experience for you to train up, which would a
    • You also have some good arguments on your side for increased pay if you have an annual performance review

In the short term

Obviously creating that process would take time, so in the short term I would suggest you discuss with your manager about the tools you've created. Ask them "what they would do" with those tools, they (or you) may suggest sharing the tool with a certain team/group at first (like a Beta test).
If you tell a small group about a tool first, tell them how to use it to get some feedback on it/documentation/training material before announcing the tool to everyone in the company.

Some questions

These are more rhetorical questions you should ask yourself which may help guide your thinking:

  1. Do you have documentation that you could share with people about how to use the tool(s)?
  2. Is there a section on your Intranet that has links to these tools?
  • And would you be able to but an icon next to them to highlight that they're new? (This may get a few people in the business using it)
  1. Does your company do a bulletin email every month/quarter? If so, you could have a section in there talking about some of the tools?
  • In a previous company, I gave a couple of talks at monthly company meetings on internal software tools. I found this was far better than being on the quarterly bulletin because people actually paid attention (rather than skipping the email altogether!)
  • These are all really great suggestions, and the warning about possibly causing problems on the production servers is a good one. Commented Jan 11 at 12:06
  • 2
    As a possible alternative to simply releasing the software, you could instead invite people to "beta test" it and give you feedback. An option to discuss with your manager.
    – mhwombat
    Commented Jan 11 at 21:34
  • 1
    @HappyIdiot thanks, the motivation behind that thought was actually this news story where people using even the most innocuous of all software (emails) brought the IT infrastructure of the UK's NHS to its knees because someone sent an email to 800,000 people (some of whom ended up clicking "Reply All" which only exasperated the problem)
    – Harrison
    Commented Jan 12 at 16:02
  • Yeah, my work email shows how many people will receive if it is a large number, but there is no Are you sure? stop prompt. This is sometimes called "The Law of Unintended Consequences" also known as: Doh! Commented Jan 12 at 16:13

There they sit, because no one knows they exist

... until one day they learn about them, introduce them in their process and suddenly your helpful applications become critical.

You then have possibly half-baked* applications that need to be seriously maintained and then you get zillions of requests for updates, features and whatnot.

Just make sure that you really want to be in that boat

* or not, this is not a criticism - I have plenty of such really neat apps that I would like people to use but then I am doomed because of the above.


Do I need to be proactive in pushing things out to everyone at my workplace?

The obvious answer is to ask your boss if it's okay to release your work into production once you feel that it is ready, or not.

I suspect the answer depends in large part on the applications themselves - what they are intended to do, and what are the ramifications if they fail.

If the applications don't update anything, put just produces non-critical reports, then perhaps an informal process is appropriate. But if failure of the application could cause important business failure or expense, then it might not make sense.

Either way, this is probably a process decision you shouldn't make on your own.


Yes/No depends on what your boss wants.

Speak with management and ask what to do. But please, just be sure they are flawless and are not going to introduce random bugs or problems in the process. You don't even have an environment for rolling out applications and testing them, that is suboptimal.

Give them the options you have, which are :

  • A general email telling people where the software is and how to use it, this will (by my experience) lead to fewer people actually using it, and keep on using it.

  • A small training for each application along with an explanation of how it should be used to reduce time spend doing X or Y, paying special attention to those that will use the application all day, every day. Teach everyone how to report a bug.

  • Yes, training would be most helpful. I'll see if I can get our internal trainers involved. There are several work locations and I can't be at all of them. But the apps are not that complicated, it's just getting people to start using them that is the hurdle. But as we know, people (including me) often have narrow focus and remain unaware of useful features and techniques, especially when the app is mostly peripheral to their main work. Commented Jan 11 at 11:57
  • 1
    @HappyIdiot That's where training will make them interact with it, and lose any "fear" or discomfort there could be as to how It's supposed to work. I work in a medium-sized Software House and that's how we do to our clients, its more of an introduction than a training per se, but the objective is to have the user interact with the app.
    – Or4ng3h4t
    Commented Jan 11 at 11:59

Having once been in that situation myself, I came up with a solution. Once I was happy with an application,

  • I would document it,
  • Place it in a an accessible location
  • Then email all the staff
    • Telling them about it
    • Informing them to expect a few bugs
    • Requesting them to test it and provide constructive feedback.

After a while I noticed that the same two people were willing to test and provide feedback, so I focused on them and involved them a little in teh specification of future applications.

  • Yes, asking for help with final testing is probably the step I was missing. I was trying to just go to 'done', and there wasn't a clear path. Emailing everyone without more clearance from higher ups feels strange though. With all the ideas I have gathered, I can talk with my boss. Commented Jan 20 at 13:14

What you are doing is not the most optimum thing in the world, but also not quite unusual. There are many topics to discuss here, but as you are relatively alone right now you should worry about yourself right now, and come to conclusions about this. Try to answer these questions for yourself, and if you have a useful answer, that will tell you directly (and better than us) how to proceed:

  • What happens if you become ill or are on vacation?
  • What happens if you leave the company (this is a different question than the previous)?
  • What happens if users get really dependent on your app, and if they require critical, immediate changes/adaptions?
  • What happens when this occurs for two different apps at the same time, with both of them not being trivial changes?
  • What happens if/when you become bored, annoyed or overwhelmed by your work?
  • What happens if you need to make changes which go beyond your capabilities (i.e., widely off your expertise)?
  • What happens if data gets permanently lost, assuming there is some persistent storage?

On the one hand, none of these kinds of problems are caused by you personally, necessarily; but you will be the one suffering personally.

Solutions could come in many different forms (for example: create a team surrounding yourself, at least one like-minded person, optimally at least two; avoid persistent data at least; avoid putting out apps with any kind of critical impact, at the very least unless there is a well-defined stakeholder/owner higher up in the company; or plenty of others). In every case, you are not the best person deciding this, but this needs to come from management.

If management is silent, then you have thinking to do on your own; imagine scenarios and see if you want to live through them.

  • Great list of impacts! I have thought of some of them, like the "one bus" issue. I have tried to document thoroughly for users, maintaners and future developers. I have tried to use the simplest and most obvious forms of coding - most is just straight up ASP.Net with the built-in wizard built SQL data access, in the page, not the code-behind as far as possible. As for data. I took over responsibility for programs that use lots of production data daily. I changed those as little as possible to modernize them. Other systems use less critical data. So I am the man on the ground here. Commented Jan 12 at 15:48

Maybe, depends on the managers personality

As I understand it, your job is to create useful tools and thats what you do. The problem is, your manager kind of ignores those, but does not complain either when you actually introduce them to production.

I think this is not uncommon, the manager is probably not the person that will use these tools, so he really is not in a good position to judge if or when it is a good idea to do that. He might not even understand what they do and what the purpose is. So he moves that mail into the "later" folder and forgets about it.

So what you can do about it depends a lot on the personality of the manager, does he like employees that show initiative or does he feel the need to decide everything?

Depending on that I see different routes:

  • go the safe route, wait for the managers approval (might never come) and do other things in the mean time. You don't directly risk anything by this but probably also are a lot less useful to the company, also this can get frustrating.
  • Press the management to make a decision, remind them with mails or in person. This may get you results, but likely will be seen as annoying and when pressed to a decision "no" will more likely be the answer, just because thats the safe and easy answer for them. But nobody can directly blame you either way.
  • Don't ask, inform. "Hey, I have this new tool for transmogrifying the flux capacitor matrix ready, when theres no reason not to, I will roll it out to production next tuesday. Have a nice day". This way it defaults to a "yes" if he ignores you and still nobody can blame you for doing it without telling anybody.

If the manager does not like initiative like this, the last will likely result in you getting told to not do this again and ask and wait for permission the next time. You might even get yelled at if this is REALLY not liked ;)

But if they are silently fine with what you are doing this will most likely in success in my opinion. And if they are suddently not fine with it anymore, well there is a paper trail protecting you, they were informed.

What other comments said about documentation, getting more people into the boat etc still is a good idea of course.

  • I like how you described the options, thanks! We recently retired our Flux Capacitor, but the new Matrix-Enabled Work Simulator is doing a good job. I have to learn more about the Busyness Inelegance reporting tool. Commented Jan 12 at 20:59

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .