Showing posts with label team. Show all posts
Showing posts with label team. Show all posts

Is Particle Physics Dead, Dying, or Just Hard?

Mike's Notes

This Quanta Magazine article about the current state of Particle Physics got me thinking.

  • Particle physicists are very good at statistical physics and maths
  • They have to be very bright and well-trained
  • They like hard problems to solve
  • There are unemployed particle physicists
  • Ajabbi Research will need people in the future. Hmmm

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library > Subscriptions > Quanta Magazine
  • Home > Handbook > 

Last Updated

20/03/2026

Is Particle Physics Dead, Dying, or Just Hard?

By: Natalie Wolchover
Quanta Magazine: 26/01/2026

Natalie Wolchover is a columnist for Quanta Magazine, where she covered the physical sciences for more than a decade. Her writing has been featured in The Best American Science and Nature Writing, The Best American Magazine Writing, and The Best Writing on Mathematics, and has won several awards, including the 2022 Pulitzer Prize for Explanatory Reporting, the 2016 Evert Clark/Seth Payne Award, and the American Institute of Physics’ 2017 Science Communication Award. She was lead editor for the National Magazine Award–winning special issue, "The Unraveling of Space-Time." Her first book, The Question to Which the Universe Is the Answer, is scheduled for publication in 2027.

Columnist Natalie Wolchover checks in with particle physicists more than a decade after the field entered a profound crisis.

In July 2012, physicists at the Large Hadron Collider (LHC) in Europe triumphantly announced the discovery of the Higgs boson, the long-sought linchpin of the subatomic world. Interacting with Higgs bosons imbues other elementary particles with mass, making them slow down enough to assemble into atoms, which then clump together to make everything else.

A couple of months later, I took a job as the first staff reporter at the nascent science magazine that would become Quanta. Turns out I was starting on the physics beat just as the drama was picking up.

The drama wasn’t about the Higgs particle; by the time it materialized at the LHC there was already little doubt about its existence. The Higgs was the last piece of the Standard Model of particle physics, the 1970s-era set of equations governing the 25 known elementary particles and their interactions.

More striking was what did not emerge from the data.

Physicists had spent billions of euros building the 27-kilometer supercollider not only to confirm the Standard Model but also to supersede it by uncovering components of a more complete theory of nature. The Standard Model doesn’t include particles that could comprise dark matter, for instance. It doesn’t explain why matter dominates over antimatter in the universe, or why the Big Bang happened in the first place. Then there’s the inexplicably enormous disparity between the Higgs boson’s mass (which sets the physical scale of atoms) and the far higher mass-energy scale associated with quantum gravity, known as the Planck scale. The chasm between physical scales — atoms are vastly larger than the Planck scale — seems unstable and unnatural. In 1981, the great theorist Edward Witten thought of a solution(opens a new tab) for this “hierarchy problem”: Balance would be restored by the existence of additional elementary particles only slightly heavier than the Higgs boson. The LHC’s collisions should have been energetic enough to conjure them.

But when protons raced both ways around the tunnel and crashed head-on, spraying debris into surrounding detectors, only the 25 particles of the Standard Model were observed. Nothing else showed up.

In philosophy, “qualia” refers to the subjective qualities of our experience: what it’s like for Alice to see blue or for Bob to feel delighted. Qualia are “the ways things seem to us,” as the late philosopher Daniel Dennett put it. In these essays, our columnists follow their curiosity, and explore important but not necessarily answerable scientific questions.

The absence of any “new physics” — particles or forces beyond the known ones — fomented a crisis. “Of course, it is disappointing,” the particle physicist Mikhail Shifman told me that fall of 2012. “We’re not gods. We’re not prophets. In the absence of some guidance from experimental data, how do you guess something about nature?”

Once the standard reasoning about the hierarchy problem had been shown to be wrong, there was no telling where new physics might be found. It could easily lie beyond the reach of experiments. The particle physicist Adam Falkowski predicted to me at the time that, without a way to search for heavier particles, the field would undergo a slow decay: “The number of jobs in particle physics will steadily decrease, and particle physicists will die out naturally.”

The crisis and its fallout made for years of interesting reporting, but sure enough, the frequency of news stories related to particle physics diminished. I fell out of touch with sources. More than 13 years on, in this first column for Qualia, a new series of essays in Quanta Magazine, I’m taking stock. Is particle physics dying, as Falkowski predicted? Can new physics still be found? What’s the future for particle physicists? Will artificial intelligence help? How much hope is left in the search for answers to the many remaining mysteries of the universe?

Some particle physicists act as if there’s no crisis at all. The LHC is still running and will for at least another decade, and its operators are finding new sources of enthusiasm.

In the last couple of years, data handling at the collider has improved with the use of AI. Pattern recognizers can sort through the outgoing debris of proton collisions and classify collision events more accurately than human-made algorithms can. This helps the physicists to more accurately measure the “scattering amplitude,” essentially the probability that different particle interactions will occur. For instance, AI systems can determine more precisely how many top quarks arise in the aftermath of collisions versus the number of bottom quarks. Any statistical deviations from the predictions of the Standard Model could signify the involvement of unknown elementary particles.


A proton-proton collision documented by the Compact Muon Solenoid at CERN in 2012 shows evidence of the decay of the Higgs boson.

CMS Collaboration; Mc Cauley, Thomas

Novel particles as hefty as Higgs bosons would not be so subtle; they would have shown up already as pronounced bumps on data plots. But as Matt Strassler, a particle physicist affiliated with Harvard University, explained to me, the traces of lighter novel particles could still lie in so-called hidden valleys in the data. “There’s a huge amount of unexplored territory there,” he said. There might exist, for instance, an unstable type of dark matter particle that leaves its mark by occasionally arising and immediately decaying into an excessive number of muon-antimuon pairs. Detecting such an excess would point indirectly to the unstable particle’s existence. “For people who thought all the new physics is at high energies — they’re very disappointed right now,” Strassler said. “I don’t share that view. There are many opportunities for nature to provide clues at low energies.”

So far, though, no such indirect evidence of new physics has been detected. The more accurate the statistics have become at the LHC, the better they match the Standard Model. Michelangelo Mangano, a particle physicist at CERN, the laboratory that houses the LHC, said the collider today is like a tool for exploring the Standard Model’s predictions, and he considers this exploration worthwhile because not all consequences of the equations are easy to calculate. The search for new physics beyond the Standard Model is ongoing, Mangano said, but “the fact that it’s not giving positive results does not mean we are stuck, dead, or wasting our time.”

These questions are so fundamental that of course it’s worth nailing down every amplitude and checking every hidden valley, since we have the tool for the job. But for hunters of new physics, does the game end there?

The community wants to go bigger. CERN physicists want to build a Future Circular Collider, tripling the circumference of the LHC with a 91-kilometer tunnel beneath the Franco-Swiss border, to both probe higher energies and look for subtler signals. This FCC would initially collide electrons, which, unlike protons, are themselves elementary particles, with no substructure. Their clean collisions would allow more precise measurements of scattering amplitudes, making the FCC ultrasensitive to indirect signs of new physics. By the end of the century, the mega-collider would be upgraded to collide protons, as the LHC does now. Proton collisions are messier, but at the FCC they would achieve unprecedented energies — about seven times higher than the LHC can currently muster — so they have a chance, however slim, of revealing heavy particles beyond the LHC’s reach. (In theory, particle masses could range up to a million billion times greater than what the LHC energy scale can produce directly, so there’s no reason to expect them around the next bend.)

We’re not gods. We’re not prophets. In the absence of some guidance from experimental data, how do you guess something about nature? - Mikhail Shifman

As of now, the FCC’s fate is unknown; formal approval and funding commitments by member countries won’t come before 2028.

