Co-workers are fighting an idea that I think could double productivity

Question

My team writes RFPs for our product and currently we do not coordinate much on writing them. I was thinking that we could just create a central database (I can code a bit and use Algolia) of questions and just cut and paste past answers into the form. Currently team members generally each have their own answers.

However the rest of the team is against it. They dont want to share their answers or let management have their answers to questions. We dont work on commission so why that matters strange to me. They call it "absurd" and "prone to hacking" and "could be destroyed by a computer failure" (also the case to their word documents).

I'm the new guy and also in my first job out of university, so I don't know what I am doing wrong? Are they dismissing me because of my age? How can I convince them to use this system?

Answer 1

Do you have double the work to do/potentially double the work to do?

In these trying times, there is probably not double the work to do. Companies are buying less. Governments are buying more, but only of specific things. Customers are being stingy.

Doubling your productivity would just mean that they could do with half the employees in your department. When companies are trying to cut costs, departments with the capacity for double productivity are good places to start.

A good friend of mine was an operations guy at a company that was going through cost-cutting. His major role was generating a report from this database. He knew SQL, so within the first week managed to automate the report. All they did with his innovation was to cancel the other internship position they were going to fill. He got nothing but being given the other intern's spot. Had he automated that, then who knows what would have happened to him?

Now, reusing RFP answers is a very standard practice. My Dad used to write them all the time and the companies he worked for had plug and fill in databases of answers. Employees like tools that save them time, which is what makes me suspect that they could have motives other than the ones they have stated. Are they as concerned about hacking for their other documents?

Now, I do concede that this is a cynical perspective. It obviously depends on your company, but carefully consider whether you want to bring this forward at all. Determine the implications of this for your own future. It could be an opportunity, but it could also be your/your co-workers' ticket(s) out the door. A lot of organizations would thank you and say "well, don't need you anymore."

If you really want this to go ahead anyway, you would need to convince your co-workers that there is double the work to be done rather than the work just requiring half the people.

Answer 2

Make it a tool for yourself, then lead by example

You can make the tool anyway and improve your own performance by using it. If at a certain point it turns out you get better results, people might become interested after the fact.

You're not just making a tool. You're endangering their jobs (or at least the possibility), they're protecting their jobs (which is normal human behaviour). Apart from that, they've likely been doing the job as they're doing it now for a while now and then this new kid wants to change that completely? People don't like change, especially if it's a (young) new person with no experience in the company.

So I suggest you create the tool (in your own time! You're not getting paid to program!) and use that tool. Don't hide it, don't promote it, don't go behind anyones back. Just use it as a tool. Don't bring it up all the time, but if anyone is interested you can explain how it works. Let them come to you.

Use yourself as field tester, find what works and what doesn't and use that to improve the tool. It might also mean that it's not as useful as you think it is.

---

^{As a programmer: Please make sure your code is actually safe. You do not want to be the guy who introduces crappy code which led to an hack or something, there are plenty of review possibilities. There are hack possible you are not aware of, so get it reviewed.}

Answer 3

In general, the best way to "sell" any idea is to discuss the pros and cons (yes, both are necessary) of the idea and show how the pros override the possible downsides. Simply verbal mentioning or advocating for something new usually is not accepted well, specifically when you're trying to push the idea from bottom to the top in hierarchy.

For example: when you say "double the productivity" - how do you measure it? Is there any study that shows the numbers? Is this something you have calculated based on any metrics? Is this something you "believe"? You need to show, not tell.

Do some study, and come up with a document / presentation that outlines the current problems, possible solutions to the issues and how your proposed idea can solve all / most of them. Then, discuss that within the team and ask for feedback. Analyze those feedback and address the points from a neutral angle. Finally, submit that proposal to your superiors for review. Ultimately, they will take the final call.

Given that you're the "new guy" around there, these sort of initiative will portray you in a good light, even if your proposal finally does not go through.

Answer 4

There's a few reasons, but I believe it really boils down to one point:

I'm the new guy and also in my first job out of university, so idk what I am doing wrong? Are they dismissing for my age? How can I convince them to use this system?

You're rocking the boat as a fresh, inexperienced hire.

It really does come down to this - you could have the best ideas going, but the team you're dropped into simply won't like it the new, inexperienced guy telling them they're doing something wrong, and how they could be doing it differently. It's fine to mention these ideas to test the water, but if you're not met with a positive response, you should back off pretty much straight away.

However, there are additional practical reasons as well why this may not be the best idea:

• You can code - but can anyone else on your team? Who's going to maintain it if you leave? What if everyone relies on the system and it breaks as soon as you walk out the door?
• Their concerns around hacking are not unfounded. How can they guarantee a fresh grad has the security knowledge & know-how to build a system that's properly locked-down? (This is especially the case since you say "I can code a bit", which doesn't imply heaps of experience.)
• You show no evidence that they'd actually be twice as productive. A new system & way of working can make people much less productive, at least initially.