The Social Network 2: The Workplace Battle Over Automation, Ideas, and Credit

A few weeks ago, I had the opportunity to present the complete automation process that another employee and I had been working on. The objective was simple: eliminate unnecessary manual work wherever possible. We weren’t trying to reinvent the wheel, introduce complicated technology, or make things more difficult than they needed to be. We simply wanted to look at the processes our team was performing every day and figure out which tasks could be automated.

After all, why should someone spend time performing repetitive tasks manually when a computer can do most of the work?

The presentation went well. I walked everyone through the automation process, explained how the different components worked, and demonstrated what we had accomplished. A few people asked questions, and there was some discussion about the overall process. Eventually, everyone went their separate ways.

It was a productive meeting, and I thought that would be the end of it.

Well, almost.

There was one particular employee whose reaction didn’t surprise me. This is someone I have written about a few times before, particularly regarding his negativity in the workplace and his tendency to disagree with things that don’t necessarily align with his own ideas.

As expected, he wasn’t entirely on board with what another employee and I had developed.

And apparently, our automation project had become something of a personal challenge for him.

We Automated The Work That Should Have Been Automated In The First Place

Before getting into the workplace drama, it’s worth explaining what we actually accomplished.

Another employee and I recognized that much of the work our team was doing involved repetitive manual tasks. These were processes that required people to perform the same actions repeatedly, often involving different systems and applications.

There wasn’t much creativity involved. It was mostly following established steps, moving information around, and completing tasks that could be handled through automation.

We decided to do something about it.

Using VBScript (VBS) and Visual Basic for Applications (VBA), we developed automation solutions that eliminated a significant portion of the manual work. We weren’t building some revolutionary software application. We were using tools already available to us to make our everyday responsibilities more efficient.

And it worked.

That’s what mattered.

The whole purpose was to give people time back and allow them to focus on tasks that actually required human involvement. Automation should make work easier, not create another layer of unnecessary complexity.

I would have thought everyone could appreciate that.

Apparently, not everyone sees it that way.

The Suggestion To Combine Our VBS and VBA Scripts

During the meeting, this employee suggested that we combine both the VBS and VBA code into one automation solution to make the process even more automated.

On the surface, it might sound like a reasonable suggestion. Why have two separate scripts when you could potentially have one?

He even asked me to provide my VBA code so he could attempt to combine it with the VBS automation.

I had no problem sharing it. I’m not particularly protective of code that was developed to benefit the team. If someone wants to understand how something works or explore ways to improve it, that’s perfectly fine.

However, there was one problem with his suggestion.

The VBS and VBA scripts were designed for different systems and served different purposes. They weren’t simply two scripts performing identical functions that could be thrown together into one larger program.

There are technical considerations when working with different applications, environments, and processes. Just because two automations contribute to the same overall workflow doesn’t mean they should necessarily be combined.

Sometimes keeping things separate is the more practical approach.

Anyway, I provided the VBA code.

That was over a month ago.

And guess what?

I haven’t heard anything since.

No update, no demonstration, no explanation of what he discovered, and certainly no finished automation.

I can only speculate about what happened. Perhaps he encountered difficulties understanding the code or realized that combining the two scripts wasn’t as straightforward as he initially thought. Maybe he eventually discovered that his proposed solution wasn’t going to work as expected.

Whatever the reason, the silence has been interesting.

It’s one thing to suggest an improvement during a meeting. It’s another thing entirely to actually develop something that works.

Now He Wants Us To Use Power Query?

You would think that would have been enough, but apparently not.

Even after the meeting, he came back with another suggestion: use Power Query to automate the process.

Now, I have nothing against Power Query. It’s a useful tool, and I’m sure there are plenty of situations where it makes sense to use it.

But here’s my question: Why?

I’m not familiar with Power Query, and more importantly, the VBA automation we already developed is doing what we need it to do.

Why should we suddenly abandon or replace a working solution simply because someone wants to introduce another technology?

There needs to be a reason for changing something that already works.

If Power Query can genuinely improve the process, reduce maintenance, increase reliability, or offer capabilities that our existing automation doesn’t have, then by all means, let’s evaluate it.

But introducing a different tool just for the sake of using something different doesn’t automatically make the process better.

Technology should serve the process, not the other way around.

I don’t believe in changing an existing solution simply because someone has a preference for another application or programming approach. If the current solution accomplishes the objective, then the burden should be on the proposed alternative to demonstrate why it is worth adopting.

Otherwise, we’re just creating additional work for ourselves.

And wasn’t eliminating unnecessary work the entire reason we started this project?

The Promise Of Something Better, Faster, and More Impressive

What makes this situation even more interesting is something I learned from the other employee I worked with on the automation project.

Apparently, this individual had been privately messaging her and telling her that he was going to create an automation tool that would be better and faster than what the two of us had developed.

Interesting.

So, instead of approaching both of us with constructive feedback or discussing specific improvements to the existing automation, he was privately telling my coworker that he was going to build something superior.