Meanwhile, U.S. particle physicists are aiming to complement the European strategy by constructing a brand-new type of machine: a muon collider. Muons are elementary like electrons, but they’re 200 times heavier, so their collisions would be both clean and energetic (albeit not reaching the collision energies of the LHC). Both the selling point and the challenge of this newfangled type of machine is that it will require major technical innovations (with all the spin-off potential that can bring), because muons are highly unstable. They must be accelerated and collided mere microseconds after they’re created.

Demonstrating the technology and then constructing the collider would take roughly 30 years, and that’s with federal funding. “We have to figure out how to do it in between 10 and 20 billion [dollars],” said Maria Spiropulu, a physics professor at the California Institute of Technology and co-chair of the committee behind a national report endorsing a muon collider program(opens a new tab) that came out in June 2025. Over the coming years, the Department of Energy will weigh whether to fund the proposal rather than competing science projects. What hurts its case is the lack of a “discovery guarantee,” which the LHC had with the Higgs boson.


Scientists and technicians inspected and upgraded systems at the Large Hadron Collider during the Long Shutdown 2, which began in 2018.

Maximilien Brice/CERN

Then again, as the mathematical physicist Peter Woit mused on his blog(opens a new tab), “Perhaps in our new world order where everything is controlled by trillionaire tech bros, the financing won’t be a problem.”

Deliberations about a Chinese supercollider have come to naught, I’m told. Instead, China has decided to pursue a “super-tau-charm facility”: a lower-energy particle scattering experiment that would cost mere hundreds of millions of dollars instead of tens of billions. The facility will produce a lot of tau particles and charm quarks, partly to study whether taus ever shape-shift into muons or electrons. This kind of switching isn’t predicted by the Standard Model, but it does happen in some theoretical extensions of it.

Okay, we might as well check. We’re desperate for new physics, and the price is good. But by definition it’s very difficult to know which shots in the dark are worth taking.

Adam Falkowski, who sounded the death knell for particle physics back in 2012, used to be known for the sharp commentary he supplied on his blog Résonaances(opens a new tab). But the Paris-based particle physicist hasn’t posted anything since 2022. He said that’s partly because he’s been tied up with fatherhood and partly because there hasn’t been much to say.

When we caught up on a video call, Falkowski told me, “I am very skeptical about future colliders. For me it’s very difficult to get excited about it.” He sees momentum behind CERN’s FCC campaign, but personally he worries about the huge costs and timescales, and the fact that “there are absolutely no hints that something is there within the reach of the next collider.”

For his part, Falkowski has turned to the theoretical study of scattering amplitudes, a growing research area focused on the geometric patterns underlying particle interaction statistics, patterns that could point toward a truer perspective on the quantum world. The field seeks to reformulate the equations of particle physics in a different mathematical language in hopes that this language might extend to quantum gravity. “There is a very vibrant program in trying to understand the structure of the physical theories,” Falkowski said. “The hope is that with the help of machine learning, that there can be very fast progress in the coming years. I think that’s where the best things have happened.”

But amplitudeology, as this field is known, is abstract — it’s no atom-smashing experiment. Falkowski said he does think experimental particle physics is dying. He has watched talented postdocs switch to other research areas or take data science jobs. “I’m not sure they are getting the best of the best as they used to,” he said, “because the prospects of returns are so distant. If you want to change the world now, you will do AI; you will do something different from particle physics.”


The ALICE (A Large Ion Collider Experiment) detector at the Large Hadron Collider was designed to study quark-gluon plasma.

CERN, Julien Marius Ordan/Science Source

This brain drain appears to be real. I spoke to Jared Kaplan, co-founder of Anthropic, the company behind the chatbot Claude. He was a physicist the last time we spoke. As a grad student at Harvard in the 2000s, he worked with the renowned theorist Nima Arkani-Hamed to open up the new directions in amplitude research that are being actively pursued today. But Kaplan left the field in 2019. “I started working on AI because it seemed plausible to me that … AI was going to make progress faster than almost any field in science historically,” he said. AI would be “the most important thing to happen while we’re alive, maybe one of the most important things to happen in the history of science. And so it seemed obvious that I should work on it.”

As for the future of particle physics, AI makes worrying about it now rather pointless, in Kaplan’s view. “I think that it’s kind of irrelevant what we plan on a 10-year timescale, because if we’re building a collider in 10 years, AI will be building the collider; humans won’t be building it. I would give like a 50% chance that in two or three years, theoretical physicists will mostly be replaced with AI. Brilliant people like Nima Arkani-Hamed or Ed Witten, AI will be generating papers that are as good as their papers pretty autonomously. … So planning beyond this couple-year timescale isn’t really something I think about very much.”

Cari Cesarotti, a postdoctoral fellow in the theory group at CERN, is skeptical about that future. She notices chatbots’ mistakes, and how they’ve become too much of a crutch for physics students. “AI is making people worse at physics,” she said. “What we need is humans to read textbooks and sit down and think of new solutions to the hierarchy problem.”

Cesarotti was a high school junior when the Higgs boson was discovered. She grew up near Fermilab, the U.S. national lab in Illinois that houses the Tevatron, which was the world’s highest-energy particle collider before the LHC. (The top quark was discovered there in 1995.) This proximity taught her that a particle physicist was a thing you could be. Later, it turned out to be her thing. “What are the fundamental building blocks of the universe — those were the questions that I was most interested in knowing the answer to,” she told me. “But what people said was, ‘Particle physics is dead. Don’t do this.’”

It may have been a fair warning; Cesarotti has yet to land a permanent job as a rising particle physicist. The subfield has continued to shrink, she and others said, as faculty hiring committees and grad students go in other directions. “Definitely all this rhetoric that there was nothing to be found and you should give up on it — people listened,” she said. “And of course that means there are fewer people. It becomes a self-fulfilling prophecy. If you’re pushing all these talented people out of trying to solve these problems into a field that it’s easier to make an impact on, then you’re setting yourself up for failure.”

Cesarotti echoed a sentiment I’d heard from others, which sounds correct to me as well: “Particle physics isn’t dead; it’s just hard.” It’s hard to know what to think about or look for. But the most devoted particle physicists are thinking and looking all the same.

“It was easy for 125 years,” Strassler said. “One thing led to the next. That lucky century has, for now, at least in the medium term, come to an end. That could change tomorrow, or next century, or who knows.”

A hint of a new lightweight particle could, in theory, show up at the LHC, or in some other experiment. Strassler is particularly excited about the study of radioactive thorium-229 decay, which could reveal variations in the fundamental constants. I’m slightly partial to experiments looking for “axions,” dark matter candidates that are so lightweight that they can act a little like light itself.

On the theory side, an obvious solution to the hierarchy problem could drop naturally out of the geometry behind scattering amplitudes. Or, if Kaplan is right, AI systems might someday suggest powerful new ideas for how the 25 particles of the Standard Model fit into a more comprehensive pattern — a possibility I didn’t foresee back when the crisis began.

Clearly, further progress toward the truth remains possible in particle physics. But there’s no discovery guarantee. I’ve had more than 13 years to think about it, and it remains a disturbing prospect: All the empirical clues we can glean about nature’s fundamental laws and building blocks might already be in hand. The universe may plan on keeping the rest of its secrets.

Tying Engineering Metrics to Business Metrics

Mike's Notes

Robust measures of financial health, tied back to engineering work, would be very useful to Ajabbi, a social enterprise that needs to be viable. The default is full transparency unless there is a very good reason not to. The plan is to have Pipi run the measurement process automatically and provide feedback loops.

To do

  • Build these measures into the DevOps Engine.
  • Add items to the workspace dashboard UI

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library >
  • Home > Handbook > 

Last Updated

11/02/2026

Tying Engineering Metrics to Business Metrics

By: Iccha Sethi
Medium: 26/11/2025

Interests include technology, building team culture, books and food. Engineering Leader..

