<?xml version="1.0" encoding="UTF-8"?><rss xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:atom="http://www.w3.org/2005/Atom" version="2.0" xmlns:itunes="http://www.itunes.com/dtds/podcast-1.0.dtd" xmlns:googleplay="http://www.google.com/schemas/play-podcasts/1.0"><channel><title><![CDATA[Unhappy Systems]]></title><description><![CDATA[My personal Substack]]></description><link>https://www.unhappysystems.com</link><image><url>https://substackcdn.com/image/fetch/$s_!NgvQ!,w_256,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fb655b339-0d44-45d8-b1f2-3bfe3648b4c3_1024x1024.png</url><title>Unhappy Systems</title><link>https://www.unhappysystems.com</link></image><generator>Substack</generator><lastBuildDate>Mon, 18 May 2026 04:38:37 GMT</lastBuildDate><atom:link href="https://www.unhappysystems.com/feed" rel="self" type="application/rss+xml"/><copyright><![CDATA[Aziz Aldawood]]></copyright><language><![CDATA[en]]></language><webMaster><![CDATA[azizaldawood@substack.com]]></webMaster><itunes:owner><itunes:email><![CDATA[azizaldawood@substack.com]]></itunes:email><itunes:name><![CDATA[Aziz Aldawood]]></itunes:name></itunes:owner><itunes:author><![CDATA[Aziz Aldawood]]></itunes:author><googleplay:owner><![CDATA[azizaldawood@substack.com]]></googleplay:owner><googleplay:email><![CDATA[azizaldawood@substack.com]]></googleplay:email><googleplay:author><![CDATA[Aziz Aldawood]]></googleplay:author><itunes:block><![CDATA[Yes]]></itunes:block><item><title><![CDATA[Beyond Management by Objectives]]></title><description><![CDATA[The purpose of measuring performance is to determine if the person evaluated is suited to the role they are doing.]]></description><link>https://www.unhappysystems.com/p/beyond-management-by-objectives</link><guid isPermaLink="false">https://www.unhappysystems.com/p/beyond-management-by-objectives</guid><dc:creator><![CDATA[Aziz Aldawood]]></dc:creator><pubDate>Mon, 06 Oct 2025 09:34:00 GMT</pubDate><enclosure url="https://substackcdn.com/image/fetch/$s_!NgvQ!,w_256,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fb655b339-0d44-45d8-b1f2-3bfe3648b4c3_1024x1024.png" length="0" type="image/jpeg"/><content:encoded><![CDATA[<p>The purpose of measuring performance is to determine if the person evaluated is suited to the role they are doing. Leaders often complicate this process by failing to isolate the individual capability from factors like the value of the role itself or external factors. This is exemplified by the idea of  management by objectives, and its derivatives like OKRs and KPIs, where individual capability is equated with outcomes of the metrics they own. The sales person becomes their quota, the engineer becomes their story points, or whatever is popular that day. </p><p>The main problem with this approach is that it blocks our ability to address the root causes of underperformance or over-performance. A failure to achieve expected objectives could stem from system level issues such as flawed processes, cultural issues, or external factors completely outside the person&#8217;s control. Alternatively, failure could because the role is not the right role to solve the intended problem (e.g. sales can&#8217;t solve a product problem).  </p><div class="subscription-widget-wrap-editor" data-attrs="{&quot;url&quot;:&quot;https://www.unhappysystems.com/subscribe?&quot;,&quot;text&quot;:&quot;Subscribe&quot;,&quot;language&quot;:&quot;en&quot;}" data-component-name="SubscribeWidgetToDOM"><div class="subscription-widget show-subscribe"><div class="preamble"><p class="cta-caption">Thanks for reading Unhappy Systems! Subscribe for free to receive new posts and support my work.</p></div><form class="subscription-widget-subscribe"><input type="email" class="email-input" name="email" placeholder="Type your email&#8230;" tabindex="-1"><input type="submit" class="button primary" value="Subscribe"><div class="fake-input-wrapper"><div class="fake-input"></div><div class="fake-button"></div></div></form></div></div><p>My view is that employees need to be evaluated based on their capabilities in the context of their role. This can be measured across five dimensions:</p><p>- <strong>Complexity &amp; Independence:</strong> An individual&#8217;s ability to handle increasingly difficult and ambiguous tasks with progressively less supervision. It reflects their capacity to learn, adapt, and use feedback to develop the critical thinking and self-awareness required to navigate challenges independently.</p><p>- <strong>Context &amp; Rationale:</strong>&nbsp;An individual&#8217;s ability to understand and articulate the purpose behind their work. It goes beyond completing tasks to grasping how their contributions connect to broader team goals, the company&#8217;s mission, and customer needs, ensuring their actions are aligned with a greater strategic purpose.</p><p>- <strong>Decision-Making &amp; Justification:&nbsp;</strong>The quality and rigor of an individual&#8217;s decision-making process. It focuses on their ability to gather evidence, challenge assumptions, explore multiple alternatives, and collaborate with others to gain diverse perspectives. A key component is providing clear, well-reasoned justification for their choices.</p><p>- <strong>Scope &amp; Influence:</strong>&nbsp;The breadth and impact of an individual&#8217;s contributions beyond their own assigned tasks. It tracks their growth from focusing on personal responsibilities to proactively mentoring others, improving team processes, and ultimately shaping broader organizational strategies.</p><p>- <strong>Results &amp; Adoption:&nbsp;</strong>The tangible outcomes of an individual&#8217;s work and whether their ideas and solutions gain traction. It measures success not just by completion, but by the extent to which their contributions are adopted by teammates, integrated into processes, and deliver real value to customers and the organization.</p><p>Separating the inherent capabilities of the individual from the outcomes helps us distinguish between a personal performance issue and other factors unrelated to the person. This brings us to a foundational idea: organizational success requires the alignment of three elements: the&nbsp;<strong>Role</strong>, the&nbsp;<strong>Person</strong>&nbsp;performing that role, and the&nbsp;<strong>Environment</strong>&nbsp;in which they operate.</p><p>This alignment is critical, and any misalignment between these three dimensions becomes the primary source of performance issues. Instead of defaulting to the conclusion that underperformance is an individual failing, this framework provides a diagnostic lens. It forces us to ask more precise questions: Are we solving the right problem (Role)? Do we have the right person solving it (Person)? And is the system enabling or blocking them (Environment)? By treating these as independent variables, we can move beyond the simplistic &#8216;target vs. reality&#8217; measurement and identify the true bottleneck to success.</p><p>Many great leaders navigate these complexities intuitively, arriving at the correct diagnosis through experience and keen observation. However, what is often lacking in organizational conversations is a clear, explicit framework and a deliberate performance management process designed to capture these crucial distinctions across the organization. Without a shared language to differentiate between a role problem, a person problem, or an environment problem, our ability to solve performance issues remains inconsistent and heavily dependent on the intuition of individual managers.</p><p>This structured approach reveals several common, yet frequently misdiagnosed, patterns. We often see the &#8216;Sabotaged Star&#8217;: a highly capable person in the correct role who is stifled by bureaucracy, or a lack of resources. This is not a personal failure; it is a leadership failure to fix the environment. Conversely, we might have a &#8216;Square Peg in a Round Hole,&#8217; where the role and environment are perfect, but the individual simply lacks the capabilities required. This is a true performance gap, but its root cause is a hiring or placement error, not a lack of effort. By distinguishing between these scenarios, we can move from blaming individuals to taking the correct corrective action, whether it&#8217;s fixing the system, redefining the role, or coaching the person.</p><div class="subscription-widget-wrap-editor" data-attrs="{&quot;url&quot;:&quot;https://www.unhappysystems.com/subscribe?&quot;,&quot;text&quot;:&quot;Subscribe&quot;,&quot;language&quot;:&quot;en&quot;}" data-component-name="SubscribeWidgetToDOM"><div class="subscription-widget show-subscribe"><div class="preamble"><p class="cta-caption">Thanks for reading Unhappy Systems! Subscribe for free to receive new posts and support my work.</p></div><form class="subscription-widget-subscribe"><input type="email" class="email-input" name="email" placeholder="Type your email&#8230;" tabindex="-1"><input type="submit" class="button primary" value="Subscribe"><div class="fake-input-wrapper"><div class="fake-input"></div><div class="fake-button"></div></div></form></div></div>]]></content:encoded></item><item><title><![CDATA[Understanding Quality Work]]></title><description><![CDATA[Figuring out what "quality" means for something you're making seems like it should be easy.]]></description><link>https://www.unhappysystems.com/p/understanding-quality-work</link><guid isPermaLink="false">https://www.unhappysystems.com/p/understanding-quality-work</guid><dc:creator><![CDATA[Aziz Aldawood]]></dc:creator><pubDate>Fri, 25 Apr 2025 18:38:15 GMT</pubDate><enclosure url="https://substackcdn.com/image/fetch/f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fb655b339-0d44-45d8-b1f2-3bfe3648b4c3_1024x1024.png" length="0" type="image/jpeg"/><content:encoded><![CDATA[<p>Figuring out what "quality" means for something you're making seems like it should be easy. But it's often surprisingly tricky, and getting it wrong is expensive. You either waste time polishing something that's already fine, or you ship something critical that isn't good enough. Knowing what quality actually means tells you where to focus and how to get better.</p><p>There seem to be two main ways to get a handle on quality. You need both. Think of them as asking two different questions. First, what's the absolute best this thing could be, based on what it's supposed to do? Second, how good are the ones other people have made?</p><div class="subscription-widget-wrap-editor" data-attrs="{&quot;url&quot;:&quot;https://www.unhappysystems.com/subscribe?&quot;,&quot;text&quot;:&quot;Subscribe&quot;,&quot;language&quot;:&quot;en&quot;}" data-component-name="SubscribeWidgetToDOM"><div class="subscription-widget show-subscribe"><div class="preamble"><p class="cta-caption">Thanks for reading Unhappy Systems! Subscribe for free to receive new posts and support my work.</p></div><form class="subscription-widget-subscribe"><input type="email" class="email-input" name="email" placeholder="Type your email&#8230;" tabindex="-1"><input type="submit" class="button primary" value="Subscribe"><div class="fake-input-wrapper"><div class="fake-input"></div><div class="fake-button"></div></div></form></div></div><p>Let's call the first question understanding the <em>utility</em>. How well the thing you made does the job the person is trying to do? Utility isn't just about function; it's about the value someone gets compared to the cost they pay. Cost isn't just money. It's also time, effort, thinking power, even social standing. A really high-quality thing delivers a lot of value for the cost incurred by the user.</p><p>Sometimes this value is crystal clear. If you make bolts, their value is holding things together reliably. Easy to measure. But sometimes value is fuzzy. Think about expensive clothes. Part of the value might be social status, which is hard to pin down. Did that shirt actually deliver the status the buyer hoped for? Who knows.</p><p>And jobs can have layers. You need a coat to keep you warm &#8211; that's measurable utility. But you probably also want it to look good. An ugly coat, even a warm one, might not have enough utility because it fails at the second job. Often, the deeper, less obvious jobs create more value, assuming you understand what they really are.</p><p>The second question is about looking around. What have other people done? This is <em>comparative benchmarking</em>. It works for everything &#8211; art, software, cooking, writing. You look at what others are doing in the same space.</p><p>Why? To get context. What does "excellent" or "average" even look like right now? What's actually possible with the tools and knowledge people have today? And crucially, <em>how</em> are others achieving good results? What tricks or techniques are they using?</p><p>Comparison grounds you in reality. It stops the theoretical "best" from becoming some impossible dream. But you have to be smart about it. Don't just aim to be average, because the average might be terrible. And don't just copy the leader. Look at the whole range, learn from the best examples, figure out *why* they're good, and use those insights to get closer to the ideal utility you defined with the first question. Compare to learn and calibrate, not just to imitate.</p><p>Sometimes, though, there's not much to compare. If you're doing something really new, like cutting-edge research, or something very personal, like raising your kids, or maybe specialized consulting, finding direct comparisons is hard.</p><p>Thinking about these two factors &#8211; how clear the utility is, and how much comparative data you have &#8211; gives you a map of different situations.</p><p>What if you have <strong>low comparative data and unclear utility</strong>? You're exploring. Think researchers in a brand new field, or someone taking up a really obscure hobby. You don't have many examples to look at, and it's hard to even measure if you're succeeding. You're driven by a belief that what you're doing matters. You probably aren't making money, unless you stumble onto something big where the utility suddenly becomes clear and valuable, like OpenAI did with LLMs. High risk, potentially high reward.</p><p>What about <strong>high comparative data and unclear utility</strong>? Think fashion, or high-end smartphones. Lots of competitors, endless features to compare, but what people *really* value is fuzzy and changes all the time. This space is full of people claiming they've figured it out. Some make money, many fail. Success often comes from having a sharp insight into what a specific group truly wants, maybe because you want it yourself, or you know that group really well.</p><p>Then there's <strong>low comparative data and clear utility</strong>. This is where you find specialists: niche consultants, custom software shops, maybe creators focused on a specific topic. There aren't many direct competitors doing exactly what you do, but the value you provide is well-understood. You need deep expertise here. You can make a good living, but the market is often smaller, and you have to be genuinely good.</p><p>Finally, <strong>high comparative data and clear utility</strong>. Think of roles like salespeople on large teams or call center agents. There are many people doing similar work, and performance is usually easy to measure. You're often part of a larger system. To really succeed here, you usually need to be exceptional, maybe even different enough that you start to look like you belong in the previous category.</p><p>Looking at it this way, a couple of things stand out. It seems like the interesting places are often where the two factors are mismatched &#8211; lots of comparison but fuzzy utility, or clear utility but few comparisons. When both are low, you're exploring. When both are high, you're often in a highly competitive, standardized game.</p><p>Understanding where your work fits helps you figure out how to operate. Are you exploring, competing on insight, leveraging deep expertise, or striving for exceptional performance in a defined role? Knowing the answer is the first step to getting quality right.</p><div class="subscription-widget-wrap-editor" data-attrs="{&quot;url&quot;:&quot;https://www.unhappysystems.com/subscribe?&quot;,&quot;text&quot;:&quot;Subscribe&quot;,&quot;language&quot;:&quot;en&quot;}" data-component-name="SubscribeWidgetToDOM"><div class="subscription-widget show-subscribe"><div class="preamble"><p class="cta-caption">Thanks for reading Unhappy Systems! Subscribe for free to receive new posts and support my work.</p></div><form class="subscription-widget-subscribe"><input type="email" class="email-input" name="email" placeholder="Type your email&#8230;" tabindex="-1"><input type="submit" class="button primary" value="Subscribe"><div class="fake-input-wrapper"><div class="fake-input"></div><div class="fake-button"></div></div></form></div></div>]]></content:encoded></item><item><title><![CDATA[Simple Rules]]></title><description><![CDATA[A Way to Navigate Complexity]]></description><link>https://www.unhappysystems.com/p/simple-rules</link><guid isPermaLink="false">https://www.unhappysystems.com/p/simple-rules</guid><dc:creator><![CDATA[Aziz Aldawood]]></dc:creator><pubDate>Sun, 22 Oct 2023 06:23:41 GMT</pubDate><enclosure url="https://substackcdn.com/image/fetch/f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fb655b339-0d44-45d8-b1f2-3bfe3648b4c3_1024x1024.png" length="0" type="image/jpeg"/><content:encoded><![CDATA[<h4>what are simple rules</h4><p>Think of situations that you deal with repeatedly in your life; complex ones like deciding how to spend money, hiring/firing decisions or simple ones like what pair of shoes to buy. What is your default way of making these calls? Most people will go through an evaluation process in an effort to make the right decision, typically without explicitly considering time to decision or consistency in making similar decisions.</p><p>Simple rules are an alternative approach that aims to make fast and consistent decisions. We have all encountered these rules in the form of advice on a specific topic, something like when buying shoes always get a black pair that are comfortable and don&#8217;t look flashy (these are my rules, although I dabbled with green shoes for a while).</p><div class="subscription-widget-wrap-editor" data-attrs="{&quot;url&quot;:&quot;https://www.unhappysystems.com/subscribe?&quot;,&quot;text&quot;:&quot;Subscribe&quot;,&quot;language&quot;:&quot;en&quot;}" data-component-name="SubscribeWidgetToDOM"><div class="subscription-widget show-subscribe"><div class="preamble"><p class="cta-caption">Thanks for reading Unhappy Systems! Subscribe for free to receive new posts and support my work.</p></div><form class="subscription-widget-subscribe"><input type="email" class="email-input" name="email" placeholder="Type your email&#8230;" tabindex="-1"><input type="submit" class="button primary" value="Subscribe"><div class="fake-input-wrapper"><div class="fake-input"></div><div class="fake-button"></div></div></form></div></div><p>The idea is, sometimes (most of the time in my opinion, will cover why later in this post) fast, good enough decisions are what is needed.</p><p>Let&#8217;s look at real life examples of simple rules to hammer in the idea further. The first story from Gerd Gigerenzer&#8217;s book <a href="https://www.amazon.com/Risk-Savvy-Make-Good-Decisions-ebook/dp/B00DMCPOA4?qid=&amp;sr=">Risk Savvy: How to Make Good Decisions</a> </p><blockquote><p>On a sunny January afternoon in 2009, 150 passengers boarded US Airways Flight 1549. Three minutes after they took off from LaGuardia airport in New York City, something happened out of the blue. A flock of Canada geese approached the plane, in perfect formation. At an altitude of twenty-eight hundred feet, passengers and cabin crew suddenly heard loud bangs. The geese had collided with the engines. A jet engine can &#8220;ingest&#8221; smaller birds but not Canada geese weighing ten pounds or more. If the bird is too big, the engine shuts down rather than exploding. But this time the improbable event had happened: The geese had flown into not just one but both engines, and both were silenced. When it dawned on the passengers that they were gliding toward the ground, it grew quiet on the plane. No panic, only silent prayer. Captain Chesley Sullenberger called air traffic control: &#8220;Hit birds. We&#8217;ve lost thrust in both engines. We&#8217;re turning back towards LaGuardia.&#8221; But landing short of the airport would have catastrophic consequences, for passengers, crew, and the people living below. The captain and the copilot had to make a good judgment. Could the plane actually make it to LaGuardia, or would they have to try something more risky, such as a water landing in the Hudson River? One might expect the pilots to have measured speed, wind, altitude, and distance and fed this information into a calculator. Instead, they simply used a rule of thumb: </p><p><strong>Fix your gaze on the tower: If the tower rises in your windshield, you won&#8217;t make it. </strong></p><p>No estimation of the trajectory of the gliding plane is necessary. No time is wasted. And the rule is immune to calculation errors. In the words of copilot Jeffrey Skiles: &#8220;It&#8217;s not so much a mathematical calculation as visual, in that when you are flying in an airplane, things that&#8212;a point that you can&#8217;t reach will actually rise in your windshield. A point that you are going to overfly will descend in your windshield.&#8221;This time the point they were trying to reach did not descend but rose. They went for the Hudson.</p></blockquote><p>Ok, we are done with planes. Now to another less scary example, how to do estimations? There is a principle called the <a href="https://en.wikipedia.org/wiki/Fermi_problem">Fermi problme</a>. I will let Jason Cohen explain in his article <a href="https://longform.asmartbear.com/roi-rubric/">Fermi ROI: Fixing the ROI rubric</a></p><blockquote><p>The first full-scale nuclear bomb was detonated at 5:29am, July 16, 1945, in the New Mexican desert of the United States. The physicists who invented it were huddled in a truck behind a plate of welder&#8217;s glass to reduce the radiation to non-lethal levels.</p><p>The physicists were already causing trouble. Future Nobel Prize-winner Richard Feynman inexplicably decided to observe the blast without eye protection, causing frightening but ultimately temporary blindness. Current Nobel Prize-winner Enrico Fermi had taken bets with military guards about how much of the atmosphere would ignite, and whether it would incinerate the entire state or the entire world; some of the guards asked to be excused from the base, angering the project director.</p><p>Fermi was also interested in the amount of energy released by the blast&#8212;one of the main goals of the test. Not wanting to wait for official analysis, he made his own estimate on the spot, using a technique that now bears his name, and that we will use to fix our rubric:</p><blockquote><p>About 40 seconds after the explosion the air blast reached me. I tried to estimate its strength by dropping from about six feet small pieces of paper before, during, and after the passage of the blast wave. Since, at the time, there was no wind I could observe very distinctly and actually measure the displacement of the pieces of paper that were in the process of falling while the blast was passing. The shift was about 2 1/2 meters, which, at the time, I estimated to correspond to the blast that would be produced by 10,000 tons of TNT.<br>&#8212;<em>Enrico Fermi, <a href="http://www.dannen.com/decision/fermi.html?utm_source=longform.asmartbear.com&amp;utm_campaign=longform.asmartbear.com&amp;utm_medium=post">Top Secret interview</a> July 16, 1945, declassified in 1965</em></p></blockquote><p>The official estimate of the energy output of the blast was 21,000 tons of TNT. Fermi&#8217;s estimate was surprisingly accurate given such inaccurate input data and quick, simple, mental calculations. How did he do it?</p><p>The trick&#8212;useful everywhere in life&#8212;is to estimate values using only orders-of-magnitude, a.k.a. powers-of-ten. No &#8220;low/high ranges,&#8221; no precision, not even any digits other than a 1 followed by a quantity of 0s. It sounds far too imprecise to be practical, and yet Fermi&#8217;s bits of paper demonstrate that it just might work.</p></blockquote><h4><strong>Why Should We Use Simple Rules Most of the Time?</strong></h4><p>When making decisions there are three considerations we take into account; is this decision reversible? Does accuracy matter? And is it time-sensitive?</p><p>My argument is that the only instances in which simple rules are not the best solution are cases in which accuracy matters, the decision is irreversible, and we are not pressed on time. For example, deciding to do a non-urgent yet life-threatening surgery is worth mulling over. Actually applying simple rules here might be irresponsible.</p><p>For any other situation, simple rules are always the best path. If the situation requires making a decision fast then by definition you can&#8217;t think it through and in most cases, winging it is not really a good way of making decisions.</p><h4><strong>Where to Go from Here?</strong></h4><p>There is more to talk about when it comes to simple rules. I will not get into it here, I will probably write about it in other posts.</p><p>I will leave you with this, the mindset to apply simple rules is that you should abandon any desire for perfection. Then you need to convince yourself that for most problems there are no more than 5-6 things that actually matter (6 is somewhat pushing it). You combine these two ideas and then go find a problem you deal with often and figure out what matters and what are the rules that, if applied, will ensure what really matters is being taken care of.</p><div class="subscription-widget-wrap-editor" data-attrs="{&quot;url&quot;:&quot;https://www.unhappysystems.com/subscribe?&quot;,&quot;text&quot;:&quot;Subscribe&quot;,&quot;language&quot;:&quot;en&quot;}" data-component-name="SubscribeWidgetToDOM"><div class="subscription-widget show-subscribe"><div class="preamble"><p class="cta-caption">Thanks for reading Unhappy Systems! Subscribe for free to receive new posts and support my work.</p></div><form class="subscription-widget-subscribe"><input type="email" class="email-input" name="email" placeholder="Type your email&#8230;" tabindex="-1"><input type="submit" class="button primary" value="Subscribe"><div class="fake-input-wrapper"><div class="fake-input"></div><div class="fake-button"></div></div></form></div></div>]]></content:encoded></item><item><title><![CDATA[Simple Rules for this Blog]]></title><description><![CDATA[When I decided to write more and share my writing, a lot of questions started popping up.]]></description><link>https://www.unhappysystems.com/p/simple-rules-for-this-blog</link><guid isPermaLink="false">https://www.unhappysystems.com/p/simple-rules-for-this-blog</guid><dc:creator><![CDATA[Aziz Aldawood]]></dc:creator><pubDate>Sat, 30 Sep 2023 12:00:00 GMT</pubDate><enclosure url="https://substackcdn.com/image/fetch/$s_!NgvQ!,w_256,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fb655b339-0d44-45d8-b1f2-3bfe3648b4c3_1024x1024.png" length="0" type="image/jpeg"/><content:encoded><![CDATA[<p>When I decided to write more and share my writing, a lot of questions started popping up. How should I write? Who is my audience? Do I want to monetize, and if so, how? Will I succeed? How long should each post be? And so on.</p><p>This train of thought is very common among perfectionists (of which I am proudly a member). What works for me in these situations is picking one goal to optimize. This definitely simplifies things, but sometimes it's not enough; there are still too many options. That's where 'simple rules' come in. Usually, 2-5 simple rules are enough. More than that, and things get complex again.</p><div class="subscription-widget-wrap-editor" data-attrs="{&quot;url&quot;:&quot;https://www.unhappysystems.com/subscribe?&quot;,&quot;text&quot;:&quot;Subscribe&quot;,&quot;language&quot;:&quot;en&quot;}" data-component-name="SubscribeWidgetToDOM"><div class="subscription-widget show-subscribe"><div class="preamble"><p class="cta-caption">Thanks for reading Unhappy Systems! Subscribe for free to receive new posts.</p></div><form class="subscription-widget-subscribe"><input type="email" class="email-input" name="email" placeholder="Type your email&#8230;" tabindex="-1"><input type="submit" class="button primary" value="Subscribe"><div class="fake-input-wrapper"><div class="fake-input"></div><div class="fake-button"></div></div></form></div></div><p>Let's quickly discuss the concept of simple rules. I plan to write a longer post about the idea of having a single goal and employing simple rules. The premise is that when faced with an unknown environment and the need for swift decisions (which is the case in 99% of situations), utilizing simple rules is the optimal approach. For instance, to maintain good financial health, one could follow these simple rules: always spend less than you earn, keep three months' salary in savings, and set a specific limit for unnecessary spending (say, 20% of income). These rules are straightforward and actionable.</p><p>So, what is my goal with this blog? My goal is to refine my thinking around the various problems I encounter, be they personal or professional. Refinement thrives on friction, which comes from sharing ideas with others, inviting challenges and disagreements.</p><p>Having established the goal, several considerations emerge. Should every fleeting thought be penned down and shared, or should there be a quality threshold? Is committing to a posting frequency crucial to keep the momentum going? And what about the length of each post; should there be a minimum or maximum?</p><p>Two primary considerations shape the 'simple rules' for this endeavor: Will people read what I write? And will I write in the first place? Here are three rules I believe address these questions:</p><ol><li><p><strong>Clear Definition:</strong> Each post should have a clear point of discussion. It's not about random ramblings but a dive into a specific issue, even if a solution isn't readily available.</p></li><li><p><strong>Consistent Frequency:</strong> A bi-weekly post seems achievable and keeps the habit alive. It demands a level of commitment that's crucial for this journey.</p></li><li><p><strong>Minimum Length:</strong> Each post should have a minimum length to ensure a level of depth and engagement with the topic at hand.</p></li></ol><div class="subscription-widget-wrap-editor" data-attrs="{&quot;url&quot;:&quot;https://www.unhappysystems.com/subscribe?&quot;,&quot;text&quot;:&quot;Subscribe&quot;,&quot;language&quot;:&quot;en&quot;}" data-component-name="SubscribeWidgetToDOM"><div class="subscription-widget show-subscribe"><div class="preamble"><p class="cta-caption">Thanks for reading Unhappy Systems! Subscribe for free to receive new posts.</p></div><form class="subscription-widget-subscribe"><input type="email" class="email-input" name="email" placeholder="Type your email&#8230;" tabindex="-1"><input type="submit" class="button primary" value="Subscribe"><div class="fake-input-wrapper"><div class="fake-input"></div><div class="fake-button"></div></div></form></div></div>]]></content:encoded></item></channel></rss>