5.1 KiB
+++ title = "Shiny objects, and learning" author = ["Phil Bajsicki"] publishDate = 2024-04-24T00:00:00+02:00 lastmod = 2024-09-26T14:21:58+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.
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:
- 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.{{}}This happens the most in companies which foster a culture of care and risk management, in my experience.{{}}
- 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 {{}}Migrating data, processes, implementing new training for hires, updating their tech stack to integrate with the new software.{{}}.
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{{}}Not always, but sometimes artificially created by marketers{{}}.Our imaginary manager, when
faced with love bombing {{}}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.{{}} 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
){{}}Frequently finding the software wanting, for many reasons.{{}}.
The new software is then integrated into the department's systems, on our manager's request. This involves great cost:
- The software itself{{}}Frequently inflated to cover the software company's high marketing and advertising costs.{{}}.
- Migrating data from existing systems into the new software.
- Migrating existing processes into the new software - including integrations, APIs, and so on.
- 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{{}}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.{{}}.
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.