Most engineering organizations I’ve worked in or led have tracked some form of engineering metrics. These range from simple metrics like uptime and incident count to more complex frameworks like DORA. As an engineering leader, you’ve probably been asked, either by someone within or outside of engineering: Why do these metrics matter? or How do they align with our business goals?

This post is aimed at demystifying some of this. We will cover:

  • Key Business Metrics
  • Lagging and Leading engineering metrics and how they connect to the key business metrics

While this isn’t an exhaustive list of engineering metrics, the goal is to provide a practical framework that you can adapt to your context.

Here is a TLDR of it, and let’s break it down along the way:

Key Business Metrics

Below are some key business metrics that most business use:

  • ARR (Annual Recurring Revenue): The total recurring revenue a company expects to receive annually from its customers. (Wall Street Prep)
  • NRR (Net Revenue Retention): A metric that measures the percentage of recurring revenue retained from existing customers over a specific period, accounting for expansions, contractions, and churn. (Planhat)
  • GRR (Gross Revenue Retention): The percentage of recurring revenue retained from existing customers over a specific period, excluding any revenue gained from expansions or upsells. (ChurnZero)
  • CAC (Customer Acquisition Cost): The total cost incurred by a company to acquire a new customer, including marketing and sales expenses. (Cast)

These metrics are lagging indicators, sometimes as lagging as 12 months, where a customer churns at the end of their yearly contract impacting the GRR.

Let us look at some potential Intermediate Outcomes which may impact these key business metrics.

Intermediate Outcomes

High GRR and NRR reflect loyal, satisfied customers who find the product valuable, easy to use (user experience), and reliable (system reliability). These customers are more likely to expand their usage, purchase additional features, and remain long-term advocates for your platform.

Acquiring new customers is generally more expensive than retaining existing ones. Studies indicate that attracting a new customer can cost up to five times more than retaining an existing one. Additionally, the probability of selling to an existing customer ranges between 60–70%, whereas the probability of selling to a new prospect is only 5–20%. These statistics underscore the financial benefits of focusing on customer retention strategies.

To grow the business via ARR and reduce CAC simultaneously, we must prioritize shipping product features quickly (feature velocity) without compromising the factors that sustain GRR and NRR.

Engineering Metrics (Lagging)

There are a number of engineering metrics which are lagging, but in much lesser magnitude of time than GRR/NRR/CAC/ARR. Metrics like uptime, time to detect and recover incidents, performance, support tickets, bugs, and team velocity can be measured over shorter timeframes.

As an engineering leader I have found that they’re most insightful when reviewed monthly and analyzed for trends over 3–6 months. These can be earlier indicators of unhappy customers and can enable the teams to take quick action, before the customer becomes a churn risk. Some examples include:

  • If there is an uptick in support tickets, growing disproportionately to customer base, or team is unable to keep up with support ticket SLAs, it is an indication of potentially higher number of bugs in the product, or an unintuitive user experience, leading to unhappy customers.
  • Increasing number of incidents, or high TTD, TTR along with decrease in Uptime means there are periods of time the product is unavailable or not working as expected again impacting customer trust.
  • Slow web app performance means it takes longer to get tasks done and unideal user experience.
  • Team velocity impacts the ability to ship customer-requested features.

Engineering Metrics (Leading)

Sometimes even months might be too late to come back and fix something. Luckily we have a number of best practices, and a set of metrics related to these best practices when done right have a high correlation to the lagging engineering indicators. These metrics though imperfect in their own ways, generally are a decent real time indicator of potential impact to lagging indicators. Some of these leading indicators include: Test coverage, PR size, Feature flag usage, deployment frequency, lead time for change, etc. Some of these can be reviewed on a per Pull request basis, or even daily. Ideally individual teams, or engineers feel a high sense of ownership for these.

Summary

Tying these all together — short lead time for change, means PRs get quickly into production. This is not only amazing for team and product velocity because we are shipping changes quickly and get to validate them quicker in production, but also allow us to decrease our Time to recover during incidents by applying a fix quickly. With lower impacting incidents, means less unhappy customers which help us maintain our GRR. Similarly with quicker time for features to get in production, means our product has higher value quicker, thereby making it easier to gain new customers and increase our ARR.

I hope this post clarifies the connection between engineering and business metrics. The next time someone asks why code coverage or deployment frequency matters to the business, you’ll have the answer — and a framework to back it up! 😀

Asked to do something illegal at work? Here’s what these software engineers did

Mike's Notes

No excuse ever for being a crook. Amazing CTO had a link to this article on Pragmatic Engineer.

Resources

References

  • The Software Engineer's Guidebook, by Gergely Orosz.

Repository

  • Home > Ajabbi Research > Library > Subscriptions > Amazing CTO
  • Home > Ajabbi Research > Library > Subscriptions > Pragmatic Engineer
  • Home > Handbook > 

Last Updated

29/10/2025

Asked to do something illegal at work? Here’s what these software engineers did

By: Gergely Orosz
Pragmatic Engineer: 02/10/2025

Writing The Pragmatic Engineer. Previously at Uber, Skype, Microsoft. Author of The Software Engineer's Guidebook..

Update on 2 Oct 2025: back in 2021, Charlie Javice, CEO of student loan startup Frank pressured a software engineer to inflate customer numbers. She told the engineer that she did not believe that anyone would end up in an ‘orange jumpsuit’ just for this. Still, the engineer refused – and was proven right. Javice, in fact, did end up in an orange jumpsuit, sentenced to 7 years of prison in 2025 for fraud.

The below topic was sent out to full subscribers of The Pragmatic Engineer, three weeks ago, in The Pulse #66. I have received several messages from people asking if they can pay to “unlock” this information for others, given how vital it is for software engineers. It is vital, and so I’m sharing this with all readers, without a paywall. In the unlikely case that you are asked to do something fishy or illegal: I hope the below will help decide how to do the right thing.

What would you do if you learned your company is up to something illegal like stealing customer funds, or you’re asked to make code changes that will enable something illegal to happen, like misleading investors, or defrauding customers? Here are three real-life cases, where what engineers and engineering managers did had serious consequences.

FTX: an engineering director went along with the fraud

A trial related to FTX, the cryptocurrency exchange which allegedly defrauded investors of $9B, is ongoing. Day 9 of the trial of former FTX CEO Sam Bankman-Fried trial, heard testimony from Nishad Singh, who joined the business as a software engineer, and later became an engineering director. Here is software engineer and writer Molly White summarizes of his evidence:

“To hear Singh tell it, he didn’t even really realize what was going on at FTX and Alameda Research until September 2022 — only a month or two before everything came crashing down. (...) Several times throughout various testimonies, we’ve seen a document written by Sam Bankman-Fried, in which he describes his thinking that Alameda Research should be shut down. That document was, ultimately, how Singh learned in September 2022 that Alameda Research had taken billions of dollars of customer funds from FTX. 

This was when Gary Wang told Singh that Alameda was borrowing massive amounts of customer money from FTX — at the time, around $13 billion of it. Singh testified that he felt ‘really afraid’, and called an in-person meeting immediately. Bankman-Fried, who was sitting next to Singh at the time, ‘seemed unsurprised and made up what I understood to be a false excuse for dodging the meeting.’ Singh, Ellison, and Wang met without him, and Singh confirmed his fears: that he had not misunderstood Wang, and that Alameda had actually taken customer funds to that extent.”

Okay, so in September 2022, Singh had confirmation that something illegal was happening at the company, which he had no direct knowledge of, until then. At that point, if he wanted to avoid being an accomplice to potentially illegal activity, his options were:

  • Talk to a lawyer on how to avoid assisting a crime
  • Turn whistleblower. See the tech whistleblower guide
  • Quit the company, ensuring he did not further aid this activity 

