+++
title = "Shiny objects, and learning"
publishDate = 2024-04-24T00:00:00+02:00
lastmod = 2024-09-27T19:30:14+02:00
tags = ["mindset", "attitude", "rant"]
categories = ["business"]
draft = false
meta = true
[menu]
  [menu.posts]
    weight = 3001
    identifier = "shiny-objects-and-learning"
+++

It's been three months, and life has moved forward a little. Today's rant is one
that's been brewing in me for a long time.

One of the most pernicious, annoying, frustrating, infuriating aspects of online
businesses is the influence of non-technical management.

<!--more-->

I consistently notice this issue in most companies I interact with. It's not a
simple topic, and there are many facets to it.

First, let's imagine our avatar. A simple, non-technical manager that has some
say in what their department does, how it works, and so on. They have friends
who they speak to, and their friends recommend a specific piece of software
because it serves _their_ business case well.

And that's great. But our manager doesn't understand the details of the
software, how it works, what it does, or how it interacts with the rest of their
friend's systems. Nor does our manager understand much about the differences
between the software they're using currently, and the software they're being
recommended.

There are two outcomes we can generally expect:

1.  Our manager does their research, and consults with their team before making a
    decision on whether they should buy and start using the new software,
    considering the upsides/ downsides seriously, as well as the overhead of
    migrating their data, processes, and training.{{<sidenote>}}This happens the most in companies which foster a culture of care and risk management, in my experience.{{</sidenote>}}
2.  Our manager doesn't do the research, and enforces the change over to the new
    software based on what's effectively hearsay, creating friction in their department {{<sidenote>}}Migrating data, processes, implementing new training for hires, updating their tech stack to integrate with the new software.{{</sidenote>}}.

The core difference is nothing else but the manager's awareness. Our
imaginary manager may understand the limits of their knowledge, and have the self-awareness to admit when they're out of their depth.

This isn't easy.

There is also the element of FOMO when faced with peer pressure{{<sidenote>}}Not always, but sometimes artificially created by marketers{{</sidenote>}}.Our imaginary manager, when
faced with love bombing {{<sidenote>}}Using the term lightly here. Businesses have social media managers whose role is to make each prospective user (lead) feel important and appreciated, playing on their emotions in an attempt to sell their software.{{</sidenote>}} from a software's community (social media groups, e.g. on Facebook),
can rarely help growing into a positive emotional relationship with the company.
In turn, in an effort to be part of the in-group, they buy into the software
eco-system because of this New Hot Amazing Feature (`Shiny
Object`){{<sidenote>}}Frequently finding the software wanting, for many reasons.{{</sidenote>}}.

The new software is then integrated into the department's systems, on our manager's request. This involves great cost:

1.  The software itself{{<sidenote>}}Frequently inflated to cover the software company's high marketing and advertising costs.{{</sidenote>}}.
2.  Migrating data from existing systems into the new software.
3.  Migrating existing processes into the new software - including integrations,
    APIs, and so on.
4.  Training staff on the new software.

As you can see, the overhead is large, and it's not limited to that.

For a non-technical person, the idea of `no-code`, or `magic thing that does what
you mean` is alluring, however it carries with itself a great cost.

But it doesn't stop there. Our manager may neglect the need to learn and
understand the software they use in the first place. Then the dangerous idea of
"we need X, let me search for the best X that we can get" appears. Despite the
existing tech stack easily allowing for that need to be served{{<sidenote>}}Example: subscribing to a CRM SaaS (Software as a Service) platform to send mass mail (e.g. announcements, )instead of using their existing Google Workspace e-mail with merge fields.{{</sidenote>}}.

If this is the case, it's inevitable that tech bloat will take place.

This is particularly an issue in startups/ microbusinesses, where an expense of
$500/mth may be significant. So understanding the feature set of the tech stack,
and ensuring that features in it don't overlap can be a very effective way of
avoiding unnecessary costs.

It's also important to think about the most fundamental cost/ benefit equation.

> Is the cost of our hypothetical manager learning about tech, little by little
> each day, high enough to offset the costs of changing the software stack in the
> first place?

I personally don't believe so. The only cure to ignorance is self-awareness, and
a drive to learn and understand the world around us.

There. Rant over.

<span class="underline">[Join the FSF.](https://my.fsf.org/join)</span>