Twitter, Elon Musk, and dignity

A lot has been said about Elon Musk's actions at Twitter. I will add a little more, with some ideas that I have not seen anywhere else. (Also, I recognize that Musk has stepped aside and is letting Linda Yaccarino run the show. But I don't know if Musk is still involved.)

Musk's behavior at Twitter has been described as chaotic, petulant, and just plain wrong. He has made decisions with wide-sweeping actions, and made them hastily and with little respect for the long-time employees at Twitter. Those decisions have had consequences.

I'm going to focus not on the decisions, and not on the consequences, but on the process. Musk is running Twitter as if it were a start-up, a company with an idea of a product or service, perhaps a prototype or minimum viable product, and few or no customers. Start-ups need to find a product or service that resonates with customers, something that makes customers ready to pay for the product or service. It is common for a start-up to try several (sometimes quite varied) approaches.

A start-up looking for its product (or its value proposition, to use MBA-speak) needs to move quickly. It has limited resources and it does not have the luxury of waiting for multiple levels of bureaucracy to review decisions and slowly reach a consensus. The CEO must make decisions quickly and with minimal delay.

That's the behavior I see in Musk at Twitter: unilateral, arbitrary decisions made with no advance notice.

While such behavior is good (and sometimes necessary) at start-ups, it is not good at established companies. Established companies are, well, established. They have well-defined products and services. They have a base of customers who pay them money on a regular basis. Those customers have expectations, based on the previous actions of the company.

Arbitrary changes to products and services, made on short notice, do not sit well with those customers. Customers want predictability, just as you and I want predictability from our internet providers and streaming services.

(Note to self: a future column might discuss consistency and predictability for streaming services.)

Back to customers of Twitter: They want predictability, and Musk is not providing it.

The users of Twitter, distinct from the customers who pay for advertising, also want consistency and predictability. Arbitrary changes can drive users away, which reduces advertising view counts, which reduces advertising rates, which reduces income for advertising.

It seems to me that Musk is well-suited to run a start-up, and poorly suited to run an established company.

(Note to self: a future column might discuss the transition from start-up to established company.)

Perhaps the best action that Musk can take is to remove himself from the management of Twitter and let others run the company. He has done that, to some extent. He should step completely aside. I'm not commenting on Yaccarino's competency to run Twitter; that is another topic.

Sometimes the best way to solve a problem is to let others handle it.

Eventual Consistency

The NoSQL database technology has introduced a new term: eventual consistency.

Unlike traditional relational databases which promise atomicity, completeness, and durability, NoSQL databases promise that updates will be consistent at some point in the (near) future. Just not right now.

For some folks, this is bad. "Eventual" consistency is not as good as "right now" consistency. Worse, it means that for some amount of time, the system is in an inconsistent state, and inconsistencies make managers nervous.

But we've had systems with internal inconsistencies for some time. They exist today.

One example is from a large payroll-processing company.  They have been in business for decades and have a good reputation. Surely they wouldn't risk their (lucrative) business on something like inconsistency? Yet they do.

Their system consists of two subsystems: a large, legacy mainframe application and a web front-end. The mainframe system processes transactions, which includes sending information to the ACH network. (The ACH network feeds information to individual banks, which is how your paycheck is handled with direct deposit.)

Their web system interfaces to the processing system. It allows employees to sign in and view their paychecks, present and past. It is a separate system, mostly due to the differences in technologies.

Both systems run on schedules, with certain jobs running every night and some running during the day.

Inconsistencies arise when the payroll job runs on Friday. The payroll-processing system runs and sends money to the ACH network, but the web system doesn't get the update until Monday morning. Money appears in the employee's bank account, but the web system knows nothing about the transaction. That's the inconsistency, at least over the weekend and until Monday morning. Once the web system is updated, both systems are "in sync" and consistent.

This example shows us some things about inconsistencies.

• Inconsistencies occur between systems. Each subsystem is consistent to itself.
• Inconsistencies are designed. Our example payroll system could be modified to update the web subsystem every time a payroll job is run. The system designers chose to use a different solution, and they may have had good reasons.
• Inconsistencies exist only when one is in a position to view them. We see the inconsistency in the payroll-processing system because we are outside of it, and we get data from both the core processing system and the web subsystem.

Eventual consistency is also a design. It also exists between subsystems (or between instances of a subsystem in a cloud system).

Eventual consistency is not necessarily a bad thing. It's not necessarily a good thing. It is an aspect of a system, a design choice between trade-offs. And we've had it for quite some time.