The smart thing would have been to do #1. The profitable thing could have been to do #2 because in the US, a whistleblower may receive a whistleblower reward of between 10-30% of what the government recovers from fraudulent activities. The final choice #3 is hard, but could have meant Singh would not have had to plead guilty as he did. 

Here’s what Singh did instead: he asked for a personal meeting with Bankman-Fried and confronted him about the missing funds. However, Bankman-Fried replied there not much to worry about, and that they’d repay the funds by raising more money from investors (!!) This should have been the point at which Singh quit. Instead:

“He thought about leaving the company then, he testified, but worried that his departure could cause everything to fall apart. He felt that if he stayed, maybe he could help the companies make back what they owed.”

For the next two months, Singh tried to make things better, but it was fruitless. FTX collapsed in November 2022.

Lesson #1: when you discover fraud may be happening, do not “stay around to fix it.” Any other approach would have been better for Singh; seeking legal advice, turning whistleblower, or quitting on the spot.

To be fair, Singh didn’t seen totally clueless, and it seems he decided to profit on the developments. Days after he found about this fraud, he took a $3.7M loan from FTX (!!) to buy a house, The Verge pointed out. It’s exactly the type of thing you don’t want to do after you discover fraud.

Now, Singh is facing up to 75 years in jail thanks to his decision to aid the company after discovering the fraud. His sentence will most likely be reduced due to his plea deal, but any course of action which leads to a criminal conviction is surely a grave error of judgment.

Update in Oct 2025: in the end, Nishad Singh was spared from prison, and received 3 years of supervised release. The judge was persuaded that Singh’s involvement with the fraud was far more limited than that of FTX founder Sam Bankman-Fried or Caroline Ellison, the former CEO of sister hedge fund Alameda Research.

Frank: a software engineer refuses to fake customer data

Frank was a student loan startup founded by Charlie Javice in 2016. In 2019, Javice was featured on the Forbes “30 under 30” finance list, suggesting she was a high-flying founder:


How Charlie Javice appeared on the Forbes 30 under 30 list in 2019. We now know the 300,000 user number was fake. Source: Forbes

It certainly seemed like Charlie Javice was a standout founder; in 2021, JP Morgan purchased Frank for $175M. However, things turned sour quickly. JP Morgan thought it bought a startup with 5 million customers, which worked with 6,000 schools. But after the purchase, this data was found to be mostly fake.

Let’s get to a software engineer’s involvement. This April, founder Charlie Javice was arrested, and a lawsuit is ongoing between her, former Chief Growth Officer Olivier Amar, and JP Morgan. From to this lawsuit, we get an inside look at how events unfolded inside Frank.

In 2021, an engineer was asked to produce fake data for 4.2M non-existent customers. As acquisition talks were ongoing, JP Morgan wanted to validate that Frank had the nearly 5M customers it claimed. In reality, Frank had 293,000 customers, so the CEO asked an engineer to fake the data and turn this list into 4.2M members. Here’s what happened next – from the lawsuit:

“[In 2021] Javice [CEO], Amar [Chief Growth Officer] and the Director of Engineering then had a Zoom meeting during which Javice and Amar asked the Director of Engineering to help them create a synthetic list of customer data. She asked the Director of Engineering if he could help take a known set of FAFSA application data and use it to artificially augment a much larger set of anonymous data tht her systems had collected over time.

The Director of Engineering questioned whether creating and using such a data set was legal, but Javice tried to assure the engineer by claiming that this was perfectly acceptable in an investment situation and she did not believe that anyone would end up in an ‘orange jumpsuit’ over this project.”

Lesson #2: when your manager claims they don’t believe anyone would end up in an “orange jumpsuit,” assume that someone definitely could. The engineering director’s next step? They refused:

“The Director of Engineering was not persuaded and told Javice and Amar that he would not perform the task, and only would send them the file containing Frank’s actual users, which amounted to approximately 293,000 individuals at the time.”

And this engineering director played it right, as the people who are likely to go to jail and end up in orange jumpsuits are the other two people on the call, who knowingly went along with the illegal.

Pollen: an engineer told to double charge customers by the CEO

Last year, I published my first – and to date only– investigative article on how events tech startup Pollen raised $200M and then collapsed, owing months of wages to staff. In the investigation, I focused on an unusual detail: $3.2M worth of funds taken months early from customers. The incident was described internally by Pollen as a mistake, and an incident review should have followed. Even more confusing, the company blamed the payments processor Stripe for the incident.

The reality was that this was a very deliberate double charge. I could not share this fact at the time – as the company threatened me with libel after I informed them of this detail – but the BBC has now produced a documentary revealing details about this deliberate double charge that was covered up as an outage. From the documentary:

[Narrator] “Pollen initially told some customers that the problem was with their payments provider. Later, Callum [the CEO] addressed his staff who were demanding to know what happened.”

[CEO of Pollen talking] “All that happened was that a couple millions of dollars of payment plans that were due to be paid at a later month were then paid earlier. It’s being investigated. We’ve committed already that once that investigation is done, it will be shared with the company so that people understand what happened.”

[Narrator] “With over 1,500 customers impacted, rumors began to circulate about the causes of the incident.”

[Dan Taylor, managing editor at Tech.eu] “From my understanding, there was a creative code ‘malfunction’ that all of the sudden, double charged customers. But that double charge magically happened to meet Pollen’s payroll, that month. Hmm! Odd, don’t you think?”

[Narrator] “The internal investigation due to be shared with the company was never completed, but a group of Pollen staff did their own, unofficial digging. (...) The code contained in the report confirms that the customer's monthly payment plans had been manually altered, which meant that double or triple charges will take place on a single day, without the customer’s authorization.”

The engineer making this change even did a test run the day before, to ensure that this code change “correctly” double charges customers! A former Pollen software engineer appearing in the documentary also makes the point that any code changing production code in payments needs to go through code review, so whoever made this change could have not been acting alone.

Two days after the incident, a senior engineering team member sent an internal chat message to 3 colleagues, where they admit that they had run the script at the request of the CEO. Here is what this message said:

“Also want to come clean that it was me who ran a bad script - in hindsight I wasn’t knowledgeable enough to alter a subset of payment plans for Balvin [one of the events organized by Pollen]. I did this as a special request from Callum and didn’t want to raise on call to handle. It’s been a long week and I displayed a very poor form of judgement.”

In the video, a Pollen software engineer is shown the message, and he says: “I’m not sure I buy this. It seems a bit fishy.”

Lesson #3: if the CEO asks you to do something potentially illegal – document it, and consider not doing it. We don’t know what happened with the senior engineering member who carried out the code changes, following a request from the CEO. This person could have said no, like the engineering director at Frank did. The message sent a few days ago already said that this person regretted doing so, and it’s unlikely that this action was worth the risk it carried.

Update in Oct 2025: no criminal charges that I am aware of have been made related to this double charging at Pollen.

If you take one lesson from this, it’s that you can always say no. In these three stories, the only engineer who’s legally safe is the former engineering director at Frank who point blank refused to assist what could be an illegal request. The engineering director at FTX who stayed after he confirmed fraud was occurring is now facing jail time, while the senior engineering member at Pollen is at the mercy of the UK police, and how they deal with what could be a potential wire fraud case. 

Subscribe to my weekly newsletter to get articles like this in your inbox. It's a pretty good read - and the #1 tech newsletter on Substack.

The Pragmatic Engineer Podcast

Deepdives with experienced engineers and tech professionals who share their hard-earned lessons, interesting stories and advice they have on building software.

Listen to it on Spotify, on Apple, on YouTube, or on the web.

The Software Engineer's Guidebook

I wrote The Software Engineer's Guidebook. Here is what Tanya Reilly, senior principal engineer and author of The Staff Engineer's Path says about it:

"From performance reviews to P95 latency, from team dynamics to testing, Gergely demystifies all aspects of a software career. This book is well named: it really does feel like the missing guidebook for the whole industry."

The Software Engineer's Guidebook