That was weeks ago.

And, as far as I know, there is still nothing to show for it.

I’m beginning to wonder whether this has less to do with automation itself and more to do with the desire to prove something.

There is nothing wrong with wanting to develop a better solution. Competition can sometimes encourage innovation, and I certainly don’t believe that the first person to develop something should automatically have the final say.

But there is a difference between wanting to improve a process and wanting to demonstrate that your work is somehow better than everyone else’s.

One is about helping the team.

The other can become a competition that nobody else signed up for.

Did We Actually Steal Someone’s Idea?

Here is where things get a little more interesting.

From conversations with the coworker I collaborated with, I learned that there might be some history between these two employees. Apparently, the other individual feels that we stole his idea.

Now, I don’t know the full story, and I don’t want to make assumptions about conversations or events that happened before I became involved.

But if that’s genuinely how he feels, perhaps that explains some of the negativity surrounding our automation project.

Maybe he had previously considered automating these processes. Maybe he discussed the possibility with someone. Maybe he had plans to develop something himself but never got around to implementing them.

Then another employee and I came along, identified the manual work, developed the automation, and presented the finished process to the team.

I can understand how someone might feel frustrated if they believe an idea they previously discussed was implemented by someone else.

But having an idea and actually executing it are two different things.

Ideas are everywhere in the workplace. People regularly discuss ways to improve processes, eliminate unnecessary steps, and make things more efficient. That’s normal.

However, an idea doesn’t become a working solution until someone takes the initiative to develop it.

If someone has been talking about automating a process for months but another person eventually takes the initiative and makes it happen, can we really say the first person owns the accomplishment?

That’s a difficult argument to make.

And without knowing the complete history, I can’t say whether there was any misunderstanding or overlap in what was originally discussed.

What I do know is that my coworker and I put in the effort, developed the automation, tested it, and presented the results.

We didn’t just talk about it.

Is This Turning Into The Social Network?

At this point, I couldn’t help but think about the movie The Social Network.

Remember the whole controversy surrounding Mark Zuckerberg, Facebook, and the accusations that he took someone else’s idea?

It almost feels like we’re watching a much smaller workplace version of that story unfold.

One person believes an idea was taken. Another person develops something and gets it working. Then there are competing claims, disagreements, and apparently an attempt to build something even better.

I’m not suggesting that our little automation project is going to turn into a major legal battle or that anyone is about to become the next Mark Zuckerberg.

But the similarities in the general theme are amusing.

Someone believes they had an idea first, someone else actually executes it, and suddenly the focus shifts from the accomplishment to who deserves credit.

Maybe we should start calling this Automation 2.0.

Or perhaps, if things get really competitive, we’ll eventually have a sequel: The Social Network 2: The VBA Files.

Jokes aside, it does raise an important question about workplace collaboration.

Why do some people become so focused on who came up with an idea that they lose sight of what the team is actually trying to accomplish?

Why Can’t We Just Embrace Improvements?

This is probably the part I find most frustrating.

The objective of our project was never to take credit away from anyone, compete with another employee, or establish who was the smartest person in the room.

We wanted to eliminate unnecessary manual work.

That’s it.

If someone had approached us with a legitimate suggestion that would make the automation better, I would have been happy to discuss it. If they wanted to demonstrate a different approach, I would have been interested in seeing what they developed.

There is room for multiple people to contribute ideas and improvements.

But constantly suggesting that something should be done differently, promising to build something better, and then producing nothing doesn’t move the team forward.

It just creates unnecessary tension.

I also think there is something to be said about recognizing other people’s accomplishments. When coworkers take the initiative to solve a problem, the natural response should be to acknowledge the effort and explore how the solution can benefit everyone.

You don’t have to agree with every technical decision.

You don’t have to like every tool someone uses.

And you certainly don’t have to pretend that every solution is perfect.

But you should be able to recognize progress when you see it.

At The End Of The Day, Results Matter More Than Promises

I’m not opposed to someone developing a better automation solution. In fact, if this employee eventually comes forward with something that genuinely improves our existing process, I’ll be interested in seeing it.

Maybe Power Query will turn out to be a better option for certain tasks. Maybe combining certain components will make sense after further evaluation. I’m open to improvements when they are supported by actual results.

But until then, I’m not going to spend my time worrying about promises.

Another employee and I identified a problem, developed a solution, and presented it to the team. We took something that previously required unnecessary manual effort and made it more efficient.

That’s an accomplishment worth recognizing.

And perhaps that’s the biggest lesson from this entire experience: There is a difference between wanting to improve something and wanting to be recognized as the person who improved it.

One focuses on the team. The other focuses on the individual.

Workplaces already have enough challenges without turning every improvement into a competition over recognition, ownership, or whose idea came first.

Sometimes the best thing someone can do is put their ego aside, appreciate what has already been accomplished, and contribute to making it even better.

After all, the goal was automation, not a workplace remake of The Social Network.

And if someone really does have a better solution, I’m still waiting to see it.