In 2025, I never publicly reflected on my work experiences. I used to treat work as everything and didn’t want any negative commentary to create uncertain consequences. But in reality, this year brought profound reflections and bitter lessons.
This article covers three things: a confession, systems theory, and thoughts on antifragility.
The confession is rather thin—nothing actually happened in reality, mostly just imagination in my head. But I’m including it here to add some flavor to the article. After all, who doesn’t love gossip?
Systems theory is a framework I’ve gradually developed a clear understanding of this year. So I also want to use this article to share my understanding of systems.
The Confession
In March 2025, I was job hunting. I came across an internal referral post for a foreign company on V2EX. I thought: why not go there to learn English? With just that thought, I submitted my resume, passed the interview, came to Changsha, and met the colleague who referred me.
Our first meeting went well, I thought. After that, every afternoon at lunch, I’d go to his office to find him. There were two other people in the office. Sometimes they hadn’t finished what they were working on, so I’d wait. Even though I was bored, I was willing to wait. After lunch, we’d usually walk along the Xiangjiang River. I really enjoyed listening to him talk about his previous work or family stories. It sounded so real, and he seemed so genuine.
The mechanism of liking someone is simple:
First, you need to be clear about what matters to you: looks, physique, intelligence, way of thinking, financial capacity, social status, or family background. Everyone’s priorities are different—you just need to focus your attention on what’s important, and everything else becomes background noise.
Next, chat and interact to test and match the feeling.
Of course, reality is always thin, so when the feeling is right, you add some imagination and filters, replaying the details of your interactions in your mind, giving those details special meaning.
So: target preference → test matching → meaning reinforcement—if you pass all these steps, that’s liking someone.
Day after day passed. I just wanted him more. I didn’t want to keep pulling back and forth between my reality and consciousness anymore. One evening, I confessed.
He rejected me with three reasons. It hurt a bit, but it was acceptable. I didn’t expect the impact of rejection to last so long. My emotions needed an outlet, so I rationalized the whole thing and shared it with many people like it was just gossip.
Someone told me I shouldn’t have confessed so rashly, that I should have spent more time together, chatted more, let things develop naturally—maybe without even needing to say “I like you.”
He had a point. I could try that next time. But then again, in life there are moments when you face a choice, and either option is fine. What matters isn’t what you choose, but whether you can accept the consequences of that choice and take responsibility for it. I chose direct expression, so I accepted the result of being rejected.
A few months later, I no longer felt awkward. Apart from work-related communication, we had basically no contact.
One day, I saw a capybara keychain on his phone. I guessed it was from his girlfriend, and a funny thought popped into my head: rip it off and throw it in the trash.
After that, I never liked anyone else again. I mentally reviewed every guy I’d ever known in my life and concluded: there’s no one I like anymore. I even tried wondering if maybe I actually liked women? Conclusion: no, not that either.
In the following months, I completely stopped thinking about this because the pressure from my work environment kept growing.
How the Pressure Accumulated Bit by Bit
The First Lesson from the Hackathon
When I first arrived, I happened to catch a hackathon competition.
The team I joined was very diverse, including tech, testing, techical writer and design, while most other teams were basically just developers. I found this organizational difference puzzling, so when chatting with another colleague, I described our team as having “biological diversity.” I got a lesson in “bureaucracy” for that. The person told me: “Before you came, all these people were handpicked by leadership.”
This was my first moment of discomfort and conflict. When you have doubts in this environment, you get suppressed and even negatively interpreted. This environment couldn’t hold my confusion, couldn’t help me grow—it was even eroding my qualities, even disgusting me with bureaucracy.
Of course, if I were to acknowledge my own issues, I could say my communication style and expression weren’t good enough. The boss’s assessment of that colleague was that she was very smart and told me to interact with her more to learn. But from the “biological diversity” example, I knew our values were different and we were destined not to get along. Later I found out she really was smart, with social abilities I couldn’t match. She is the social queen.
Doubts About the Circle
The company was a foreign enterprise, with about 60 people in a small circle in Changsha. I was repeatedly reminded that this place valued technology highly and many people were very capable. I was skeptical and kept looking for evidence, but the longer I stayed, the more I found that their definition of “technical atmosphere” was different from mine. There was indeed one genius, but I rarely worked with him and could only observe from afar. I imagined him as a geek, as a symbolic support for staying here.
Backend Interface Confusion
I’m a frontend developer who needed to interface with backend. The first thing that felt strange at work was: why are the backend interfaces so atomic? The backend couldn’t explain it clearly either. Their answer was basically using the atomic reason “business needs” to answer me, without any specific explanation.
It felt like you ask why, and they answer you with the question itself, with no other logical evidence or reasoning process.
It wasn’t until half a year later that I found a reasonable explanation for this problem: this was a 0-to-1 product, and in the early stages you need to deliver features quickly for validation. I continued observing the team’s development with this reasonable explanation, but I found I had been too optimistic about my interpretation. There was no rapid validation here at all. The team’s work was more like going through the motions, with no real value delivery or long-term thinking.
So this was another way this environment didn’t suit me: not only couldn’t it hold my confusion, but everyone else in this system had no doubts—only I had doubts. This was an organization with low learning rate and low reflection.
Requirements Ambiguity and Responsibility Shifting
Product requirements were my biggest headache.
First, the inconsistency problem. You had to integrate the requirements from three different dimensions: verbal explanations, written descriptions, and prototype designs—trying to piece together what the product actually wanted.
Second, requirement value couldn’t be externally validated. For example, changing the layout seemed to be just because the product liked it, so you had to change it. This approach had no rigorous, systematic System Design whatsoever.
Third, responsibility shifting. Without prototypes or proper documentation for major changes, developers as the implementation layer had to define the scope and standards of changes themselves, even creating multiple versions for them to choose from. After issuing requirements, the product people only did the most basic progress tracking, acting like bosses playing supervisor. They seemed to vaguely enjoy the manipulative thrill that comes with having authority. Whenever requirements were questioned, they’d deflect responsibility. In this team, developers and testers who could survive were either more experienced than them or obedient and compliant. Those with judgment but not strong enough yet, and unwilling to play dumb, were continuously drained.
Of course, this kind of role ambiguity certainly exists, but what’s worse is that the product people here weren’t even aware of the premise of role ambiguity. They thought this work should naturally be undertaken by developers.
The first time I encountered this, I hoped the product could give clearer requirement definitions. I then also expressed my implementation approach regarding code writing requirements, hoping they could combine this information to give more specific requirements. However, the response I got was the workplace PUA trilogy: victim-playing and deflection under a righteous narrative shell, moral blackmail under the banner of “owner consciousness,” capability insults and concept substitution.
One inference: if everyone on a team has a high sense of responsibility, then whoever calls for “owner consciousness” is actually doing responsibility shifting.
My best friend said, since they don’t know, just define it yourself—how great to be able to define it yourself. I agreed with this principle: when there’s no standard, you need to define the standard. But thinking back now, I need to add a supplement: not only do you need to define it, but you also need to expose the systemic risks of this lack of clarity. If this work must be undertaken by developers, then use engineering methods, like documentation and paper trails, to make the lack of clarity explicit.
This was my first conflict with product side. Later the boss even held a meeting for the three of us to coordinate. But I could clearly feel that the boss wasn’t clear on the details—his understanding of this matter wasn’t as deep as mine. And although his conclusion in the meeting was to acknowledge my approach, his actual alignment was with the product side.
Looking back, this was another way this environment didn’t suit me. Even if my communication style could be improved, they didn’t cultivate better communication methods in me—instead they used workplace PUA to suppress me. Although the boss to some degree seemed to lean toward my side, his ultimate position was inconsistent with what he said and did. Moreover, in this team, I heard many people comment that I was “too idealistic,” calling themselves “old workplace veterans” with years of experience, using this empiricism to make me question myself.
Of course, this environmental confrontation also deepened my understanding of engineering. I realized engineering methods can be used not only in code organization and architecture design, but also in product development process design. This is a way to transform lack of clarity, complexity, and human subjectivity into verifiable and traceable systematic design through institutionalized, formalized, and reusable process methods.
Meeting Conflicts
At an experience-sharing meeting that invited people from other BUs, I just wanted objectives. But throughout the whole session I didn’t hear a single point. The speaker kept breaking boundaries and diverging. What I wanted was a solution that weighed trade-offs and pushed things forward.
However, the speaker kept repeating the weighing process, even guiding things in the opposite direction of the trade-offs. My expectation for this meeting was: everyone should already have the premises and results of weighing, and next we should all push toward the positive goal. And I thought everyone had this expectation as I did.
So when I didn’t hear a satisfactory answer, at the end of the meeting I said without any reservation: “After listening for so long, I didn’t hear any conclusion. I don’t even know how to write the meeting minutes—there are no action items.”
The PM immediately pushed back. I forget what she said, but she thought I was criticizing and denying the speaker’s sharing. I knew what she meant—she wanted me to express myself like she did, first praise a bit to liven up the atmosphere, then discuss the matter itself.
The boss said nothing the whole time. Honestly, I was worried about leaving a bad impression on him, but I felt the general direction was fine and didn’t care about his opinion anymore.
After the meeting, another frontend developer also came to criticize me, saying I couldn’t criticize the presenter in a meeting. I was speechless, and thought: who would criticize individuals in a work setting? I was grateful to the presenter if anything. Then I said: “I didn’t mean to criticize. If I wanted to praise him, I have plenty to say, like I noticed the presenter has done a lot of technical thinking… What do you think the goal of this meeting was? Even if I do have expression problems, that’s separate from the meeting objective.” She replied with more, and I responded: “That’s just your interpretation, it doesn’t represent what he actually thinks, right?”
To confirm the person’s feelings, I messaged him on WeChat. He seemed fine. Between “brothers”, there’s only tech. I originally had no bias against women, but these three women gave me pressure that always made me feel excluded, as if they wanted me to be like them, giggling and chatting about everyday life after work. I’d like to, but that’s not my personality.
This exclusion also happened in weekly retrospectives, where I had to listen to them praise each other. At first I struggled internally for a while, then thought about it—the most beneficial approach for me would be to praise them too, but I could never abandon my just-stick-to-the-facts style.
This was another way this environment didn’t suit me: work style disharmony. What dominated this environment was a false experience of humanistic care, with overall low sense of responsibility and morality in the team.
Why say this humanistic care is false?
If it were real, it should be consistent, showing humanistic care to everyone. So when they blamed me, shouldn’t they also consider this would affect my feelings? Shouldn’t they also pay attention to their own expression, not making me feel criticized?
Taboo Topics in One-on-One Meetings
For year-end reviews, the boss gave me the highest score in the whole group. Rationally I felt good about it, but I had this invisible pressure—I knew those three women would definitely gossip about this behind the scenes.
After the year-end scoring there was a one-on-one meeting. Honestly, I didn’t feel it went well. I shared my views on how the lab operated. Recently there had been zero-sum personnel movement in the lab—someone left our group, but I hadn’t seen any product 2.0 plans on the roadmap. I was somewhat doubting whether the lab was really seriously making products. Another reason was that I observed the lab’s products always ended up going nowhere after being made, with no retrospectives or experience summaries, I wanted to see what the boss thought about how this lab runs, whether it matched what I was experiencing. I noticed the boss’s expression became very serious—it looked like I’d touched on a taboo topic. The boss’s answer didn’t satisfy me much and even made me feel his decision-making logic wasn’t rigorous, lacked long-term thinking, was just improvising. Or maybe he had thought about it, knew the environment didn’t operate this way, just wasn’t willing to tell me.
In the meeting the boss mentioned that the other frontend developer had come to him for an explanation about the performance score, feeling it was unfair. I said nothing, just internally verified the fact of where my invisible pressure came from. I’d thought about disliking this frontend developer, but I found that disliking her didn’t make sense by any calculation. On the contrary, I should back her up.
A few days later, my best friends shared with me that she was reading “How to Win Friends and Influence People” and had just read this line: “Now I am convinced that bluntly telling someone they’re wrong has no benefit whatsoever and only causes all sorts of bad consequences. Your only gain is trampling on their self-esteem and making yourself unwelcome in any situation.” I agreed with this and excerpted the passage.
After this meeting, I’d already concluded this place wasn’t right for me and I should leave soon.
The Attack in the Retrospective Meeting
I gave a report to my boss’s boss, and as a developer in the meeting I said we needed business definitions. I didn’t think about the consequences of this statement. At the time I was just sticking to the facts—as a developer, my assessment was that this element was indeed lacking.
A few days later, an internal retrospective meeting was called, and I got “attacked” badly. The PM and PO used pretty rhetoric, not speaking directly, first invoking the righteous weapon of “align internally first, abstract when reporting upward”—which I also agreed with. I also clearly knew they were implying I shouldn’t have asked for definitions in that meeting, but I only thought to the level of “shouldn’t have.” After the meeting, I heard from the other frontend developer that they were actually dissatisfied with me about this because I’d angered them—my approach made them lose face in front of the boss’s boss. Finally, they compared me with the other frontend developer, turning it around to say I lacked initiative on projects, didn’t proactively align with them, and had poor self-management.
I really wanted to refute using their logic, like self-management is a requirement for everyone, expeciall for PO and PM who are truly responsible for the product, so why don’t they take initiative? But I felt this was too disgusting. I have a strong moral sense—I demanded of myself not to use this logic to shift responsibility onto others. I could only say I’m not a talkative person by nature, I rely on processes and systems.
The boss said none of this was wrong, but in a small company, processes and systems slow down efficiency. His logic was always fuzzy, adding details according to actual needs to pick sides. This time, I knew he’d sided with product again. I became even more aware of his problems as a boss: doesn’t understand architecture so can’t participate in technical discussions, doesn’t understand business so can’t evaluate value. In management and decision-making, he could only pick sides based on authority and position. Of course, there’s another possibility—he clearly understood everyone’s stance and position in this team, but chose to sacrifice me. Sacrificing me, the rest could continue working for him; if product left, that wouldn’t work. I thought about what I would choose if I were in his position. But anyway, I’m not in his position, and I no longer trusted him.
Thinking of this, I recalled again what Uncle Ben said before dying in Spider-Man: “With great power comes great responsibility.” In this organization, was there anyone who shared this value with me?
Also, the more clearly you can see a system’s dilemma, the more your choices at the moment of weighing reveal what kind of person you are. Some people’s words and actions are completely inconsistent—this makes you appreciate the rarity of integrity even more.
Another developer responded to the “self-management” topic for me, objectively and neutrally pointing out the difference between projects: one had clear business with clear steps, the other was refactoring where value still needed to be clarified. At that moment, I felt someone was speaking up for me, and I couldn’t help but cry.
The evening of this meeting, my best friend and her husband video called me and learned about the situation. They advised me not to make any decisions while my emotions were running high, to take time off and come visit them. So I took Thursday and Friday off, making it a 4-day break, and went to their place.
What happened at the company played over and over in my mind. I couldn’t help thinking about how to refute and vindicate myself, then realized this was stupid, told myself to stop, don’t seek validation, it’s not worth it, don’t waste emotions. Then after a while my attention would return to the company, and I’d start arguing for myself again, then stop myself again. Back and forth like this.
Being with my best friend was comfortable. We lay on the sofa watching TV shows at night. While watching, I suddenly remembered what happened in the retrospective meeting again. My eyes got moist and tears wouldn’t stop. My best’s husband said “stop thinking about it, look forward.” He was right. I wiped away my tears and collected my emotions. Leaning against my best friend, an English phrase came to mind: “Slap that bitch”. I said to my best with a smile: “That woman is so awful, can you give her a slap for me?”
It was so ridiculous. Rationally analyzing, I didn’t actually want to do this. Even though they were indeed awful, I even knew I wouldn’t take this to heart, because I’d already realized the whole problem was brought about by systemic structural fit. But I needed to release this breath, so I picked up a plush toy from the table and gave it a light slap.
After those 4 days I’d decided to resign. I wanted to drag it out until after the New Year to add one more month to my resume, so on the first day I requested 15 days off. HR talked to me, wanting to understand the reason for my leave. I said my mom was sick, which was true, but I knew it wasn’t the main reason. She mentioned that I’d cried in last week’s meeting and guessed it was related to this. She guessed right, but I couldn’t say it was because of this. I said nothing, but tears uncontrollably flowed from my eyes. After briefly put myself together, I still didn’t say anything. She kept pressing step by step. I could see she was setting up a framework trying to get me to jump in and tell the truth. I even found this test funny in the moment. This lucid awareness felt incredible. I wanted to laugh, then I quickly jumped out and asked can I still take the leave? She said yes. Later 14 days of leave were approved, and I promised to make things clear after the New Year.
People in the group probably knew I was unstable because I received some probing.
There were more meetings in the following days. After one meeting finished, I realized this environment’s drain on me was no longer worth staying even one more day, so on Thursday I submitted my resignation. Then came the exit interview. The Rednotes told me to never tell the truth in exit interviews, to find some excuse (like family matters). But during the interview, faced with HR’s first question—“What are you thinking?”—I found I couldn’t tell lies. I cried. After briefly collecting my emotions, I told all my doubts about the projects here and operating mechanisms. The boss was inevitably questioned too. While speaking, thinking, struggling whether to tell the truth, after questioning I had to explain—I couldn’t blame anyone, this wasn’t a personal problem, because I’d thought of objective systemic factors, like the company’s strategic position at headquarters.
Finally, I said: Everything seems reasonable, but only my feelings are real. I have to decide what kind of person I want to become. In my view, this environment doesn’t suit me, and clearly I don’t match this position either.
The Unstable Element in the System
During those 4 days of leave after the retrospective meeting, I reviewed my entire experience at this company, analyzed the organizational structure, redefined myself and the environment this company created. I made a choice and self-confirmation: what kind of person am I, what kind of person do I want to become, what kind of environment suits me. Emotions mixed with rationality, then emotions invaded again after rationality. Back and forth.
The final conclusion: resign. From the current perspective, this system is draining me, eroding the qualities I want to develop. This system doesn’t suit me.
I am an unstable element in the system; they are unstable elements in my system.
This is a low-externally-verifiable execution-oriented organization. I wanted to use logic and systems thinking to deliver value, stay objective and neutral, stick to the facts. This system only pays lip service to this—in reality it suppresses thinking and value, rewards circles, obedience, and responsibility shifting. These “justices” are always used as weapons to protect oneself, shift responsibility, or substitute concepts. Moreover, reflecting on this year, the work environment constantly subjected me to suppression from empiricism saying I’m “too idealistic, too young, unrealistic.”
Writing this really does sound like elevating myself and belittling others—it’s indeed inappropriate. I want to stay as objective and neutral as possible, but I have no other words to describe this situation.
I can only say: this isn’t about moral superiority or inferiority, only about compatibility.
I can understand the source of my internal struggle. From a systems perspective, my internal struggle is also reasonable: when I refuse to point the finger at individuals, yet also haven’t clearly returned responsibility to the system itself, and there’s no intervention from someone with authority, then responsibility automatically flows back to me, becoming the internal struggle of “is it my problem?”
I can also understand each person’s narrative and behavioral logic. For example, that frontend developer who privately went to the boss feeling unfair—from their perspective, they might indeed feel like they described, that they’d already worked very hard, so why didn’t they get the same score? It does seem unreasonable.
Although emotionally I really dislike those product people and have lost trust in the boss, those people were also trained in the workplace. Whether they’re networking, playing office politics, or shifting responsibility—these are all survival methods they’ve practiced. When they use these methods here, is there really a problem? It seems there isn’t. From a systems perspective, they’re not awful—they’re just adapting.
And the boss—although he gave me the highest year-end performance score, trying to publicly show the team he rewards these qualities, in reality when it came to actually taking sides, he chose the product side. As a leader facing systemic coordination issues, his final alignment, his thoughts versus execution, conflicted with his ideals—is this also his problem?
Moreover, considering all position architecture strategies within the organization, as well as factors like geographic location of positions, among the candidates who could match, how much is due to human manipulation?
Thinking of these things, how much space do I really have to blame?
The only factor related to people that I can evaluate is: these people’s choices (when interacting with the system) are inconsistent with mine. They chose different paths, but can this be evidence for me to criticize them? Simply because what they chose is different from what we chose.
So looking at all this, the conclusion I can draw is: in the workplace, this system isn’t wrong—it’s just not designed for me. And if I continued staying, that would be irresponsible to myself.
The Communication Panacea: Survival Strategy Within the System
Recently, besides handover work, another thing was to chat more with people here.
When I talked about this with a colleague, his perspective was a brief conceptual impact for me. He felt that within this system, I actually had better solutions when handling conflicts. I define this value system as: the communication panacea type.
He helped me analyze some specific interpersonal collaboration conflicts and provided corresponding communication solutions. I thought what he said made sense, and at the time I didn’t think of a better counterargument. Because probabilistically speaking, good communication methods can indeed play a lubricating role.
But thinking more carefully later, I found the premise of this method is that you acknowledge: all conflicts are essentially problems of misunderstanding, insufficient expression, or emotion management between people. Under this premise, good communication methods are indeed a universal solution.
But this method itself isn’t a solution to the systemic structural problems I see—it’s a tactic to reduce friction with the system.
I’ve already seen the structural problems, and the magnitude of friction doesn’t actually change the main contradiction. Thinking about solutions from this main contradiction, there are usually only three choices:
- Either you have the power to reform this system and define system rules.
- Or you leave this system.
- Or you change your core to comply with this system.
So you can see communication’s relationship with these three solutions:
In the first choice, communication is a means, a tactical tool for achievement. You can build influence through communication, but you need to calculate the ratio of this influence to the emotional drain, experience, and time investment you consume to see if communication is feasible.
The second choice is to directly not communicate, to cope by changing yourself—nothing much to say about this.
The third choice is to change yourself. Changing your core isn’t actually simple. This doesn’t mean directly changing your entire value system, but rather, for example, changing your goals at the company:
(a) You might initially feel you’re at the company to obtain and realize value.
(b) Later you find this system doesn’t fit you, so you can switch to a minimal goal: just take money and do work.
(c) Most miserably, you directly rebuild your value system, changing your core and also changing the “you” that previously defined you.
Looking at all this, you can see how many decision-making components exist in individual and system operations. How many mechanisms do you need to build to adapt to this system? How much determination do you have to persist in the values you believe are right? In this process, how many compromises have you actually made?
One of the most useful courses I learned in elite education is that you have to make choices without grasping the full picture. And when you face choices, what matters isn’t what you chose, but taking responsibility for the consequences that choice brings after making it.
The Feeling of Being Trapped by the System
During the resignation preparation phase, I also kept thinking forward. I was thinking about what kind of team really suits me, but I found that no matter how I think about it, from a macro perspective, all these path choices might be seen clearly by higher-order cognition, predicted and controlled, then judged as too idealistic, too young, taking detours. It feels like I should be like them, comply with the system early and become one of them. Looking back, when I was interacting with the system, some of my cognition did change, and these changes seem to have really been prophesied.
This thought made me feel like I’m on a map. Assuming I have multiple path choices, no matter which one I choose, I’ll be trapped by the system, taught by experience, then adjust direction and be taught by another set of experiences. This way, wherever I go is wrong, all controlled by others.
On the other hand, I feel people in this world are all confused and uncertain, meaning is self-created. So why is this uncertainty completely opposite to the certainty of being controlled and trapped mentioned above? Can I not find a breakthrough?
I thought about it—the breakthrough lies in: the system boundary being trapped above is small, while human uncertainty has a much larger range, like the tip of an iceberg. I need to see clearly earlier where this certain system boundary is, then find an open space, define my own rules, attract a wave of like-minded people, and exercise initiative. This is the breakthrough.
But as long as people participate, my defined system will be eroded by previous experience. People smarter and more experienced than me can quickly master the patterns of the system I define, even transform or replace my system, and then my breakthrough is gone again.
If I make choices in a finite rule system, not complying with the system, using other objective functions to change the system, then I’m always punished, always trapped by experience, taking detours. I’ll get hurt, and some costs might be unbearable.
So reasoning this way, I act with the thought “can’t change the system.” Of course the premise is: this system is absolutely or relatively (highly probably) a finite rule, unchangeable system.
The good thing is, I stay open, explore this system’s boundaries, align goals, prepare for my own system, accumulate material and settle thoughts.
Reasoning this way, I can’t wait until certain before acting—there’s no certain thing. So what is very stable, unchanging and certain within my finite lifetime? This way, every time I’m accidentally attacked and broken through, I can always return to a complete Land to restart.
If looking in the external world (companies, professions, tech stacks, even countries), nothing is stable. They’re all finite rule systems with life cycles.
The only Land is my internal antifragile structure:
- My craft and flow state. Writing code, system design, writing, thinking about problems—this creative thrill is a biological reward to my brain. As long as I’m thinking, no one can take away the sense of control in the moment.
- My metacognitive ability. I’m always observing the self being observed. My metacognition can always extract itself to observe my rationality and loss of control, allowing me to be examined objectively and neutrally. As long as I can still review and think, can deconstruct pain and confusion, then I won’t truly be defeated.
Systems Thinking
In less than a year at this company, my greatest growth has been in systems thinking. I can use this thinking to analyze organizational operations, switch perspectives to understand narratives, then analyze what I want and what choices to make.
Every system has a value function that it revolves around to achieve its goals. However, systems often have gaps between ideal and reality. It’s more like a gray box—you must test it yourself to understand how it truly operates.
Moreover, I now realize that what systems pursue is stability, not achieving the goals set by the value function. Achieving the value function is just an important way to supply this system, but its ultimate purpose is to maintain the system’s operation. The process of achieving the value function can be defined through different narratives, multiple times and from different angles.
Another is my view on open systems.
If it’s a closed system, both its value function and boundaries are fixed. Such systems often can’t satisfy everyone.
Therefore, a good system should be open:
- Boundaries can be redefined.
- Value functions can also be multiple solutions that rotate.
This is as far as I can think for now.
System Exit
System.exit();
本文采用 署名-非商业性使用-相同方式共享 4.0 国际 许可协议，转载请注明出处。