Get the book here.

Annual conference talk

I do one conference talk every year. My last one was at LDX3 (formerly: LeadDev) in London, on 16 June 2025. You can now watch the full talk, online:

Software engineering with LLMs in 2025: reality check

LDX3 is running conferences in New York and in Berlin in the fall of 2025. If you're an engineering leader, check them out.

Thinking Like a Data Engineer

Mike's Notes

Great read here. It takes humility to write this. Thanks, Ananth.

Data Engineering Weekly is an excellent newsletter to subscribe to.

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library > Subscriptions > Data Engineering Weekly
  • Home > Handbook > 

Last Updated

30/10/2025

Thinking Like a Data Engineer

By: Ananth Packkildurai
Data Engineering Weekly: 23/10/2025

Ananth Packkildurai is a data engineering leader, writer, and author of Data Engineering Weekly, sharing insights on modern data platforms, large-scale pipelines, and AI-driven architectures.

I thought becoming a data engineer meant mastering tools. Instead, it meant learning how to see. I thought the hardest part would be learning the tools — Hadoop, Spark, SQL optimization, and distributed processing. Over time, I realized the real challenge wasn’t technical. It was learning how to think.

Learning to think like a data engineer — to see patterns in chaos, to connect systems to human behavior, to balance simplicity and scale — is a slow process of unlearning, observing, and reimagining. I didn’t get there through courses or certifications. I got there through people.

Four mentors, in four different moments of my life, unknowingly gave me lessons that shaped how I approach engineering, leadership, and even life. Each taught me something not about data, but about thinking systems.

What follows isn’t a tutorial. It’s a map of how four people — and their lessons — rewired how I think.

#1. “Chasing Knowledge.”

One of my friends recently asked why you are constantly reading and writing. It all started with an internship. A family friend of mine helped me find an internship. He was the person who taught me Java — patiently explaining not just syntax, but how to think through logic, abstraction, and design.

When I called him after getting my first full-time job, I expected congratulations or career advice. Instead, he said something that I only understood years later:

Don’t chase money. Chase knowledge. Money will follow.”

The advice struck a chord with me forever. In technology, everything changes — languages, frameworks, stacks, even paradigms. But curiosity compounds. The more you learn, the faster you learn. The more you focus on mastering fundamentals, the easier it becomes to adapt when the next wave arrives.

That advice became a quiet compass throughout my career. Every time I faced a decision — whether to take a higher-paying role or a role that stretched my skills — I thought back to his words. And every single time I chose learning, the money eventually caught up.

It taught me that data engineering is not a sprint to expertise, but a lifelong apprenticeship in curiosity.

#2. “Modeling the World.”

It was in my early days of career as a data engineer that I met another mentor — an industry veteran, family friend, and one of the most grounded data people I’ve ever known.

One day, I asked him a question I thought was simple:

“How do I become a data engineer?”

He didn’t answer directly. He just said, “Go to Walmart and tell me what you see.”

I didn’t get it. But I went.

I walked through aisles, looked at shelves, and bought a few things — shampoo, snacks, and batteries. I came back and said, “Okay, I went. I bought x, y, z. Now what?”

He smiled and said, “Now tell me — how would Walmart model this data?”

That’s when I stopped seeing stores — and started seeing systems. I started describing the data model — a shelves table, a products table, a users table, and an events table. I started seeing not a store, but a database. Every product placement was a joint. Every checkout was an event stream.

That exercise reshaped how I saw the world. Data engineering wasn’t about ETL jobs or pipelines. It was about modeling reality.

When you can take something as ordinary as a store and translate it into entities, relationships, and flows, you start to think like a data engineer.

That mental model helped me immensely later. During one of my interviews at Slack, I was asked to design a data warehouse for Netflix. I didn’t start from schemas or metrics. I started by thinking: what’s the store? What are the products? What are the customers?

That grounding in observation and modeling helped me move fast and think clearly.

That day at Walmart was my real introduction to data modeling — not through theory, but through the physical world.

#3. “Thinking in Systems.”

When I started my career in the U.S., I worked on a loyalty analytics system — one of my first end-to-end data design projects.

I spent weeks sketching, refining, changing, and rebuilding the system. Every week, it looked different. One day, as I stepped into the elevator, my boss turned to me and said,

“I saw your design. You changed it completely from last week. That’s good. It means you’re thinking. Keep it going.”

That short elevator ride changed the way I viewed iteration. Until then, I thought redesigning meant I’d made a mistake. But his words reframed it — evolution is the process of engineering.

I started seeing every design review not as a checkpoint, but as a conversation.

Every new diagram was not a failure of the previous one, but an iteration toward clarity.

As we worked together more, he became my go-to mentor — not just for technical guidance, but for how to think. One day, over coffee, I asked him a question that had been on my mind:

“How do you cultivate architectural thinking?”

He smiled and gave me an unusual exercise.

He said, “Every day you walk from Montgomery Street to the Caltrain. It’s what — fifteen minutes? During that walk, observe how the city works. Watch how people who don’t know each other coordinate. Notice how traffic lights, signs, and signals function without central control. You’ll start to see the same patterns in our system design from emergent behaviour to the leader-follower model.”

It sounded odd, but I did it.

Each evening, I walked through downtown San Francisco — watching the rhythm of people, cars, and crosswalks. I noticed how one signal turning green in one intersection triggered waves of motion down the street. I saw bottlenecks at corners, retries when people crossed late, failovers when lights malfunctioned, and officers took control.

And suddenly, distributed systems weren’t abstract anymore. They were everywhere.

Humans, too, were part of a system — loosely coordinated, mostly independent, but connected through protocols, feedback, and flow.

That was the moment I truly understood system thinking — the ability to look beyond components and see interactions, dependencies, and evolution.

It also taught me humility: a good architect doesn’t impose order; they design for emergence. They build for change, not for perfection.

To this day, when I review a data platform design or a data flow diagram, I still imagine that walk from Montgomery Street to Caltrain. Systems are just cities — made of processes instead of people. Once you see it, you can’t unsee it.

#4. “Believing You Belong”

After I moved to the USA, I spent more time doubting myself than writing code.

Every meeting felt like an exam I hadn’t studied for. Every question felt like a test of belonging. I carried a quiet imposter syndrome — that whisper in your head that says you just got lucky.

One afternoon, my boss noticed my hesitation during a design review. After the meeting, he stopped me and said something simple that stayed with me forever:

“If you’re sitting here, you’re already good enough.”

It was a short sentence, but it landed deeply. There was no lecture, no performance review, no pep talk — just a fact. If you’re in the room, it’s because you earned it.

That moment changed how I carried myself. I realized confidence doesn’t come from knowing everything; it comes from recognizing that you’ve earned your seat — and you can grow from there.

I’ve repeated that same line to dozens of people since then — junior engineers, interns, even peers who were struggling to see their worth. Because the truth is, the data world can be intimidating. There’s always a new framework, a new paper, a new “modern” stack. You’ll never feel fully caught up.

But you don’t need to.

You need to keep showing up, keep learning, and keep thinking.

That sentence became the foundation for something else — it taught me that data engineering, at its core, is a confidence game. You’re constantly making decisions under uncertainty: what schema to use, how to partition data, how to handle scale. Doubt will paralyze you faster than a bad design.

Good engineers are not fearless; they just keep thinking despite fear.

Looking Back

When I look back now, I realize that everything I learned about data engineering started with a mindset shift, not a technical one.

  • Don’t chase money — chase knowledge. → Focus on curiosity; mastery compounds faster than rewards.
  • You’re thinking — keep it going. → Iterate relentlessly and observe systems beyond code.
  • Go to Walmart. → Learn to model the world in data.
  • If you’re sitting here, you’re good enough. → Believe in your ability to learn and grow.

The tools, frameworks, and clouds will keep changing. The mental models won’t.

Those mentors taught me that thinking like a data engineer is not about syntax or pipelines; it’s about curiosity, observation, and humility.

It’s about realizing that the best engineers don’t just build systems — they listen to them.

They watch how systems behave, evolve, and sometimes break — and they design with that reality in mind.

These lessons stayed with me — not as quotes to remember, but as ways of seeing the world.

So, if you’re early in your career or doubting your place in the data world, remember this:

You don’t need to know everything to think like a data engineer. You just need to keep observing, iterating, and thinking.

Because in the end, data engineering is less about moving data — and more about understanding how the world moves.

Closing Thoughts

If I had to summarize years of learning into one sentence, it would be this:

“Thinking like a data engineer is not about data. It’s about systems — human, technical, and everything in between.”

The world around you is the best classroom. Every store, street, and signal is a distributed system waiting to be understood. Every mistake is a feedback loop waiting to be improved. Every mentor is a node in your network of thought.

Keep learning. Keep thinking. And most importantly — keep observing.

Once you start seeing the world as data, you realize you've always been engineering it.

Wiring the Winning Organization: The Hidden Management System Behind Extraordinary Performance

Mike's Notes

I'm going for stable, autonomous, self-managing teams. Here is more evidence from IT Revolution.

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library > Subscriptions > IT Revolution
  • Home > Handbook > 

Last Updated

12/07/2025

Wiring the Winning Organization: The Hidden Management System Behind Extraordinary Performance

By: Leah Brown
IT Revolution: 30/06/2025

Steve Spear is Principal at HVE LLC, Founder of See to Solve, and co-author of “Wiring the Winning Organization.” His research on high-velocity learning and problem-solving leadership has influenced organizations from Toyota to NASA to the U.S. Navy.

Leah Brown is Managing Editor at IT Revolution working on publishing books and guidance papers for the modern business leader. I also oversee the production of the IT Revolution blog, combining the best of responsible, human-centered content with the assistance of AI tools.

The number one predictor of organizational success isn’t technology, resources, or even talent—it’s how fast you can solve problems.

In a recent presentation at Prodacity 2025, Steve Spear—coauthor of Wiring the Winning Organization and longtime student of high-performing organizations—shared a startling discovery that challenges everything we think we know about competitive advantage. His research spanning Toyota production plants, NASA missions, Navy shipyards, and technology giants reveals that when organizations have the same resources, technology, and constraints, the winners are distinguished by one thing: their ability to identify and solve problems at high velocity.

The Half-In, Twice-Out Discovery That Changes Everything

Spear’s journey began in the late 1980s when fellow MIT graduate student John Krafcik studied all 186 final assembly plants worldwide. What he found was remarkable: while 181 plants required roughly the same inputs to produce the same outputs, five plants achieved something extraordinary—with half the people, half the physical space, and half the capital equipment, they produced twice the output. This “half in, twice out” performance was all achieved by Toyota plants.

But the advantage was even more profound than the “number four” suggests. These plants didn’t just double productivity—they achieved:

  • Higher initial quality by hundreds and thousands fewer defects
  • Better durability in their finished products
  • Greater agility switching between models in half the time

This wasn’t about being Japanese or making cars. The same pattern emerged across industries and continents: Nokia versus Apple, Yahoo versus Google, organizations before and after transformation. The only variable that consistently explained extraordinary performance was the management system.

Redefining Leadership: From Hero to Steward

What separates winning organizations from the rest isn’t visionary leadership in the traditional sense—it’s leaders who understand their fundamental role differently. When Spear visited Toyota’s San Antonio plant, he asked the new site president about her legacy goals. Her response was illuminating:

“Legacy? I’m a steward. I am temporarily responsible for the management system that allows all these thousands of people’s individual efforts to come together in harmony every day. I just want to make sure when I leave, this system has a better shine than when I found it.”

This stewardship mindset extends to a core paranoia about organizational capability. As the Toyota executive explained, “Because of the number of problems we have, I’ve got to make sure we have a lot of good problem solvers. That’s my concern, that’s my paranoia. Are we developing people everywhere, all the time, to be wickedly good problem solvers?”

The Social Circuitry Problem

Organizations excel at engineering technical systems—the machines, software, and instrumentation that act on objects. But Spear identifies a critical blind spot: the “social circuitry overlay” of processes and procedures that determine whether individual genius translates into collective success.

Most work can’t be done unless we harmonize individual effort into collective action. It’s the processes, procedures, routines, and norms that determine whether we create conditions for people to give fullest expression to their ingenuity, creativity, and problem-solving skill—what Spear and co-author Gene Kim explore extensively in Wiring the Winning Organization.

Too often, organizations inadvertently create what Spear calls the “danger zone”—conditions that make effective problem-solving nearly impossible:

  • Time pressure that forces reactive responses instead of thoughtful solutions
  • High stakes that make experimentation too risky
  • Complexity that overwhelms individual cognitive capacity
  • Isolation that prevents learning from others’ experiences

Three Mechanisms for Escaping the Danger Zone

Spear outlines three key mechanisms that winning organizations use to create optimal problem-solving conditions:

1. Slowification: Taking Control of Time

Our brains can do things very quickly, but only things that are already muscle memory. When you’re triggered in an unfamiliar situation, you’re going to behave very badly. Leaders must engineer situations where people have time for deliberation, repetition, contemplation, and feedback processing.

2. Simplification: Breaking Down Complexity

Taking really big problems and breaking them down into smaller pieces makes the pieces manageable even if the whole is not. Spear uses NASA’s Apollo program as the perfect example—Neil Armstrong’s “small step” was literally small, building on Apollo 10’s descent to 47,000 feet, which built on Apollo 9’s orbital rendezvous testing, and so forth.

3. Amplification: Making Problems Visible

The culture must not only allow but also encourage people closest to the work to identify and escalate problems early. A colleague from the naval reactors program spent 35 years “trying to see little problems before they have a chance to become big ones.”

Democracy in Action: Eliminating “People at the Bottom”

In his presentation, Spear passionately argues against hierarchical thinking that relegates frontline workers to “the bottom of the organization.” “We have documents that say we hold these truths to be self-evident—that all are created equal. But then we talk about ‘people at the bottom of the organization.’ Pick one—they’re mutually incompatible ideas.”

In a powerful Navy shipyard example, a machinist named Emory was given permission to refuse work unless conditions were perfect for uninterrupted completion. When problems arose, senior leaders responded immediately, breaking down silos and creating the support systems she needed. The result was giving frontline workers voice to complain when situations were imperfect, with leadership responding in non-bureaucratic fashion by creating connectivity across silos.

The Bottom Line

Organizations that consistently outperform their peers share one characteristic: they’ve engineered management systems that create optimal conditions for collective problem-solving. They’ve moved beyond heroic leadership models to stewardship approaches that develop problem-solving capability everywhere, all the time.

The competitive advantage isn’t just about having smart people—it’s about creating conditions where those smart people can solve hard problems together at high velocity. If you’re not solving problems at high velocity, you’re losing.

In an era where every organization faces unprecedented complexity and change, the winners will be those that wire their organizations for continuous problem-solving excellence. The question isn’t whether your people are capable—it’s whether your management system creates the conditions for their capabilities to flourish.

The 2025 DORA survey is open now

Mike's Notes

Note

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library > Subscriptions > IT Revolution
  • Home > Handbook > 

Last Updated

03/07/2025

The 2025 DORA survey is open now

By: 
DORA: Copied 03/07/2025

The DORA research program is dedicated to helping technology teams get better at getting better. That journey often starts with a moment of reflection.

We invite you to take 10 minutes for that reflection with the 2025 DORA Survey. Participants often tell us the survey itself is a valuable self-assessment, sparking immediate ideas for how their team can improve.

Your anonymous contribution will also power the industry’s most trusted research on software delivery performance. This year, we’re exploring crucial topics like AI integration, platform engineering, and developer well-being.

By participating, you:

  • Discover potential improvements for your team just by taking the survey.
  • Shape the industry’s understanding of what defines elite performance in 2025.
  • Help create the benchmark you and your peers will use to drive change.

This research is strongest when it includes diverse perspectives. Whether you’re a Software Engineer, Data Scientist, Product Manager, QA Developer, or anyone else who participates in the creation and delivery of software your voice is critical.

Thank you for helping us all get better at getting better.

Consider holding a team discussion about the survey using our discussion guide.

Psychological Safety vs. High Standards: A Misunderstood Dynamic

Mike's Notes

This is an interesting take on learning from making mistakes. I make lots of errors because I try new things, always learn from them, and never repeat the same mistakes.

The main lesson here.

"Psychological safety and high standards are complementary, not contradictory."

Leadership is a fascinating subject. Many "leaders" I have seen in big companies act like psychopaths. And don't get me started on politicians of all stripes .......

I read the book Elon Musk (2023) by Isaacson. Musk is clearly a genius, but there is never an excuse to behave like an arsehole.

Resources

References

  1. Isaacson, W. (2023). Elon Musk.
  2. Edmondson, A. C. (2024). Interview. In Harvard Business Review, Psychological Safety (Emotional Intelligence Series).
  3. Edmondson, A. C. (2012). Teaming.
  4. Edmondson, A. C. (2018). The Fearless Organization.
  5. Edmondson, A. C. (2023). Right Kind of Wrong.
  6. Collins, J. (2020). Beyond Entrepreneurship 2.0.
  7. Argyris, C., & Schon, D. A. (1974). Theory in practice: Increasing professional effectiveness. 
  8. Duhigg, C. (2016). What Google Learned From Its Quest to Build the Perfect Team.
  9. Edmondson, A. C., & Lei, Z. (2014). Psychological Safety: The History, Renaissance, and Future of an Interpersonal Construct.
  10. Edmondson, A. (1999). Psychological Safety and Learning Behavior in Work Teams.

Repository

  • Home > Ajabbi Research > Library >
  • Home > Handbook > 

Last Updated

01/06/2025

Psychological Safety vs. High Standards: A Misunderstood Dynamic

By: Sheril Mathews
Leading Sapiens: 17/10/2024

The term “psychological safety” is often misleading. When managers hear safety, many dismiss it as a soft style that implies complacency. Meanwhile, psychology implies too much mumbo jumbo. High-profile figures like Elon Musk advocating for a “hardcore” style perpetuate this misconception. But this is a fundamental misunderstanding of the relationship between high standards and psychological safety.

In this piece, I unpack the confusion surrounding psychological safety and why you need both psychological safety and high standards to achieve high performance.

In his biography of Elon Musk, Walter Isaacson cites an exchange that’s telling. The backdrop is the initial days after Musk took over Twitter.

Between Twitterland and the Muskverse was a radical divergence in outlook that reflected two different mindsets about the American workplace. Twitter prided itself on being a friendly place where coddling was considered a virtue. “We were definitely very high-empathy, very caring about inclusion and diversity; everyone needs to feel safe here,” says Leslie Berland, who was chief marketing and people officer until she was fired by Musk. The company had instituted a permanent work-from-home option and allowed a mental “day of rest” each month. One of the commonly used buzzwords at the company was “psychological safety.” Care was taken not to discomfort.

Musk let loose a bitter laugh when he heard the phrase “psychological safety.” It made him recoil. He considered it to be the enemy of urgency, progress, orbital velocity. His preferred buzzword was “hardcore.” Discomfort, he believed, was a good thing. It was a weapon against the scourge of complacency. Vacations, flower-smelling, work-life balance, and days of “mental rest” were not his thing. Let that sink in.

Musk had wrought one of the greatest shifts in corporate culture ever. Twitter had gone from being among the most nurturing workplaces, replete with free artisanal meals and yoga studios and paid rest days and concern for “psychological safety,” to the other extreme. He did it not only for cost reasons. He preferred a scrappy, hard-driven environment where rabid warriors felt psychological danger rather than comfort. [1]

Amy Edmondson of Harvard, the leading researcher in psychological safety, defines it as the belief that you won't be punished or humiliated for speaking up with ideas, questions, concerns, or mistakes. It encourages intelligent risk-taking by reducing interpersonal anxiety.

Hundreds of studies, including Google’s Project Aristotle, show that psychological safety is essential for high performance in the modern workplace. Given its importance, you’d think managers would actively work to enable it.

Yet, in practice, these findings often fall on deaf ears. Why is this so?

In my experience, there are two main confusions that muddle the message: “comfort” and “safe spaces.” Let’s examine the two.

Psychological safety is not “comfort”

In Isaacson’s exchange, psychological safety is conflated with “coddling” and “not to discomfort”. Meanwhile, “hardcore” is considered the opposite. The implied message? "Psych safety is for losers; we are hardcore here".

Musk's disdain for the term "safety" stems from its association with a lack of urgency, complacency, and laziness. For him, discomfort drives productivity, where fear and stress combat complacency and push people toward "orbital velocity."

From his perspective, psychological safety is the opposite of high performance. It hinders accountability and the "hardcore" mindset required for rapid innovation. Comfort is anathema to performance, and psychological safety is about free artisanal meals and a lax work attitude.

Musk isn’t alone in making this mistake. As a manager, when I myself came across the concept in 2018 I dismissed it as “soft” and another management fad destined to die.

Edmondson herself acknowledges the problem with terminology:

The term implies to people a sense of coziness — “Oh, everything’s going to be great” — and that we’re all going to be nice to each other. That’s not what it’s really about. It’s about candor, about being direct, taking risks, and being willing to say, “I screwed that up.” It’s being willing to ask for help when you’re in over your head. [2]

Maybe that’s why she called her 2018 book “Fearless Organization” instead of “The Psychologically Safe Organization.”

She clarifies:

Psychological safety is not an “anything goes” environment where people are not expected to adhere to high standards or meet deadlines. It is not about becoming “comfortable” at work.

This is particularly important to understand because many managers appreciate the appeal of error-reporting, help-seeking, and other proactive behavior to help their organizations learn. At the same time, they implicitly equate psychological safety with relaxing performance standards – that is, with an inability to, in their words, “hold people accountable.” This conveys a misunderstanding of the nature of the phenomenon. [4]

Psychological Safety is not about comfort.

Such a climate does not, however, deny failure and whitewash poor results but examines them to see how they can be eliminated or reduced. The reinforcement that comes initially from others and later from oneself is the knowledge that one has made a genuine attempt and that failure occurred only because one's goals were beyond one's current abilities. Failure to perform beyond one's limits is not the same as failure to perform what one is capable of performing. 

— Chris Argyris, Donald Schon, Theory in Practice

Let’s look at the next culprit.

It’s not about “safe spaces” either

Another term that adds to the confusion is 'safe spaces.' Although sounding similar, they serve different purposes and come from different contexts. Even experienced practitioners get these two mixed up.

Safe spaces originated in social movements and are designed to be environments free of conflict. They're found in educational settings or communities dealing with sensitive issues, where the goal is to protect individuals from potentially harmful situations. Discomfort is intentionally minimized, and clear boundaries are set from the outset.

Meanwhile, psychological safety emerged in the context of organizations and team dynamics. It focuses on creating environments where people feel safe to speak up, make mistakes, and take risks, especially in challenging, high-stakes situations.

Unlike safe spaces, psychological safety doesn't aim to eliminate discomfort. Instead, it ensures discomfort is productive — an essential part of learning and growth.

Safe spaces are about protection from external judgment by removing threats or negative stimuli. In contrast, psychological safety encourages risk-taking for group performance and learning.

This distinction is crucial. Equating psychological safety with safe spaces creates the misconception that it means avoiding accountability or difficult feedback. In reality, it is compatible with high standards and challenging expectations.

The role of leadership also differs. In safe spaces, leaders act as guardians, setting and enforcing norms to protect members. In psychologically safe workplaces, they model fallibility, ensure open dialogue, practice humble inquiry, and frame failures as learning opportunities.

A psychologically safe workplace isn't devoid of challenge or discomfort; it ensures that discomfort is generative, not destructive.

What Psychological Safety really is

Psychological safety isn't about avoiding discomfort; it's about ensuring that discomfort — what Musk calls "hardcore"— fosters growth, intelligent risk-taking, and learning. He is half-right: there's no growth without discomfort. But for people to embrace it productively, you need psychological safety. This means creating an environment where people feel secure enough to fully engage, experiment, make mistakes, and challenge themselves and their leaders.

Contrary to misconceptions, psychological safety enables — not hinders — the "discomfort" and "hardcore" approach that Musk advocates. It's not about removing accountability or avoiding challenges, but supporting people to confidently face them head-on.

To use one of Edmondson's analogies: psychological safety is like removing the brakes that keep a car from moving, while high standards act as the steering mechanism. Without it, even with high standards, you risk chaos—team members may be too afraid to accelerate, or if they do, they might crash due to uncertainty.

While discomfort is indeed a powerful catalyst, it's an error to assume stress and fear are the only ways to generate urgency. High standards are most effective when people feel supported in reaching them. Without psychological safety, innovation suffers as people avoid exposing their vulnerabilities or lack of skills, fearing ridicule and punishment.

High-performance teams understand that excellence requires iterative failures. They don't demand perfection; instead, they encourage trial, error, and adjustment. In this environment, failure isn't just tolerated; it's an integral part of the process.

Expectations remain high, and people work hard. However, the crucial difference is that it's safe to fail and learn, driving both individual and organizational growth.

The 4 organizational archetypes

Elon Musk's management of Twitter is an extreme example of coercive power. He let go 75% of the workforce to ensure only the "hardcore" survived. The idea was that discomfort would push the remaining employees to innovate and execute faster, which, to some extent, did happen. Twitter continued to operate, albeit in a diminished form, and introduced new features with a much smaller staff.

High pressure and discomfort can indeed lead to bursts of productivity, especially in a crisis where the stakes are high and the need for immediate action is clear. However, sustained pressure without psychological safety leads to burnout, reduced creativity, and reluctance to take risks. People focus on avoiding failure rather than striving for excellence. This anxiety undermines the creativity that companies like Twitter need to thrive.

This interplay between high standards and psychological safety is depicted by Edmondson’s 4 organizational archetypes:

Psychological safety and high standards.

High Safety, Low Standards (Comfort Zone)

This is the version of psychological safety Musk imagined — one where no one is pushed to excel. Teams enjoy a collegial atmosphere and are comfortable but lack challenge.

While this might seem pleasant on the surface, it's not conducive to learning, innovation, or high engagement. Without a compelling reason to push boundaries, teams don't grow or achieve significant results.

It’s a breeding ground for complacency. There’s a lack of healthy conflict or debate, with people agreeing too readily to maintain the status quo. Without a pressing need to improve or take risks, innovation stagnates. The desire for harmony overrides critical thinking, leading to groupthink. This results in a decline in competitive edge and market relevance.

Low Safety, High Standards (Anxiety Zone)

This quadrant epitomizes Musk's "hardcore" management. It's a common pitfall in modern workplaces, where leaders demand excellence but fail to cultivate psychological safety. The result is an anxiety-inducing environment that undermines the very performance it seeks to enhance.

There’s often a veneer of productivity masking deeper issues. Teams may seem to be highly productive, but there's increasing signs of burnout – absenteeism, declining work quality, and a blame culture. Information is hoarded for job security instead of shared for collective benefit.

Teams retreat to the status quo, paralyzed by the fear of failure. Crucial questions remain unvoiced, stifling quality and ingenuity. The organization inadvertently cultivates a risk-averse workforce, favoring "safe" decisions over potentially transformative ones.

People work hard, but primarily out of fear. While it may yield short-term results, it limits an organization's capacity for breakthroughs and sustained growth.

High Safety, High Standards (Learning Zone)

This is the sweet spot where psychological safety and high standards coexist. In this quadrant, people feel empowered to take calculated risks, voice unconventional ideas, and own up to mistakes without fear of repercussions.

It balances both comfort and challenge. Ideas are challenged respectfully, regardless of the source. Feedback flows freely and constructively in all directions, regardless of hierarchy. Teams feel secure enough to push boundaries and tackle complex problems, knowing they have support.

Failures aren't career-ending; they're viewed as learning opportunities. Cross-functional collaboration happens organically, as people seek diverse viewpoints to solve problems. Innovation thrives because people feel safe to experiment. They're not paralyzed by fear of failure but energized by the possibility of breakthrough. This creates a dynamic, engaged workforce pushing the envelope.

Low Safety, Low Standards (Apathy Zone)

Without safety or standards, people do the bare minimum to stay employed. Team members may engage in “presenteeism” or “quiet quitting” - showing up physically but not mentally. They likely prioritize self-protection over extra effort, leading to unproductive behaviors and conflicts. This is common in large, bureaucratic organizations where people have figured out how to do their jobs with minimal effort.

In these places, mediocrity takes root along with passive-aggressive behavior, office politics, and a lack of initiative. There’s also high turnover rates and strong resistance to change.

People develop learned helplessness, believing their efforts won't matter. It creates a destructive cycle where low expectations lead to low performance, reinforcing apathy.

The paradox of “hard” and “soft”

Psychological safety and accountability are not two ends of a continuum, but rather two distinct attributes of a work environment. [3]

The dichotomy of either psychological safety or high standards is a classic case of “either/or” thinking. Effective leadership requires an “and” approach: integrating both psychological safety and high standards to create places where people can take risks and be challenged simultaneously.

A culture that makes it safe to talk about failure can coexist with high standards… This is as true in families as it is at work. Psychological safety isn’t synonymous with “anything goes.”

A workplace can be psychologically safe and still expect people to do excellent work or meet deadlines. A family can be psychologically safe and still expect everyone to wash dishes and take out the trash. It’s possible to create an environment where candor and openness seem feasible: an honest, challenging, collaborative environment. I’d go so far as to say that insisting on high standards without psychological safety is a recipe for failure— and not the good kind. [5]

Psychological safety and high standards are complementary, not contradictory. The job of leadership is to both challenge and support. It allows people to fully commit to high standards because they trust they won't be penalized for mistakes or deviations during the learning process.

Jim Collins calls this leadership dynamic “the paradox of hard and soft”:

A good leader doesn’t demand high performance (demanding implies that people are basically lazy and are inclined to withhold their best effort—that it must be extracted out of them, like pulling teeth). No, a good leader offers people the opportunity to test themselves, to grow, and to do their best work.

There is no shortage of people interested in doing something in which they can take pride. But there is a vast shortage of leaders who provide the stimulation of stiff challenge and high standards, combined with the uncompromising belief that seemingly ordinary people can do extraordinary things.

Leaders who build great companies master the paradox of hard and soft. They hold people to incredibly high standards of performance (hard) yet they go to great lengths to build people up—to make them feel good about themselves and about what they are capable of achieving (soft). [6]

As leaders, the challenge is to create an environment for team members feel secure enough while pushing to meet ambitious goals. It's not about implementing policies, but about modeling and reinforcing behaviors that support both safety and excellence.

Pay attention to subtle indicators. Are team members engaging in candid discussions about failures? Do they proactively seek feedback? These signs can help you gauge if you're in a "Learning Zone" or "Anxiety Zone".

The goal isn't to eliminate discomfort, but to ensure it serves a productive purpose. Mastering this balance sets the stage for excellence.