Candost's Blog

Busyness Is a Choice

Sun, 04 Oct 2026 13:00:00 GMT

After I began playing in an improv theatre, I've been observing people more. The more I observe, the fewer people I see who are willing to move out of their comfort zone. Even when they have the energy and really want to do something, like sign up for a hobby class or host a dinner with friends. When I ask why they aren't doing the things they would love to do, I hear the same answer from everyone, like they are in a choir. They are busy. Everyone is busy. People want to do a million things and never find the time. Perhaps they think time is like a material that can be mined, and they are waiting for someone to show them where to start digging. But they—all these busy people—have something in common. They choose to be busy. And they use busyness as an excuse to avoid showing vulnerability.

"Being busy" is a choice. I know, I know, most people don't have the luxury of stopping work when they want to. So, naturally, they are busy with work. Still, what's left after work is still a significant amount of time that anyone can choose how to spend. Yet, they don't want to do anything. What drives me mad is that many use the job as an excuse. Sometimes to explain why they haven't yet looked into something they promised, sometimes to avoid learning about something as much as they would have loved to do, and sometimes not to meet up with someone they haven't seen in a while.

A few weeks ago, I was sitting alone in a café as part of my Sunday ritual, and I eavesdropped on a conversation. I have no idea who these people were, but I can confidently say they were old colleagues working in tech companies in senior roles (likely "Head" or "Director" level or above). One of them asked the other about a common colleague and whether they have any contact with that person. I think you can guess the answer. It was no, because the person—after taking a sip of the flat white on a chill Sunday morning—said they really wanted to but had been very busy over the last few months.

I found that excuse to be insincere. I am not blaming or shaming that person right now because I don't even know their name, let alone their life and personality. Still, I could sense the insincerity. For us, as a society, it should be okay to say, "I wanted to catch up, but that sadly was not my priority recently. I have other things I consider more important these days. Once these conditions change, I definitely will." But no, we're "just busy."

Saying busy is the easy way out. Because almost everyone responds with, "Oh, yeah, I understand", while sensing the affectation (and calling out the hypocrisy in their internal voice because they saw their last Instagram reel from a lake). Instead of using the B word, explaining life's priorities might expose the person. They might need to disclose what really matters to them, and this may make them feel vulnerable. I understand. However, when I hear the word busy, I immediately portray the person in my mind as either ashamed that they haven't yet done what we talked about, or not wanting to talk about it right now or with me. Instead of being straight up front and expecting empathy, they take the shortcut.

It's okay, my friends. You can be busy with something that has great importance for you at that stage of your life. But remember, it's your choice to be busy with that thing. If you're not really busy and use it as an excuse, then think about it: why do you use the word "busy"? Why not, "I can't do it these days because of..."? I try to follow a communication principle: "Say what you mean, mean what you say." Saying "because I'm busy" is the opposite. You neither say what you mean nor mean what you say.

Don't use busyness as an excuse. Find what's underneath. You may not really want to go to the movie with that friend who is asking. If so, ask your friend to do something else or stop seeing them. You may not want to sign up for a class you always wanted because your job cannot afford distraction right now. If so, just say that, not busy.

Maybe you don't feel comfortable saying all these truths out loud. Still, be aware that you are using the word busy as a shield. Shield from the truth and an uncomfortable but genuine conversation. Maybe your colleague or friend will tolerate it for a while and cut you some slack, but don't do the same with yourself. Know why you are putting your shield up.

If you're really busy with something you're passionate about and don't want to do anything else, it's okay. You can say, "I'm busy with that thing I care a lot about, and I'm avoiding all other distractions." You don't need to juggle ten things at a time, even though the Internet and AI claim you can. Accept that you won't do other things at this stage of your life, and prioritise what matters to you.

Be truthful and transparent with others; don't try to hide behind busyness. Because it doesn't work.

Reply via email | Reply via Mastodon | Comment

Magazines are superior products to newsletters

Tue, 15 Sep 2026 06:05:00 GMT

Most newsletters have turned into daily newspapers, publishing 3-4 pieces a week. If you're like me and subscribed to many newsletters, you find yourself in a constant "catch-up game," never able to read and, more importantly, understand the content. For the ones you are able to read, you skim and delete them, thinking you got "the gist of it." If you take a break from chasing the finish line in these newsletters when you go on a vacation, you feel like the world has gone too fast while you're lying on a beach. While the newsletters want you to think the world has moved on without you, magazines help you to see that it actually didn't.

A few years ago, before a summer vacation, I didn't want to bring my phone to the beach. I wanted a light, cheesy read to "waste" time on the beach and not think about anything from my daily routine. I had books with me, but also wanted short reads. I picked up Men's Health and Monocle in the airport. While Men's Health gave me the cheesiest read I had in a while and helped me sleep for many hours on the beach[^1], Monocle unexpectedly opened new doors.

After that vacation, I started reading Monocle frequently. But Monocle provided much more than its content. I found myself reaching for magazines unconsciously more and more. While wandering joyfully in Berlin bookstores, I came across a small bookstore called "Do You Read Me?" On my first visit, I spent ~30 minutes in that tiny store, looking through magazines and buying four I'd never heard of before. As someone who reads articles, essays and opinions exclusively digitally, I discovered a different world (that existed for centuries).

Those few magazines showed me how much better products they are than all the digital newsletters I subscribed to.

Why newsletters are not great

Most of the digital newsletters are not editorial products. I receive an email from a writer, mostly talking about a single topic from a single perspective. The creator economy and digital consumer behaviour have forced many creators to focus on a niche, losing the benefits of an editorial approach. Everyone tries to shout louder as an individual. As a subscriber, I must subscribe to multiple newsletters to get broad perspectives on a single topic. Yes, the curation newsletters exist, but they almost never collaborate with the writer of the articles they share. They act as sourcing machines, focusing on one part of curation—selection—and shifting the rest to readers.

As a reader, I have to subscribe to multiple newsletters, skim through the hoses of content machines just to find a good article that has a possibility of giving me an additional perspective. If I'm lucky enough, I may leave my echo chamber and find another one. If I do this with enough newsletters, I may succeed in curating my ideas pool. But I have to do it every day and every week. Considering my RSS feed alone is reaching 50 items a week and I have interest in multiple topics, reading them all is impossible. There is no surprise that many people, including me, feel overwhelmed. However, the moment you stop chasing it for a week or two and come back, you realise that all articles deemed important to read were not important at all.

The digital newsletter ecosystem is centred around 'recency', like daily newspapers. Most writers think that they must talk about something relevant to people's lives right now. That's what grabs attention, and that's the incentive for any writer. As a reader, when you stop consuming and look at the articles a month later, you discover that they are not as attractive as they were when you saw them right after they were published. Most content loses relevance over time.

That, you find it less in monthly magazines.

What makes magazines superior

Long-term thinking often leads to better writing. The writer must detach from the daily hustle to expand relevance until at least the next issue. If you follow this blog for a while, you may know that I don't read daily news for the same reasons. Daily news is full of noise, clutter, and prediction. Something happens in a day, and all news agencies talk about that for days. The same is true for most newsletters. But monthly, bimonthly or quarterly magazines cannot do the same. Even if they do, they do it differently.

The magazines are time-bound differently. They have set dates for production and distribution. The cadence forces them to approach daily news differently—discussing the long-term impact. Journalists and writers must detach from daily life to see the bigger picture and trends. In newsletters (and, similarly, daily news), you don't get this holistic thinking. As recency grabs the attention of the reader, there is nobody asking a writer to approach it holistically. Unlike magazines.

All print magazines have editors who are responsible for building the magazine or its sections. Working across theme and design and working with writers, other editors, photographers, designers and artists to improve the quality of the articles, pictures and design results in a tasteful product. Each issue of a magazine focuses on an area and has a theme. Although most newsletters also have a theme, they call it a niche, magazines bring together different voices: sometimes with conflicting ideas; sometimes each representing a piece in a puzzle.

The editor provides a filtering mechanism to eliminate pieces that won't fit into the puzzle. It's rare to have a low-quality text in a print magazine. Printing an article on paper forces everyone to up their game. All articles are vetted, edited, and each word is chosen carefully. The stakes are too high; the magazine business is ruthless. You don't get this quality mindset with digital newsletters. Because the production is 'free.' If this newsletter issue is not great, the next one in two days has another chance.

How about personal blogs, big digital media, and curation newsletters?

Many print magazines offer digital subscriptions. I put their digital solutions into the same category as newsletters. When a magazine goes digital-first, print-second, its overall quality takes a hit. For example, Harvard Business Review's online website is full of crap (even with editors). Because their main focus is digital, the magazine's quality also suffers. Foreign Affairs is a good read in print, impossible to follow on digital. Monocle is already a packed magazine in print; digital is too much. However, when the magazine is print-first and digital-second, both solutions somehow become higher-end.

On the other hand, I still deem personal blogs superior to newsletters and in a different lane than magazines. Never mind the romanticising of indie web, personal blogs have a different purpose. Their purpose is not to become a product. An up-to-date weblog is beautiful in its clumsiness, gorgeous in its lack of perfection, and great in its all-over-the-place content. I might be biased because I have put a lot of effort into making this blog. However, I keep the weblogs I follow in my RSS feed because they give a lot of ideas about the person behind them, and that's what matters in the end.

Writers against creator economy

Writing is a big challenge (from my experience), whether in print or online. Anyone who dares to publish their writing already goes through a lot of inner criticism. At first, the inner critic makes you hallucinate as a writer that your writing is of better quality just because you edited it a hundred times. However, in my experience working with a developmental editor, I can easily tell the stark difference between a text I edited twenty times and one a developmental editor edited once.

Learning how to write in the creator economy is difficult. The rule of creativity says that to be able to write well, you have to produce hundreds of bad ones. Picasso produced hundreds and thousands of pieces, and only a fraction were masterpieces. Eminem writes thousands of songs on scraps of paper, and a fraction of them turn into a song. That's how creativity works.

This nature of creativity, combined with unrestricted publishing, gave birth to many writers (e.g., me) who also write newsletters. I am happy that some earn a living from online writing, even though it's a difficult journey. However, eliminating editors and curation also means readers have to go through all our shitty writing. Worse, I don't see a way out.

All should coexist, but not like today

I'm neither going to praise or romanticise the paper feeling and how good it's to hold in hand nor vilify the whole digital ecosystem. All should co-exist. My criticism isn't aimed at any writer, but at the direction of the newsletter ecosystem.

We need to abandon most Substack-style newsletters where the writer only writes without any editorial thinking. Although Substack-like platforms reduced the friction in writing, that friction was necessary. Perhaps all writers should have their own website and think about how to structure content and build a digital reading experience, not just a single article.

Instead of waiting for everything from the readers and pushing in all directions to grab more attention, perhaps we need more formats like the Ideas Letter or The Humanist Review of AI or more writers like Maria Popova from The Marginalian who is a grand boss editor in the shape of a writer. Perhaps we need more good, old personal blogs. I do not know which one we need, but I know there is no silver bullet. All should co-exist and complement each other somehow. I guess.

P.S. Not all magazines are great. You have to find what you like. We also need these magazines to get cheaper and become more accessible.

[^1]: I never read Men's Health again.

Reply via email | Reply via Mastodon | Comment

Is Education for Industry or for Thinking?

Thu, 03 Sep 2026 08:48:00 GMT

I read Guy Standing's short essay on education in Monocle's Issue #195. I have mixed thoughts about Guy's arguments.

I think the introduction explains the whole article well:

The acquisition of knowledge is becoming more commodified, seen as a way of filling gaps in the workforce. But for a society to thrive, it needs to remember how to value learning.

I understand that education previously aimed to teach people how to think (influenced by thinkers like Jean-Jacques Rousseau). This focus has been decreasing over time, shifting the main purpose of education to fulfilling industry's needs. Humanity is increasingly abandoning critical thinking from multiple angles (e.g., AI is also nudging people to think less). People think less and follow what's given to them, hand over their judgment because they don't have the right mental tools to think clearly in different situations. I share the worries.

However, this doesn't mean we change the whole education system to teach people how to think better, as in the old days. The old days were different in many ways. In less industrialised, less connected, less automated work, many educated people were able to master multiple fields because the fields were not that deep. These days, education is about teaching multiple subjects at an "enough level" so that people can find their next steps easily. Becoming more industry-oriented, from K12 to universities, is better because it gives people time to think and learn.

With education focusing on filling the gaps in the workforce, it reduces the stress and worry about survival in the modern world. More money might not bring happiness beyond a certain threshold, but most people must first earn enough to cross it, and education is one way to do so (not the only way). In the end, education can give people the freedom to think.

Thinking must be a side activity of work. The action of doing something teaches and gives someone a chance, while equipping them with tools to think better allows them to get better at the action they are doing (and also helps assign a value to it). From my perspective, the university must teach both, but the main focus should remain on building skills for the future. The more jobs we can fill and the more income people can earn, the more time they will have for learning how to think. There is no need to go back to "good-old-days." First comfort, then wondering.

In response to: If education is only about earning, what happens to learning?

Reply via email | Reply via Mastodon | Comment

Magazines are rarely sold in book stores in Berlin. Why?

Sun, 30 Aug 2026 14:53:00 GMT

I never understood why most bookstores in Berlin (and perhaps in Germany) don't sell magazines.

I'm writing a new article right now about magazines and how they shaped my life in the last year. While writing it, I realised that for magazines I often go to stores other than bookstores. Weird.

Reply via email | Reply via Mastodon | Comment

Emails & Essays & AI

Sat, 29 Aug 2026 17:30:00 GMT

Hello! How are you?

(I moved to a new email address to match my blog URL, and from now on I'll be sending you an email from this new address. Don't forget to add it to your contacts when you receive the email.).

It's been a while since I sent you an email. I've been debating the value of the Mediations newsletter in the age of AI. I have to admit that I've had a hard time integrating this newsletter with my blog since day one. When I wrote something, I debated its form: an email or an article. Every topic I wrote about could fit both. Eventually, I published everything on my blog, although I sent it as an email. Now, that's changing. I cannot say I figured everything out now. But before I share, I want to explain why you should bother reading them, even with AI in your pocket.

We must start by asking one question: what makes something valuable? Why do we find things (like this email) valuable? Many confuse newsletters or content with being informative or entertaining. They often want new information, something they didn't know. However, new information doesn't make the information valuable. For example, I have five books on my desk right now. Here you received new information. Is it valuable? Definitely not. So, how can a writer (or creator) make information valuable? Short answer: they can't.

The creator does not create value until the consumer community (e.g., readers like you) agrees that the content is valuable (I'm sorry to break it, but you cannot decide alone). The content must move the community a step forward or alter it. So, whatever I write won't be valuable unless a portion of you agree that it's influencing your life, or it makes you feel something (don't underestimate feelings; they are the change itself), or it solves a problem you face (like a different perspective to improve your relationship with someone important to you). OR the information must come to you at the right time you need, which is "mission impossible" for a creator.

That's where AI helps the best. It gives you personalised information no creator can match. The vast amount of information the AI has been trained on can be customised for your needs at a specific time. Yet, what AI cannot do is be a human, even when it reaches superintelligence. This begs the question: what does being human mean in this context? Answering this question will also unlock the value question.

Although the AI has the data, information, and calculation power, it is not sentimental. It can generate a story but cannot live through the change a piece of information creates. It cannot feel or live the information. Moreover, current LLM models use a probabilistic approach, selecting their next token (phrase) based on the highest probability, using data generated by the masses. A story a human writes is statistically insignificant compared to available content. Yet, each human is unique. That's AI's weakness.

Perspective and experience gained by living. As a person, I can live through situations, face challenges, and (perhaps with the help of AI), overcome them. When I tell you what I have been through, you also know it's been lived; there is someone accountable for it (me). While AI can give you a similar story if you ask for it, it cannot give you the unique perspective gained from living. That's the value of these emails (or similar content).

So, the promise I can make with these emails is the value you decide to assign, and an insignificant (hence unique) perspective I live and employ, delivered through stories from my life, sent to your inbox in private.

Yes, I'm moving these emails to a private setup. I will not cross-post emails to my blog or Substack (except for this last one, because I want to end the Substack publication with a note).

As you may have noticed, this email doesn't have any fancy styling. That's how we all write these personal emails. All future emails will be as if I'm writing to a friend or a government office. When you reply, your email will land in my inbox.

No more Substack, email open rate or link click rate tracking; I don't care about them. What I count as success will be the replies I get to each email. I won't publish these emails anywhere. Once you delete it, it will be gone. Whenever you want to unsubscribe, just reply to any email you receive and let me know that you no longer want to receive them; I'll remove you from the list (FYI: I also removed you from the Substack publication, so you don't have to clean up there.).

I'll not promise a weekly or biweekly emails. I'll try to send as often as possible but definitely not more than once a week (who has time to read more anyway?).

If it's private, how can others read already sent emails? There is only one way: you forward the email to a person. If an email is valuable, I hope you forward to at least one person who you think will benefit as well (while reading, imagining someone who can benefit other than yourself is always a great way to give back to the community).

I hope you keep valuing things that are unique albeit being imperfect.

Until next time, Candost

"...

And be sure to use AI when working on your next

book or essay or piece of art or photography,

and then smile or even laugh at your own

cleverness when you see how good it is,

and how easy,

because who the hell has time

to work at something, to give time to craft, to

create with their own minds, to spend

years being mediocre. Why do that when

mastery, or at least competency

is so simple

only a good prompt away?

..."

— Please Use AI by Shawn Smucker

P.S.: I shared a project I created at work as a software engineering leader to leverage AI.

(Did someone forward this email to you and you want the next one? Use this link to subscribe.)

Do you want to ~~unsubscribe~~ stop these emails? Just hit reply and send me an email. I'll remove you from the list right away.

Reply via email | Reply via Mastodon | Comment

Building an AI Hive Mind to Understand Systems as a Manager

Fri, 21 Aug 2026 06:05:00 GMT

From the day that I stepped into a manager role till today, I've been relying on other people to do my job. Every passing year, I sacrificed a piece of my software engineering 'expertise' to organisational constraints.: the work that requires me to help aligning people and problems, gathering context and structuring it for better comprehension and narrowing the problem down, listening to people daily to help in various aspects, team performance management, and more. Every step pushed me away from the writing code. But I always tried to stay close to engineering part to understand how systems actually worked, rather than how people thought that they worked.

As much as I tried, I became harder every day. My work at SumUp demands working across domains. Considering each domain consisting of dozens of services and applications, I always needed engineers from each domain while working in a project to gather context and surface what needed changing. Nobody had the full knowledge of the system (still doesn't today). I always had to gather 3-4 people in a room just to figure out how the system works.

My attempts to outline systems relations made me the master of Mermaid diagrams, Miro boards (that sometimes became outdated faster than the text documentation), RFCs, PRDs, and random technical documents. All of these have succeeded thus far. However, the pace of change (especially with AI) has got higher, and it has become notoriously difficult to continue the same way. I decided to try solving it differently.

The main goal I established for myself was to eliminate the "gather 3-4 people in a room just to figure out how the system works" stage: find out how the applications, services, tools, and infrastructure connect together and combine it with the deterministic knowledge: the codebase and team structures. As a secondary goal, I wanted to build a mechanism to surface tacit knowledge—knowledge that's not written in a document, shared, or made explicit.

First Attempt: A General Agent

I built an AI project using Notion Custom Agents (as we use Notion at SumUp). I connected GitHub and a few other tools so the agent could access the data. I wrote custom instructions to guide agents and explain the purpose and expectations as concretely as possible. I also wrote a few specific documents for agents to use while navigating a big Notion workspace and various repositories.

This approach has worked for a while. Especially when the scope was limited to a single team's domain, it was useful. However, it began limiting once it started crossing domain boundaries. The more domains and repositories I connected, the less it could surface the right information. It often missed reading documents that I explicitly directed to read. The tool invocations sometimes timed out, and sometimes agents failed randomly without much explanation. The reliability was good enough, but I still couldn't rely on it to do my job.

All these nudged me to look for a more concrete, reliable, and established solution. Instead of searching for the next AI SaaS product that claims to become the ultimate knowledge worker, I decided to build it myself.

Second Attempt: Hive Mind

SumUp is a big organisation with thousands of Git repositories, thousands of Slack channels, and millions of pages of documents. I definitely didn't want to cover all of these. I limited the setup to three core components of SumUp: two domains and one shared mobile application, and I built everything around the domain that I oversee.

This approach has worked.

I created a single repository where all other repositories are connected as git submodules with their own AGENTS.md files to give context—creating, as I call it, the hive mind.

Setup Outlook

A single repository with all other relevant repositories (currently ~66) added as git submodules
Four AI tools: OpenCode (the heart) connected to an LLM provider, Notion + Cursor to update knowledge weekly
6 custom AI Agents to help users of the hive mind
A lot of AGENTS.md files, a MEMORY.md, and a SOUL.md file
One AI agent to collect information, create a report and a GitHub issue
One AI agent to update the knowledge base and AGENTS.md files by creating a new pull request from the GitHub issue
One human to read the report, correct any mistakes, remove unnecessary parts and merge the pull request
A custom CLI tool to manage git submodules

That's it.

Let's get into the details.

One Git Repository to Rule Them All

I created a repository and added all the relevant repositories using git submodules. Having 60+ repositories forced me to introduce some folder structure.

I grouped repositories by how the product and teams were structured (not by technical structure, like Kotlin repos, Go repos, etc.). For example, Sales and Payments are two big domains at SumUp, and each is placed in its respective folders: domains/sales and domains/payments.

Then, under each domain folder, I added an AGENTS.md and the repos/ folder. AGENTS.md file provided an overarching domain context for the folder. Instead of adding any specific repository context, it includes the domain's definition, its principles and structure, plans to retire some services (like if a team wants to remove some service but there is no active project to do so), and ongoing mid- to large-scale projects.

As I work in the sales domain and aimed to build the hive mind for this domain, I put the clients of the sales domain's APIs in the main clients/ folder, and platform infrastructure in infrastructure/ and so forth.

Some domains were big and needed subdomains. I added a subfolder within the domain, and the relevant repositories went into that subfolder. The subdomain also got an AGENTS.md file.

Example structure:

domains
- sales
  - core/
    - repos/
    - AGENTS.md
  - reporting/
    - repos/
    - AGENTS.md
  - AGENTS.md
- payments
  - processing
    - repos/
    - AGENTS.md
  - payouts
    - repos/
    - AGENTS.md
- clients
  - …

Instead of adding all repositories at once, I only added a few repositories to test the system. I evaluated by looking at how a good LLM model with an OpenCode harness would handle multiple repositories when I ask a cross-domain question.

When it comes to AGENTS.md files, I created a domain template and extracted all this information from Notion & Slack using AI and validated with my own organisational knowledge and random spot checks. This part took the most of my time. I tweaked these AGENTS.md files quite a lot until I could get a good response to the cross-domain questions I asked.

(Side note: The moment Anthropic's Opus started to struggle was roughly around 10 repositories. After 10 repositories, I started creating custom agents to control dispatching subagents.)

(Another side note: Managing these submodules was quite a burden. Some users of this system won't know Git. Disk space was also a problem, as some repositories require gigabytes of storage. Therefore, I developed a custom CLI tool (details are in the appendix) to load and offload modules on the local machine as needed.)

Custom AI Agents

I used OpenCode to create custom agents. OpenCode allows setting up instructions, models, a permission set and a few other granular settings for custom agents.

In OpenCode, I created three primary agents and two subagents:

General Companion primary agent
Primary Investigator
Primary Brainstormer
Domain Investigator subagent
Repository Inspector subagent

A hive mind user can work with the primary agents but can't dispatch the background agents. Why use custom agents rather than leave it to the model to decide?

Four reasons:

I need to dispatch an agent scoped to a single repository to keep the context small and limited.
Within a single repository, there is no need to use Opus of Fable; Sonnet or GPT-Terra (or even Haiku) are enough. However, Opus or GPT-Sol class LLM need to handle complexity of the whole work.
When generic subagents handover the work to the primary agent, their context handover is random. I needed to have a structured report from each background agent to create consistency across domains and provide the same input to the primary agent. I also wanted to make these reports accessible and readable to humans afterwards.
I wanted to learn how to design this kind of system with structured handovers.

Custom Background Agents

After ~10 repositories, LLM started randomly spawning a subagent to narrow down the work, but sometimes it took on the job itself. This dynamic behaviour confused the agent because it thought the repositories in different domains were part of the same scope albeit not.

Each repository has its own bounded context, its own practices, structure, and more details. They are often in different programming languages. No matter how clearly I told the model (using words like "critical" or "must"), it made up its own "mind." So, it needed taming.

Creating custom background agents and ensuring the dispatch command is structured helped the primary agents not to go confuse the boundaries of a repository or domain, so the investigation or brainstorming was finally scoped.

Background agents also created a result report with findings and suggestions using that domain's best practices, scope, principles, goals and ongoing projects. This report became the handover document between agents. It's quite similar to how humans work in teams: each team owns a domain and repositories; they decide how to navigate the investigation/brainstorming based on that domain's context. When they handover a project or a task, there is (ideally) a handover document.

I'm not saying that LLMs cannot handle this complex task; Fable with high reasonning most likely can. Yet, it costs a fortune for my budget. In my experience, the results are also much better when the main agent dispatches a specific background agent with specific command.

Thus, I created two custom background agents (one for investigation, another for brainstorming) whose main jobs are to narrow down the work in a single repository and write up a report file. The primary agents provide these agents with a structured prompt, along with the user's initial prompt. Each background agent also produces an output report using a clear JSON structure (defined by a Zod schema).

Let's talk about how these background agents are used by primary agents.

Primary Agents

At first, I had no primary agents. In each prompt, I told the LLM to dispatch an 'investigator' agent for each repository or domain. That worked until a certain point. It still wasn't user-friendly (as I had to repeat the same prompt), and I couldn't expect other users to know how to mention this and some other specific words. So, I started adding more to the main AGENTS.md file; it got longer and longer.

I went back to the problems I wanted to solve. The first one was: I don't want to gather 10 people in a room to learn how systems work. I could dispatch 10 background agents to understand how each one worked, but that still didn't give me anything about how they all fit together. So, I need primary agents to connect the dots.

The Primary Investigator Agent

The primary investigator agent oversees the whole ecosystem. It performs an initial investigation before dispatching any subagent to figure out which domains and repositories are most likely relevant. If the repositories are not loaded, it downloads them. Once it creates an investigation plan, it dispatches investigator background agents, reads their output reports, merges the whole context, connects dots, creates its reasoning about how things work and assembles a final report. It also creates Mermaid user sequence or system context diagrams if needed.

The primary investigator then also creates a final report. The final report is a single-page HTML file created using the JSON outputs. As it's a single .html file, the users can easily send the file to anyone if they want to share the knowledge.

The Primary Brainstorming Agent

The working mechanism of the main brainstorming agent is the same as primary investigator. However, the purpose is different. It investigates multiple domains, and also helps brainstorming on the problem with the user. This adjustment made exploring multiple solutions across domains possible.

The primary agent dispatches domain-specific brainstorming subagents, gathers back their output reports and brainstorms an overarching solution based on them rather than running a deep investigation itself.

In my experience with brainstorming workshops, evaluating the solution in each domain clearly always brought up interesting discussions and clear trade offs. When compared to listing down pros and cons of each solution across domains, the individual domain brainstormings were more comprehensive. Thus, replicating here gave advantage for each primary agent to orchestrate background agents for specific domain, then compare results with a "fresh" context window.

The background brainstorming agents try to come up with solutions according to the best practices for that domain and creates a report with multiple approaches, including the pros/cons of each and the recommended approach.

Then the primary brainstormer agent reads these reports and synthesises them to identify a few approaches that span the whole ecosystem, with their pros/cons, and recommends a solution that's better for the whole ecosystem.

The Mind of the Hive Agent

Focusing only on technical solutions is helpful for many problems. But not all. While trying to solve some problems, I needed to bring additional context such as organisational structure and prioritise some of the good practices or mental models I try to employ as an engineering leader (e.g., Domain-Driven Design, Conway's Law, Team Topologies)

Thus, I introduced another agent that is neither for brainstorming nor for investigation, but one that has additional organisational context and can think like an engineering leader, including team structures, SumUp's organisational values, and engineering strategy. This agent is freer than the others and can dispatch other primary agents as it sees fit. It cannot dispatch background agents alone.

All primary agents use good frontier models (e.g., Opus) as they need to handle complex queries.

Keeping the information up-to-date

I've been a fan of creating autonomous teams, but I know it's not easy. Maintaining an autonomous team is even more challenging. I see this system (also all systems in general) is similar. After I created this system that will give a user (in this case, me) some autonomy for investigation, the system still relied on an individual to update context proactively.

At my daily work, I spend a good amount of my time and energy following the organisation and learn as much context as possible. That gives me leverage at work to find intricate details, better prioritise the work and bring a more comprehensive context to my team. However, simultaneously, the moment I stop extracting the context I gather and share with others, things slightly go south. That's the opposite of what I want.

So, I looked at what kind of information I gather in a very dynamic organisation like SumUp. A few themes popped up: how different systems between tribes and squads work together, what data they send to each other, what flows teams want to deprecate and retire, what flows they plan to kick off and what flows they have no desire to change unless absolutely needed, what challenges they are facing today and what challenges are upcoming in the future. I gather all these by following the conversations and participating in certain meetings. Extracting this siloed information became my side goal.

I first looked into creating a RAG and have all product and technical documentations along with this "tacit" knowledge and update the data dynamically. However, a RAG was an overkill. What I needed was creating the first information set and a weekly update on what happened in the last week.

So, I created an automated cron-like agent.

Setup

Custom AI agent researches updates in the last week across Notion and Slack (with a guided prompt)
The agent creates a new GitHub issue on the repository with its weekly report attached.
The agent dispatches a Cursor Cloud Agent to read the report and update context in the repository.
The Cursor agent picks up the task, reads the issue description, the report, researches the relevant context files and creates a pull request to update them.
A human reads the pull request, makes changes if needed, merges the PR and closes the GitHub issue.

To create initial context and also set up the prompt for custom AI agent to use every week, I searched Slack and Notion to find each domain's and team's Slack channels (including private ones I'm part of) and the Notion team spaces. Then, for each domain, I followed the same folder structure in the hive mind repository and created all context and agent's prompt to use every week (now anyone in the organisation can also see how the information is collected).

The custom AI agent reviews changes from the last week only, creates a report based on the folder structure in the hive mind repository. The agent uses an LLM model with 1M context window (LLMs with lower context have failed).

Once the agent run is completed, it creates a new GitHub issue and tags Cursor and asks to update the context files using the information in the report and create a pull request. There is no customization for the Cursor cloud agent. Once Cursor is done, it tags me for review.

I review both the report and the pull request. I make slight changes as needed, then merge the pull request and close the issue.

Then I update all submodules once per week (I'll automate this soon, too).

That's it. Although there are tons of improvements, I'm happy with the whole setup. I think 80% of the setup is complete. The last 20% might consume 80% of my time yet yield little benefit compared to the whole project. I will slowly develop it furher.

We'll see.

P.S. I didn't mention any specific LLM model because that's the dynamic piece of this setup. No need to stick to one, I defined some defaults but change it depending on the job.

Appendix

I want to add a few more details about the setup and aim to expand this section going forward.

Custom JSON Reports & Final Report

I created a Zod JSON schema for handover reports, a few custom tools to create and read JSON reports using the schema, and "told" agents to use the tools when working with reports.

That allowed primary agents to also load the same schema to understand the format and to directly read the relevant part of the report when they needed information. That made the agents faster as they no longer had to discover the report’s structure.

It also allowed me to create an overarching HTML report to share with others. When I run an investigation and find something I want to share with others, the best option I have is either to send the outcome of the conversation or to ask AI to summarise it again. However, that also lacks context for each domain.

I created a new tool in OpenCode that generates a single HTML file from all reports from subagents and the main agent. The primary agents create these HTML files as a result of the investigation using the tool. I read this HTML file to learn the investigation result and also send it to anyone when I want to share, and they can see the whole thing: key findings, listed pros/cons for each domain, final result, and my prompts, what the primary agent told the subagents, etc.

This way, I don't need to worry about another write-up, and the HTML serves multiple purposes by definition. It has a key summary for people who need the result and detailed findings for those who need more.

Why OpenCode?

I got this question from one of the readers of this blog after a few email exchanges. I chose OpenCode for one specific reason: I can change my LLM models and find what fits best. Claude locks me into Anthropic models, Codex locks me into OpenAI, and Gemini locks me into Google. While I can test and play around with many models, why would I lock myself into a single one?

While Claude Code is a really good harness, it becomes non-functional when it's down. I use Claude Code with my personal subscription. With OpenCode at work, I switch my LLM model provider and continue working.

OpenCode has an opinionated approach while still being customizable, which is good enough. It also has a desktop app (although not great) that non-developers can install and use, like my Product Manager. I would love to try as many tools as possible, but who has that much time? I would rather keep my focus on building what I need. Then I can ask AI to move my opencode.json file to whatever the next tool we choose, if we want to change.

Last but not least, OpenCode is open source and has a strong, active developer ecosystem that keeps it well-maintained and rich in plugins.

Custom CLI Tool

After having 10 repositories, it became problematic to manage the whole submodules. So, I built a custom CLI tool. It is nothing fancy, and I don't even know how it works as I vibe-coded it. It only needed a few simple functionalities:

Load/Unload modules
Load/Unload predefined groups of modules
Load/Unload all repositories under a single domain
Status of loaded/unloaded modules
Delete modules (without disconnecting them) to save space
Define new groups of modules to load/unload with one command

It works very smoothly and is super easy to use. The custom AI agents I created also use the CLI tool instead of using git directly to load groups of modules with a single command (increasing token efficiency).

Future Improvements

I'll keep this section up to date with the latest status. Here are the next improvements I'm considering.

I am thinking of adding an update-all-needed submodules step before any primary agent run, and maybe a GitHub action to update the submodules with a cron job, then push to the main branch right away. But it will also require everyone to pull the changes. So, I'm more inclined to add it as a task to the agent. BUT it will make the agent run longer, as there are almost 60 repositories to review. Maybe a cron job to update modules and commit to the main branch, and then an agent to review for new commits on the main branch, would be sufficient.
I want to be able to run the investigation without access to GitHub and in the cloud. Although this is not a primary goal right now, it will definitely come in handy for people who are not familiar with the terminal.
Updating MEMORY.md in every run and from everyone using the repository, and automatically pushing to the repository.
Use Primary Agents via @-mentioning them on Slack. This is my ultimate goal.

Reply via email | Reply via Mastodon | Comment

Blogs and Emails

Tue, 11 Aug 2026 08:48:00 GMT

One thing I keep thinking about is making sense of the Internet. Everything is mingled and mixed. I'm okay with it being chaotic. I'm not okay with my corner of it contributing to this jungle.

Although a little outside of the context Jim & John talk about in their posts, I've long struggled with the newsletter concept being presented as a website (yes, I'm using Substack).

I'm still annoyed by the dickovers, but I'm more annoyed with blog posts being sent as emails. I'm even more annoyed that I'm doing this as well.

You might have noticed that I haven't sent any emails in the last months. That's because of exactly this.

John says it well:

A webpage should show the webpage. An email should show the email. I should not have to explain this.

That said, a few changes are coming soon to my corner of the Internet.

In response to: Blogging Can Just Be Stating The Obvious

Reply via email | Reply via Mastodon | Comment

Timelapse of the Universe Video

Sun, 09 Aug 2026 15:22:00 GMT

I watched this video that shows (and also explains) the universe from the Big Bang till now.

The moment you see the human is the last thing, as a fraction of a second. That tells how insignificant we are in the universe.

However, it's also impossible to comprehend billions of years. We don't need to go too far; think about how you perceive the next 5 years. Then think about 20 and 30. To me, 20 and 30 feel similar, although there are 10 years in between them. However, the next 5 years feel much, much bigger compared to 20 just because I can imagine it.

Thinking about 13 billion years: it's the same as money. I can't imagine 13 billion Euros. I can't even imagine 1 billion Euros... I also cannot imagine the length of 13 billion years. It's a lot.

Anyway. Watch the video if you want to humble yourself.

In response to: TIMELAPSE OF THE UNIVERSE: 13 Billion Years in 10 Minutes

Reply via email | Reply via Mastodon | Comment

Ambiguity Is Where the Reader Meets the Writer

Mon, 03 Aug 2026 07:35:01 GMT

102 asks O’Sullivan’s question from the writer’s side: what happens when the production of prose no longer guarantees a mind behind it? Mandy Brown answers the same question from the reader’s side. Reading, she writes, “presumes that what we are reading is the product of a mind, that the reading is itself a gathering of minds.” When there is no mind, “we find not a mind but a forgery, and a glib one at that—a thin, transparent skin wrapped around an empty void.”

StoryScope measures where that forgery shows. AI over-explains the narrative compared to humans (AI narrators explicitly state the story’s theme 77% of the time vs. 52% for humans.) AI doesn’t trust the reader to infer meaning. That inference is what powers the human writing. It’s that nuance the narrator creates that connects with people because every reader can have different takes from the narrative while AI’s verbosity is there to reduce the ambiguity. That ambiguity is the heart of the story.

The paper names the same mechanism: “The pattern is one of over-determination: AI spells out meaning rather than trusting the reader to infer it.” The rest of the numbers point the same way — humans keep morally ambivalent protagonists (59% vs. 38%) and treat the audience as a co-participant (an aside to “you, dear reader”), while “AI writes as though no one is watching.”

One number cuts against the easy version of this argument: AI’s references to other works are vaguer than ours (72% vague allusions vs. 50% for humans; humans name things specifically). So vagueness isn’t the ambiguity I mean. AI is imprecise about its sources and over-precise about its meaning. The ambiguity that works is the opposite pair — concrete in the particulars, open in what they add up to.

So the gathering of minds needs a gap to happen in. Meaning that is stated is delivered; meaning that is inferred is produced — by the reader, in the reader. A text that closes every gap leaves the reader nothing to do, and nothing to do means nobody there.

This doesn’t overturn what I said in 102a — it bounds it. “It won’t matter who wrote it as long as it’s valuable” holds for writing whose value is delivered (the fact, the answer, the how-to). It breaks for writing whose value is produced in the reader, because there the reader’s inference is the value, and you can’t get it from prose that has already done the inferring for you.

Related Note(s):

102: the root question, answered from the writer’s side (accountability) — this is the reader’s side of the same question.
102a: my “valuable regardless of who wrote it” answer, which this note gives a boundary condition.
29: “Certainty is the enemy of open thinking.” Over-determination is certainty applied to a story; ambiguity is what keeps the reader open.
2d: a tension worth holding — one idea for the reader to leave with is not the same as one meaning spelled out. Zinsser’s rule is about the writer’s discipline, not the narrator’s commentary.
69b: the average of the internet also averages out the ambiguity; the tidy single-track plot is what the mean looks like.
73a: if you can’t validate the source of truth, you also can’t do the inferring — both notes are about what the reader is left holding. Sources:
StoryScope: Investigating idiosyncrasies in AI fiction — Jenna Russell, Rishanth Rajendhran, Chau Minh Pham, Mohit Iyyer, John Wieting (University of Maryland / Google DeepMind), preprint. Figures from §4.1 and Table 15; 61,608 stories.
Umyazu by Mandy Brown
We’ll soon find out what is truly special about human writing by James O’Sullivan

Reply via email | Reply via Mastodon | Comment

AI as a Teammate

Mon, 03 Aug 2026 07:35:01 GMT

When you onboard someone to the team, what do you care about? Their contribution, whether they solve the right problem in the right direction. The same should apply to the AI. You must treat AI as a teammate. Consider them as junior engineers with infinite energy and zero context.

Sources: Patterns for Reducing Friction in AI-Assisted Development

Reply via email | Reply via Mastodon | Comment

Accountability in Writing at the AI Age

Sun, 12 Jul 2026 07:35:01 GMT

“What happens to writing when the production of prose no longer guarantees the presence of a mind behind what’s written?” James O’Sullivan, Psyche.co, 29/05/2026

Then James answers with: “Writing has always asked of the person who does it: a willingness to stand behind words, to mean them, and to accept the consequences of having claimed to have written them.”

James puts accountability at the heart of writing (even when it’s not public). That’s what separates the AI writing. He argues that anyone can publish a piece, but can they stand behind every word it generates? Also, how to evaluate the output yourself when you don’t understand the written prose. You know there is nobody behind who spent time thinking thoroughly and decided on those words.

I still think it won’t matter who wrote some text as long as it’s valuable.

Related Note(s):

In the LLM age, why do we even bother to write? What is it that matters? Source(s): We’ll soon find out what is truly special about human writing by James O’Sullivan

Reply via email | Reply via Mastodon | Comment

The Criteria for Valuable Writing with AI

Sun, 12 Jul 2026 07:35:01 GMT

James O’Sullivan argues in his essay on Psyche.Co, “Essentially, the criteria for valuable writing might shift to provenance, from fluency to accountability, and writing that matters will be writing that can still function as evidence of human deliberation—work that cannot be faked because it carries the marks of genuine thought.”

This is romanticisation of writing. In reality, in practical terms, valuable writing is what moves the conversation forward and what a group in a given community considers valuable. One can put the most deliberate work into it and write it for years in a way nobody can fake. If nobody reads or cares, do we consider that writing valuable just because a human wrote it? We never did, and I doubt we will. Writing most move a community from A to B. It must solve a problem after identifying it. And everyone (or the majority) in that community must agree that it’s a problem that needs solving (even when the problem is fictitious).

Source(s): We’ll soon find out what is truly special about human writing by James O’Sullivan

Reply via email | Reply via Mastodon | Comment

Configurations of Businesses

Sun, 12 Jul 2026 07:35:01 GMT

I always wonder what kind of businesses I’m unaware of because the founder chose to stay off the popular culture. It feels like most companies are either backed by VCs or publicly known. I don’t think I want to create a startup. I want to form a boring company that delivers. But I don’t know in which form or what this company would do.

In his piece There are Many Configurations of Business That Work, Cedric gives a good provocation and thinking frame. A few examples of how he uses them are on point. However, I found that the article is missing a perspective: a strategy to expand our horizon and search for various companies that operate differently. I understand that each company would be unique if we formed in different configurations. Yet, a frame to look for these companies and get inspired by them about what can be done would have been great. Now, it looks theoretical, and I felt the need to buy his subscription. Because he has extensive case studies on different companies, and because I feel lost about the next steps to start a company.

Related Note(s):

A system can be set up in different ways, but you need to be aware of where the bottleneck is or where to let go of some parts to start with a better setup. Know your advantages and disadvantages. Source(s): There Are Many Configurations of Business That Work.

Reply via email | Reply via Mastodon | Comment

Design-first Thinking with AI

Sun, 12 Jul 2026 07:35:01 GMT

The difference between spec-first and plan-to-implementation is the same difference between what to build and how to build. Initial analysis with AI and specs should focus on what to build, not how to build.

In the engineering world, two things are really close. That's why product thinking is required in agentic software development. Although AI shrinks the thinking from design to implementation, the design step comes first. If an engineer sees the AI's design thinking while reading the code, it's already too expensive. It's also cognitively demanding.

If two engineers have a whiteboard session on the design, the code review becomes really easy. That's what we should focus on: make agreements and disagreements visible as early as possible to avoid costly mistakes. In a brownfield project, this can include refactoring parts of the project, whereas greenfield projects are easier to design on the whiteboard.

Reply via email | Reply via Mastodon | Comment

The data set of LLMs is just average

Sun, 12 Jul 2026 07:35:01 GMT

AI produces the average of the internet. Which knowledge are you relying on? What is your information source?

The AI code generation doesn’t follow team conventions or tacit knowledge unless these are explicitly stated in the AI agent’s context.

Reply via email | Reply via Mastodon | Comment

Technology Wars

Sat, 20 Jun 2026 07:35:01 GMT

SpaceX’s IPO is restricted to Chinese and Hong Kong investors. There are similar trends in chips and AI technology, too (the Fable 5 LLM model is restricted to the US by the US government because of its power).

SpaceX is not the main thing. The problem stems from gaining access and influence over a country’s defence and intelligence systems, primarily military. The U.S. is not innocent; they scream for freedom, free speech, and democracy, but only for itself.

From a European perspective, we must stand against any restrictions and build mechanisms and systems that always offer more than one option to replace any given one. This is evident in Apple’s restricted access to its brand-new Siri implementation (Apple cannot release the 2026 model of Siri in the EU because of monopoly restrictions although Siri has existed for years). The EU doesn’t allow Apple’s monopoly in its market (up to a certain point). Even for new features or products. Big tech can’t have the same monopolistic and capitalist approach in the EU as they do in the US. The EU stands against this from another angle. Twenty-seven nations make up the EU. The rules are there to balance between them and the rest of the world. 450 million people are a gigantic market for any company, and access should be open to all companies when big tech develops a product.

Related Note(s):

Capitalism creates wealth through innovation. I wonder how innovation can survive in this tech-war environment.
Sources: Commentary on “Absent from hot IPOs? Chinese Investors” by Alexandra Stevenson, Maureen Farrell, Lauren Hirsch, New York Times International Edition, July 13-14 + “Apple AI Upgrade Kept out of Europe for now” by Adam Satariano from the same newspaper.

Reply via email | Reply via Mastodon | Comment

On the Changing Role of Software Engineers

Tue, 09 Jun 2026 09:50:00 GMT

Software engineering as we used to know it is dead. AI condensed the code-writing step of the process from days to minutes. Engineers found themselves having many tasks on their plates, running many agents in parallel. They are burning out tokens and themselves at the same speed. However, I argue that the approach is incorrect. Because one aspect of software engineering hasn’t changed: having an ownership mindset. Today, the ownership mindset defines the role. Although I’ve been preaching about it for a long time, establishing an ownership mindset finally became feasible with AI.

I had various conversations with software engineering leaders over the last few months, trying to understand the changing role of software engineers. Perhaps for the first time ever, we are in consensus about job titles: we have no idea what to call software engineers after they powered up with AI. Context engineers? Product engineers? AI engineers? Prompt engineers? AI-native software engineers? Full-stack builders? Or still software engineers? But our discussions don’t get stuck there; we move forward to looking at what’s behind all these titles. Because they all mean something different from writing code.

I have preached about end-to-end ownership for software engineers for a very long time. I have seen that engineers perform their jobs better when they are closer to their users, have a product sense (even platform-as-a-product), when they communicate with stakeholders and demo their own work (and ideally, directly to their users). Many, many times, I have seen higher-quality, more reliable results that require less rework and have fewer bugs in this operating mode. However, we couldn’t expect engineers to do all of these before.

Because typing code and staying in context to cover various edge cases in the codebase required huge time and effort. And there was nobody other than engineers who could do these. They were focused on completing this part of the work. Organisations, naturally, added a few roles over the decades to parallelise work and let engineers take care of their parts as quickly as they could. The product manager or owner was added to the front of the pipeline, along with someone to focus on user experience and someone to oversee quality downstream. Then we started shifting left the quality, security, and many other things until we were bottlenecked with engineering again. While this approach supported business growth, enabled fast changes and allowed engineers to design a better codebase, it’s no longer holding steady.

As typing code has shrunk to a minimum thanks to AI, engineers have found themselves juggling multiple tasks in parallel. Just because there was more time to do something else while the AI was working, everyone thought asking for more of the same work was a good idea, so they did. After a while, problems such as cognitive debt (overloaded people who are getting closer to burnout) or the vibe-coding trap (AI-generated code that has never been checked) began to appear. The solution was there all along, but many decided not to see it.

It is the core idea of Kanban: the work-in-progress (WIP) limits, but with a little caveat. Although unintuitive, limiting the amount of work that runs in parallel is actually producing better outcomes and outputs. I believe the idea of WIP limits must be emphasised more strongly than before. But perhaps not in the way that many people did it before.

While work is being split into multiple tasks, everyone still tries the same thing as before: splitting the work into different contexts. However, the context one person can manage is still limited. Many organisations expect engineers to parallelise their context and scale vertically: stack up different tasks in parallel. I argue that they should expect engineers to manage a single context while parallelising different tasks within it. Therefore, engineering should scale horizontally over the stack, forming a chain of tasks.

Let’s take quality assurance (QA) as an example. There are many debates about the role of QA: some teams have a separate person, some don’t. Although I see the QA team (when it exists) as enablers that help engineers manage quality, many organisations work differently: engineers hand off work to QA to run tests, report bugs and sign off releases. Even in some teams, QA is responsible for writing tests.

While handing over the work to QA was previously needed for the feasibility reasons I mentioned above (typing code taking a lot of time), it’s no longer realistic. Now, AI requires verification layers to be up front. The more we shift the quality left in the process, the better and faster feedback we get. The non-deterministic nature of AI forces us to build verification mechanisms first to ensure AI outputs are accurate. And there is no point in having a separate person writing tests and handing them over to software engineers. This is a single-person job. In my opinion, it has always been. But now, there is no argument left against it.

So, suddenly, software engineers have to—not should—understand their users, their product, and the business to write effective tests across the stack. Moreover, they also can’t write good specs that are prerequisites for AI agents to perform better (not everyone does spec-driven development, but the plan-and-build approach many people follow is also a form of spec-driven development). Software engineers being responsible for specifications and quality is the horizontal scaling.

This kind of horizontal scaling reduces cognitive debt because engineers can stay in the same business/product context while using various AI agents to handle different parts of the job. This is a fundamental mindset shift: moving from building features in parallel to building a single feature end-to-end faster. They will need to understand users, the project and scenarios to write clear specs for AI agents.

There is a counterargument that engineers now have to learn many different parts of the process and lose their speciality. The same argument also claims that they will still be overloaded across different contexts as they take on more than just coding. In my practical experience, this argument isn’t strong. I’ve been working on building this mindset at my day job, and my experience shows me otherwise.

When people are coached and mentored well, they become more specialised in what they are doing and achieve even better results. They gain the power to make more decisions independently. Once they become a part of defining the why and the what of the job, how they build it becomes more effective.

I also must admit that this is not everyone’s trait. Although I had more than a few people in the organisation who struggled to build the needed skills, they also admitted that they enjoyed the work more (albeit sometimes with more stress due to a steep learning curve).

If we continue establishing an ownership mindset and scaling engineers horizontally over the stack (not vertically), we can’t hold ourselves from posing two big questions:

What will happen to the people who used to “support” software engineers?
How can software engineers adapt and learn tons of new skills?

I really have no answer for the first question as I can’t predict the future. However, today I see product people moving to “builder mode” and using AI, and quality engineers moving to “builder mode” as well, focusing on building automations end-to-end (in ways that were impossible before). So, they are spreading through the software engineering side of things. We’ll see what happens in the future.

For the second question: if the leadership sets expectations and incentives correctly and engineers are willing to build an ownership mindset, they develop these skills over time. I’ve seen it before, the AI and also observed that these engineers shine with AI. I see them enjoying the work much more when they own the entire feature end to end. All they need is a little help to identify the skills they lack and define a growth trajectory for them through training, practical experience, and mentorship.

Good to Great

I share up to three things I found interesting, sorted from good to great.

Good: Many people are struggling to understand what they think about AI and how to approach it. Perhaps the bigger problem is that the technology is not fully deterministic but probabilistic. I quite like the framing of the idea Dan presents: AI’s biggest difference is that it cannot care about anything. I certainly can relate to it and think about many scenarios where I knew something was wrong but couldn’t frame it what or why. Also, the text is crisp and on point. Dan now provided the right words for me to use in different contexts.

Better: You need a space to sit down and let yourself hear your thinking. Beautifully written.

Great: I often don’t link popular articles here. I’ll make an exception. Read the Patterns for Reducing Friction in AI-Assisted Development on Martin Fowler’s website (including all sub-pages). I printed out the whole article and have been studying it for a while to understand how to establish AI in a tech organisation. It sparked so many ideas.

Reply via email | Reply via Mastodon | Comment

Critique: AI Can’t Care

Tue, 02 Jun 2026 09:22:00 GMT

Many people are struggling to understand what they think about AI and how to approach it.

Perhaps the bigger problem is that the technology is not fully deterministic but probabilistic.

I quite like the framing of the idea Dan presents: AI's biggest difference is that it cannot care about anything. I certainly can relate to it and think about many scenarios that I knew something was wrong but couldn't frame it what or why.

Also, the text is crisp and on point. Dan now provided right words for me to use in different contexts even.

I recommend reading it.

In response to: AI Can’t Care

Reply via email | Reply via Mastodon | Comment

How to Truly Disagree and Commit

Tue, 26 May 2026 08:05:00 GMT

Recently, I learned what “disagree and commit” truly means, a concept everyone struggles with a lot. Committing to an idea that you disagree with is difficult. Or, let’s say it was, until today.

The idea is that you may disagree with whatever life throws at you. You accept it as it is, but you have to commit to yourself. I learned this at the most unexpected place (to me): in an improv comedy course.

Improvisational theatre is magical. When you’re on the stage (or taking an improv course like me), it teaches you life skills that you already knew but had forgotten. When you learn a concept from the improv world, you rarely say, “Whoa! How would I have known?” You often say, “Yeah, it makes sense.” When you leave the class, you’re surprised by how little you learned, but also amazed by how much you re-learned and the different perspective you have gained.

In improv, you commit to whatever your scene partner throws at you or whatever weird thing your brain pops up, so you make yourself a fool on the stage. You “yes-and” ANY idea. When your scene partner calls you a monkey, you become one. You don’t reject and say “no, I’m a horse” (unless you’re a delusional monkey who thinks that it’s a horse) just because you were planning to become a horse in your head.

The audience’s expectation builds up instantly. All eyes are on you to see how you become a monkey, not a horse. At that moment, your brain plays games with you. All the plans you have made about what kind of horse you will be, its mood and behaviour are gone. Your soul disagrees with the monkey, but you commit to it and become a monkey that people were waiting for from the moment the monkey word was heard.

Life is the same. As the famous quote says:

“Life is what happens to you while you’re making other plans.”

So, you must commit to what happens in life, as you can’t control most of it. You don’t force your own way into life, but life forces upon you. The more you fight with reality, the more difficult your life becomes.

In one scene in our class, someone came up with a character who was a rich douchebag. The improv game we were learning was about copying others and increasing the level of absurdity in each phrase (yes-and’ing everything), so we became five rich douchebags, and the scene built into a poor-people-blaming scene.

Although we all committed to becoming douchebags on the stage, one person couldn’t commit to shaming poor people and found themselves halfway in, halfway out. The person was committed to the character but not to the play; they struggled on the stage. Their struggling acting, which denied the narrative yet tried to adapt it to the douchebag character, was visible to everyone, including the audience. The more they tried to fight against their heart and soul, the more difficult their acting became.

At first, the douchebag characters started out innocent. We all built on each other’s phrases and eventually began mocking with the bad taste of cheap beer. (Essentially, we were mocking the rich douchebags by showing how douchebag they are.) The more the struggling person tried to participate, the more isolated they became; the phrases they came up with didn’t fit. Even physically, they moved to the corner of the stage and unconsciously separated themselves from the four of us. Their body was rejecting the idea.

At that point, the teacher paused the scene and asked the person to commit to themselves—not the narrative—as well as the douchebag character. In a way, they had to yes-and the rich douchebag and yes-and themselves. That was the easy way out, but they couldn’t see it until someone else pointed it out. When we continued, the person said, “I must admit: from time to time, I drink a cheap beer because it’s actually damn tasty.”

That admittance made the scene much, much better. We desperately needed a way to get out of the constant blaming of cheap beer, and that phrase changed the course to a much funnier direction. During the rest of the play, we all smiled and ended with a big laugh (the best ending in improv comedy).

When someone calls you a douchebag or a monkey, and you have to commit to it, but it’s up to you how you play it. Your choices depend on how you feel about yourself and how you view the situation. What matters is that you commit to whatever comes and find an angle within yourself that you can commit to. AND, fully commit to both.

Let’s say something happened in your life, and you’re sad. Even if your scene partner calls you a monkey (or your boss shares some difficult news), you still must commit to yourself and perhaps play a sad monkey who really needs a cheer up. You have the power to transform the monkey into whatever you want (if your company laid off 20% of its people and you were not affected, you can disagree with the decision and still turn that into an opportunity). When you try playing the happiest monkey in the world while deep down you are sad for something you can’t get out of your head, the audience (and your teammates and boss) will see right through it.

When you try to do something conflicting yourself, everyone around you clearly sees it, even though you think they don’t. Much like on stage, you’ll make your life difficult because you’re trying to become something your soul and body can’t accept. Everyone will see your struggle, but will have a hard time naming it. The moment you accept the reality and “yes-and” to yourself is the moment everyone, including you, will see the most amazing side of you (or the best play that everything fits together well).

Within the spontaneous and random things happening every day, you constantly choose how to react. It’s your choices that turn the day into a good or a bad one, not what life throws at you. Every day, you become the person of your choice.

That choice is sometimes yours, sometimes somebody else’s. You don’t always get to decide. At work, it might be a new responsibility or a role change you have no choice but to shoulder. The escape from random events popping up in the most unexpected times is yes-and’ing them and finding something for yourself that you can yes-and, too.

If you can’t yes-and yourself and only yes-and whatever is thrown at you, there is no way that thing will make you happy. When your body and soul reject it, you can turn to yourself and commit to whatever is within you. But not halfway in and halfway out. You have to be all the way in to committing yourself or all the way out and leave the stage.

While still playing the (life) game, you can commit to anything, because in life (and in improv), you write the play as you go; there is no script. Creativity and commitment are two things that move the scene and life forward.

Good to Great

I share up to three things I found interesting, sorted from good to great.

Good: I’m not rich. BUT I am aware of my privileges. Although I most likely won’t understand what it feels like to be poor, I try to put myself in the shoes of those less fortunate. This showed so much that I couldn’t even think.

Better: You may know from the last newsletter that I’m a big fan of physical magazines, especially editorial or journalistic ones. I bought the latest issue (32nd) of Electra magazine on my way back from travel and read the piece called “AI As A Measurement Of Human Intelligence” by Matteo Pasquinelli. As it starts with this quote: “Civilisation advances by extending the number of important operations we can perform without thinking of them,” you know it’s a good article. That’s how I see AI affecting us. Really, really good article.

Great: I always appreciate well-written hard truths. This one is about how to make a living as an artist. You don’t need to be an artist to read the article. I urge you to read it, especially if you’re NOT an artist. Learning the harsh realities rather than relying on Instagram’s or TikTok’s algorithms, which display only the good side of things, can turn your (and maybe your kids’) life around.

Do you have suggestions for great things? Comment below (or reply to this post via email).

Reply via email | Reply via Mastodon | Comment

On Strategic Thinking

Tue, 12 May 2026 08:05:00 GMT

I never understood what people meant by “strategic thinking” or “being strategic.” I couldn’t accept the feedback when I heard “you need to think more strategically” as well. Nobody could explain what that “strategic” word meant. I finally understood the real meaning when I tried to build an engineering strategy myself.

As I create an engineering strategy for my team and other teams, I have an answer to what it means to think strategically, especially after seeing how people think and approach strategy as we build it together.

It became clear to me that the strategy is about aligning people—agreeing on which problems to solve and in which order to solve them. It is the exercise itself that matters: deciding which direction to go and creating a plan. A plan that everyone will stand behind, even if they disagree with (or don’t like) it.

Being strategic means seeing the forest and its condition first and explicitly stating that the forest exists. Many people miss the forest for the trees. They lose a lot of time focusing on their local optimum without taking a step back to find global maxima. They try to prune the wild trees (small or wrong problems) in front of them and jump from one tree to another, while forgetting to care about the greater forest.

The root cause of this behaviour is jumping to solutions right away after seeing a problem. ”We can do this right away! It’s a tiny thing,” they say, without thinking about understanding the problem deeply. They operate with first-order thinking—focusing on immediate results and obvious outcomes. They don’t see the cost of distraction from the main goal. They focus on small wins.

If you read or watched The Lord of the Rings (LOTR), you may remember a scene where The Fellowship of the Ring has been formed in a council to take the One Ring to Mordor. Gimli is a dwarf without strategic thinking. Upon seeing the ring in real time, he hits the ring with his axe to destroy it. Little does he know that it won’t fix the problem. Then Gimli argues with Legolas that an Elf can carry the ring over his dead body; surely walking on the way to failure, as he is distracted from the main goal: destroying the ring. However, strategic thinking means thinking about the consequences of actions, which Gimli doesn’t do. It’s not about quick wins; it’s about understanding and agreeing on the biggest goal (that the Ring must go to Mordor and be unmade in Mount Doom).

Being strategic means aligning people on the path to solutions to the most important problems. While you can show someone the biggest problem, they often can’t comprehend how multiple problems feed each other, and can’t figure out the underlying factors contributing to a single problem.

During the same scene, Boromir tries to choose an easy way: use the ring to their benefit, thinking that it’s the solution (even after seeing the biggest problem). He tries to distract others, too. Aragorn takes a step to convince him. Although he joins the Fellowship of the Ring, he still disagrees with the direction and has other plans. There, Boromir sees the biggest problem—that as long as the ring exists, Sauron will exist—but can’t comprehend it. That pushes him to focus on another problem.

People who can’t think strategically lose themselves in building the perfect system design, while the business isn’t even sustainable or profitable enough to support it. Many startups fail because someone tried to build a system for millions of users when they had only a dozen.

Last but not least, being strategic is about being constructive, forward-looking. Everyone can contribute to a strategy, but not everyone can stay constructive. Enduring generosity and thoughtfulness is difficult, especially when the strategy may entail extra responsibilities. Strategic thinkers find ways to detach themselves from individual interests and focus on the organisation’s welfare. That detachment is not something everyone is willing to do (in LOTR, Boromir arrives at this point a little too late).

Strategy, of course, doesn’t end here. A successful strategy is not only about vision and agreeing on problems. It’s also about execution. Until the ring reaches Mount Doom and is thrown away, the strategy cannot be successful. Any strategy needs agile planning because of the duration of obstacles encountered along the way. However, once everyone is aligned on the direction and solving the biggest problem, the problem can ultimately be solved as difficult as the Fellowship of the Ring’s journey.

Strategic thinking is not bound to or reserved for managers and needs no title. It can be applied anywhere and by anyone. However, it’s not easy to find people who can do this consistently. It has a steep learning curve and requires practice.

Good to Great

I share up to three things I found interesting, sorted from good to great.

Good: As much as I read dozens of digital newsletters and blogs, my favourite is still physical media like printed magazines and books. The problem with physical media I can read in English is that they are limited to the Anglosphere, giving me a narrow worldview. I want to read people from Spain, China, Japan, Lebanon, Saudi Arabia or any other non-Anglosphere regions. Although translator tools do a good job, finding these people is the most difficult. To avoid being in a narrow bubble, I subscribed to physical Translator Magazine (not to their digital newsletter called The Dispatch). They sent me the new issue, number three, by post last week. I highly recommend it.
Better: Rich Hickey, the author of Closure, has a talk named “Simple Made Easy” that I watch once in a while. Really, really good talk about dealing with complexity. Even after 5 years, even after AI is everyone’s centre of life, his talk remains a fundamental piece that everyone should watch—at least once a year.
Great: The reason I love magazines is the editorial process. As a blog author, I have no editor to give me feedback and tell me my prose is a piece of crap. In digital media, it’s rare to find great pieces because production costs are ultra-low. That’s where the physical media plays a big role. The space is limited, and quality has to be high. Therefore, I recommend another physical magazine that I get every two months, Works in Progress. Great print quality, great ideas, great essays.

Do you have suggestions for great things? Comment below (or send me an email).

Recently I published

✍🏼 Managers Returning to ‘Coding’ with AI: I found myself building more and more. Other managers around me are similar, too. However, we all have different motivations. Over several conversations, I realised there are different groups, and I’ve been trying to figure out which one I feel I belong to. Spoiler: I am building things more because I feel nervous and curious about new tech and consider that I need to learn more about it to lead my team better.
🔖 Learning Domain-Driven Design Part I: Strategic Design: I shared my notes from the first part of the book I’m reading currently, Learning Domain-Driven Design by Khononov. I will share my notes on the upcoming three parts as I read them, too.

Reply via email | Reply via Mastodon | Comment

Managers Returning to 'Coding' with AI

Fri, 08 May 2026 06:05:00 GMT

We have been talking with other engineering leaders around me about the impact of AI in our profession. Although nobody knows what will happen, I kept thinking about where I'm standing and what others are doing today.

There is certainly a trend among managers to go back to building with AI. People who haven't been working as an individual contributor for longer than a decade find themselves building software again; some for production, some for open source, some for fun. All have a mixed bag of reasons.

I haven't been coding for almost five years, and now I'm back to contributing to the codebase. I want to uncover why I'm doing it, where I stand and its impact on myself and my team. I believe where I stand matters to my success as a leader, as well as where I'm headed, as many changes will happen on where I stand today. I see the road ahead is (once more and has always been) full of mud, rocky hills and a lot of pain.

Based on what I observe, there are a few groups of managers I can be part of.

Managers who

are expected to "code."
are "coding with AI" for self-entertainment.
are "coding with AI" as an extra to stay grounded.
are nervous/curious/excited about new tech and feel like they need to learn to lead their teams better.
feel the FOMO.
are doing whatever they are doing pre-2025.
others.

Before I dive into each group, I want to clarify one thing: I put the word 'coding' in quotes. Because it's not the coding that we know pre-2025. The "coding" means that it's performed by an AI tool (with LLM); the AI writes the code, not the person. The person perhaps tweaks a few lines here and there by hand. That's it.

Managers are expected to "code"

I think this group is straightforward. A lot of articles are written about this group.

With or without AI, these managers are expected to work like a combination of an individual contributor and a manager. This group was always there, but small in the late 2010s and early 2020s. However, the industry expectations have recently shifted toward this direction.

Instead of being only a people manager, they also code. Now, with powerful LLM models and good agent harnesses like Claude Code, Cursor, etc., this group's IC work has become easier (or chaotic).

Along with the upsides, there are many downsides to managers actively coding features due to unbalanced power dynamics within the team. Many problems pop up when the team is more competent than the manager (which is often the case), but the team can't argue against the authority's decisions.

(A small note: there are many managers looking for jobs and hitting this expectation, finding themselves sharpening their technical skills. It's very challenging to do it while searching for a new job. There are also many like me who are taking precautionary steps in case we are laid off.)

Managers are "coding" with AI as an entertainment

This group is probably the least harmful of all. One can argue that it's the best.

For these managers, building software with LLM is a hobby, so to speak. They play around with things that don't contribute to production code, or they work on their hobby projects outside of work.

There are not many downsides to the people at work, other than the time spent on these. The benefits are much higher than in the first group: these managers see what's out there and can judge better when people talk bullshit without incurring the penalty of authority imbalance.

Managers are "coding" with AI as an extra to stay grounded

This group acts on a felt necessity. They are also the combination of the first two groups.

Nobody directly expects them to build with AI. They might or might not have a hobby project for entertainment. Often (not always), the expectancy comes from the inner world and pushes them to stay grounded. However, these managers often don't get in the way with production-level building (that's what separates them from the first group).

At most, they pick up bug tickets that otherwise would not have been prioritised. Their drive is to stay grounded in the codebase and team processes while learning how to use available AI tools. So they can understand how the AI shift affects their teams.

I felt close to this group for a while. Not because I don't trust my team, but rather my inner engineer was telling me not to lose touch with the craft. I couldn't justify any other reason. But then, I thought my motivation and intention were different.

Managers feel nervous/curious/excited about new tech and think they need to learn to lead their teams better

I put myself in this group. Therefore, I'm going to write directly from my perspective.

The industry is changing, and I'm trying to navigate myself. As we are still in the early phases of AI's impact on software development, no best practices have been established yet. The industry hasn't had enough practice to understand what's best. What we say best today changes tomorrow.

I feel an urge to follow the shift closely to lead my team better. Although my team follows the changes with hands-on practice, I still want to understand and learn together with them.

Also, this change is not something I can ignore. When the cloud infrastructure came as a new technology, your life as a UI engineer might not have changed. You got an API that's hosted somewhere. The same with the introduction of iOS. The iPhone changed the world, but if you were a backend developer, you offered APIs. You just had yet another client and had to maintain APIs longer than you'd like (I'm oversimplifying). With AI, all software engineers are changing. And that's the main problem.

As a manager of this group, I don't know how to set my expectations with my team. I don't know how to give feedback or mentor/coach them. Because not only what engineers build has changed, but also how they work has changed (and it keeps changing every day).

Before, it didn't matter much to me what kind of software the team was building. I could see the missing pieces and see how the team works; I could find ways to evaluate their performance, collaboration, and communication. I could coach and share feedback on any of these topics to help them become more productive as a team.

Their tech stack was secondary. I could rely on establishing a feedback culture where they share feedback with each other on technical topics more than I do. Also, I could learn the tech stack on the way, which always worked out so far.

Now, all my grounds are weak.

That's why I have no other choice but to learn how to build with AI and find out what I can expect from others. When someone doesn't adapt to new tools, I need to know what they are missing out on so I can explain the impact. When it comes to using these tools, the team will (for sure) be better than me, as it always has been. But I need to push them to their limits and coach them to achieve their goals. And that's all about the fourth group.

Managers have FOMO

The fifth group's main driver is the fear of missing out (FOMO). This is the group overburdening others. Maybe they won't admit it, but that's the group that sends you a Slack message copy/pasted from ChatGPT without changing a character. They follow the latest tool or news without trying any tool themselves or knowing what exactly the problems their teams have. They act with hype.

Although it's okay to receive a message written by AI, you never know whether they understood your message in the first place. There are gazillions of tools popping up every day; the hype is real, and it's going to stay that way, one way or another. You can easily spend hours and thousands of dollars without creating any value for anyone. This group of managers are mostly falling into this bucket.

I hear that various managers (also director and VP-level) are sending a huge pull request, fully developed with AI, for review. I don't know which is worse: dealing with the always-on AI talk of an ignorant person, or dealing with the work of an authoritative, incompetent person using AI.

As a manager, it's difficult to stay mindful about not joining this group while still building with AI, especially when motivating the team.

I can also admit that we can embed FOMO in any of the groups above, but I want to clearly distinguish this group: their purpose is not to create value but to create the illusion of value. You can be the judge of it. If you look around, I'm sure you'll find one that fits the criteria.

Managers are doing whatever they are doing pre-2025

This group is the opposite of FOMO. They avoid whatever is going on. They learned how to do their job over the years and built time-proven habits. So, why change? Maybe there is nobody in their organisation driving any change; maybe they have a very strict process for making small changes; maybe something else; they have reasons.

Regardless of why, these managers see this AI trend as similar to any JavaScript framework trend that bursts over time, or as an NFT trend that will be long forgotten.

I can't tell what will happen with AI in the future, but it's already clear to anyone that coding as we know it is dead. Whether you accept it or not, nobody needs to write in any programming language, as their native language is enough to define what they want to build.

Managers have a mixed bag of reasons

The last group is the mixed bag of all, and I think it's the biggest group (or maybe I'm being lazy and not grouping further). Pick one or two properties from the others and define this group.

It's actually difficult to belong solely in any of the first five groups because humans are complex creatures.

For example, one day I am a member of the fifth, one day fourth. It depends on what happened that day. If a new LLM model were to arrive, I want to give it a try and share the announcement with others. If there is a new tool that interests me so I can finally build the pet project that I've held hostage for years, I'm in the second group for a few days. I think this mix of bag approach is completely okay. However, with a caveat, an important one.

To an organisation, a manager has to be clear in where they stand. Otherwise, people get confused. For example, my organisation has to know that I'm standing in group number four when I work. In my free time, I can be in any group I want. Additionally, if I'm changing my position, that also has to be clear to others. If I'm expected to "code" with AI or if I'm doing it for fun, we can all align our expectations with each other, adjust ourselves, and can share fair feedback with each other.

So, which group is better than the others? I don't know. I think that's not the point. What matters to me is knowing where I stand today and figuring out where I want to be. For you, maybe you're happy with where you are. If so, I'm happy for you.

When I step back from all these, I always believed that change is constant. As a manager, I had to learn the skill of adapting to changes. One of the biggest changes was reorganisations or pivots in product, in my experience. They were always painful, dreading, and a lot of work. But I couldn't imagine how the AI would change everything.

What a time to live in.

I thought I'd seen a lot in my career. But actually, I've seen nothing, and the world is even more ambiguous than yesterday. The thing is, there's no other alternative but to deal with the world we have. And nobody knows how this change will shape the world. If anyone claims that they know, they are lying (or trying to sell you stuff).

So, don't take anyone's word for it, including mine.

Reply via email | Reply via Mastodon | Comment

Learning Domain-Driven Design Part I: Strategic Design

Wed, 29 Apr 2026 05:16:00 GMT

The tighter the connection between business strategy and technical design, the easier for a software engineer to understand and implement. The more apparent this knowledge is, the easier for the AI to pick up and apply the principles and engineer to guide it correctly.

Chapter 1. Analyzing Business Domains

While designing and building software, engineers must understand the problem they are solving. To understand the problem, they must understand the context in which the problem exists. The context always comes from the business strategy and domain, and the value that it seeks to gain by building the software.

Business Domain: Main activity of the company. For a FinTech, processing payments; for a delivery service, it's the courier delivery; for a coffee shop, it's the coffee.

Subdomain: A detailed area of business activity. Building blocks of the system. In e-commerce, there are subdomains such as accounting, billing, dunning, payment, order tracking and shipment.

Subdomains

I think this part is the crux of understanding business strategy and domain boundaries. Subdomain separation has to be glued with the business strategy (considering you have one). If the business is unclear—such as in early-stage startups without product-market fit—talking about domain-driven design is inadequate.

In conjunction with having product market fit and multiple teams working in the engineering department, untangling subdomains becomes mandatory.

There are three types of subdomains: core, generic, and supporting subdomains.

Core subdomains

Think of this as the domain that gives the company a competitive advantage. If we consider Amazon, its core subdomain is probably not the payment processing system, but rather the warehouse and shipment management and customer support. Seamless payment processing and offering all possible payment methods is crucial to Amazon's success, but it's most likely not its core subdomain after they support majority of payment methods.

Core subdomains, by nature, are complex. This only makes sense: if it were easy, competitors would have already replicated it, and the company would lose its competitive advantage. Using Amazon again, if everyone were as efficient as Amazon's customer service or warehouse & shipment management, we would not be talking about Amazon today.

Core subdomains are not necessarily technical (unless it's selling digital products), as is visible from the Amazon example.

Generic subdomains

Think of this as the domain that every company has, such as user identity management or an online shop for a physical-goods company (e.g., Nike, Adidas). The online store is not the main driver of Nike's competitive advantage.

Generic subdomains are also complex and hard to implement. However, the company doesn't need to innovate in these subdomains. Consider identity management; every organization has it to manage its users, and the implementation is almost the same everywhere. So, the company doesn't gain a competitive advantage by innovating here. If their core subdomain is not performing well or not creating a moat, there is no value in spending time in a generic subdomain. There are tons of generic, battle-tested solutions available on the market.

Supporting Subdomains

Think of these as simple domains that support the core subdomain without providing any competitive advantage to the organization.

If we consider Amazon again, they likely have a shift management software solution to manage staff shifts in their warehouses. That can be a simple system with basic CRUD operations (create a shift, clock in, clock out, etc). That software doesn't create a competitive advantage for Amazon, but it supports the warehouse management and shipment planning.

Comparing Subdomains

We can compare the subdomains from three angles: competitive advantage, complexity and volatility.

We discussed competitive advantage extensively above; in short, the core subdomains are the real competitive advantage for a company. They are naturally complex. That said, competitive advantage doesn't only come with user-facing solutions. An e-commerce product can build organizational efficiency that no other e-commerce platform can, reducing operational costs and enabling cheaper sales. The organizational efficiency becomes their competitive advantage.

When it comes to complexity, the core and generic subdomains are both complex, but the supporting subdomains are often simple. The differentiator between core and generic is that generic subdomains don't change often and consist mostly of solved problems that don't require innovation. Core subdomains are naturally complex and continuously evolve (or iterate on) their complexity. If the complexity evolution stops, the competition catches up, and the company loses its competitive advantage.

(I will open a cross-reference to David Farley's Modern Software Engineering definition: our job is to become experts at managing complexity and at learning. So, the modern software engineering definitely supports this definition.)

Differentiating core and supporting subdomains is more difficult than separating generic subdomains. The main question to ask is: would someone pay for a domain on its own? Can we spin off a company only with the specific subdomain? If yes, it's a core subdomain.

Supporting subdomains are often so simple that other organizations can quickly build or outsource. They are often simpler to hack and build than to buy from outside.

Generic subdomains are still complex domains, but they are solved problems. They can be bought from outside sources (such as Twilio for sending emails or SMS).

The generic and supporting subdomains can also intersect because of their lower volatility than core subdomains. The core subdomains must evolve continuously; they are volatile.

Identifying Subdomain Boundaries

Which domain is a core, which is supporting and where are their boundaries?

The trick is thinking of this as similar to modular software design. If we aim to make everything into separate modules, that becomes overengineering without bringing any value. So, we must find the balance.

The core domains need to be drilled down as deeply as possible to separate the generic and supporting subdomains.

The generic subdomain, however, will not provide benefits when split into more generic subdomains.

We have to find the most coherent core subdomains that are complex and volatile, so we can put our attention to it to keep a competitive advantage. While doing so, we should get rid of the technical mindset and think in terms of business. Although a CEO can rarely tell their product’s domain boundaries when asked, the organizational design, organizational rituals and strategy are good places to start identifying core subdomains.

Domain Experts

Domain experts are the people engineers and analysts solve problems for. They represent the business; they are the ones who identify the business problem and from whom the knowledge originates. They are either the end users of the software or the people coming up with requirements.

They hold the domain expertise. That's why engineers must stay close to these people to solve the right problem.

Chapter 2. Discovering Domain Knowledge

Sharing knowledge between domain experts who know the problems and engineers who build solutions is key. Understanding the business domain problems requires using a common language between domain experts and engineers. This language should not be translated by an analyst or product owner. Instead, it must be a shared language that explains the business domain without any technical jargon.

This language is called ubiquitous language.

In software development, we often talk about the stages: discovery, design, implementation and delivery. The first part (the discovery) includes identifying the ubiquitous language—establishing a shared mental model of the problem and starting to speak the same language. This shared language must be used across the board by all the people, software engineers, product owners or managers, domain experts, designers, quality assurance, etc.

The ubiquitous language must be explicit, precise and consistent without ambiguity. There shouldn't be two terms used interchangeably; one term for one definition (if we're talking about a user while having multiple variations, the definition must clearly say 'visitor,' or 'admin,' or 'user,' etc.)

Only with ubiquitous language as a communication tool can we talk about designing a solution model and implementing it.

Model of the Business Domain

The book provides a great example of how to define a model.

Think about maps such as terrain, subway and navigation. If you want to go from A to B via subway, a terrain map is not useful; you need a subway map. Similarly, with a subway map, you can't measure the distance between A and B; you need a terrain map.

That's how modeling works. The model isn't 100% objective and explicit representation of what the business is; it's how we make sense of the business, and is purposed to solve the problem it is supposed to solve.

A model is not a real copy of the problem; the model should abstract the complexity of the problem and the domain and bring just enough, and the right, information to solve it.

The model should represent the domain expert's understanding of the business domain (their mental models), not the engineers'. The ubiquitous language shouldn't try to cover every possible detail of the domain.

There are a few helpful tools to support having a shared ubiquitous language: glossaries and a Gherkin-based test suite.

(I will open two cross-references here. 1) A product requirements document should serve to align everyone on models and a ubiquitous language. If there is a product manager whose job is to understand the domain and choose what to build, they should be accountable for the ubiquitous language, and engineers must be accountable for using the same lingo in the codebase. 2) In Product Management's Sacred Seven book, the authors talk about products evolving over time as the userbase changes and changing the product design with the userbase. I see a strong correlation between finding the right product design and identifying the ubiquitous language and domain modeling_. In the end, solutions to most problems aren't techy.)

Chapter 3. Managing Domain Complexity

Domain complexity often comes from different domain experts naming the same things differently or naming different things the same. They use similar words to explain completely different things. Hence, all domains get entangled because engineers building these systems also get confused. Sometimes people try to build a grand model that can address the needs of multiple domains.

Solving this problem requires establishing boundaries between domains. We call these boundaries the bounded context.

Bounded Context

A bounded context is an explicit context assigned to a sub-section of the ubiquitous language. It aims to create boundaries so that model definitions can stay consistent, explicit, and have a single meaning. Terminology conflicts and implicit contexts are eliminated with bounded contexts.

A model cannot exist without a boundary (a stop on the subway map has a different meaning in a navigation map). The bounded context allows the definition of distinct models, principles, terminology, and business rules that are consistent within its boundaries.

"A ubiquitous language is ubiquitous only in the boundaries of its bounded context."

A ubiquitous language can't be used without the explicit context in which it can be applied.

For example, if we consider an order in a Point of Sale system's order management software, the order model is a very complex entity that handles items, taxes, fulfillment, kitchen preparation, and many more. However, the same order in the accounting domain means a very different thing, which doesn't involve anything related to kitchen management but only the taxes, money movements and the order's date to account for the order in the books correctly.

Order management and accounting are different bounded contexts, where "order" means very different things in each domain. If we used the same order model for both, we would make the whole system much more complicated than necessary.

Each model needs to be useful in its own bounded context. If we widen the boundary of ubiquitous language, it becomes more difficult to keep it consistent. However, the scope will depend on the domain and the system. Sometimes, keeping the scope wider helps compared to splitting the boundaries and the ubiquitous language.

Subdomains vs. Bounded Contexts

Subdomains are discovered based on business strategy. This decision doesn't belong to software engineers; it's about how the organization works and plans its competitive strategy. Software engineers analyze the business domain only to identify subdomains (not to decide).

Bounded contexts, on the other hand, are designed. Choosing models' boundaries is a strategic design decision. We decide how to divide the business domain into smaller, manageable problem domains.

"Each bounded context should be implemented as an individual service/project, meaning it is implemented, evolved, and versioned independently of other bounded contexts."

"Each bounded context should be owned by only one team. However, a single team can own multiple bounded contexts."

(A side note: This is where the Inverse Conway Maneuver and team topologies come into play. Also, the idea of DDD is that once you discover these bounded contexts, you can align your teams accordingly and define responsibilities clearly. Although we often see Conway's Law more effective.)

Chapter 4. Integrating Bounded Contexts

Bounded contexts can be integrated in three ways:

1. Cooperation

In cooperation, the teams' successes depend on each other. A single team can't be successful without the other. Hence, don't choose the cooperation method if teams are not geographically co-located, as it requires close collaboration.

Cooperation can be implemented using partnership or shared-kernel approaches.

Partnership

Two teams share the work. They must collaborate closely on it at all times. When one team changes something in the API, they tell the other team, and the other team changes it too without drama.

Shared Kernel

Two bounded contexts keep the same models, but as separate libraries or something similar. While the rest of the bounded contexts differ, the shared model leaks the ubiquitous language and implementation into each context.

2. Customer - Supplier

In this collaboration pattern, two teams can succeed independently, although one team has more power.

Conformist

The power imbalance favors the upstream team. Downstream conforms to whatever upstream dictates. Downstream accepts the upstream's bounded context and ubiquitous language.

Anticorruption Layer

The power imbalance still favors the upstream team, but is slightly countered by the downstream team. When the downstream doesn't accept the upstream's bounded context, the downstream translates the upstream's model into its own bounded context's model by implementing an anticorruption layer (called ACL in diagrams).

This pattern is good when upstream changes are too frequent, or when upstream is inefficient or when the downstream has a core subdomain that needs protecting.

Open-Host Service

The power imbalance favors the downstream team. Upstream team decouples its implementation model from the integration model (what they offer to downstream) by adding an open-host service (called OHS in diagrams). This way, the upstream can evolve its internal model at a different speed and publish new versions for the integration model. The downstream can move to a new version of the integration model at their own pace.

3. Separate Ways

The last collaboration pattern is going its separate ways, deliberately duplicating bounded contexts across different domains.

This pattern can be used for various reasons, such as organizational design, communication issues, generic subdomains, or the need for different domains in bounded contexts.

Context Map

A visual representation of the system's bounded contexts and their integrations, aimed at providing insights into high-level design, communication patterns and organizational issues.

Reply via email | Reply via Mastodon | Comment

What is true friendship for you?

Tue, 28 Apr 2026 08:05:00 GMT

Mediations is a newsletter I write for software engineers and leaders but I never focus solely on software engineering. This is a newsletter for humans trying to mediate the challenges life presents, so the topics are as wide as it gets.

In the last few newsletters, I talked a lot about AI. While it's both bothering me and making me feel excited, it's not the only challenge I face. There is a bigger question in my head over the last year or two.

A while ago, I put myself way outside my comfort zone and decided to join a meetup on friendship. If I want to describe my experience, I wouldn't use any other word than "weird". We were around forty people gathered in a potluck dinner across three long tables in a private space.

While we ate and talked about different stages of friendship, I kept thinking about the single question the organizer asked at the beginning for everyone to answer in turn.

"What's true friendship for you?"

Although I was still confused that the meetup started with a body stretch (followed by this question) while the food was laid out on the table, the question turned out to be the one I had been avoiding for quite some time.

I answered with,

"A true friend just calls without either of us feeling weird about it. Nobody is calling anymore. The most you get from someone these days is a voice message. Nobody is spontaneously ringing your doorbell anymore. The true friend is the one who feels comfortable ringing your doorbell unannounced, and you are happy to see them, not surprised that they didn’t call up front."

Many people later told me that it was spot on and they felt heard.

It was surprising to me because I thought I was the only one thinking that a true friend could "knock on the best friend's door and neither would be surprised."

Yet, it's not acceptable anymore.

Everyone is busy with themselves (or with their AIs). Although I observe that the in-person meetings and meetups are soaring, the true friendships are often neglected. Everyone has their hobbies, self-care rituals, or chilling at home after a tiring week of work. Everyone has to schedule a catch-up week or two in advance, or you must share some of your hobbies. Otherwise, you can't see anyone.

Maybe this is coming with age, but I doubt that. I know many people have kids and responsibilities they can't avoid or neglect. Often these responsibilities are under some schedules that can't be adjusted. But I observe that many singles are also living under somewhat strict schedules for themselves.

I'm also falling into the same bucket. You know, while everyone around is busy with themselves, you also start to get busy with yourself.

I think this trend started before, but accelerated with COVID. We found ways to enjoy the time we spent alone and at home with our hobbies during the COVID years. During those two years, we built our muscles (also our workstations) to adapt to a different life. We also began noticing others doing the same. The phone calls turned into voice messages (if you send one that is longer than two minutes, people call it a podcast), and text messages turned into sending a meme in an Instagram DM.

Somehow, we can't demand our good friend's attention right away while they doomscroll on Instagram. We can't expect anyone to ring our doorbell while doing nothing substantial at home.

Our friendships, these days, depend on bits of information from Instagram stories and social media DMs, so we can share experiences and form or strengthen our relationships.

I observe that the crumble of information our relationships depend on neither makes anyone feel full, nor pushes for a starvation for closeness. What surprises me most is that many people act as if this amount of friendship or closeness is enough until they hear my answer to that question.

For me, though, it's often not enough. Although I need my alone moments from time to time to clear my head and recharge my energy, good friendships have always been at the center of my life. I usually valued my chosen family more than my birth family (I know my parents are not reading this, it's okay to admit it).

I'm sharing this with you because, as software engineers, we typically spend quite a bit of time alone in front of a computer (or phone or tablet). But it's crucial to ask ourselves from time to time and to remember what true friendship means. It helps to set expectations with our friends and understand their expectations of us.

So, what’s true friendship for you? Reply to this email or leave a comment.

P.S. I also have friends who feel more comfortable alone, who are introverted or who need good planning. I'm keeping these people separate.

P.P.S. It's also funny that I joined that weird meetup and never talked with anyone from that group again.

Good to Great

I share up to three things I found interesting, sorted from good to great.

Good: I’m not here to claim that I know how to form good friendships. But this post has some good ideas if you want some practical advice on how to make emotionally intelligent friendships. I like reading Eric's posts on Barking Up The Wrong Tree from time to time.

Better: It’s a good reminder to everyone that the creative work requires humbleness, and a prerequisite for humbleness is being more than okay with looking stupid. Well written.

Great: A 9-year-old blog post by John Salvatier, but a very good one. It’s also a crucial reminder in the AI age that reality has a surprising amount of detail that needs to be discovered to do something right.

Do you have suggestions for great things? Send me a message below (or an email).

Reply via email | Reply via Mastodon | Comment

Ignorance in investing

Sun, 26 Apr 2026 16:00:00 GMT

I keep researching to learn how to invest the 10€ I put aside every month. Everyone I asked tells me different things: real estate, funds, commodities, bitcoin, stocks, bonds, savings accounts, all are on the table.

I keep thinking and reading. Yet, I still can't figure it out.

The money is too tiny to turn into real estate.

Bonds don't bring much, they say.

Have you seen Bitcoin lately?

Commodity feels weird, and I don't know what makes it different from bitcoin (also, coincidentally, in gold color?).

Funds and stocks are the only things left for me to look at. To be able to invest in stocks, I need to have basic knowledge of accounting and bookkeeping, finance, economics and psychology. I can't learn from ChatGPT or Reddit any of those. I mean, I can, but even then, ChatGPT can't pick a stock for me. I have to put the hours in to evaluate each stock individually.

I'm not even getting into the income and capital tax world for any of those. The more I look, the more I find building things easier—at least something I am familiar with. But the money becomes 20€ the next month, and I seriously consider investing in something beneficial. But who has time to learn everything in that world?

The more I look at it, the more I think all of these are scams, and only people getting rich are the intermediaries telling people like me to "do X" or provide "financial services" under some umbrella.

I don't trust intermediaries as their incentive is to increase their income, not my financial value or my portfolio.

I really wish our educational system taught about these in school. But I also know I wouldn't listen to it, as I had zero money to invest.

I don't know. I have no solution. Investing in index funds seems the most viable option for now. 🤷🏼

Reply via email | Reply via Mastodon | Comment

AI code review fights between Claude Code and Devin

Sat, 18 Apr 2026 21:01:00 GMT

I started using Devin for Code Reviews. I must say that it’s pretty good.

I develop using Claude Code. It pushes changes, Devin reviews. Then I hook Claude Code to address the comments automatically (there is a checkbox in the Claude Desktop app).

Devin and Claude fight it until all comments are addressed.

Pretty neat.

Reply via email | Reply via Mastodon | Comment

Humans are cyborgs

Thu, 16 Apr 2026 11:00:00 GMT

I recently read the following text in the book Co-Intelligence by Ethan Mollick.

"You are not only a human, but also a cyborg. You are a cyborg because you use machines to enhance your abilities and extend your senses. You use computers to store and process information, phones to communicate and connect, cameras to capture and share images, and so on. You rely on machines to perform tasks and solve problems you cannot do by yourself."

If I read this text anywhere, I would say it's not written by AI. However, Mollick says it's entirely created by AI, word by word, during a conversation.

As much as I don't think AI is sentient, AI can form arguments (in a way), the ones that I haven't even thought about before.

I have never considered myself a cyborg. When I think of a cyborg, RoboCop or Darth Vader comes to mind (or Inspector Gadget or even Stephen Hawking).

Yet, the AI is right. We actually became cyborgs when you think about it. Especially with the addition of artificial intelligence tools to our inventory, we started enhancing our abilities even further.

When I ask an AI to perform a thing for me that I can't do it myself, how does it differ from Inspector Gadget adding or removing a new gadget on his hat? I think it is the same.

So, yes. We are cyborgs AND we can learn from a machine.

Reply via email | Reply via Mastodon | Comment

Who has the knowledge? Me? Or the LLM?

Tue, 14 Apr 2026 09:05:00 GMT

I couldn’t send the last few Mediations due to sickness and not getting enough rest to recover fully. I kept telling myself that I should write and send something, but I didn’t want to send anything half-baked. Also, I realized that I still don’t have a stable mechanism for sending this newsletter biweekly to keep the show going. But, so be it. We’ll get there. I’m also a human after all.

Three weeks ago, I was trying to add new metrics to our system to track the types of validation errors the API returns and to create an alert based on specific validation errors. Until that moment, these errors were written as text to be returned to the client, explicitly stating the problem with the request they sent.

Providing text in the response and clearly explaining the problem helped a lot to the engineers integrate with the APIs. However, when creating metrics and dashboards, vanilla text with varying parameters is not ideal due to its high cardinality. Grouping errors by text was not an option.

So, I fired an Al agent to implement key/value pairs for all validation errors, use those keys for metric collection, and keep the values as human-readable text. It did. However, the solution was not elegant at all. I had to perform various iterations.

I gave one prompt (on a GitHub pull request) to iterate, left the agent and came back 25 mins later. 💸 $35 💸 was gone. For a moment, I was like: WTF-has-happened-here.

I was surprised because Cursor (Cloud Agent) decided to run the prompt with the highest available LLM model with the highest thinking variant, ignoring my default settings (side learning: always explicitly tell which model you want to use). The bigger problem was that it still produced poor results, which I wouldn’t expect from that model.

I could curse the LLM’s inability at that stage, but then I read a short article on the Internet (which I can’t find anymore to link here).

The big question the article asked was, “Who has the knowledge, LLM or humans operating them?” I interpreted the article according to my situation.

What information was I relying on to build the key/value pairs? Was it me? Was it the LLM’s training dataset? Or was it the context files like AGENTS.md? Or was it the prompt I gave?

In my failed scenario, I solely relied on the LLM’s training dataset. I neither gave enough nor correct knowledge in the prompt, nor was the knowledge available in any context files (such as AGENTS.md or skills). I didn’t even know how to implement the changes, as my Kotlin (the language we use) coding skills are rusty.

After that, I learned to ask myself every time which knowledge I am relying on. If that knowledge is in my head, I have to spell it out in my prompt. If I’m relying on some knowledge that is recurringly needed, that needs to be added to AGENTS.md or as a new skill for AI.

If I rely on the LLM’s training dataset because I don’t know how to implement something specific, I need to approach it differently. The LLM’s training dataset is rich, but all models still operate with probabilistic resolution. The training dataset is generic and not tailored to the context I’m working in. Therefore, I have to narrow the AI’s playing ground so it doesn’t deviate too much and can remain creative within those bounds.

Considering all, these days, this is the prioritized order of the knowledge I am relying on while working with AI:

Context files > Prompt (all knowledge in my head) > LLM training data set

Also, I shift the knowledge to the left as much as I can. When I discover something in my prompt that will be needed later, I add it to AGENTS.md or create a new skill for it (or ask AI to do it for me). Over time, with some additional tools, I aim to create a good agent harness.

Agent harness became the differentiator as the difference between foundational models became indistinguishable. With a good harness, we can manage the knowledge, context, and tools the model has access to and guide the LLM in the right direction—providing the customization layer based on the project context.

For example, when I realize the model is repeating the same steps often and producing different results (or wasting time generating the same output again and again), I aim to extract that operation into the agent’s harness to improve determinism. Sometimes the answer is a new skill; sometimes it’s a single-line addition to AGENTS.md or a specific function as a plugin, and telling the agent to use it.

Now that I think about my $35 failed AI run, was it a failure? I don’t think so. Because it made me think and helped me gain a new mental model. If it had cost $0.5, I probably would have neglected being diligent and couldn’t have connected the dots like this.

While these are still new for me (and I have other costly failures), I always thought I missed the golden age of software engineering (90s & 00s) as I caught the bug at the end of the 00s. These days, I often think that we’re living in an industry and world-changing time. Now, with AI, the software world is changing on a grand scale, way bigger than before.

None of us knows what’s “the best.” We need to keep talking and sharing what we discover and learn. We have to share the failures with a slight optimism. We must ask questions, be skeptical and be mindful simultaneously to evaluate every step we take. We shouldn’t hand over our judgment to AI, but we can hand over structured knowledge and guide it well to use that information. Then sit back to see the amazing results it gives back.

Good to Great

I share up to three things I found interesting, sorted from good to great.

Good: While living in EU, I can see so many problems with how the corporate structures work across countries and regimes. EU Inc. A new harmonised corporate legal regime is in the plans of EU Commission. If you’re outside of EU, this might still be crucial for you as it might allow your company to expand to EU with a single entity instead of many. I’m waiting for its positive impact in the market. It’s sad that this came late. But better late than never.

Better: I read this again after a while. Very good reminder: start with solving the problem with smallest effort. Once your solution proves itself, you can advance it.

Great: Let me take you away from technology a bit. I came across this. The interpretation of the book, the conversation, the thought flow, the picture book itself, what can I say; everything is pure gold. How not to love it?

Do you have suggestions for great things? Send me a message (or email).

Reply via email | Reply via Mastodon | Comment

Wild Times with Claude

Thu, 09 Apr 2026 20:30:00 GMT

I might be late to the game but I’ve been developing a personal iOS app I have wanted for years, but never had the time or chance to dedicate a few weeks to. In a few hours, I have a functional app and I only need to tweak a few things here and there. The code is also good and well structured but has zero tests (but I didn’t ask it to choose TDD per se).

I only used Claude Code (from the app, not terminal) in Plan + Build mode without any tools or plugins. This is wild.

On top of it, I asked Claude to use fastlane to setup my my Apple Developer account so I could install it on my phone.

I’m writing this post from that application. Such a wild time.

Reply via email | Reply via Mastodon | Comment

An Ode to Things That Do One Thing Well

Mon, 23 Feb 2026 06:05:00 GMT

I have a long-standing argument that passes the test of time.

A product should do one main job and do it well. When it tries to do more, it often does none well.

It's tough to do one thing exceptionally well, let alone two. If we consider the difficulty of doing one thing masterfully as 10 times more difficult than doing one thing moderately, doing two things exceptionally well is not 20 times more difficult, but instead 100 times more difficult. The difficulty and complexity grow exponentially.

Most people who build products don't have enough time, resources, or energy and can't afford to spend 100x. They usually can't even afford 10x. They say "enough" after 7x. Hence, the world is filled with crappy products with subpar user experience.

Let's take multi-functional, fully-automated coffee machines (like this one). The coffee quality of multi-functional coffee machines (like this one) is, at best, arguable. When a coffee machine grinds its coffee, tamps it, then brews an espresso shot, froths the milk on the side, mixes them, and dumps the used coffee into the bin, how can the maker reliably optimize every single step? They were trying to build multiple functionalities simultaneously. They were trying to stand out in the competitive coffee machine industry with innovation for convenience. While making a single operation in the process really well is notoriously difficult, they tried six.

That's why the best coffee shops, and all those gurus, use an espresso machine that does only one thing (and does it really well): an espresso shot. That's why they use separate grinders; the machine does nothing but grind coffee beans.

The moment I see a machine that can make espresso or cappuccino, I know I won't get the best coffee, regardless of the quality of the coffee beans. That machine ensures getting a good enough coffee consistently, not the best.

Take Starbucks coffee machines, an art of innovation. It looks similar to those espresso machines in small coffee shops. But it also grinds the coffee and cleans up the grounds. It's optimized for consistency and speed, replacing much of the work a barista puts in to make the best coffee.

Starbucks' promise, although they claim, is not to offer the best coffee. Their promise is consistently good coffee. I get the same coffee in every Starbucks branch, even across continents. I still enjoy it from time to time, but it doesn't give me the quality of a great coffee made by a great espresso machine that only does espresso.

It's pure joy to use products that do one job and do it well. The product hides all the complexity and doesn’t distract me from the main purpose. It's simple (not basic); I know what to expect. There are no hustles. No surprises. It. Just. Works.

Reply via email | Reply via Mastodon | Comment

Learning. Again. And Again.

Tue, 17 Feb 2026 09:05:00 GMT

Last week, I saw a message from December 18th in our team’s Slack channel. It mentioned a minor bug that affects only a few users. The team responded, “Let me create a ticket, and we’ll prioritize accordingly.” You can guess the story; the ticket stayed at the bottom of the backlog for almost two months. A bug affecting only a handful of users is often ignored and never prioritized in big companies with millions of users.

Luckily, the person posted a follow-up message last week asking whether there is any progress. Instead of responding with “we couldn’t get to it yet,” I triggered an Al agent as a response to the message.

I gave the AI (Cursor in this case), right from the exact Slack thread, ~30-word prompt saying, “@Cursor this thing X is connected to Y via A, and there is a fallback to B. But X occasionally doesn’t work as it should. Find the problem and fix it.” Within fifteen minutes, it found the issue and opened a pull request with a fix.

I don’t know why I was surprised, but I was. If I had approached it traditionally, I would have prioritized the bug ticket, refined it in the refinement meeting, then an engineer would pick it up, work on it, get a code review, and then merge the pull request. This process would take at least two days. It took AI to fix in fifteen minutes.

After the AI opened a pull request, we reviewed the code with one of the engineers on my team. The logic was spot on. We did one more iteration on the pull request (also with AI) to improve the code. Then, we merged the pull request, deployed and released the fix.

Keeping in mind that I work in a large company (3000+ people) operating in a regulated Fintech business, this one-thread conversation was not an easy destination to reach. But it was enough proof that we were moving in the right direction.

One prompt in a Slack message wouldn’t work if we hadn’t invested in the foundations up front. We are slowly integrating AI into our daily work. Recently, we refined AGENTS.md files and rules files, and advanced our AI code reviews to ensure Al agents have the right context. That Slack thread was not actually my first attempt.

My first attempt failed a few months back before we invested in defining contextual files for AI agents. Now that we have the context, I want to take the next steps with my team. Although I’m following people who are deep into agentic coding, I am approaching it with more mindful steps because we’re fundamentally changing how we work.

Meanwhile, and coincidentally, I was exchanging emails with one of my blog readers about how the engineering role has been changing for a while. We acknowledged that not only does the way of writing code change, but also how a team works.

How does a team review code now, or do they even review at all? How do they host daily standup meetings, or do they even need them? Do they even need sprint planning? All of them need to change.

We, as software engineering teams, must learn everything again. And again. We must invent new ways of working, form new team structures, and create processes that are different from what we know now. Right now, I don’t know what these processes will look like, especially in mid- to large-sized organizations.

The good thing is that we don’t start from scratch.

All technological advancements have built on top of existing ones. What looks revolutionary is almost always the accumulation of decades of small steps. Tiny pieces come together over time to enable a breakthrough.

We have at least two decades of agile practices, many more decades of software engineering, and even more decades of running business practices under our belt. Now it’s time to experiment with new ways of working. Take a step to make one process easier and better, then fail. Learn from it and then take another step. At some point, we will hopefully figure out a new way.

Perhaps we’ll need AI agents to communicate with each other instead of hosting daily standups, so agents don’t override or block each other’s work or create conflicts. But for now, we will keep suffering through the daily standup (as if we haven’t suffered enough) and take small steps to adjust existing meetings.

I must admit that I am nervous. Because of the future of my job, my profession is less predictable than five years ago. Although I’ve seen this coming (I have been closely following deep learning developments since 2017). I had high hopes of working in language models or machine learning, but I wasn’t brave enough to switch to a completely new profession back then due to life constraints.

That said, I’m not scared. Although I can’t predict the future (unlike many others who claim they can), I know I need to add many, many maaaany new tools to my tool belt. It’s time to learn and adjust. And then learn again.

It’s also time to ignore the voices such as, “Al will eat the world” or “Al can’t do my job, it slops...” I think both sides have a point, but also unhelpful.

The correct attitude is to accept the change, experiment with new tools and ways of working and learn from them. The right way is (and it always was) to solve the right problem at the right time. Only then can we focus on building products and systems that benefit people and help us make a living.

P.S. If you already tried new ways of working in a team with a mix of AI agents and people, hit reply to this email and let me know.

Good to Great

I share up to three things I found interesting, sorted from good to great.

Good: The debate between The Builder and The Thinker hit home for me. “I miss thinking hard,” says Ernesto. I feel you, Ernesto.
Better: There are people who affect your career trajectory. They change how you think, work and live. They are often unaware of what they have done, which makes it even more beautiful. I hope you will come across one (if you haven’t already). Susam did. Also, I admire Susam’s passion for computing spanning over twenty-five years.
Great: I used to think that I could control or influence a lot of things around me, especially in my job. When I couldn’t, I complained. In the last year, I changed my mindset around how I work. It was neither apparent nor sudden; it happened gradually. I am a much happier person now. Last week, I read this and realized that what Satya (the CEO of Microsoft) says is what I didn’t have before this change: an attitude of solving problems without complaining. Read it. Dissect Satya’s words, letter by letter.

Do you have suggestions for great things? Send me a message.

Reply via email | Reply via Mastodon | Comment

Living with one rule for a better life

Tue, 03 Feb 2026 09:05:00 GMT

I’ve been part of boy-scouts for only three days in my life. I always admired them, but wasn’t able to keep up the discipline of regularly joining when I was a little boy. As much as I enjoyed nature, I preferred active sports.

In my three days (and also thanks to my father), I learned one rule from them that I apply everywhere. Although I didn’t apply it for personal gain, I’ve received tremendous benefits from it (both external rewards and inner peace).

The rule is famous and simple: “Leave a place better than you found it.” But many people get it wrong. They focus on the literal meaning: “Clean the place before you leave.”

In its core, it’s about getting rid of the attitude of “it’s not my job” or “I’ll do it later.” You know, it’s often someone else’s job, and later time never comes, even if it’s your responsibility. So, instead of shifting the responsibility or postponing the inevitable, you might as well embrace the reality and make everyone’s (including your future self’s) lives a little better.

At work, you can correct a tiny grammar mistake in someone else’s document while you read or grab a dirty coffee cup that’s lying around while walking to the kitchen to get a drink. At home, you can take out trash while you’re heading outside instead of adding to your to-do list a task that says “take out trash.” You grab it on your way out; that’s the simplicity.

The “leave” word in the rule doesn’t have a literal meaning. When you move from the living room to the bathroom for a quick pee, you’re not leaving home for others. Before you stand up from the couch, grab the dirty clothes lying next to you and bring them to the laundry basket.

The rule is also popular in software engineering: before changing a single line of code to quickly fix a bug, rearranging 10-20 lines around it can improve overall readability. When these small refactorings accumulate, the team slows down, the likelihood of bugs increases, and untangling messy spaghetti code becomes a big effort. I had many debates with people at work after they spent five minutes creating a Jira task for a cleanup task that could have taken the same time to refactor.

The moment you grab those dirty socks from the ground on your way to brush your teeth, the moment you take that dirty cup with you on your way to drink water in the kitchen, you avoid accumulating work for your future self. Carrying one cup is always easier than cleaning a desk full of dirty cups; refactoring 10 lines of code is easier than refactoring the whole codebase.

There is one caveat with this rule: you should not expect any external appreciation while doing so. Otherwise, you can’t follow the rule sustainably. The state of the code is the motivation. The state of the living room or kitchen is the pride, not the “thank you” from a colleague or family. The more invisible the favor is and the more you can deal with being invisible, the more peaceful you’ll be.

The inner will or making things better should be the driving force, not the appreciation of others. When you correct a grammar mistake your colleague made in a document without anyone (including your colleague) noticing, you make your and your colleague’s world a little better. That mistake you fixed is an unknown unknown (they were not aware that the mistake existed) for the next person (even when that person is you). It takes no effort from you, and your colleague’s document doesn’t look sloppy anymore. Isn’t that a great thing?

And you know what: the moment this becomes a real habit is the moment others start noticing it. They realize your little efforts. You win people’s hearts almost without effort. But that is a secret. You don’t know it. Never heard of it. Because that’s not why you do it.

Reply via email | Reply via Mastodon | Comment

OSTEP: Chapters 1-4

Sun, 01 Feb 2026 15:46:00 GMT

I've recently started reading the Operating Systems: Three Easy Pieces by Remzi H. Arpaci-Dusseau and Andrea C. Arpaci-Dusseau. The book is, to my surprise, free. This is probably one of the biggest contributions to the computer science community. I first saw the book when I came across Phil Eaton's book club. I'm reading the book together with hundreds of people in this book club.

It’s been more than a decade since I read anything about Operating Systems. I also don’t work in the area. It’s purely an interest and curiosity that I'm reading this book. I really liked book’s language, which is very different than any other book I've read in computer science. You're having a conversation with authors and it's really fun.

It was great to finally understand what virtualization mean, especially on the memory side. Looking forward to learning with you and from you all.

Here are my notes from first chapters:

Chapter 2

Virtualizing CPU

While running multiple programs on a single CPU, the Operating System (OS) creates the illusion that the machine has multiple CPUs. That is done via virtualizing the CPU. For example, if you run multiple commands in the CLI on a single CPU, the CPU will switch execution between these programs until all are finished. That creates an illusion that they run in parallel.

Virtualizing Memory

When a program tries to access memory, the OS creates a virtual memory and assigns it a private virtual address space.

Even if multiple processes run in parallel and try to create a new allocation, they each get their own private address space. That’s why, when we request memory with malloc() in C for two processes simultaneously, they can get the same address, indicating both programs are assigned to the same address space. Actually, they both have their own virtual address space. For the program, it appears to have access to physical memory (and it does), but the OS manages the actual access while the program is in its virtual address space. So, one program can’t affect another.

Chapter 4

The Operating System (OS) creates the illusion of multiple CPUs (even when there is only one) by using a technique called time-sharing.
CPU needs low-level methods or protocols called mechanisms and high-level intelligence called policies.

Running a process

Before running a program, the OS needs to create the process:

Load the process’s code and data from disk to memory
Allocate memory for the program’s stack
Allocate memory for the program’s heap
Initialization of I/O
Start the program (call main()) and transfer the control of the CPU

Process States

The OS has data structures, such as “Process List,” to keep track of important operations. Each process has a data structure representation that includes context, memory location and size, state, parent process, and more.

Reply via email | Reply via Mastodon | Comment

Overcoming Content Overload

Tue, 20 Jan 2026 09:05:00 GMT

In the dopamine economy fed by infinite content, our relationship with content turned to mindless consumption. The profits from getting attention bred the arms race of dopamine-inducing weapons disguised as comfort delivered through sloppy content. However, this comfort became costly.

The engagement with the content decreased, causing cognitive overload, resulting in one way relationship based on seeking low-quality content to satisfy our dopamine addiction. In turn, this behavior (also known as doom-scrolling) promoted even sloppier (sometimes AI-generated) content consumed in greater quantities.

This whole ecosystem is what I’ve been fighting against on a personal level for the last few years.

Also, I often feel stressed by the amount of content I want to read, watch, listen to, or learn. This stress lowers my guard against crappy material and shifts my aim to consuming more rather than qualitative engagement with the content. Both to reduce my stress and improve my content pipeline, I set out to find an approach.

(If you don’t want to read the whole post, scroll down to the TL;DR section.)

Friction, Inconvenience, Constraints

Before I go into details, I need to talk about friction.

Friction is often considered unpleasant. The inconvenience it creates is the undesirable sin everyone is trying to avoid. As Fatih says, “[Friction] is a constant force against you. And the hard part of it is that most people don’t realize that they live their lives with friction all over the place.” Most people are not aware of the inconveniences. As Fatih adds, “You have a single salt and pepper grinder in your kitchen, perhaps next to the oven. While cooking, you might want to add a bit more salt, so you get up, take the salt grinder, and use it at your dinner table.” Instead of buying a new pepper grinder, people carry it back and forth. They live with that inconvenience.

Yet, when it comes to content, people maximize consumption. Promoted by influencers under productivity, they apply dozens of ways to “easily catch up with the world.” They conceal overconsumption with wisdom.

I consider friction as a fundamental element of productivity and intellect. Friction, inconvenience, and constraints are enablers of creativity, productivity and quality. Learning to live with them, or even leverage them, positions us to face reality rather than an illusion of convenience. Friction forces you to find new ways of doing things.

What I will explain below adds friction to (or causes inconvenience) in content consumption, with the aim of increasing quality and maximizing growth, not the quantity. Rules act as constraints that power creativity and force us to think more, changing the ways we fill our dopamine reserves.

The Method

I repeatedly realized one thing that works: extending the time between first seeing a material and engaging with it.

The longer the distance, the higher the quality of the engagement.

Collecting in a central database

I wrote before that I avoid using algorithmic feeds in almost everything (algorithms are optimized to increase the owner’s profit, not the user’s benefit). I curate my own feed using the Readwise Reader app.

I subscribe to blogs, newsletters, YouTube channels, and others via RSS or set up mail forwarding of Readwise Reader if newsletters don’t support RSS.

For movies or TV series, I use a Markdown file as a watchlist. I add to the list when I get recommendations from people in real life. When I want to watch something, I open that list and choose from there (instead of letting Netflix or AppleTV decide for me).

For magazines, I skim them before buying and only buy when I find at least two things inside that are valuable.

For books, I don't buy any in the same year they are published. I keep a Markdown file similar to movie-watchlist. When I want to learn a topic, I research books but never read the reviews. When I find one I want to buy, I add it to my list and apply a time test. If I can, I go to a bookstore and skim the book there, reading a paragraph or a page here and there before buying it (this doesn’t always work, as I can’t always find all English or Turkish books in bookstores in Berlin).

The next step after building a list of resources is deciding to take a deeper look.

How I Use Readwise Reader

Readwise Reader has two features I leverage: Feed and Library.

Feed: All content from my subscriptions arrives here (I currently subscribe to ~75 feeds, including blogs, newsletters, and YouTube channels, none of which are commercial media). I never consume directly from the Feed.
Library: All custom-imported content (such as random blog posts) is directly added to the Library. I only consume from the Library.

Once a day, I check my Feed and decide whether I want to engage with incoming content. I mostly skim the content (or move forward and backward if it’s a video), understand its structure and make a decision. By the end, I mostly know what the material is about and its main idea.

If I don’t want to engage further, I delete the document. If I do, I move it to the Library. It takes me 10-15 seconds to make a decision for a single piece.

When I want to consume content, I go directly to the Library section (not to Feed). Pick one piece and ask three questions.

Three questions before engagement

I can't recall where I read it, but setting expectations from the content before you consume it alters how you approach it and improves your comprehension. Even if it's only for fun, you enjoy it more when you acknowledge it’s for fun.

Before I read/watch/listen/experience anything, I ask three main questions. My answers often reveal my real intention, reduce mindless consumption and stress. If I don’t have any expectations from the content, I don’t consume it at all.

Before I share these questions, let's test it together. When you read the questions below, don't continue further. Pause for two seconds, then answer them for yourself. If you answer with ”no” to all of them, stop reading this post. Seriously. Don't read the rest; it won't be worth your time.

Here are the questions:

Will this content tell me something I don't know and want to learn? Is this the right material to learn from?
Will it tell me something different about something I already know?
Is this something that will give me fun/joy/mindfulness/relaxation/... and I want that right now?

Now, answer them for this text you're reading.

Did you answer at least one of them with "Yes"? If you said “no” to all of them, stop reading.

If you said "yes," let me tell you why these three questions work and why not others.

I tried to ask, "What do I expect from this content?" It was a more difficult question to answer, though it covers all three. I needed to think harder and longer to understand what I think, how I feel, and how I want to approach the material in front of me to answer the question.

I talked about why friction is both good and bad. It must be strong in certain places, weak in others. Answering these questions should have the lowest friction (simple answers: yes or no). Hard questions are unnecessary at this point; they put barriers to the goal. With low friction, it gets easier to build this new habit.

Once I have at least one “yes” as an answer, I consume the material. But consumption still doesn't mean comprehension. I have one more step.

Consumption ≠ Comprehension

In my "About" page on my blog, I wrote:

One day, ten pages before finishing a book, I realized that I had read that same book before. At that point, my perspective on reading and, therefore, my life had changed.

This is a real story. The book was roughly 400 pages, and it took me quite some time to read. Now, I try to avoid that mistake. In the continuation of my about page, I say:

Now, I don’t care how many books I read; I take many notes, connect dots, and share what I’ve found on this blog and my newsletter.

Focusing on understanding what I consume required me to build other habits that I had written about on my blog before.

I almost always read with a pen in hand, use index cards or my reMarkable tablet to take notes, move my notes later to Obsidian, and apply methods from the Zettelkasten system to connect notes with each other. While taking notes and making those connections, I understand. Then I try to share what I understand on my blog to force myself to fully comprehend it, think it through, and reflect on it in my own words.

All of these take time. The optimization here isn’t about catching up on daily trends, reading all the latest blog posts, or watching the most recent movies or videos. It's about consuming wisely and improving the quality of the ideas or information I'm exposed to.

Time is a very expensive currency; we must treat it as the world's scarcest resource. By limiting the time available for consumption and adding friction, the quality bar for content at each step keeps rising. Each piece of material should raise the quality bar and deserve its engagement.

The content I route around is pruned at each step, and only the content that is worth attention is elevated for consumption. This strategy, as time-consuming as it is, works for me as I’ve been trying it for a few months.

TL;DR: Step-by-step methodology

When I come across new content (assuming I want to engage with it), I do the following:

I add it to Readwise Reader and never open it right away.
When I have time later for content (e.g., on the subway), I open the app.
I pick a content and skim over it and check if I still find it interesting.
If yes, I ask the three questions I shared above.
If I answer at least one “yes,” I engage with the content (while ideally taking notes if it’s non-fiction).
I move on to the next content.
Later on, I move content notes to my permanent notes and connect them to other notes.

For the content I’m subscribed to, they arrive in the Feed section of the Readwise Reader app.

I open the content from the Feed.
I skim over and check if I still find it interesting or think that it’s something I want to know/learn/have fun with (if it’s a video, I watch parts of it for ~10-15s)
If I think I want to spend time with it, I move it to Readwise Reader’s Inbox.
Clean up the whole Feed by repeating steps 1-3.
I open Readwise Reader’s Inbox and find a piece of content.
I ask the three questions I shared above.
If I have at least one answer with “yes,” I engage with the content (while ideally taking notes if it’s non-fiction).
Move on to the next content.
Later on, I move content notes to my permanent notes and connect them to other notes.

P.S. Some of the above strategies also apply to fiction material, but not all. When I want to have fun, I approach it a little differently. I still collect them in a central database (if digital content, in Readwise Reader; if physical, I add it to my list before buying), but I don’t skim over or engage with them in multiple steps. Once I start, I aim to finish it as soon as possible to keep the story and fun intact.

Reply via email | Reply via Mastodon | Comment

Observability

Sat, 17 Jan 2026 07:35:01 GMT

Observability of a system can be achieved by setting up metrics, logs, events, and other monitoring tools. Metrics are limited by definition as they represent a scalar value. Metrics are the pre-aggregation of scalar values. They measure the system performance over a period of time and can't give information about a specific operation. A metric like page-load can't tell which requests were slow. It can only tell the average over time.

Related Note(s):
- Observability to solve debugging problems
Source(s): Observability Engineering 1st Edition by Charity Majors, Liz Fong-Jones, George Miranda

Reply via email | Reply via Mastodon | Comment

Debugging Distributed Systems

Sat, 17 Jan 2026 07:35:01 GMT

Functional decomposition and microservices combined created a set of problems, especially around debugging. What used to be understanding how the code runs (which is eliminated by IDEs and containerization), turned into finding where a certain problem lives in the system. Debugging became a difficult problem as the systems and code bases are separated.

Source(s): Observability Engineering 1st Edition by Charity Majors, Liz Fong-Jones, George Miranda

Reply via email | Reply via Mastodon | Comment

The Obstacle Is The Way—Book Review, Summary and Notes

Thu, 15 Jan 2026 06:54:00 GMT

How Strongly I Recommend It: 9/10

How Likely I Will Gift It: 8/10

The Review & Summary

It's a book that has gained a permanent place on my table. I'll be coming back to this book regularly to remind myself of the principles of stoicism when I feel down or stressed.

It's a good book because it's short, actionable, and focused on dealing with problems that are in front of you.

The book's structure builds from a foundational understanding of Stoic principles to application. While reading, you don't feel lost or missing any information. Chapters build on top of each other.

Also, chapters are readable alone. That's the main reason I place it on my permanent bookshelf.

I also like the writing style: direct without fluff. The style is probably not for everyone, but it speaks to me.

I tried to write a short summary of the book and of what Ryan Holiday explains. Yet, the book itself is already short. So, there is no point in sharing a detailed summary.

I will be giving this book as a gift to many people.

Reading Notes (Chapter Notes)

Our brains are wired to interpret the environment and act as fast as possible. This evolution was needed to survive and compensate for our weak bodies. The brain and its shortcuts have saved humans from extinction. Now, they cause detriment. We have enough power to eliminate most threats and don't need quick reactions to survive most of the time. This behavior remains part of us and complicates decision-making and judgment.
Gaining perspective is an exercise. It's the work you must put in. Spending that mental energy and capacity will bring you clarity. The more perception you try to gain, the more you see things as they are instead of how you feel about them. You gain control over the events and situations. The more you exercise, the easier it will get.
The inner critic plays a big role in how we perceive the obstacles we face. Focusing on how we played a role in the existence of the obstacle makes the obstacle bigger than it seems. Now we have to learn to deal with our impact on the obstacle, rather than focusing solely on overcoming it.
There are things within our control (our emotions, our determination, our attitude, perspective, decisions, desires, creativity), and most of the rest is beyond our control or influence. What we can do is accept what we can't influence as what it is and focus exclusively on what's within our power.
In leadership (and in life), we add more meaning to the moments we have — shifting our focus from what things are to why they happen. We complicate the circumstances unnecessarily. Focusing on understanding situations as they are eliminates all the fluff, additional meanings and harmful perceptions that bring no benefit.

"Remember that this moment is not your life, it's just a moment in your life."

We focus on why things happen and give them meaning, rather than accepting them as they are. It's easier to deal with what they are than to widen our scope to extra meanings. Choose the simpler approach, although it is difficult. Live in the present and focus on what's in front of you. Discard additional meanings or reasons that the thing happened.
(Adversarial growth) Instead of accepting the obstacle as a fact, we need to change our perspective, focus on what we can control, think differently and see it as an opportunity to grow and beat. The struggle against an obstacle is what makes the person stronger. The moment we can see through and understand how we can flip the script is what we seek.
Prepare for none of it to work. "The world could use fewer martyrs." Sometimes you do the best you can and put in all the work. You roll the dice, and the result is not what you expect. You gotta accept defeat and move on to the next. You gotta accept the verdict and move on.
The true will is not loud. It's the silent one that pushes forward in the path. The path is never straightforward. The truth bends and silently stands up all the problems on the path. It doesn't shout at the obstacle because it knows it won't change anything. Instead, it silently seeks to understand what it is and never gives up until it cracks its heart.
You need to prepare your inner strength for an upcoming challenge. A hardship will come. Nobody knows how or when. But it will. You must be physically and mentally ready to defeat it. That readiness is only built in times of peace and in times of hardship. Work on your inner castle, always.
Constraints are always good. Without them, there is no creativity; without them, there is no growth; without them, there is no guidance on the journey.
On the way to success (however you define it), there are always tragedies, setbacks, and problems. You can't walk between flowers to achieve great things (again, however you define it). Accept and learn how to find joy in all of these. Once you do, they won't look as difficult as they seemed at first.

Reply via email | Reply via Mastodon | Comment

Offline gets back but online is still here

Wed, 07 Jan 2026 11:25:42 GMT

Recently, Ava wrote this post.

I've been thinking about something similar for a while. Here are my added thoughts (read Ava’s post first for the complete picture).

The personalities we build always have masks, either in real life or online. AI didn’t change it; it made it easier. I think the trust was always problematic when it comes to authenticity.

Maybe someone like Ava tries to be as authentic as possible on the internet (especially on the personal blog). But it was never the case for everyone. I truly try to show my real thinking on my personal blog. Yet I’m 100% sure I talk differently with my wife or my parents.

That said, I agree we lost trust in the web because of AI fabrication. The trust in the content was already kind of broken; now it’s shattering.

Still, I want to look at the world more optimistically. The Internet remains a main enabler for diversity.

I met so many different people online before and after AI. I’ve never seen 99% of these people in real life. Whether our conversations with these cool people are real or fabricated. For me, the experience with the person that counts—the feeling.

I still meet people online; that doesn’t change. AI doesn’t send me an email to respond to my blog post; a human does. I don’t have a conversation with AI over email. Although these people might be producing content with AI but our conversations feel real. And that’s what matters.

I also acknowledge that offline beats online when it comes to feelings. I’m happy to see that offline finally gets back on track. Now, we can get the power of both.

Reply via email | Reply via Mastodon | Comment

Product still shouldn't be left to (only) product managers

Wed, 07 Jan 2026 09:25:42 GMT

I wrote this post in May 2022. Now using AI is common, I stand by it more than ever.

Product shouldn't be left to product managers.

Reply via email | Reply via Mastodon | Comment

Why don't you get the compensation increase you think you deserve?

Tue, 06 Jan 2026 09:05:00 GMT

As an engineering manager, I have various conversations and make decisions about compensation changes after promotions and annual reviews. People are sometimes satisfied with decisions; sometimes not. Discontent is higher when they believe they have exceeded expectations but have not received sufficient reward. Then, we have a long conversation about the why.

In these conversations, I explain how these decisions are made, not to manipulate their thinking. Instead, provide them with context so they can evaluate their satisfaction and next steps, enabling a better conversation. I have observed that this approach helps people (even when they are happy with the compensation change). They judge the change more effectively and make a better-informed decision about whether to seek higher pay elsewhere or stay.

I’m sharing below the same context I bring into these discussions. After I learned this context and mindset, it helped me form my own perception and set better expectations for my own compensation, too.

Often, unhappiness stems from misjudging the company’s situation, especially when leaders’ messages in company-wide communications are misleading. Sometimes, executive leaders want to celebrate small wins to motivate people, creating a “financially great” perspective, even when the reality is being in financial distress. Because most employees don’t share the same context as executives, they view the evaluation differently.

In the last two Mediations issues (1 and 2), I talked about psychology and economics and their contribution to efficiency and effectiveness. Understanding the company’s situation is another area where we need lenses from economics and psychology, combined with finance and accounting.

What contributes to decisions for compensation?

Behind the closed doors, multiple factors contribute to the budget evaluations and decisions. Not in any particular order:

The company’s current financial performance (+/- profit, revenue, etc.)
Investment plans
- Growth (part of CapEx)
- Deals with (new and existing) shareholders
- Savings for the future
- Strategic Investments (Merge&Acquisitions, Research, etc.)
- Inventory & Logistics (might not apply to all)
- Tax and Debt
- Operational Expenses (OpEx)
Market conditions
- Product Market (competition, expansion, etc.)
- Economic Outlook (world and country)
- Talent Market (finding the needed talent)
Risk tolerance and appetite
Company goals
and probably a few other things that I am unaware of

Within all these factors, the executive leadership team tries to figure out where to invest (or cut) the money so the organization can achieve its goals. The goals can range from finding product-market fit to selling the company, from an IPO to paying off debt or fines.

For example, the company can scale up its Operational Expenses (OpEx) if it plans to support growth through hiring or faces intense competition for the product or has a competitive talent market.

Leadership can also reduce OpEx if debt levels are high or if growth or financial performance doesn’t support the expenditure.

The company might have a large inventory it needs to reduce, and therefore can temporarily scale back production to lower output (though this is rare for software companies).

There are possible variations and combinations of all these factors. Once executive leadership decides, the budget is allocated to departments and teams.

The budget of departments

These contributing factors cascade across all departments, though some elements are eliminated along the way (e.g., shareholder deals, debt, taxes, and more).

For example, if the company has two departments, the decision to split operational expenses (the category that determines compensation) between them may depend on growth, strategic investments, product and talent market conditions.

A very profitable company can keep a department’s budget at last year’s level or shrink it, eliminating any potential compensation increases for the people working in that department. Unless the department can manage the budget differently or secure additional funds, there might be no money available for any compensation increase. In these situations, a layoff is even being considered (remember, even when the company is profitable).

From departments, the contributing factors cascade down further to the teams. A department’s leadership team does a similar exercise to decide where to invest its available budget. They may take risks to create a competitive edge for the entire organization by forming a new team. They may also cut another team’s budget to support this. They may invest heavily in CapEx and don’t add any additional funds to OpEx, halting any compensation increases.

Once a department’s budget allocation is complete, the conversation and decisions shift to OpEx: compensation for teams and individuals.

Team and individual performance, at last

In my conversations, I often explain the compensation decisions using a matrix after the company and department context.

I simplify all of the above to better focus on and assess the impact of individual performance on compensation. I consolidate all of the contributing factors under “company and department performance.” Think of this as the sum of the parts. This is one side of a matrix.

On the other side of the matrix, we have individual performance. Most often, an expectation framework (sometimes defined by career matrices)) is used to evaluate an individual’s performance.

For both sides, I use the following: meets, exceeds, and above expectations. Compensation changes or staffing decisions can be made based on a combination of these two factors.

Here is an example matrix:

Needless to say, there is never a guarantee of a compensation increase even when both company and individual performance are above expectations. A company can be profitable for a long time but can decide to invest these profits fully into CapEx or R&D. It can also decide to shut down one department/team to focus on other areas.

On the other hand, even when an individual’s performance falls below expectations, the leadership can still decide to increase their compensation. That was normalized in the zero-interest-rate policy (ZIRP) era, especially while the talent market was hot. Many people who started working in that period mistakenly consider it “the normal way” compensation works.

Although I didn’t mention an individual performance evaluation much, that aspect of the matrix above is another dimension of these decisions. That part of the matrix is often discussed deeply. Although more comprehensive knowledge exists for individual performance management, many managers (including me) make mistakes because of misalignment of expectations.

Performance evaluations are based on (ideally) aligned expectations. But a perfect world, sadly, doesn’t exist and aligning expectations is hard. On top of it, biases (e.g., gender bias, unconscious bias) still impact these decisions. Also, tons of reasons may cause conflicts between manager and individual, ending up with the decision at the wrong cell of the table above.

Another aspect is that a manager can distribute the budget within a team while keeping everyone’s compensation balanced to prevent unfairness. Sometimes, a team as a whole can work remarkably well, while one individual can shine above them. But when the compensation review comes, the change might feel small compared to others’ to keep everyone’s compensation balanced.

All things should come together

There are many more details on how these decisions are made, but this should provide a good enough overview.

Seeing all the contributing factors AND understanding them takes time and energy. However, I found that once an individual understands the context, their judgment of the situation improves. What matters is understanding the contributing factors and forming more accurate expectations of the compensation.

Ultimately, working with a company is a business contract. An individual offers skills in exchange for money. If the skills (as a whole) are valued for the organization (and the more irreplaceable they are), the more leverage they’ll have. Combined with a deeper understanding of the factors above, they can form a clearer perception.

“Both happiness and unhappiness depend on perception.” — Marcus Aurelius

Good to Great

I share max three things I found interesting, sorted from good to great.

Good: As you might know, I love solving real problems. Reading three ways to solve problems gave me a good framework.

Better: I always enjoyed Gurwinder’s writing. As much as I don’t read most predictions (as they are like a fortuneteller’s story), I found Gurwinder’s 26 Useful Concepts for 2026 post as a better approach. Short and crisp.

Great: The Size of Life. Just go and see yourself (ideally on a computer). You won’t regret.

Recently, I wrote about

The Unbearable Joy of Sitting Alone in A Café: Currently, I am in the last week of PTO from work. I wrote this two weeks ago while trying to slow time down as much as I could. It resulted in this post. A lot of observations, some reflections. (Also, it made it to HN’s front page. I rarely read comments there. But if you want to join the conversation, it’s here.)
I added a bunch of new ideas as notes to my Zettelkasten. All notes are atomic.
A small journal entry: Easy is the enemy of good.

Until next time,

Candost

P.S. I reorganized my blog’s front page and simplified a lot of things with a goal to make discovery easier. Let me know how you find it!

Reply via email | Reply via Mastodon | Comment

Uncertainty and fear can be eliminated by training

Sun, 04 Jan 2026 15:00:00 GMT

Most strong emotions, such as fear, are caused by uncertainty and the unknown. Once trained, managing these emotions becomes simple (not easy). Training takes effort and time. Yet the steady one always heads to the chaos, knowing what to expect and finding an easier way out. Acknowledging emotions (rather than eliminating them) and controlling them are ways to view obstacles differently.

Related Note(s):
- Fear is your body's call to action. Training fear teaches you when to listen and when to override.
- Metacognition is how we observe our own fear and uncertainty; you can't train what you don't notice.
- Training puts you through discomfort. Acknowledge weaknesses rather than hiding them.
- Self-discipline is the long-term character investment that makes training stick.
- Understanding why you make decisions is a practical way to train when fear or bias is driving you.
Source(s): The Obstacle Is The Way by Ryan Holiday

Reply via email | Reply via Mastodon | Comment

Perception Shapes Our Reality

Sat, 03 Jan 2026 19:00:00 GMT

How the world is a matter of perception. The way to achieving what we want lies on how we look at what's in front of us. A small success may blind us or display the truth with full-blown reality; a tiny problem might cause unnecessarily swirling emotions or shows a new way to resolve—all matter of perception. An obstacle on our way can be a detriment or an advantage; it's us who defines it.

Related Note(s):
- We are weakest when we're strongest—success blinds us and we underestimate luck. The same event can blind one person while another sees it with ruthless objectivity.
- Choosing good values and metrics defines our perspective and perception of life; it determines whether we see a glass half-full or half-empty.
- The media distorts reality with extraordinary people, creating misperception. Accepting reality as it is helps us focus on the present.
- Coaching ourselves is difficult because we perceive ourselves differently from how others perceive us.
- Our common humanity pushes us to avoid pain and obstacles and choose the easy way.
- Distractions are obstacles on your way.
- Doubts are your mind’s obstacles.
Source(s): The Obstacle Is The Way by Ryan Holiday

Reply via email | Reply via Mastodon | Comment

Three Simple Questions to Collect Feedback

Fri, 02 Jan 2026 08:35:01 GMT

Three simple questions to collect feedback when you don't know what to ask:

What should X (I, he/she/they) start doing? Why?
What should X (I, he/she/they) stop doing? Why?
What should X (I, he/she/they) continue doing? Why?

Be aware that you're pushing the responsibility for thinking to the person receiving the questions. If you don't know which specific topic you want to gather feedback on, you perhaps shouldn't ask for any feedback in the first place.

Use these questions at last.

Related Note(s):
- Before giving feedback, ask the person how they would like to receive it. Similarly, before collecting feedback, you should know what you actually want to learn.
- When giving feedback with a coaching mindset, ask what they could have done differently. The same questioning approach applies, but with intentionality.
- The feedback in relationships is about you AND the other person. Generic questions might miss the relational context that makes feedback meaningful.
- Confident humility means being open to feedback. But openness requires purposeful inquiry, not just generic questions.

Reply via email | Reply via Mastodon | Comment

Not Learning from Software Failures

Fri, 02 Jan 2026 07:35:01 GMT

Most of the incidents have mitigation actions and follow-up fixes applied to the system. They focus on addressing the root cause. Do these actions mean the organization/team/systems had learned from the issue?

No.

If the root cause is addressed and a few more tests are added to ensure the system won't fail for the same reason in the future, the team has improved, but is still missing crucial learning.

They need to identify other areas with similar weak points, share the knowledge with the organization and expand the knowledge base. This is never prioritized in the rush of the feature and product delivery. It's also invisible when a similar error triggers an incident, because people don't look back at prior incidents to connect them. People who might remember the previous one often left the company. The team is now focused on what they have at hand.

Unless everyone has learned, unless all similar issues have been fixed, we can't say that we have maximized learning from software failures.

Related Note(s):
- Effectively learning from mistakes requires clear intention and follow-ups, not just mechanisms.
- Great debugging pursues 'the why', finding similar weak points requires the same mindset.
- Sharing learning publicly builds organizational resilience and accountability culture.
- An open feedback culture eliminates recurring mistakes.
- Coaching for responsibility: look holistically at how multiple factors contribute to problems.

Reply via email | Reply via Mastodon | Comment

Don't trust people's judgments in conflicts

Fri, 02 Jan 2026 06:35:01 GMT

When you deal with "us vs. them" conflicts, listen to the people but do not trust their judgment. The conflict will create unconscious bias toward the other side. Gather facts and meet with individuals to understand their problems and perceptions. Drill down into the root problem: often, it's an unaddressed need of someone that the other person isn't seeing. Find and address it.

Related Note(s):
- Ask questions without bias to understand.
- Compassion destroys "us vs. them" rivalry.

Reply via email | Reply via Mastodon | Comment

Tools for managing managers

Wed, 31 Dec 2025 08:00:00 GMT

Tools differ when you're not managing Individual Contributors anymore

Related Note(s):

Reply via email | Reply via Mastodon | Comment

How to debug a dysfunctional team?

Wed, 31 Dec 2025 08:00:00 GMT

Debugging a dysfunctional team includes seven steps:

Form a hypothesis
Check the data
Observe the team
Ask Questions
Check The Team Dynamics
Jump In To Help
Be Curious

Related Note(s):
- You need to ask questions with genuine curiosity rather than interrogating.
- Making a team functional is the heart of the management craft.
- Often, dysfunctional teams have unhealthy conflicts. You need to turn rivalries into teams.
- Listen with attention.
- Without creating an open culture (or kicking it off), you can’t even form a hypothesis.

Reply via email | Reply via Mastodon | Comment

Engineering Managers with a Debugging Mindset

Wed, 31 Dec 2025 08:00:00 GMT

Great engineering managers have strong debugging skills and know how to apply them to non-technical problems. They pursue 'the why' of the problem before jumping to conclusions. They seek the underlying issue and don't stop at half-baked ideas.

When managers skip this debugging mindset and jump to conclusions, they solve the wrong problem—one nobody cares about. This not only undermines their abilities within the team but also creates additional problems.

Related Note(s):
Source(s): "Best engineering managers are often great debuggers. Because a great debugger is relentless in the pursuit of the 'why' for a bug." — Camille Fournier, The Manager's Path

Reply via email | Reply via Mastodon | Comment

Easy is the enemy of good

Fri, 26 Dec 2025 06:25:42 GMT

Easy is the enemy of good.

We all opt-in for the easy, all the time. The learning comes from chasing the simple, not easy. Making things simple is difficult. That’s why simple things are almost always great.

Reply via email | Reply via Mastodon | Comment

Engineers have more power than they think

Thu, 25 Dec 2025 17:00:00 GMT

I consistently receive requests from the team to reduce tech debt. Every time, I say similar things. I want to share them here.

As a software engineer, you have more power than you think.

When you're coding for a new feature, you have the power to refactor a specific part of the codebase. You don't need any permission.

When you see that reducing debt in a specific part of the codebase makes the next engineer's job faster and the results are visible quickly, you have the power to reduce tech debt. You don't need any permission.

When you recognize that changing a system's architecture can enhance its reliability, maintainability, extensibility, or availability, you have the power to devise a structured solution and implementation plan, rather than waiting for divine permission.

When you see that changing something in the codebase or in the tools we use will reduce cognitive load or maintenance efforts, you have the power to do so. You don't need permission.

Most of these things don't need to be separate work tickets with estimates. You can easily embed all of these into your existing work. If you are punished for doing something like that, then you're in the wrong environment.

Don't forget, as an engineer, you make most of the decisions of organizations, although they might seem trivial at first glance. Each decision you make every day affects the future of the organization you're in.

Related Note(s):
- This is the complement to managing tech debt from a leadership perspective. Leaders justify to the business; engineers act with autonomy.
- Engineer autonomy is about proving you can work independently. This note expands on what that autonomy looks like in practice.
- Teams need emancipation, not empowerment. Engineers already have the power—they just need to recognize and use it.
- Giving ownership through delegation works from the top down. This is about engineers taking ownership from the bottom up.
- Decision-making strategies apply here—if your decision leaked, could you justify it? If yes, you have the power to make it.

Reply via email | Reply via Mastodon | Comment

Capitalism creates wealth through innovation and productivity

Thu, 25 Dec 2025 17:00:00 GMT

Thanks to the growth, productivity, resourcefulness, and innovation of corporations, capitalism creates wealth—a positive-sum game for its owners. Capitalism is a provider of wealth accumulation and the backbone of innovation due to financial investments. Unlike zero-sum games, where one person's gain is another's loss, the stock market grows because companies create real value through their innovations and productivity improvements.

Related Note(s):
- This wealth accumulation works like compound interest—small returns multiply over time into significant wealth.
- Success requires long-term thinking, not chasing short-term gains: capitalism and index fund investing reward patient investors.
- When making investment decisions, remember you're investing in this wealth-creation engine, not just buying stocks, funds, or bonds.
- The idea of increasing gains by reducing costs is simple and often overlooked.
Source(s): The Little Book of Common Sense Investing by John C. Bogle, p. XIX

Reply via email | Reply via Mastodon | Comment

Minimizing costs and trading frequency increases market returns

Thu, 25 Dec 2025 17:00:00 GMT

Minimizing costs and trading frequency increases the chances of earning a fair share of the market. Similar to gambling's motto of "house always wins," financial intermediaries make a lot of money while others are investing. Reducing these costs increases the chances of earning higher shares from the market.

Related Note(s):
- Just as compound interest multiplies wealth over time, investment costs compound negatively, eating away returns year after year.
- Capitalism creates wealth through innovation, but intermediaries extract value without creating it. Minimize their take.
- The solution is simple—buy low-cost index funds and hold them. Simple ideas prevent complicated problems.
Source(s): The Little Book of Common Sense Investing by John C. Bogle, p. XX-XXI

Reply via email | Reply via Mastodon | Comment

Investor returns decrease as market motion increases

Thu, 25 Dec 2025 17:00:00 GMT

For investors as a whole, returns decrease as motion increases. The motion means the intermediaries win more as they take fees, taxes, and deduct costs from shareholders' value.

Related Note(s):
- This is the mathematical proof of minimizing costs and trading. More trading = more motion = fewer returns.
- Capitalism creates wealth, but motion transfers that wealth from investors to intermediaries without creating new value.
- Long-term thinking means minimizing motion. Patience is profitable; activity is expensive.
- Just like compound interest works positively, motion compounds negatively through repeated fees and taxes.
Source(s): The Little Book of Common Sense Investing by John C. Bogle, p. 5

Reply via email | Reply via Mastodon | Comment

The Unbearable Joy of Sitting Alone in A Café

Thu, 25 Dec 2025 10:33:00 GMT

It's contradictory to sit alone in a café. It's against the reason cafés exist.

They are designed as meeting spaces. There is no table with a single chair. Even the ones placed right by the window with high seating are big tables with many chairs.

Cafés are community spaces. Most go there to see their loved ones, friends, or colleagues.

You find only a few people sitting alone. Most are buried in their laptops, working hard to make a living in their own worlds, whatever world they have.

I rarely do that.

When I took time off from work, I chose a staycation. Unlike most of my friends, who visited Japan in 2025.

When I heard their experiences, I was jealous. When I told them my staycation plans of doing nothing for four weeks, they were jealous.

While off work, I wanted to slow time down as much as I could. The best way to freeze time, I read somewhere, is to get a dog. Luckily, I have one already. So, I took long walks with my dog.

What used to feel like 10 minutes between breakfast and lunch while working became a full-blown day. Even though I was spending two hours walking my dog instead of a 30-40 minute rush, it felt like an eternity. A peaceful eternity.

On the second day, I decided to leave my phone at home, so I lived those two hours to the fullest. I didn't take any device that could connect me to the internet or to other people.

I was nervous.

But all the anxiety evaporated after 30 minutes.

I felt free, so to speak.

It wasn't that nobody could reach out to me that felt like an escape; it was that I couldn't reach out to anyone or anything that caused the turmoil.

I had no possibility to text anyone. No possibility to watch or read. No chance to look up anything to fulfill my curiosity.

My mind was alone after a long time.

There were a few moments I put my hand into my pocket to take out my phone to look up something I was curious about. My phone wasn't there.

I smiled. Every. Single. Time.

On the second day, I randomly walked into a neighborhood café. I ordered an americano with a double shot of espresso.

Sipping a hot americano feels different when you are in a rush to catch a subway. Its purpose is to wake you up. A sip from that little hole in a single-use cap burns my tongue every time. I despise that.

With a porcelain cup, you don't have that. Coffee changes its purpose. It becomes a pleasure.

I sat down with a proper cup of americano. My dog crawled under the table.

I was sitting alone in a café with a dog that had crawled under the table without any electronics that could distract me.

Distract me from, basically, nothing.

It was pure delight. Every element. Or rather, the non-existence of any element. No phone. No headphones. No tablet. No laptop.

My mind was just drifting with the chatter in the café. I left myself to the flow.

When you let your thoughts wander, they take you on a journey you'll never think possible. You reflect on the smallest details of your fast life. Your brain absorbs all the mistakes you've made. You accept that you can't change failures anymore, as much as you feel guilty.

You might as well not worry about them and focus on what you can change: what you do now. And what you will do next.

Nothing else.

The next day, I left my phone at home again and decided to stop by the same café. I was lucky; I sat down at the same table.

Sitting alone in a café without distractions reveals a lot about people. The same people you pass by in a split second while rushing from home to work, from a meeting to a meeting. The invisible suddenly appears right in front of you. People don't go away in two seconds. They stay. They sip a coffee. They talk with others, laugh, cry, and worry. Oh, worry.

Worry is only visible in people's eyes. Eyes are the channel of the heart. You have to close your ears and look at people's eyes to see their hearts.

You realize that looking into eyes is frightening—both for you and the other person. You try to avoid it, but eventually make eye contact because nobody is physically moving anywhere.

As none of you are passing by in a second, you mimic looking at something else. They continue their conversation. But you saw their worry, and you can't help but try to understand.

You leave the café to avoid making things awkward.

I went there the next day. This time, my table was occupied. I don't know when it became my table. But it felt like that. I found another one. It was closer to the staff.

Sitting alone in a café without distractions shows you how a café works. You never contemplate how they operate behind that giant coffee machine while you're waiting for your coffee before you run to catch the next bus, tram, subway, or taxi. You never ruminate when you sip from a single-use cup and burn your tongue.

You notice how the staff circulates porcelain cups, from dirty to clean, to the top of the coffee machine. You observe the staff's reactions to each customer. You try to analyze if someone is a regular by noticing how the staff talks.

You wonder whether they consider you a regular, since you've been there for the last couple of days. Or they call you a creepy guy with a dog. You will never know. You're not fine with never knowing.

You promise yourself to come the next day to observe how the staff talks to you.

I again went to the same café. Unlucky me. A different staff were working on that day. Yet I ordered the same: a cup of americano with a double shot of espresso.

Sitting alone in a café without distractions, with a dog that had crawled under the table, brings a light to a truth: you can't control or influence other people's thoughts and feelings, no matter what you do. Staff may think of you as a weirdo with a dog; your friends might want to be in your place; your family might be nervous because they can't reach out to you.

You know you can't change any of those unless you change who you are. It makes you feel alone and powerless.

You are alone and powerless. You encounter a deep challenge.

The next day, I didn't go to the café. I instead took an even longer walk. I went there the following day, knowing I had faced that challenge in my longest walk.

Sitting alone in a café without distractions shows everyone you're alone.

It's an alone act.

A scary but powerful one.

Many avoid at all costs. That's why everybody looks at you with wondering eyes. They are afraid of your powerful joy. They can't grasp why someone would do this to themselves. They are hesitant but are thinking of doing the same.

Then you realize you're planting thoughts in people's minds that you can't control. Feelings are feelings. Thoughts are thoughts.

Just at the moment you think you are alone again, you see another weirdo across the café sitting alone without distractions. That weirdo is looking at your sleeping-in-a-croissant-shape dog under the table. Weirdo is enjoying the moment, while your dog is on an adventure in her second dream.

You smile. You know you're not alone. You are one weirdo sitting at a distance from one other. You know there are many.

Maybe one of them is reading this and feeling heard. Perhaps one will never see this and will always feel alone. But it only needs one look around. You glance over the café and leave with a smile.

The next day, I went there again. This time, I put in an intentional distraction. A good one.

Sitting alone in a café without distractions only gets better when there is something to write on. Not with a keyboard. You must use your single hand to write, not two. Ideally, with a pen on paper.

The pen is meant to slow you down. The words shouldn't land on paper at the speed of thinking or even talking.

The writing must hurt your wrist or hand. It must turn into a burden. That pain is a signal telling you that you have written long enough. Maybe you wrote only five lines. Perhaps one thousand.

It doesn't matter.

You take a break.

Reply via email | Reply via Mastodon | Comment

Increasing Efficiency and Effectiveness with Psychology & Economics - Part II

Tue, 23 Dec 2025 09:05:00 GMT

In the last Mediations, I discussed economics, in particular, how better technology, processes and infrastructure increase efficiency and effectiveness. However, economics alone can’t cover all six pillars of socio-technical systems.

I also realized that in the last issue, I made socio-technical systems theory look like an economics theory. It was actually born from psychology.

Psychologists sought to explain why productivity declined following technological improvements. They found that assuming people will adjust to the technological advancements without incentives was a mistake. They looked for motives that drive people to change their behavior. Their founding was groundbreaking back then.

No organization can evolve and survive without understanding and learning what drives people. Researchers covered those motives within the other pillars of socio-technical systems theory: people, goals, and culture—the heart of psychology.

Although all pillars are interconnected and can’t be considered in isolation, I will focus on the people pillar and briefly touch on the goals.

Designing effective incentives and systems requires understanding the needs of the exact people who will do the work. If the needs aren’t addressed, no infrastructure, technology or process can change the system’s productivity.

Over the decades since systems theory, extensive research has been done on what drives people to improve productivity. At the foundation, we find autonomy and self-regulation, psychological safety, and cognitive and emotional load.

Autonomy and Self Regulation (a.k.a. The Drive)

Without understanding why anyone would want to expand themselves upward, no leader can build what Daniel Pink calls, drive—our deep-seated desire to direct our own lives, to extend and expand our abilities, and to make a contribution. Without drive, people always choose the easy way: living in their comfort zones.

Although the underlying theory in psychology is called Self-Determination Theory (developed in the 1970s), I prefer Daniel Pink’s rebranded version, which has three core elements: autonomy, mastery, and purpose.

People don’t need to be managed in a traditional sense anymore, especially in the tech industry. They desire to be autonomous. When people own the decisions in their areas and can choose what and how to build, the rest is watching them create remarkable things without external pressure. Yet, autonomy is often misunderstood. It isn’t complete freedom. It means to have the desire to be self-directed. A good example of autonomy is Google’s 20% time policy: everyone may spend 20% of their time initiating and driving innovative projects as long as it supports Google’s mission.

However, autonomy only works when people have the mastery needed to make the right decisions.

Mastery is also often misunderstood. It isn’t the expertise; it is the urge to get better at something that matters (to the person). Anyone can approach mastery but never fully reach it, hence it keeps them engaged with what they do. The desire to learn how things work deeply and know what to do when faced with a challenge can only be built with experience. Combining autonomy and mastery brings a “can-do” attitude that is driven by pragmatism. The more people approach mastery and can work with autonomy, the more efficient they become.

Although improved efficiency is good, what about effectiveness? How can we align all pragmatic decisions with the organizational goals? The only way to ensure effective decision-making is sharing the same purpose or goal, something larger than individuals, something meaningful beyond quarterly earnings. If someone is convinced of the organization’s values and the rationale for those values, they will eventually make decisions aligned with the organization’s objectives.

When we work with people who have the drive, we observe a constant desire to do better, to push forward, and to increase effectiveness alongside efficiency, not separately.

It’s common that the same people also make many mistakes. We can’t expect anyone to make the right decisions 100%. When they take a faulty step or fail in their mission, does it imply they lack the desire to improve? Why do they create chaos even though they are autonomous? How do we expect them to take ownership of their actions and their consequences? How do we extract learnings from failures?

We can’t answer any of these questions or build a driving organization without establishing psychological safety. Without it, the drive has no room to shine.

Psychological Safety

Probably one of the most popular (yet often neglected) concepts in organizational thinking is psychological safety. It’s also the most fragile foundational element of any organization. While building it takes a mountain of effort, a tiny mistake shatters it.

Anyone can claim that they try to provide a psychologically safe environment, yet they can’t guarantee it. People can only feel safe, and nobody can control others’ feelings.

Most leaders struggle with psychological safety and get it wrong because they think it’s all about giving people space to talk or encouraging them to ask questions in company-wide meetings. They never learn what psychological safety really means.

Harvard Business School professor Amy Edmondson defines it as the shared belief that it’s OK to take risks, express ideas and concerns, speak up with questions, and admit mistakes—and here’s the important part—without fear of negative consequences.

Psychological safety demands showing vulnerability (while admitting mistakes) and facilitating a safe conversation, at all times. It’s not only about giving space to ask questions, but it’s also about welcomingly reacting to questions.

In a safe environment, people talk about the problems and mistakes openly and try to find the best possible solution instead of hiding things that might hurt them. This, in turn, increases the effectiveness: if someone is focused on the wrong things, others should be able to raise their voice even if it doesn’t bring individual benefits.

Although psychological safety enables people to take risks and try new ideas, it is equally important that they can manage information and emotions to operate in a safe environment.

Cognitive and Emotional Load

When the mental effort required to process information or hold it in memory, or when there is constant context switching between tasks or tools, cognitive load increases. Every new tool, notification, or system adds cognitive overhead, even if each seems minor individually.

High cognitive load directly impacts effectiveness in the short term and efficiency in the long term. High cognitive load introduces complexity. The higher the complexity, the lower the confidence in decisions. An incorrect decision can cause the team to work on the wrong things from the get-go. Although they can maintain a high delivery speed, it won’t matter if they work on the wrong thing.

A lot of unwritten documentation, bugs, workarounds built into the system, incidental complexity (or accidental), or entangled business logic cause high cognitive load. If adding a slight change to the system causes many “we need to look at where it needs changing” moments because people can’t keep it in mind, this indicates high complexity.

Meanwhile, emotional load can impact efficiency or effectiveness in the short term. Although acute emotional load can be sustained without a significant long-term impact on effectiveness, it must be resolved quickly. Chronic emotional load demotivates, destroys the drive, and drains people’s energy. When emotions are consistently high, the quality of decisions and output drastically reduces.

One of the main challenges of the “socio” part of socio-technical systems is that technical systems often include dashboards, metrics, and other means to clearly monitor progress day by day. Socio-systems have none.

Measuring Psychology’s Impact

Social systems usually have lagging indicators that are difficult to measure and to observe their impact. Because there is no “safety meter” for psychological safety, leaders struggle to gauge it. However, there are tools leaders can use, including 1:1 conversations, attrition patterns, the quality of conflict in meetings, trust levels between teams, surveys, communication patterns, and more. It’s always better to start with the leanest and most frictionless tools and observe and “measure” the changes.

You want to leverage psychology more, but where do you start?

There is no need to read Nietzsche, Jung or Adler’s academic texts at the beginning. Here are some recommendations:

Start with learning the intersection of both economics and psychology by checking out Daniel Kahneman’s Thinking Fast and Slow and Robert Cialdini’s Influence; popular psychology-driven practical books. Both books provide a clear understanding of how the human brain works in terms of decision-making—a crucial mechanism in systems thinking. Kahneman’s biases will help with understanding how to hire more effectively and manage projects, while Cialdini’s strategies will help with driving change in the organization and convincing people to follow your guidance.
Reducing cognitive load is all about proper team setup and clear domain boundaries. Looking into Team Topologies by Matthew Skelton and Manuel Pais is a great start. Also, reading about the incidental (and accidental) complexity is a good option.
Reducing emotional load is not that simple as it depends on relationships and communication. There is extensive literature on both, but I found Dr. Rosenberg’s book Non-Violent Communication the most helpful and practical.
Systems thinking theory is the overarching theory of socio-technical systems theory. Donella Meadows’ book Thinking in Systems explains systems thinking in depth. Highly recommended.
If you want to combine Systems Thinking, Team Topologies, organizational design, domain-driven approach in practice with Wardley maps, I recommend watching Susanne Kaiser’s talk (I have Susanne’s book waiting on my desk to read soon).

For some people, understanding others comes straightforwardly, but they can’t wrap their heads around organizations easily. For some (like me), it’s the other way around. So, you might be strong in one but not the other. Focusing on the weak skill is always a better option. Even developing a basic understanding gives you a big leap.

Reply via email | Reply via Mastodon | Comment

Increasing Efficiency and Effectiveness with Psychology & Economics - Part I

Tue, 25 Nov 2025 09:05:00 GMT

Software systems have become incredibly complex over the last decade(s), along with the organizations that build them. As a result, increasing an organization’s efficiency and effectiveness became as challenging as developing a software product.

A problem I see is people spending a lot of energy and time learning the intricacies of their craft (software development, design, marketing, etc.), and almost no time learning the backbone of working in or with an organization: economics and psychology.

Both subjects are often discarded, but they specifically focus on increasing the efficiency and effectiveness of an organization and its people, respectively.

To understand how economics and psychology help navigate an organization, we can use a few different theories as lenses. In this issue, we’ll talk about Economics. Part II will be about Psychology.

Socio-Technical Systems Theory

Maybe the most popular Economics theory these days is the socio-technical systems theory (STS).

STS was born in the 1950s, when coal mines began using machinery. People held the dominant view of workers as “extensions to machines” (does it sound familiar to how we evaluate working with AI?). Researchers sought to understand why they faced a paradox in coal mines: new mechanical technology decreased productivity and worker satisfaction, despite being technically superior.

Over the last seven decades, STS has evolved into an interdisciplinary framework and has been applied to many complex organizations across different fields.

According to STS, optimal organizational performance requires joint optimization of both social and technical subsystems that are divided into six: people, technology (not only software development but also tools used in the organization too), processes, goals, infrastructure (not only software infra but also the infrastructure of an organization) and culture.

Falsely, many leaders focus solely on technology, processes, and goals to increase effectiveness and efficiency, paying less attention to the other three. Moreover, the interconnections among these six and how they affect one another are often not considered. While new industry-altering evolutions like AI are in full swing, this comes at a cost.

Many leaders lack the understanding of how concepts from STS directly contribute to their organization (look at the ‘Great’ link I shared below to learn how). Almost all categories show their results in lagging metrics, making it difficult to connect the dots between a change and its impact. Yet, we can get help from other theories.

Institutional Economics Theory

Institutional economics theory characterizes institutions as extractive or inclusive: extractive ones concentrate power and wealth in small elites, while inclusive ones distribute power through pluralistic mechanisms.

In tech, extractive institutions can concentrate power and limit autonomy through decision bottlenecks (any change requiring multiple approval layers slows down iteration) or by hoarding knowledge and information at the top. These patterns result in long release cycles and teams perpetually blocked by dependencies due to a lack of context or micromanagement.

On the other hand, inclusive institutions distribute authority and enable autonomy through decision rights at the team level (such as teams controlling their roadmap within boundaries), transparency (information access is open to everyone), and flat hierarchies (managers as enablers, not gatekeepers). These patterns result in frequent deployments, teams functioning as “mini-startups” with end-to-end ownership, cross-functional collaboration without permission demands, and knowledge sharing that enables domain ownership.

Creating inclusive institutions within the organization will enable “sustainable wealth” (so to speak) for everyone and advance the organization (using RFCs or ADRs, Netflix’s culture, Spotify Organization Model, or Jeff Bezos’ API Mandate are among the best-known examples of creating inclusive institutions).

The essential mechanism is that the leaders must commit to giving up power. Knowing the results of decades of institutional economics research can help shape culture, infrastructure, and processes directly, while also having an indirect positive impact on goals, technology, and people.

While institutional economics focuses on the institutional structure, evolutionary economics focuses on organizational capabilities, which are more linked to innovation.

Evolutionary Economics

Evolutionary economics favors a variation-selection-retention framework in which organizations generate modifications through experimentation and search processes, select environments in which to run these experiments (e.g., by choosing to compete in a market), and retain successful variants through organizational routines and memory. Innovation is not a discrete event but a continuous process of search under ambiguity and recombining existing knowledge in novel ways.

When we consider adapting AI or developing new AI tools, we need inclusive institutions that allow for innovation, and organizational capabilities and culture that nudge people to use their existing knowledge and experiment with newly available technology to select the right option that increases team and system performance.

For example, the guild or chapter structure in Spotify’s model (guilds are voluntary communities organized by technical domain, such as incident management guild or developer experience guild, that share best practices, coordinate technical debt, and enable expertise development) addresses the trade-off between cross-functional delivery teams and function specialization. Guilds act as meta-routines that share and update other routines. Allowing guilds to form and wield “soft power” to drive changes in organizational routines enables innovation.

At SumUp, I’m part of the incident management guild, and we have put a lot of effort into automation. We improved how each team reports and manages their incidents with small steps, enabling a well-established blameless and effortless incident management culture.

But how these theories play a role in a daily life of a software engineer?

Software Development and Economics

I see economics as a bonus that will help with any software engineering task. A better understanding of the environment helps reduce toil and rework. By learning evolutionary economics, a software engineer can seek small innovations in their work (or join a guild) without expecting divine permission. Using a variation-selection-retention mindset, they can create slight variations in the codebase, select the best, and retain it for the long term.

By understanding institutional economics, engineers can choose the organization they want to work for and assess the company’s long-term value and sustainability. If a team lead has an ambition to collect all the information and power, the engineer in their team might have fewer chances for a promotion. When an engineer faces an extractive organization rather than an inclusive one, they can also plan how to influence it (a crucial skill for any leader) in the absence of transparency and accountability.

We mainly delved into the technical aspects of socio-technical systems, briefly touching on the social elements. When we consider the DORA research, which investigates the capabilities, practices and measures of high-performing technology-driven teams and organizations, leaders have to think in terms of processes (e.g., how to dedicate time to guilds/chapters), people (e.g., how to structure teams), culture (e.g., how to create autonomous teams), technology (which AI tools everyone is encouraged to use), and even infrastructure (if your security team is sitting in the corner office alone, you will have a hard time shifting left on security). They need to create inclusive institutions that innovates using evolutionary methods.

Of course, no leaders will be successful by learning these theories without practicing them at different scales (e.g., first in one team, then in the department) and without combining them with learnings from psychology.

Lastly, all of these learnings are not reserved for the organization’s managers. Anyone can drive a change (it’s just easier when the managers are on the same page) and influence their manager to take tiny steps in the right direction.

We’ll talk about psychology in the next Mediations.

Good to Great

I share the max three things I found interesting, sorted from good to great.

Good: I sent this to a few people at work. Also deserves its share here. Building agency is what I wish everyone would try to do. How to be high agency at work by Torsten Walbaum

Better: “…a reminder that self-understanding, like so many facets of life, rarely moves in a straight line.” let me repeat for myself: self-understanding rarely moves in a straight line._ From Prison, a bank robber and acclaimed author reflects on time by Psyche.

Great: Adaptive Socio-Technical Systems with Architecture for Flow is a great talk by Susanne Kaiser about the topic we talked about this week. She uses Wardley Map, Team Topologies, and Domain-Driven Design approaches to structure an organization and its systems. Highly recommended!

Recently, I wrote about

I was looking for the meaning of life for the last few years. I found nothing. Apparently, it was there all the time. All I needed to do was to do a retrospective look (which took me a few weeks to complete). I wrote the end result and the journey of how a problem-solving mindset helped me get better at something I feel is my passion now.

Until next time,

Candost

P.S. My RSS feed didn’t include the whole post before, now it does. Thanks, David, for reporting!

Reply via email | Reply via Mastodon | Comment

Added Ko-fi to this blog

Sat, 22 Nov 2025 06:25:42 GMT

I have now added Ko-fi support to my blog. I am still unsure about this, but I would like to experiment. I aimed to place it in the least intrusive place possible: at the end of the post.

I don't know how it will conflict with the two action buttons I have there.

I still prefer people commenting on the post instead of sending me money, but some people are more comfortable with the latter.

Let's see how this goes.

EDIT: I removed the link/button. It feels weird to receive money from others for an open blog.

Reply via email | Reply via Mastodon | Comment

Solving Problems Worth Solving

Fri, 21 Nov 2025 14:11:00 GMT

In the last five to six years, I've been looking for a grand goal in life. My search yielded nothing. The more I looked, the more it concealed. Then I stopped and turned around to look at what had happened so far. Something appeared out of nowhere. This retrospective look didn't reveal the meaning of life to me, but there was a beam, hidden behind my back, guiding me. That ray of light materialized as an eagerness to solve problems. That's when I realized I had found it.

My clearest memories start from high school. Memorizing topics or formulas always drained my energy. Most of my weak subjects were the ones that forced me to memorize word-for-word: history, geography, literature, and even biology. The ones I thrived in—mathematics, physics, and sometimes chemistry—always gave me problems to solve. Naturally, I chose to follow a STEM degree and graduated as a computer engineer.

It's boggling my mind how this eagerness to solve problems has always been there, but disguised. Apparently, it was scattered across multiple fields, and my forward-looking approach hid it behind me (you can't see your back unless you use a mirror; and you don't see yourself in a mirror all the time).

As little as I knew, this joy of solving problems has evolved throughout my career.

Problems with programming

I first enjoyed solving software problems because the stupid, riling, wily machine—ahem, computer—was puzzling me.

I remember very clearly the first lecture of the Introduction to Computer Science I had at the university. The professor told us, "The computer is stupid. I mean, really stupid." We need to think and act as if it’s the dumbest thing that has ever existed. His job was to teach how to give clear instructions to the machine so it would do what we wanted. Learning those instructions became the first of many problems I tackled. I spent a decade working on it.

I solved many problems in different programming languages; I learned best and worst practices, fundamentals, patterns, and paradigms. The more I learned, the more I realized that the problem wasn't the computer. It was doing precisely what I was telling it to do, but what I said was sometimes wrong. I had to start from scratch multiple times. That was the problem I needed to fix next: how to think clearly and give precise direction—the exact thing the professor told me years ago. So, the problem was hominid.

Problems with thinking begin to appear

The human mind caused all bugs, not the machine. For the machine, it was all a matter of true or false, 0 or 1. It was the humans who coded those incorrect bits. That's when I thought we would be better off if we had solved the problems before coding. I moved one step to the left in the process.

I focused on designing a solution up front, shaping my thinking about how to solve a set of problems rather than letting the design emerge over time. I learned more about quality, automation, better software architecture, system design, and the importance of building guardrails. The coding was much easier once we solved the problem on a whiteboard (or paper) and once we defined how we would shape the system for future iterations.

After a while, I realized that approaching this way required a different mindset that not everyone possessed. If I helped people gain a fresh mindset, we could solve more problems efficiently. This approach paved the path to management and leadership.

Leadership and Management

I focused on avoiding wasted time by looking at the team's culture, structure, and interpersonal dynamics that enable healthy problem-solving and debate culture. A culture in which people lift each other, in which incentives are correctly placed, in which everyone is encouraged to think in and outside of the box, in which debate for finding the best possible solution rather than ego satisfaction, and in which delivery speed is high thanks to high-quality work, became my goal.

In the end, it also became my job, and I became an engineering manager. At this stage, the process was no longer linear.

I learned that I needed to jump one or two steps to the left, right, up, or down, or even around corners, in the process (I didn't know systems thinking at first). This demand changed how I approach problem-solving overall.

The management and leadership problems were drastically different than machine problems. The biggest one I recognized was that the teams were often solving the wrong problems. We wasted money and time solving a problem nobody cared about (and for sure weren't willing to pay for).

I began working closely with product, design, and other business units to understand why we are doing a project, what we aim to achieve, and how to make it feasible for the business.

I'm still learning, but so far, this is the steepest learning curve I've faced, not the programming languages. Because it not only includes product and business thinking, it also encompasses all the things I've learned (machine language, software architecture, system design, people, culture, incentives, etc.).

Problems at the intersection of software systems, psychology, and economics have become interesting not only because they reflect what I have learned so far. They are interesting because of the sheer complexity they contain.

Software Engineering, Psychology, and Economics on Complexity

While the software systems are technically sophisticated by themselves, we can't leave out the psychology (especially social psychology, the study of how people's thoughts, feelings, and behaviors are influenced by the real, imagined, or implied presence of others) and economics. Solving problems with software in socio-technical systems (the word ‘technical’ doesn't necessarily mean software; rather, technicalities of an organization) effectively and efficiently demands understanding both.

Effectiveness has a lot to do with psychology, while efficiency is more about economics.

Understanding motivation architecture (what motivates people), reading invisible signals (how to build psychological safety while working with different cultures), managing cognitive load effectively (why is a team/an employee underperforming) and navigating conflicts constructively (what unmet need created the conflict) require a good understanding of psychology. Learning psychology doesn't mean becoming a therapist. It's about understanding the operating system a person/a team is running on, so we can work with human nature rather than against it.

While psychology examines why people behave as they do, economics focuses on the consequences of those behaviors within systems and how to optimize resource allocation. Learning more about economics (the study of how individuals, businesses, and societies manage their scarce resources to produce, distribute, and consume goods and services) opened my eyes to various instruments I wasn't aware of. Opportunity cost, marginal analysis, incentive structures, transaction costs, economies/diseconomies of scale, sunk cost fallacy, supply & demand, impact of biases, information asymmetry, and other mechanics raise awareness of how to increase the system's effectiveness; I was ready to learn them all, but...

Learning all of these takes considerable time and energy. However, none of them solved the majority of the problems that I have faced single-handedly. Instead, each helped me to avoid some stupidity.

"It is remarkable how much long-term advantage people like us have gotten by trying to be consistently not stupid, instead of trying to be very intelligent." —Charlie Munger

Instead of trying to make a smart move, focusing on avoiding stupidity is the best approach I’ve found, since we have a minuscule amount of control over the components of socio-technical systems, unlike software.

In a way, it is all clear to me now. Software engineering leadership (regardless of the job title, Engineering Manager, Director, VP, CTO, etc.) sits right in the middle of these three disciplines; practicing all demands time and focus.

Focusing on the right problems

While some people focus on influencing others or advancing the industry, I focus on building socio-technical and software systems that solve problems worth solving. I constantly remind my ego that influencing one person is a big win in the attention economy and solving one problem can be a much bigger gain for the community than earning a million Euros (if the problem is the right one).

It's correct that through solving some problems, I get paid. I earn enough to give me a headspace to learn a variety of topics, think about them and share them here.

Still, not all problems are worth solving.

I don't mean focusing on problems that bring money when I say the word 'worth.' It is the other way around. If a problem is worth solving, it has a high probability of bringing some benefits, whether monetary or not.

The world is a vast garbage heap of problems that were unnecessarily solved. People solving the wrong problems (careful, not solving them the wrong way) is the biggest waste of resources. That's also one of the main reasons many organizations fail. I intend to avoid that.

People getting stuck with the wrong problem is the grand challenge of our modern age. It's a knotty task as most problems have become more layered, intertwined, and vastly complex. Nobody can solve any problem without going through the levels of complexity. That's why I'm still surprised by how people think they can jump to bigger problems without going through the evolutionary process (a few can do, many can't).

Career journey

A junior engineer needs to solve problems at the code level; they need to learn the language of the machine (this might seem like changing with AI, but I think foundational knowledge is still as crucial as before). They can become senior engineers once they accumulate enough solved problems.

During seniority, they should see enough problems and solutions to start recognizing patterns and different architectural shapes of the system(s). This approach will help them solve different problems and become reliable. That's what experience means.

Now I understand better why job postings ask for some years of experience: solving problems needs time—the biggest constraint of all.

If you claim that you have great knowledge to be called a senior engineer after 1-2 years of software engineering, I can't diminish your knowledge, but I can play down your experience. I am 100% sure that you haven't solved enough problems.

What is enough? It's a big question that I can only answer famously: it depends. It's one of those "you'll know it once you get there" questions. But then, how do you know you'll arrive? Well, it depends on how your organization defines the destination. When it comes to me...

I see this as a journey and a race with myself; a journey through complexity and a race between humbleness and ego. The ego is pushing in every possible direction to contain life and always tries to bite more than it can chew (e.g., seeking the next promotion, surrendering to hustle culture, or being the servant of the attention economy). That's why humility comes from knowing how much I don't know and being aware of gazillion problems, and from facing the challenge of finding the right one.

A journey through complexity, because resolving problems at work is already arduous, let alone the whole life.

The journey going forward

I focus on the complexity of life and on solving problems at the intersection of software systems, psychology, and economics. One branch of this, in which I have dedicated my last 9 years, is solving problems for small- to medium-sized businesses—the backbone of the economy. Imagine solving an admin problem of a restaurant owner, a freelancer, a bakery, a landscaper, an event planner, or a handicraft shop. That enables them to focus on what matters to them and brings joy: their craft. That's where I believe many wonders are hidden.

The other branch I'm focused on is helping others learn how to approach solving these complex problems. If I'm learning something to solve a problem I faced, I want to share my learning with others, and writing it down ensures that I have a clear understanding of what I'm talking about. Repeating what Feynman said: "If you want to master something, teach it."

That's why this blog exists.

And I doubt that this journey will end anytime soon.

Reply via email | Reply via Mastodon | Comment

Distributed Discussions

Tue, 11 Nov 2025 09:05:00 GMT

Back in the late 90s, the Internet wasn’t readily available in my hometown. As it was costly, my parents couldn’t afford it. At that time, blogs were the TikTok or Instagram of today. By the time the Internet became accessible, social media websites like Facebook and Twitter were in full swing. Naturally, I caught the end of the blogging era and grew up with social media. Yet, I still dug into blogs and finally jumped on the train around 2011 and published my first blog article (on Blogger, neither the post nor the blog survived).

One thing I learned from the era in which blogs were reigning the Internet is that most discussions took place in the comments section of the article or were posted as a follow-up blog post. The blog author could have a conversation with readers in one place. Discussions were centralized while the content was distributed. This has changed.

Before social media, forums popped up first to provide a place for people to get together around a shared interest. People having a conversation about all possible topics gave many people a voice, as they didn’t have to build and maintain their blogs and still be part of the Internet. However, forums hit blogs hard as they took the discussions away from the blogs and into the forums. Then, forums became centralized in places like Reddit. Social media took this to another level.

Reddit and other social media platforms centralized both the discussions and the content. Today, when someone reads any blog post they enjoy, they share it on social media with their comments. However, social media algorithms are trained to demote posts that include links as they take people away from the platform (of course, Meta/X/LinkedIn don’t want you to leave even for a second). That further encourages people to copy/paste some of the text from the original post (or share a screenshot) and share their thoughts about it—not even allowing the original post to be reachable directly.

The punishment of algorithms leads people back to forums to have a conversation there. One group discusses an idea over Facebook, a different group talks about it over X, another one starts a debate on HackerNews or Reddit, while yet another group takes it behind closed doors and runs a lengthy discussion over private chat groups.

What could have been a meaningful discussion turns into a set of siloed monologues.

By distributing the discussion across multiple platforms, we are creating echo chambers. The exponential growth of echo chambers is one of the most significant problems facing the Internet (and, to a certain extent, the world). Trying to gain a different perspective became a luxury skill that a few people possess. This evolution contributed to the polarization of the world as people sporadically see contrasting ideas and become less susceptible to outsiders.

Additionally, social media gave everyone a voice. I’m an advocate for freedom of speech, but against hate speech. Anyone on social media can comment on anything, but sometimes it’s better if they don’t. People brew harmful thoughts within their echo chambers and stir each other up. The simmering thoughts that don’t encounter any contrarian ideas while they are tiny waves overflow the echo chamber like a tsunami. If all comments were centralized, people could have seen diverse thoughts, and each blog owner could reduce hate by moderating comments.

The last problem I see is that having fewer comments on the original blog article forced authors’ hands to abandon their blogs and join the social media train and contribute to the dopamine economy. The Internet has become a graveyard of abandoned blogs because people couldn’t see any reaction to the articles they posted (I acknowledge that we have gazillion more blogs than in the 90s; most of them are garbage, and it’s impossible to find all of them, let alone react). Bloggers moved to social media platforms and put their content behind closed doors of X, Facebook or Instagram. Once open and free blogs (and thoughts) began to feed the insatiable profit machine of social media. Meanwhile, most of the remaining bloggers have removed comments from their blogs because they only receive spam comments.

I argue that open and centralized discussions (on distributed content) are far better for humanity. They provide an opportunity for diverse views to be expressed and coexist. It also gives the author a chance to learn from the audience and correct their mistakes. Otherwise, we all live in echo chambers (often for the profit of big corporations) seeing people like us, taking the same perspectives, complaining about the same concerns, and never learning that other views exist in the world.

When we centralize conversations, ideally in the original location that is open to everyone, all perspectives can coexist.

I acknowledge that not all blogs offer a commenting mechanism, forcing everyone to move discussions elsewhere (the chicken and egg problem). Often, the reason for this choice comes down to maintaining infrastructure, comments, and spam. Many bloggers (rightfully) don’t want to deal with that as they want to focus on the content. One or two real comments per year don’t justify the cost and effort (I do maintain a commenting system on my blog here). However, once the blogger decides to have it, we owe a response in the place it’s published, if we are to respond.

Good to Great

I share max three things I found interesting, sorted by good to great.

Good: The question,“What is the purpose of a corporation? Is it solely to maximise shareholder value, as some free-market purists argue? Or does it bear responsibility to a broader set of values and stakeholders?” led a group of researchers to study Chinese companies that are closer to temples and how they distribute their profits. Read the “In China, companies that are closer to temples are more generous to shareholders: religion subtly shapes economic behaviour” by Zhangxin (Frank) Liu.

Better: “Technology is the active human interface with the material world.” A great definition of technology from my favorite author. She wrote this in 2005, and I still haven’t seen a better definition. “A Rant About Technology” by Ursula K. Le Guin.

Great: “I deeply believe in environments that cause people to accomplish bigger and better things than what they imagined they could have done,” says Tobi Lütke, CEO of Shopify. Listen to Tobi Lütke’s great conversation with Stripe’s John Collison.

Until next time,

Candost

P.S. I signed up to Berlin Triathlon (June 6-7) to challenge myself and train during winter. If you wanna join me (or join another event), just send me a email/message/comment and we can form an accountability group.

Reply via email | Reply via Mastodon | Comment

Evolving Software Engineering with AI

Tue, 28 Oct 2025 09:05:00 GMT

I’ve been thinking about how the definition of software engineering has been changing with AI, as everyone is expected to do more.

An engineering manager used to be the person focused on the team’s strategy, developing people’s skills, hiring, project management, etc.. They were deep into meetings and were the person who connected the dots across product, design, and engineering without actively coding on a project, but still reviewing the written code from time to time. Now, they also need to code themselves.

A senior engineer who used to focus on bringing a somewhat ambiguous project or feature to completion now needs to lead a larger project together with fewer team members. A junior engineer who used to take smaller tasks is now expected to handle larger tasks (sometimes up to the previous senior level).

What is behind all this stretch is the AI. The capacity AI has “freed up” needs to be utilized. Instead of leveraging the freed-up capacity to innovate, many organizations are squeezing more out of their people to increase efficiency.

I don’t see anything new in the world when I look at the overall scenario. Every new tool that can affect the team’s productivity is always sought after. All these efficiency efforts must eventually translate into money (that’s where the current debate over AI is). The first step was always to exhaust existing capabilities while organizations tried to determine where and how to utilize the new capacity. We’re seeing the same with AI usage in software engineering. But what can we, as people who have been exhausted, navigate this change?

Although definitions of roles and titles vary across organizations, the definition of software engineering doesn’t. That’s where I believe Dave Farley’s approach still holds and is sound. Dave says that software engineers have to be experts at learning and managing complexity.

Becoming an expert at learning has become much easier thanks to AI. AI can provide direct feedback on code, writing, system design, and more (although not 100% accurate; but hey, humans can’t provide 100% precise feedback either) before asking others to share feedback. With fast feedback cycles, we can increase efficiency and produce higher-quality work, which, in turn, reduces the effort others must put into sharing feedback. However, we can’t say the same about being experts at managing complexity—the other half of the heart of the craft.

The more AI-produced code tries to make its way to production, the more we need to get better at managing complexity. Any codebase, including its structure, architecture, and patterns, must be consistent and simple so that AI—as well as humans—can easily follow it (with accurate instructions). If the AI-generated code increases the complexity, we need to know how to simplify it.

Moreover, software engineering these days is less about writing code and more about reviewing the code that AI tools produce. Getting better at code review is another skill than writing the code, and it needs training. Maintaining critical judgment over AI results is as crucial as before.

That’s why engineers must understand the fundamentals of software engineering (principles such as SOLID, modularity, and separation of concerns), architectural capabilities (such as maintainability, extensibility, and reliability) and general concepts (such as observability and monitoring). Without understanding the fundamentals of the craft, we can neither leverage AI effectively nor stay up to date with ever-evolving software engineering.

As organizations extract efficiency with AI, the engineers who thrive will be those who double down on fundamentals to manage that complexity. Our roles are stretching, but software engineering’s definition remains constant: expertise in learning and managing complexity. Once we master that, AI can actually amplify rather than exhaust us. As Martin Fowler said, “Good programmers write code that humans can understand.” In the age of AI, good programmers ensure AI writes code that humans (and AI) can understand, maintain, and evolve.

Good to Great

Good: Beliefs of Lee Robinson. Although I believe one or two things differently, it’s a good list.

Better: Thank you for being annoying (also inspired one of my entries below).

Great: Nothing great I found this week.

I wrote about

As an engineer, you have more power than you think.
Admit that you like it
I added 10 new notes to my Zettelkasten.

P.S. The Mexico F1 GP was one of the best of this season. It was super fun!

Reply via email | Reply via Mastodon | Comment

As an engineer, you have more power than you think

Wed, 22 Oct 2025 06:25:42 GMT

I consistently receive requests from the team to reduce tech debt. Every time, I say similar things. I want to share them here.

As a software engineer, you have more power than you think.

When you're coding for a new feature, you have the power to refactor a specific part of the codebase. You don't need any permission.

When you see that changing something in the codebase or in the tools we use will reduce cognitive load or maintenance efforts, you have the power to do so. You don't need permission.

Most of these things don't need to be a separate work ticket with estimations. You can easily embed all of these into your existing work. If you are punished for doing something like that, then you're in the wrong environment.

Reply via email | Reply via Mastodon | Comment

Admit that you like it

Fri, 17 Oct 2025 12:25:42 GMT

People are masters of complaint. Yet their feet keep walking the same path. They don’t surrender, retreat or abolish whatever they are not happy about. They are on a crusade with perennial whining.

I, too, do the same. I complain about my job and my responsibilities. I hate doing certain things again and again. I complain about many things I’ve committed to in life, and now it feels like I have no time to do them all.

But.

But I know and I tell out loud: I love it. I just love it.

I love that I’m failing to do them all. I love that I find it too stressful and difficult to resolve uncertainties or simplify complexities.

If I had a second chance, I would do it again without regret.

And you know what, everything becomes easier when you admit it.

Reply via email | Reply via Mastodon | Comment

Who Will Build Your Products Tomorrow?

Tue, 14 Oct 2025 09:05:00 GMT

One of my biggest concerns, and also a challenge many people are facing, is the reduction in the number of entry-level jobs, primarily due to AI; everyone is now looking for an experienced employee. Especially in a sector such as tech, this should be alarming because of basic math: fewer junior engineers means fewer seniors in the future.

Considering our future needs for skilled and experienced talent, without investing in hiring junior talent and developing them, no organization will be able to find the necessary personnel to build its products. There is a myth that AI will take over all these jobs. I say myth not because I don’t believe in it, but also because of what Sam Altman says: they want to build the AI that’s useful for humans (not the AI that replaces humans).

Why do I believe organizations should continue to hire junior talent and invest in developing their skills? Isn’t it the responsibility of the person themselves?

This is where things get tricky. If you recall the two previous Mediations (about the intellect and biases surrounding AI), learning with AI without any supervision or critical thinking is dangerous. When people use ChatGPT to learn new things without critical judgment, they leave themselves at the mercy of AI.

This is worrying because seniority in a profession doesn’t only mean the person has some information in their head, it means the person knows where to use that information and can decide based on facts and their experience. When we think about this concern, which is amplified by the fact that junior or graduate engineers are typically in their early 20s (the time when the prefrontal cortex, responsible for judgment and decision-making, is still developing), we will find ourselves surrounded by engineers making wrong decisions based on how AI guides them.

There are a lot of resources and companies preaching to non-engineers to code with AI to build products or solve problems (and they recommend their product for sure). While this is practically possible and will get even better over time, people still have to understand the underlying system. The product or a feature they build can be functional on the surface. However, when you dive deep, you find a product without a solid backbone holding it steady and ready for future iterations.

When companies like Anthropic say 90% of code will be written by AI, many interpret this as eliminating human engineers entirely. This misses the critical point: that the remaining 10% and the supervision of the 90% requires experienced judgment. This judgment ensures that the product being developed has a steady foundation, is maintainable and extensible, while not full of security vulnerabilities.

I strongly believe that AI can and will take over the majority of the hands-on coding part, where an engineer codes based on a pre-defined plan. For AI, coding is no different than answering in a language. A person gives an input, and AI translates it into another language. What is still required for humans to do is to (learn how to) create the plan for AI to execute. When we talked about the importance of proper planning in Mediations #25, I didn’t mention AI at all. Yet, with AI, we need to plan enough before acting and writing very specific plans requires experience and knowledge that junior engineers lack.

As junior engineers have no production-level coding or detailed planning skills yet, developing them needs consistent and deliberate practice, which practices like pair programming can provide (I’ve found the most effective approach is having two engineers write a plan for AI together, then elaborate on the output as a pair). Makinh judgment calls during this pairing is where we train junior engineers and teach them the craft. Instead of junior engineers vibe-coding and making costly mistakes, we need to take the time to show them the way.

Employers want to hire more people who possess high-quality reasoning skills and still need people to think critically so they can deliver high-quality products. All of this can’t be sustainable without a new generation taking over the flag. We still have the responsibility to train them and bring them into the workforce.

Don’t forget, all seniors started somewhere, and there were always one or two people who showed the way. It’s time to be one of them for the next person. Hire a new graduate or a junior, or mentor someone to gain experience. You won’t regret it.

Good to Great

Good: “Voyager 2’s Computer Command System has not been turned off since it first booted up about 48 years ago, making it the longest continuously operating electronic computer.” 11 Oddball Technology Records You Probably Didn’t Know

Better: We need to protect peasants. They grow much of the world’s food, protect soil, water and biodiversity.

Great: Always invite Anna.

Until next time,

Candost

P.S. I’ll be giving a few lectures for an AI Software Engineering Bootcamp!

Reply via email | Reply via Mastodon | Comment

Relying on AI too much

Tue, 30 Sep 2025 09:05:00 GMT

The more I use AI, the more I realize that cognitive biases have a significant influence on my decision-making process. I unconsciously rely on Al’s output whenever I task it to do something and use the result as confirmation of my assumptions, thoughts, and ideas. The problem is that I have flaws, and neither my assumptions nor my ideas are always accurate.

The problem is also apparent in the topics on which I consider myself knowledgeable. When I am using AI to think about an issue I’m facing at work (e.g., product or software problems) or debate on a topic, I don’t recognize AI’s mistakes because I lower my guard quickly. I trust it too much.

I was talking with one of my colleagues, who is a good and experienced engineer. They were telling me about a problem Al introduced in the codebase while they were working on a new feature. They lost a day and a half to fix the problem.

They didn’t initially catch the issue because it could only occur in edge cases. While guiding the AI, they had a flaw in their thinking and prompts, which the AI used it to build the problem into the system. Yet, the issue was an obvious one in hindsight.

They used AI to refactor the codebase a few days earlier, and the AI did a remarkable job. The reliable result of AI output biased their judgment on the next task, and they overlooked an obvious problem, leading to major rework. My colleague expected (unintentionally) AI to do a good job, and they trusted the result (amplifying confirmation bias).

My colleague is not a novice Al user. They are using AI every day in a variety of tasks, which I think also causes problems. The more AI tools get to know the person, the more the person trusts the result, the less they recognize the mistakes.

The mutual confirmation loop reinforces confirmation bias, causing the person to overlook errors. If the person is working in a domain with high stakes, such as finance or healthcare, these situations can cause major problems and cost a fortune to recover from.

While my colleague and I are knowledgeable in a field where we use AI, imagine juniors or novices who can’t even detect the issue due to a lack of knowledge. As they lack sufficient experience and rely more on AI to perform tasks (instead of learning themselves), building a reliable and safe system becomes more challenging.

I know that these bugs can still occur even without Al. Yes. They will continue to happen, whether AI-generated or not. That’s why I consider AI tools as assistive to humans, not a decisive authority in itself. They supplement, not replace, humans.

We still need to educate ourselves, learn the fundamentals of the craft, as well as recognize our cognitive biases. We need to nudge ourselves to challenge both our own results and those of AI. We still need mechanisms such as peer reviews, cross-validation (e.g., four eyes principle), and adversarial and critical testing.

So, next time when you use AI, be aware that just because it produced a correct result before, it doesn’t mean it’ll do it the next time.

Good to Great

Good: The dawn of the post-literate society and the end of civilisation. Screens and falling literacy are eroding deep reading and critical thinking, threatening innovation, democratic debate and the future of our civilization. I still can’t believe how little we read…

Better: Written in 1899. A Message to Garcia is a wonderful piece. I added “carry a message to Garcia” to my dictionary.

Great: “Man cannot stand a meaningless life.” 38 mins with Carl Jung, the founder of analytical psychology, two years before his death. (On a side note, the interview style is very different than today’s interviews.)

Recently, I thought/wrote about

I didn’t publish anything. I’m working on a few pieces, but couldn’t polish them enough to share here. Next time!

P.S. I don’t know how many times I mentioned this blog post in real life.

Reply via email | Reply via Mastodon | Comment

Plan Slow, Act Fast

Tue, 16 Sep 2025 05:11:00 GMT

Although this text seems related to software development projects, most lessons are also applicable to projects like planning a wedding, renovating a kitchen, and writing a book. I marked lessons with bold.

I’ve been managing several large, months‑to-years‑long, cross‑team projects. As these projects tend to go over schedule and budget, I learned to take a different approach: plan slow, act fast. The bigger the project, the more planning I do.

When we choose the Silicon Valley way and "move fast and break things," we often discover flaws in our approach in the late stages and must rebuild the solution or create workarounds to address them. Moreover, teams’ estimates are substandard or often plain wrong, which exacerbates the situation by creating a false perception that we will finish early. Sometimes, all of these problems are together.

Moving fast and breaking things is probably one of the worst things that a large project team can do. Rushing to start the implementation of a project guarantees that the project will go over schedule and budget. When problems are complex, they require a careful and precise approach. Yet, we rarely take that approach to untangle the whole complexity.

In software projects, product managers and designers often take time to understand the problem and prototype a few solutions to test their ideas. It's a great approach to invalidate various proposals and choose a good direction. Yet, this is rarely mirrored on the engineering side. Engineers are sometimes involved early on in the product and design decisions, but they rarely touch code until implementation begins. Once the project kicks off, they act quickly, but end up moving slowly and often exceeding the schedule and budget. So, what can we do better?

Once the team understands the complexity, they should identify the smallest repeatable module. Imagine building a skyscraper. Consider building the whole thing at once; the project looks highly complex. But if the plan was to build one story of it, it appears simpler. So, the plan for the skyscraper, as building the same story over and over, makes it simpler. Although finding that module is difficult, once the team finds and builds the first one, the next iterations become easier and more predictable.

Modularity also supports contingency planning. The reality is that something always goes wrong in a large project. I've never worked on a project where everything worked as expected. That's why there must be a contingency plan and backup approaches. Modularity helps with this because human brains are better at thinking in smaller pieces rather than comprehending the whole complexity. When we plan slowly, we consider risks carefully and choose the ones to guard against.

When it comes to teams' estimations, we need to change our approach. Instead of asking people to estimate the time, we need to examine any similar work that's been done before. Humans are almost always wrong by a significant margin when it comes to predictions. Using previous data as a baseline and helping to anchor and adjust estimates is a more accurate way to build a timeline.

The whole idea might sound like going against the bias toward action I advocate for. I still believe that learning comes from action. However, the learning should move to the beginning of the process: planning. Learning from mistakes is cheaper in the early stages of a project compared to later stages. Examining and moving the solution of the most complex parts to earlier phases, prototyping in code, and building contingency plans keep the project on a realistic timeline and increase the chances of finish on time.

Good to Great

Good: This one is for software engineers—Joy & Curiosity Newsletter. I've been following for a while. It gets better every time. Better: I've been reading Lorin's blog about resilience engineering for a long time. Great: Nothing this time. Great things are rare.

Recently, I thought/wrote about

I didn't share any writing yet but I'm thinking about one thing that I'll post an article soon:

We can’t disconnect from our friends anymore. We carry emotional and relationship baggage with us wherever we go, often due to the influence of social media. We used to let go of friends when we moved on to somewhere else and found new ones on the way. We didn’t know what old friends were doing. Now, everyone we meet comes with baggage. We are in their life constantly and can’t disconnect at all because unfollowing on social media is considered rude (even though we might not see the person again).

P.S. I wrote about how engineering managers lead big projects before.

Reply via email | Reply via Mastodon | Comment

Growth of startups is often constrained by the economy

Sat, 13 Sep 2025 16:00:00 GMT

Similar to villages being poorer, startups also often fail due to a lack of talent, capital, etc. The only way to prevent failure is to increase demand. It will, in turn, increase the capital and enable the founder to hire and divide the labor.

Reply via email | Reply via Mastodon | Comment

How to create a tech strategy?

Sat, 13 Sep 2025 16:00:00 GMT

Put a step-by-step plan, start small, and try to deliver value quickly.
Have your budget in the strategy.
Consider sickness & vacation in your plans.
Consider the impact of side work on your plans.
PoC and step-by-step guides are good.
Know your audience.
When you go to a board meeting, go with multiple options (and with your recommendation).
Don’t put a wall of text in the presentation.
Say three things to leave on people’s minds and tie all of the rest to those three points, and address them.
Don’t just mention risks, but also show your plans for addressing them. (e.g., tech debt)

Reply via email | Reply via Mastodon | Comment

Why are villages poorer than cities?

Sat, 13 Sep 2025 16:00:00 GMT

Due to the lack of division of labor, everyone ends up doing many things by themselves. Due to time constraints, people often struggle to accumulate sufficient capital for growth, as the cash flow is very low. Due to low demand, people can’t generate enough income from a single income stream, regardless of their choice. Due to the lack of access to the talent. There are not enough people around to take an active role in the business.

Related Note(s):
- Many startups can’t afford to hire a person to delegate some tasks. Many founders suffer from burnout due to trying to do too many things simultaneously. The same rules apply there, too.

Reply via email | Reply via Mastodon | Comment

What you're NOT doing

Wed, 10 Sep 2025 16:00:00 GMT

“What am I not doing?” is a good question to ask when you’re trying to do things and struggle to get results simultaneously. It’s also a good question to ask when you want to discover other options. Despite creating discomfort, inverting the approach provides insights and reveals what you haven't been looking at.

It’s a question to ask yourself at all times, even when things go well, and also when you get ambiguous feedback about what you’re trying to achieve.

Related Note(s):
- Professional growth at work demands finding what you’re not doing enough of for promotion, especially if you don’t have a manager who’s helping you. This approach becomes necessary for managers.

Reply via email | Reply via Mastodon | Comment

Humans can't understand increasing scope well

Mon, 08 Sep 2025 16:00:00 GMT

Exponential increases in scope create only a linear understanding in humans. When planning an event, a year ahead may seem far off. However, planning an event 5 years or 10 years ahead doesn’t feel 5x or 10x one year from now. We can’t comprehend the scope. Between 5 years and 10 years, there are five more years. However, both 5 years and 10 years seem very close to the human brain. We can neither visualize nor feel the real difference. This is called Scope Insensitivity.

Related Note(s):
- We struggle to split things into chunks and eliminate. Comprehending the full picture and seeing all effects is a big challenge.

Reply via email | Reply via Mastodon | Comment

Approaching growth when faced with competition

Sun, 07 Sep 2025 16:00:00 GMT

Competition makes progress dynamic and demands rapid change. However, success ultimately slows down. You need time, a consistent and gradual increase in success while keeping a fast pace and dynamic processes. The result and gratification will come in small pieces and slowly. Focus on what matters and discard the noise. Keeping your head straight and relentlessly trying is what you need to do if you know you’re on the right track.

Related Note(s):
- Competition always brings good results. Without any contest, we can’t talk about any progress in humanity.
- You need to establish your fundamentals so you can handle both competition and growth challenges.
- You’ll need to get comfortable with uncertainty. Trying to grow while facing competition will bring you many surprises.
Source(s): From Kinsale Capital’s Q1/2025 earnings call. The CEO said: In a competitive market, it’s going to be a little bit slower than in a less competitive market (referring to growth).

Reply via email | Reply via Mastodon | Comment

The Quest for Happiness

Sat, 06 Sep 2025 16:00:00 GMT

There are fundamental elements of happiness. At the door of happiness, the porter bounces you off without wealth, health, and friendship. Without a certain level of wealth (the basics of living, such as a secure place, basic clothes, food, clean water, etc.), happiness can’t be built. The level of wealth required to make one person happy changes, but beyond a certain threshold, the returns diminish. Despite health being one of the fundamentals and the absence of it definitely causing unhappiness, its existence still can’t guarantee happiness. There are many healthy and wealthy, but unhappy people in the world.

The last layer of happiness is closely tied to compassion and social relationships. It doesn’t mean that one has to have friends around them; it’s about not feeling alone. Some people happily live in solitude, but they never feel alone.

That suggests there are layers to happiness. Happiness is an inner interpretation of wealth, health, and social relationships. Only understanding that level and finding it can bring happiness.

Related Note(s):
- For quite some time, I believed having goals and achieving them was key to happiness. I was wrong.
- The media bloats the happiness of others and creates a delusion that everyone is happy but us.
Source(s): Beyond Religion by Dalai Lama

Reply via email | Reply via Mastodon | Comment

Compassion is the foundation of well-being

Sat, 06 Sep 2025 16:00:00 GMT

“Without another’s loving care, none of us would have lived more than a few days.” Although compassion begins within oneself, it is about caring for others’ problems (not yours) and actively helping to resolve them without expecting anything in return and without any self-interest. The benefits of compassion are gaining happiness and relief through others. Instead of prioritizing our own goals and happiness, it’s about putting others’ happiness first, knowing that greater happiness will increase the happiness of society, including our own. Compassion is what can bring all humans together around a single entity, “we,” and destroy the fundamental rivalry and hatred of us vs. them.

Related Note(s):
- Building compassion might not come easy. Find the story behind someone’s behavior. Ask questions.
Source(s): Beyond Religion by Dalai Lama

Reply via email | Reply via Mastodon | Comment

Justice and compassion - to forgive is not the same as to forget

Sat, 06 Sep 2025 16:00:00 GMT

“Physical or violent measures can only restrain others’ physical behavior, never their minds.”

“To forgive is not the same as to forget. After all, if one forgets a wrong that has been done, there is nothing left to forgive!”

I still struggle to understand how justice can be applied with compassion and aimed at preventing the wrongdoer from committing the deed again. Yes, we can and should remove the death sentence and apply justice and set up punishments proportionally to the crime. Yet, it’s still a failure.

I understand the arguments against a compassionate approach to justice. But the Dalai Lama is right. The justice should be compassionate, recognizing that people can change. Probably that’s the half summary of the chapter. The other half is “to forgive is not the same as to forget.”

We need to separate action from the actor. How can we punish the action and forgive the actor? According to Adler, the human mind and body are one and the same. The only forgiving can happen person-to-person. When someone hurts another, the person can forgive, but the justice system will punish the action. That’s why I don’t see a way out besides educating people not to do the harmful action in the first place.

Additionally, the punishment alone is not enough. Although we can put the most balanced justice system, the majority of perpetrators repeat their actions because our punishment system doesn’t prepare people to go back to life without a big struggle. I believe we should incorporate more compassion into how we apply punishment and enable perpetrators to have a better life after serving their sentence. Once the punishment is served, they shouldn’t seek to return to jail because they don’t feel they belong in the community outside of prison.

Related Note(s):
- Forgiveness is within our control; focus on what you can change. Justice is no longer in our hands.
- You need to face all your emotions head-on to be able to forgive.
- Not everyone had the same life as you. People make mistakes. If you surround yourself with diverse people, you’ll already develop a habit of interacting with a variety of individuals and can build empathy more easily.
Source(s): Beyond Religion by Dalai Lama

Reply via email | Reply via Mastodon | Comment

Reading a lot vs. Reading Well

Tue, 02 Sep 2025 09:05:00 GMT

I took a short break from writing due to some family matters, which have left me feeling incomplete. These days, I’m trying to come back and build those broken habits once again.

Although I didn't write much, I somehow had a lot of spare time for reading; 10 minutes here, 15 minutes there. It’s too short for writing but perfect for reading a few articles and books. Thanks to it, I caught up with the majority of the online articles I wanted to read, which were waiting on my endless reading list.

During reading, I realized one thing I had tried to avoid: focusing on reading a lot of things.

On my “About” page on my blog, there is a sentence I wrote: “I don’t care how many books I read.” This statement dilutes the importance of reading a lot and portrays reading well as a remedy.

Reading a lot and reading well are both crucial elements of life. Reading a lot is a discovery; reading well is a settlement. Without discovering, one never knows where to settle. Once settled, wanderlust kicks in after a while, and one seeks to discover. It’s a constant tension.

I’ve never stopped reading a lot of things. However, I slowed down discovery. These days, my wanderlust for reading new things is urging me to accumulate yet-another-reading-pile. This time, I’m not fighting back; I’m recovering my equilibrium.

Meanwhile, during this break, here are the three things I’ve read, from good to great.

Good to Great

Good: Books are my main learning material. Andy challenges the approach of existing non-fiction books to learning. Something to think about… (I love Andy’s writing by the way)
Better: I re-read this. It’s on friendship, parents, and you. Read it and think about it.
Great: Somehow, I overlooked this community. It’s the community and the content I’ve been scouring for years. I’m reading non-stop for days.

Recently, I thought/wrote about

I really, really, really can’t worry about the whole world. It’s not about becoming numb; it’s rather about staying sane. I wrote about it.
The majority root cause of incidents in general is “people choosing the easy way,” as Lorin says. I wrote a short one about it.
I mentioned this concept to my boss a few weeks back, and since then, we’ve been referring to it in our conversations. So, I wrote a short one about it.

P.S. As I’m in discovery mode these days, add a comment and send me what you've found interesting lately.

Reply via email | Reply via Mastodon | Comment

The Invisible Gun

Fri, 29 Aug 2025 05:11:00 GMT

I started referring to one management concept. I refer to it often, also to remind myself when I am talking with people I’m working with. The concept is called an invisible gun. I don’t know where I read it on the Internet. The closest I could get to the source is Adam Weisbart and Adam explains it well.

Still pointing the gun at him, I explained: “See, the trouble is, every manager has an invisible gun, whether he knows it or not. Some bosses carry big shotguns, while other, more self-aware managers carry small pistols. Regardless of the size, they all have them. Because of this gun, ‘suggestions’ often become ‘directives’ in the minds of employees. It’s not a boss’s fault necessarily, nor is it the fault of the employee; after all, we’ve been trained to listen to our bosses, and we have a financial incentive to do what the boss wants. We’d hate to get shot. No one wants to get a bad review, or worse, lose his job.”

If you have ever watched The Office TV show, the whole show, 9 seasons and 201 episodes, is a testament to this analogy. There you see how people take great distances to avoid getting shot, even though their boss is a weirdo.

I also had been in many situations, both as a manager and a direct report, where this analogy was 100% true. When I was on the barrel side of the gun (when talking with my manager), I chose my words wisely, as if saying anything wrong could cause problems. When I was on the other side (when talking with my direct reports), it wasn’t clear why the person was hesitant to explain their thoughts openly and freely. I wondered why I was not able to decipher the person I’m talking to and why they encrypt the conversation. I thought it was that person’s problem. But it wasn’t.

The power dynamics of the relationship are imbalanced. The manager has the decision power over the direct report’s income and their future in the company. They can make a person’s life miserable or remarkable. The direct report doesn’t have this power.

Anyone knowing this power imbalance will feel uncomfortable when they talk to their manager. Regardless of their relationship, authority will always be there to tip the balance to one side.

As a manager, I would love to carry no gun, but it’s impossible as the whole idea of ‘working with a boss’ is embedded into our society and, as Adam says, ‘we have a financial incentive to do what the boss wants.’ However, I keep reminding myself of this concept, so I at least work on making the gun I’m carrying smaller and smaller, so people may sometimes forget it’s there.

Reply via email | Reply via Mastodon | Comment

The Root Cause of All Incidents

Wed, 20 Aug 2025 05:11:00 GMT

I used to be puzzled by complex problems that cause incidents. I used to think that service disruptions or unavailability were due to complicated implementations, complex approaches that require brain power, or network issues where reliability is always questionable. After coordinating dozens of incidents, I began to be puzzled over how so many small mistakes were leading to incidents rather than complex ones.

Overlooked or straightforward implementations were the majority of the root causes. All of them looked like small mistakes in hindsight. Maybe it’s the nature of these situations: people often underestimate the complexity of solution design and approach, assuming everything is easy. Yet, the simplest solutions are the most complex ones as they require a thorough understanding of all fundamentals.

In his blog post, Lorin talks about why choosing the easy solution often trumps the simple ones. People opt for easy solutions due to production pressure to deliver a piece of work within a deadline. Easy solutions are naturally the ones that are fastest to implement. Nobody has given the time to design the simplest solution.

When we give enough time and chance to design the simplest, remarkable things happen. We’ve seen this various times in the partnership of Jony Ive and Steve Jobs. They also had production pressure, but Steve Jobs gave Jony the time and space to find the simplest solution from all angles, which led to inventing various things along the way. They never use the easy solution. But not every company is Apple. I don’t think the current Apple is the same as the one with Steve Jobs. These days, Apple has started to choose easy ones.

Lorin, I think rightfully, also accepts the failure of simple in the battle with easy. People will always choose the easy option if leadership doesn’t push for a simple solution and give the team time to think, experiment, and plan; even that sometimes means dropping everything and starting from scratch.

That’s why we’ll always have incidents or crappy product experiences, and the majority will be caused by people choosing, or being forced to choose, the easy way.

Reply via email | Reply via Mastodon | Comment

Find the story behind the behavior

Sun, 17 Aug 2025 16:00:00 GMT

You never know someone else’s story. When you find anyone difficult, there is always an underlying story or reason. Some people don’t understand why they behave the way they do and are unaware of their desires. Try to learn and understand their story behind the scenes.

For yourself: if you don’t know why you act in a certain way and what your underlying beliefs and reasons are, you won’t be able to change your behavior. Discover your values and what you care about. Make them explicit to yourself.

Reply via email | Reply via Mastodon | Comment

Driving Empathy with our commonality as humans

Sun, 17 Aug 2025 16:00:00 GMT

Our common humanity properties are related to mind, feeling, and thinking. It appears that we distinguish ourselves from other beings through the way we use our minds to direct our feelings and thoughts, in various ways—whether to understand our surroundings or interpret our internal struggles. Ultimately, we seek happiness and strive to avoid pain. All humans have this same drive. That drive looks different for people, but ultimately, it’s the same. Whether it is imagination or real things that our minds create, we all seek happiness. That’s how we can feel empathy for anyone. We need to share a common purpose to feel a sense of belonging and be part of a community. To the Dalai Lama, that common purpose appears to be seeking happiness and avoiding pain.

Not the empathy part, but the rest looks/sounds very close to stoicism; I think they have a lot in common.

Related Note(s):
- To feel the whole world as part of our group, thinking that we all seek happiness and try to avoid pain, helps.
- Most of the stories behind why people behave in a certain way end up in either seeking happiness or avoiding pain.
- Selfish goals are unattainable. The only way to get rid of them is to approach others with empathy.
Source(s): The Wealth of Nations by Adam Smith

Reply via email | Reply via Mastodon | Comment

Division of Labor

Sun, 17 Aug 2025 16:00:00 GMT

One of the most significant advancements in society's business came from the division of labor. There are three roles in a business: landlord, manufacturer, and laborer. Landlord and manufacturer are often one person (and usually the same). There is no division there. However, in manufacturing, labor is divided into multiple roles. When divided, the productivity of the labor is the multitude of the sum of the productivity of each person working alone. When everyone takes a distinct role and the product results from the combination of everyone’s combined effort, the output is more than the sum of what each person can produce. Let’s say 10 people are working in a manufacturing setting, and each can produce two units per day individually. With division of labor, they can make 1000 units per day (instead of 2 × 10 = 20). This is the gain of the division of labor. It’s also the reason that cities are much richer than the villages. Because there are not many people to divide the labor or produce something on a farm throughout the year. The farm work is seasonal; you can’t employ ten people all the time. Typically, one person handles most tasks on a farm, and the produce is limited to the efforts of one or a few people.

Related Note(s):
- Although we’re discussing the division of labor on a grand scale, I think the separation is also applicable to teams within an organization. Landlord: Executives, Manufacturer: Team Leads, Laborer: Individual contributors. More on 84;
- Once you know where you stand, it’s easier to find ways to penetrate another.
Source(s): The Wealth of Nations by Adam Smith

Reply via email | Reply via Mastodon | Comment

Fundamentals of increasing the quantity of work

Sun, 17 Aug 2025 16:00:00 GMT

An increase in the amount of outcome/output comes from:

Increase in dexterity: Once a person learns how to do a job, they increase the quantity of output. Doing the same thing over and over again, understanding its characteristics and adjusting to it takes time, but helps produce a lot more than others.
Reducing context switching: When the context changes, the person’s mind doesn’t go to it directly. It takes time to adapt to the new work, become focused, and establish a new rhythm. This is irrelevant to dexterity. Sole changing context is already reducing the quantity.
Enable one person to accomplish many tasks using machines and automation: Machines undoubtedly increase the quantity. However, automation innovation and machines often stem from people who are doing the job and their laziness. When a person knows what they are doing, they will try to invent new ways to do less work. This laziness leads to innovation. #leadership (increase productivity, improve the outcomes/output) #investment (look at the CEO if they know what they are doing)

Related Note(s):
- Invest in growing your employees so their dexterity increases.
- Measure the productivity to make constant improvements.
Source(s): The Wealth of Nations by Adam Smith

Reply via email | Reply via Mastodon | Comment

Belonging together to something increases likeness

Sun, 17 Aug 2025 15:35:01 GMT

Regardless of its form, belonging to a place unites people, similar to belonging to a family. Not only kinship, but also people who look alike actually like each other more. Also, when people come from similar places or families, they like each other more. Commonalities increase belonging. This closeness in proximity peaks when we invite people to our homes. As homes are the most intimate places, people visiting homes as guests are liked more, and they feel they belong to a closer group after being invited, the family. When we want to increase unity or likeness, we can gradually invite people and involve them in dinner preparations. Acting like they are part of the family allows us to create stronger bonds, improving the relationship overall.

Related Note(s):
- For Genghis Khan, kinship alone wasn’t enough to belong; he united behind companionship.
- Expats often form communities within themselves, and others discriminate against them as both sides unite behind common locations.
- When people identify too strongly with their geographical location, polarization increases.
- To unite people behind a common goal, find what they actually have in common.

Reply via email | Reply via Mastodon | Comment

I Can't Worry About The Whole World

Sun, 17 Aug 2025 05:11:00 GMT

When I wrote about how much I abstract myself from daily news (1, 2, 3), many people asked me how I can stop worrying about a gazillion things happening in the world. I pondered whether I had become numb. I found out, over time, that I developed a high level of attention to certain things and serenity to worry less about many, many others.

My attention became laser-focused on what’s in my immediate surroundings or what’s influencing them. Instead of worrying about what’s going on thousands of kilometers away, I narrowed down my worry to one to two thousand kilometers. I still care about what’s going on in far lands. Yet, I choose ignorance; I prefer not to hear them. When I say this aloud, it sounds wrong, doesn’t it?

It’s wrong only if knowing problems far away brings any benefit to the people there or me. If knowing what’s going on helps me act on issues with my actions’ success rate higher than, let’s say, 5%, then what I’m doing is wrong. Let me say again: 5%. It’s a low bar.

The best I can offer is either financial assistance or attending a protest. The last protest I attended was “Occupy Gezi” in 2013. Although I find protesting people admirable and support them, I can’t see a huge influence when the protests focus on issues in faraway lands. I don’t know what protesting Putin or Trump in Berlin would achieve. We can argue that our protests put pressure on our government to act, but I rarely see any successful results.

On the money side, I already have a recurring donation to certain places and still do extra whenever I can. Even with this, knowing minor problems in faraway lands every day doesn’t change much. Instead, when I can combine monetary help with other support for issues nearby, then they become more effective.

In addition, I choose ignorance because the more I know, the less I act. It feels overwhelming due to the paradox of choice—increasing anxiety when there are many things to choose from. I can’t worry about all the things happening around the world because I have one life to live (sounds selfish, doesn’t it?). I can’t protest against all political decisions, wars, and more because I have a family to feed. I have certain things I care about, and I can focus on helping with them as much as I can. The rest, I can’t do much; so, instead of cognizant inertia, I choose illiteracy on the concerning topic.

Also, knowing all causes desensitization—reducing the psychological arousal to concerning events and lowering the likelihood of helping victims. The more I know, the more I normalize what should be abnormal. My threshold to act on issues increases, and I stop acting on anything because I see them all day, every day. I want bad things to be still unusual.

What puzzles me is how people choose the other way: high knowledge and no action. It’s our reality. The interconnectedness of the world has led to it, and it’s worsening continuously.

The world wasn’t interconnected this much for thousands of years. We had no idea what was happening even in our close family’s lives until we saw them face-to-face and they told us what had happened. Now, the majority of humans are connected and learn when something is wrong, regardless of where. While we survived for thousands of years without knowing what was happening hundreds of kilometers away, today’s reality is different; a reality I can’t deny.

I can’t deny it, but the problem is that we still don’t know how to live with this much interconnectedness and information overload. Therefore, we need to explore various approaches to learn how to play with the cards we have.

Hence, I’m taking a stand that many may find unorthodox. Instead of creating an illusion for myself, I intentionally don’t learn about certain things so I can focus on helping with what I care about every day. That means I carefully curate my news feed, ignore a lot of news, and don’t follow micro news. Instead, I want to understand the immediate things that directly affect my life or the lives of my loved ones, and the long-term trends and movements that change the direction of a large population (hence the world).

We might argue that whatever happens on the other side of the world affects me whether I like it or not. True. When the US President announces a trade bill, it, of course, affects me. However, there is nothing I can do about it when the day this news hits the headlines. I neither live in the US nor am I a US citizen who can vote, nor do I engage in any trade myself. I have practically zero influence. Knowing all the details of the trade bill won't change anything in my daily life compared to learning it vaguely. Therefore, I spend time understanding how it will change the world order and whether I should adjust how I position myself in the new movement.

I hold a specific position in life. The reason I’m writing here about the struggle of living, mediating between many issues, learning various things, is my ethical stand: I care about humanity. Without actively luring anyone into any political side, I’m trying to bring a perspective that hopefully can slightly impact someone’s life (I think I barely succeed in that). I’m focused on people surrounding me; trying to bring joy and peace to their lives (which in itself is a really demanding task that I still don’t succeed at) and make their lives a little better every day so they return the favor to someone else, and eventually, we can reach masses of compassion.

I try to stand with anyone around me who brings peace and shows compassion. I can’t fly to Taiwan to support the oppressed, or I can’t go to Gaza to bring food with my hands to many orphans. Yet, I also know the power of the words that I write here. I know these words influence people (so far, very few). The words that might change people whose names I don’t even know.

I know that certain groups will try to oppress and dominate others in all parts of the world. These groups need to be prevented somehow. The only people who stand against them are often the people who are closest to the problem. We can argue that we can create international pressure, but I don’t believe it works in this age (I am probably wrong. Prove me wrong, please). Look at Russia and Israel, the conflict-ridden countries of today. The pressure I can create here on Putin or Netanyahu by active protesting doesn’t even make a dent. I’m not a pessimist. Quite contrary, what I’m trying is the most optimistic approach I could find.

Here is my optimism: Imagine that you somehow make the place around you a little better. Then your next street neighbor does the same after seeing you. Then their neighbor replicates the behavior. We start a chain of compassion. This compassion chain can spread everywhere in enough time. It is very slow progress and can take centuries. But any other approach is the same; the mass changes always need, at least, decades.

While abstracting myself from the distant problems I can do nothing about, I create a headspace for the problems around me. Instead of spending hours learning about anything going on at the other corner of the world today, I can learn much more about what’s going on in the city/country I’m living in and can act on it. That said, I’m not recommending my approach to anyone. I know that this type of living is not for everyone.

Reply via email | Reply via Mastodon | Comment

How to Train Yourself Under Work Deadlines

Tue, 24 Jun 2025 09:05:00 GMT

You finish one piece of work and look what’s next and see there are thousands of things waiting for you. It’s a never-ending story. Features pile up, deadlines look at you, and the pressure to go faster never lets up. Simultaneously, the need to train yourself and upskill (especially as AI transforms how we work) has never been more urgent. Your manager asks you to spend time training, but never clarifies if that’s more important than the feature you have to deliver. So, you default back to delivering the feature because if you don’t do that, you might find yourself in trouble.

Meanwhile, if you ask any manager, they will tell you up-skilling is key to survival, especially for knowledge workers, as AI reshapes careers. Even with this awareness, they still don’t give any time block for training. When you’re sprinting from one release to the next between tight deadlines, who has hours to spare for training modules? If your manager is laser-focused on output, training feels like a “nice-to-have,” not a “must-do.” It’s easy to put off learning until “things calm down,” which is never.

The key is making learning work within your existing workflow rather than against it. Integration is everything. Apply what you’re learning directly to your current projects.

Let’s say you’re a software engineer juggling code reviews, feature development, and meetings while trying to stay up-to-date with testing best practices and push yourself to do more with AI. Instead of blocking out a whole afternoon for training (which never happens), use an AI-assistant to explain to you testing best practices and experiment with the assistant’s suggestions for additional test scenarios for your new feature, learning about boundary testing and mocking strategies in the process. While coding with AI, ask AI to explain to you the concepts, and mix practice with theory. This way, you gain both theoretical and practical knowledge while still advancing your work. And you shouldn’t stop there.

Form an unofficial “learning pod” with your teammates where everyone shares insights, holds each other accountable, and swaps tips on what you learned. Don’t wait for your manager to organize this. Learning pods turn individual learning into a team advantage. These meetings don’t have to be big. A thirty-minute one-on-one sessions also work. You can share these testing patterns you’ve discovered with another engineer on your team and brainstorm what else you can do, turning the session into a mutual learning opportunity.

Once you’re ready, show your approach to your manager and ask for support. Research shows that middle managers make or break training engagement. Teams with proactive managers—those who champion learning and can actually connect it to career growth—see much higher participation.

Whether your manager is one of these types or not, you can take the first step without consulting your manager and surprise them with the result. They will see you still delivering while learning and contributing to others’ growth, too. This approach will help you get buy-in for dedicated learning time (when needed) and connect the training to team objectives. Frame it as an investment in better delivery, not a distraction from it.

There’s no perfect formula for balancing delivery and learning. The reality is messy, and the pressure to ship isn’t going away. But integrating learning directly into existing work will help you adapt to industry changes, while the cost of standing still is rising with AI. The organizations and individuals who thrive will be those who make learning a habit, not a luxury.

Good to Great

Good: I will look, understand, act on the survey results from Lenny: How tech workers really feel about work right now + many things resonate a lot.
Better: Is Netflix dumbing down the TV Series so you can watch it easier when you scroll through your Instagram/TikTok? I rarely watch Netflix, but for other reasons.
Great: I found nothing great this time. Great things should be rare. Finding one is a blessing and requires a bit of luck.

Until next time,

Candost

P.S. I'll be speaking at two conferences in July. Click here to join me (with 10% Discount) at WeAreDevelopers World Congress. Click here to claim your 100% discount to join me at API Days Munich.

Reply via email | Reply via Mastodon | Comment

Deglobalizaiton

Tue, 10 Jun 2025 09:05:00 GMT

You probably heard the word globalization countless times. But these days, after decades of pursuing globalization, we're chasing deglobalization.

Rather than simply being the opposite of globalization, deglobalization is a deliberate movement toward less connected societies characterized by powerful nation-states prioritizing local solutions and border controls over global institutions and free movement.

Following the Industrial Revolution and World Wars, there was a shift toward increased interconnectedness between countries and culture, when institutions like the European Union were founded.

Now, the time is changing again toward a more closed society—countries are leaning toward becoming self-sufficient as the fear of "losing authenticity" and "losing the race" becomes stronger.

However, the caveat is that it's not easy, especially due to the Internet and technological advancements. Anyone can still learn what's going on on the other side of the globe in a second, even when the borders are closed.

Right-wing deglobalization populists are afraid of losing control due to the Internet. However, they still have a means of control: migration policies.

While countries attempt to close their borders under the umbrella of boosting internal talent, they have begun to stagnate in technological advancements. The best talent doesn't follow borders or boundaries. If anyone is skilled at the job and it's a high-demand one, all countries will still want to acquire them, regardless of whether they make it difficult or not.

By now, you probably know that this newsletter doesn't always provide specific steps to take; its primary purpose is to take a step back and offer you a timeless idea. Yet, I still ask the question of "What can I do in this era of deglobalization?

Understanding the whole system is almost impossible. Any prediction can be proven wrong in an instant. All we can do is to know what we aim for in life, follow a purpose, and ensure that what we chase is in high demand. If that makes us feel we don't belong where we are or that requires a change, we still have the opportunity to migrate to somewhere else.

Meanwhile, we must follow how policies evolve and their impact on our daily lives, work, and relationships is crucial. Therefore, we have to continue to read, analyze, and reposition ourselves again and again and again.

Let me know your observations on deglobalization. Just hit reply on this email.

Good to Great

While we're talking about demographic shift and migrations, what is our ethical obligation to refugees? Read a good essay: Moral Refuge
A better breathing exercise for instant relaxation. Read the video description before you begin. (A related article from someone else)
"Alignment is the difference between progress and stagnation." Great post: Alignment > Autonomy.

Recently, I Wrote About

I have a weekly Sunday ritual where I close out the week on my small agenda and write my weekly promises to myself for the upcoming week + some other habit tracking stuff. This ritual has been working so far for ~6 months. I wrote a post about it.

Until next time,

Candost

Reply via email | Reply via Mastodon | Comment

A Weekly Planning Ritual That Works

Fri, 30 May 2025 11:33:00 GMT

For a long time, I’ve been searching for a planning methodology that fits my life. I delved into bullet point journals, to-do lists, daily notes, and the Obsidian rabbit hole. None of them worked. I followed some for months, but never felt like they fit into how my brain and life work. Until I created my own system, combining the best of all things I tried. Now, every Sunday around 21:30, I go to my desk, take my physical agenda, recap the last week and plan the next one. I can’t say this system will work for everyone, but I’m sure it will give ideas to a few.

The system I created takes all the pieces from different planning systems. It contains to-dos, calendar, mindfulness, checklists, reflection, promises, and tracking. It’s a combination of ideas that fit one week into two pages of a pocket-sized notebook.

It’s essential for me that this is not a digital system. The pen and paper, and limitations of the size of the agenda give constraints. When limitations are removed, creativity and focus go with them. Most digital tools offer flexibility by eliminating these constraints, providing a sense of pseudo-creativity when it comes to planning. Additionally, the pocket-sized agenda allows me to carry it everywhere, preventing me from reaching for my phone for every single thing.

Agenda Layout

I use a Leuchtturm A6 weekly planner with an extra pen loop to ensure I always have a pen with it. Although the Leuchtturm weekly planner’s page layout looks a little different, I customize each week in the following setup.

Seeing the whole week at once and the quality of the paper and agenda are the reasons I chose Leuchtturm. At a glance, my layout gives everything I need to plan for the whole week:

Days section to write down important events, exercise plan, and crucial TODOs
Weekly Focus for mindfulness
Reading/Listening to/Learning section to track progress
Pre-week Checklist to ensure I don’t miss anything during the ritual
Weekly Promises to push myself out of my comfort zone
Reflections to retrospectively look at the last week

Once I place the layout, I focus on checking all items on the Pre-week Checklist one by one. The items inside are not for the week, but for the planning ritual itself. Although the checklist fulfills its job within the next 15-30 minutes, it ensures I don’t miss anything during the ritual. Once all items are checked, the ritual comes to an end.

After the layout is set, I begin by recapping the last week.

Recapping the Previous Week

Without looking back, I would be fooling myself to plan the next week well. Retrospection brings learning: learning from mistakes, learning from unexpected events, and learning about what has happened both within and outside my control, as well as what I did well. That includes assessing how much I was able to stick to my habits and my budget.

Habit Tracking

One of the things I learned from Jerry Seinfeld’s chain method and James Clear’s Atomic Habits was to track the things I want to do and get better.

Therefore, I try to track habits as much as possible. However, sometimes, I forget to mark some habits as completed in my habit tracker. During this ritual, I complete the previous week’s missing tracking. Because if I don’t, I’ll never remember them in the future. So, this step ensures that I track my habits at least once a week—for my memory, it is a good time span to remember.

Financial Tracking

I did budgeting for a while and tried to plan all my spending with apps like YNAB, but it didn’t fit my lifestyle. I was stressed while trying to maintain a budget. As I don’t spend money unnecessarily, don’t have any debt, and am privileged enough not to need a tight budget, I've abandoned budgeting.

Instead, during this ritual, I look at what I spent money on in the last week and learn from it. If I had an impulse buy, I would acknowledge it and try to prevent myself from making it in the future. If I had an unexpected big payment, I would try to learn and increase my savings goal to put extra money aside for the next unexpected event.

I also check on my investments and review their performance. I don’t follow the financial market daily as it is volatile. I instead look for substantial changes in my investments and observe if I need to set time aside during the week to reassess any situation.

Reflections

Once I complete the tracking, I use the empty section on the bottom right to write my reflections on the last week.

Reflections mostly focus on understanding if the plan for the week was challenging, whether my promises were impossible to achieve, and whether the events were overwhelming. Evaluating the previous week allows me to set the upcoming week more realistically, which is what I do next.

Plan the New Week

After a retrospective look at the last week, I can usually position myself better. I begin with routine tasks and planned events, and then gradually move on to my ambitious wishes.

Event Prep & Scheduling

When I sit down to plan the week ahead, I often have a few events already scheduled. Although all are always on my Google Calendar, I still write them down on the left side under the day. These events include meeting with a friend, joining a meetup, or going to a concert.

The purpose is to know how much time and headspace I will have left for the day and the rest of the week. If I already plan to attend a meetup on Tuesday, I know I won’t have time in the evening for something else. If I know I will have to sleep late on Saturday, I don’t plan a workout for the early morning on Sunday.

Once events are on the calendar side of the agenda, I know what I can plan for workouts.

Workout Schedule

I used to be indecisive in the mornings. While trying to decide, I lost time and, along with it, my motivation. I do not want to find myself in a limbo of “Which workout should I do today?” when I wake up. That’s the reason I plan what workout I will do each day and choose my rest day(s). The main goal is to decide for my future self.

It is easier for me to follow the plan if I have already decided and distributed the workouts to the days. I sometimes change the plan during the week, but only when I have a specific reason. I might shift a rest day when I feel sick or have muscle pain, or shuffle it with another workout, but I still stick to the workouts as much as I can.

Once the events and workouts are planned, the time comes for what I want to do beyond my routine life.

Weekly Focus

I choose one trait to focus on during the week. This is neither a goal nor something to complete in a day or two; it’s a continuous mindfulness exercise, something to keep in mind throughout the week.

A weekly focus becomes even more powerful when it lasts for a few weeks.

For example, a few months ago, my focus was “write without self-judgment or self-criticism” for a few weeks. During that time, whenever I had a pen at hand, I wrote whatever came to my mind. When I caught myself thinking, “This text doesn’t make sense,” or “I produce terrible ideas,” or “delete everything and find another angle,” I diverted my attention away. The focus was to keep writing without self-destruction.

The important thing is to have mindful moments and focus on what truly matters while making progress on weekly promises.

Weekly Promises

If I have to choose the most important part of weekly planning, I would choose my weekly promises because these promises bring ambition to my life.

Until setting promises, everything is still a routine life for me. Nothing ambitious; only the routine is more organized. With three weekly promises I make to myself, I raise the bar.

You can think of these as goals, but using the word promise gives a different meaning. If I promise myself to do something by the end of the week, I try my best to achieve it. It also forces my hand not to do other things. That’s the whole point.

In a given week, I may want to do a hundred things, but I deliberately focus on my promises and avoid the rest. One example from my previous promises is “Finish Mediations newsletter’s 13th issue.” I always send the newsletter on Tuesday, and the promise was to make it ready on Sunday, two days before. During the week, that’s what I focused on and worked on to bring to the finish line. That required me not to do many other things, such as binge-watching a TV series or watching random YouTube videos. When I had to choose one, I knew what I had promised myself. By deciding on one promise, I eliminated many other decisions.

Ending the Ritual

Once the weekly promises are set, I briefly scan the whole plan again. I ensure that everything on my checklist has a ✔︎ on it. If yes, I’m ready for the week. I close the notebook and go to sleep.

During the week, I regularly check my notebook to remind myself of my promises. Whenever I find myself sitting idly or binge-watching random YouTube videos, I look at my agenda and pull myself to keep my promises.

Sunday evenings are my ritualistic moment—my last 15-30 minutes before I go to bed. The ritual mentally closes my week and prepares me for the next; then I sleep in peace.

And with this post being published, I kept another promise to myself. ✔︎

Reply via email | Reply via Mastodon | Comment

On AI vs. Intellect

Tue, 27 May 2025 09:05:00 GMT

I keep thinking about how AI is changing my life and where I should be cautious. Although I’m not against using AI to improve my life, my hobbies, and my work, I’m hesitant to apply it in some other areas, mostly gathering information and learning. Considering the history, I’m unsure whether we gain an advantage.

If we look back, the TV changed the world in a way nobody could have imagined. People trusted whatever they heard on TV (which they still do today) as it became a single source of information for many (and still is). After decades, only the Internet could dethrone TV.

The Internet has become a platform where people learn almost everything. Unlike TV, which was initially controlled by governments and later by the wealthy, the Internet’s decentralized approach allowed the public to shape its own knowledge base.

Topping up the Internet, AI has arrived. Although the AI can be adjusted to be slightly deterministic and less creative, we don’t know where and how the information it provides is shaped or whether it’s true. Yet, many people receive information and use it without filtering; they accept it as the truth.

What started with TVs progressed to a more dangerous state with each step. With each invention, we lost our intellect. With TV, we believed and trusted in people who were on TV to guide us to the truth. That didn’t go well, and TV became the ultimate vehicle for disinformation. The Internet topped that up as it introduced social connections—we can have a conversation with others, unlike TV. That introduced echo chambers. When any idea looked popular, it was considered the truth. This disadvantage is leveraged by many, including manipulators and politicians.

With AI, another unprecedented change in society has begun, in which we rely on information produced by an algorithm whose results are volatile. We don’t know its dataset and how it forms those “thoughts.” It uses data scraped from the Internet and creatively generates ideas. Along with it, it multiplies the problems of the Internet.

I’m not here to bring pessimism to your life about AI or warn you against it. Yet, similar to how we criticize the TV and the Internet, we must keep our critical judgment when using AI. When we seek information from any AI tool, we must evaluate the result, distill it to extract the truth, and ensure that it’s not a hallucination of the model. Otherwise, we’ll learn precise but completely inaccurate information as the truth. That’s the real danger.

We must become ignorant

Of what we’ve been taught,

and be, instead, bewildered.

— Rumi

Good to Great

I share max three things I found interesting, great, cool, etc., from good to better to great.

One of the reasons I rarely watch movies or read fiction is that most of them have a similar and predictable plot. I know that structured storytelling is compelling and generates a good income for the storyteller. Yet, I prefer listening to stories from people, even though their storytelling might be subpar—a good piece by Eliane Glaser on this topic.
I must admit, I admire Patrick Collison as a leader. He had an interview with Jony Ive, an iconic character. His questions were good, but what stood out was Jony's answers, thoughts, approaches, and you name it, whatever he said. Watch this.
At around age 30, I began to wonder about my impact on my younger brother, my only sibling. I recalled various moments from our youth. I pondered how my actions shaped him. To this day, I still don’t know if I influenced him to switch his profession not once, not twice, but three times and move to Australia. After reading this, I began wondering again.

“We can’t choose our families, but we can choose the stories we tell ourselves about them.”

Recently, I thought/wrote about

I wanted to finish a blog article this week. However, my job took up a lot of my time this week, and I couldn’t finish it. I had to make a decision: either exercise or finish the article. So, I chose exercising. Hence, nothing to add here this week. 🤷🏼

Until next time,

Candost

P.S. Building a product from an idea is one thing; manufacturing is another.

Reply via email | Reply via Mastodon | Comment

The One with The Wrong Problem

Fri, 16 May 2025 06:05:00 GMT

I spent two weeks obsessing over a problem that, in hindsight, didn’t even exist. The one that was attractive to me, without asking myself whether it really mattered. My ego took over, and stubbornness kept me locked in. I stuck with the wrong problem until I finally “solved” it. I changed how I approach problems after noticing it and observing others fall into the same trap.

As my job as a manager is to observe how others work and help them improve, I often catch people when they focus on the wrong problem because they regularly misinterpret situations and reality. It’s comfortable to choose the first approach they find, the easiest problem they encounter, or the one that they assume will bring the most benefits. They find a problem attractive when it is relevant to what they enjoy doing or what they think they ought to be doing.

I was in the first group rather than the latter. If I saw an opportunity to do something I liked and was familiar with, I jumped on it. Because I knew I would do a good job and bring results. I assumed these results would also benefit me. I convinced myself that others would accept me more and see me as successful. I created an illusion of success and became a victim of my own pride and ego.

“Experts cling to their beliefs in large part because their egos are attached to being ‘smart’ or ‘the best’ in their area of focus.” — Sydney Finkelstein

When the ego is destroyed, when desires are stripped away, when arrogance is torn down, we arrive at the truth. Nobody wants to be seen as stupid or wrong. I didn’t want either. However, the person who can admit that they are wrong triumphs. Confessing the mistake requires setting the expertise aside and sitting in the learner’s chair.

When I employed an open mind, a learner’s mindset, the right problem revealed itself, not the one that would presumably benefit me the most. Feeling like an expert (and having the attitude of “I know them all”) prevented me from evaluating the problem fairly. I became a fake expert, shortsighted at the expense of "effectiveness." I focused on the number of issues I solved, while forgetting the efficiency: solving the right problem.

The surprising truth, especially for people in leadership roles like me, is that others often tell us the problem, but we ignore it. We deny taking another perspective.

Most problems are already obvious

Arnie Malham, in his book Worth Doing Wrong, talks about the importance of fostering an open culture at work. Only an open culture can provide opportunities for everyone to raise their voices, escalate problems (or even solve them without anyone noticing), and share feedback. The leader’s job is to create this culture and listen to the people, understand the problems, and prioritize correctly.

Most escalated problems may appear as noise, especially when they conflict with problems leaders identify on their own. Many leaders tap into their ego and think, “My team neither sees the big picture nor the right problems.” They choose the problems they assume are important. They miss the forest for the trees.

:::note[Story Time] Sometime ago, my team was falling behind on deliverables and was becoming a bottleneck in various projects. I focused on delivering results project by project and looked for all small problems that their resolution could speed up development. The harder I pushed for speed, the slower we got. However, the moment I took a step back, the moment I listened to my team, the moment I looked at the forest, I realized that I had chosen the wrong problem. The problem was not in my team or the speed of development.

We had a lot of dependencies in most projects. At any moment, we had more than five teams working on projects that are relevant to each other, and my team was part of at least four of them. As my team was responsible for a core functionality and consisted of seven engineers, we were expected to provide support to almost all. Hence, we had a lot of ongoing projects and constant context switching between them.

The day I listened to my team became the day we decided to move two or three team members from my team to other teams and let other teams develop features on our codebase. The change was going to reduce my influence as a leader but would make the organization more efficient. By shifting our focus to the right problem, we unclogged the organization’s bottleneck even though we reduced the bottleneck’s size. With the change, my team also became happier as the team size and work-in-progress projects were reduced. :::

The higher we are up the hierarchy chain, the more people look up to us. We’ll frustrate even more people and harm the business when we are on the wrong problem. Contrary to the benefits we think we’ll gain in the short term, solving problems nobody cares about or not the most important ones will put our job at risk in the long term. When we listen to the people and acknowledge our ignorance, we’ll find success and wisdom.

Wisdom

The wisdom comes from how we handle the ignorance. Acknowledging complex problems that consist of many unknowns, understanding the intricacies between components, listening to the people who are closer to the problems and learning from them are the steps I take now.

So, what can YOU learn from my mistake?

Don’t invent problems. Leave your ego aside and carefully observe and evaluate what people tell you. Ask questions with curiosity. The more you learn, the easier it gets to identify the right problem. Don’t worry too much about the solution. When you’re on the right problem, you’ll eventually find a solution that works.

I created this article using these notes: 46j, 52a4, 7, 12, 31, 27a, 38b, 54, 30, 52a, 68, 7c, 20c, 24a1, 56m

Reply via email | Reply via Mastodon | Comment

What you do on bad days matters more than on good days

Tue, 13 May 2025 09:05:00 GMT

What you do on bad days matters more than on good days

I am considering making this newsletter more helpful for you by extending its content while reducing the time required to read it. So, your return on investment should increase with every issue. I decided to open the issue with a few paragraphs of text, focusing on one timeless idea. Then a few things across the world that I found great—a product, some news, a person. I’ll try this and look forward to your feedback. Hit reply and let me know what you think!

Four months have passed since New Year’s resolutions. According to statistics, 23% of the people quit within the first week, 43% by the end of January, and up to 80% by mid-February. At the end of the year, we will have 8-9% of the people remaining. The long story short is that fewer than 1 out of 10 people stick to their resolutions. Which group are you in? One in 10 or the remaining 9? I’m somewhere in between (we’ll see at the end of the year).

Albeit the majority of my resolutions are on track, I abandoned a few. It’s challenging to keep pushing and staying on track. There is one thing I constantly remind myself: if I wait for motivation or inspiration to arrive, I will most likely not find it. Even when I do, I probably won’t take any action about it.

We all have good and bad days. It’s easier to work out or eat healthy when we are in a good mood. But “what you do on your bad days matters more than what you do on your good days,” says Kevin Kelly.

I try to think of all my resolutions as my work. I work every weekday, even if I’m not motivated. Why not think of the new pledges we make to ourselves in the same way? As I’m trying to change how I live, who said it’s gonna be like a vacation?

The best we can do: Take the action today, quit tomorrow. Action creates progress; progress turns into momentum, and momentum eventually brings motivation.

Good to Great

I share max three things I found interesting, great, cool, etc.

LEGO F1 GP in Miami. Think about the engineering, the planning, and building the real-size ten F1 cars with Lego. A team of 26 people spent 22,000 hours and used a total of 4 million bricks. 🤯 Why? F1 and LEGO are both about pushing boundaries; why not do it together and create a successful marketing campaign?
Bill Gates is shutting down the foundation and giving away all his wealth (~$108bn). It blows my mind how much wealth a person can accumulate. Anyway, he finally decided to give it all away.
Download, print, and hang on the wall: How to instantly feel better?

Recently, I thought/wrote about

I feel like owning a website/blog is a different thing from other hobbies. I wrote about how I see it.
I wrote about why and how I am trying to run away from recommendation engines and algorithmic feeds.

Reply via email | Reply via Mastodon | Comment

How many times did you solve the wrong problem?

Fri, 09 May 2025 13:15:42 GMT

How many times did you see someone solving the wrong problem?

How many times did you catch yourself doing the same?

I often catch myself focusing on the wrong problem or a non-urgent one because it's easy to focus on what we like or what we think will position us well.

I heard from one of my previous leaders that solving a problem that nobody even wants to get close to brought them a lot of learning. So, maybe we shouldn’t invent problems that don’t need any solution or whose solutions don’t matter.

Instead, we should seek the most critical problem. Even looking for that will teach us many things along the way.

Reply via email | Reply via Mastodon | Comment

Self-discipline is a long-term character investment

Mon, 05 May 2025 19:00:00 GMT

Building character is defending against the short-term wins of your ego and pride. Only self-discipline and quieting ourselves, investing in long-term wins, can show the way to enlightenment, a fulfilled life that is driven by purpose. If we become slaves of lust, fear, and vanity, we distance ourselves from courage, honesty, and humility. Self-discipline is what anchors us to stick with a permanent and important thing in the long term, rather than collecting the short-term benefits that have detrimental results over time.

Related Note(s):
- Instead of ego, build confident humility.
Source(s): The Road to Character by David Brooks

Reply via email | Reply via Mastodon | Comment

No achivement alone

Mon, 05 May 2025 11:05:00 GMT

Although society is more individualistic than ever and day by day becomes more individualistic, you need others’ assistance to fight your inner struggles. Some people have God to fill this gap and use it to fight prejudices, selfishness, greed, and pride, and they develop self-compassion and individual will. These inner forces are too strong to fight alone. You have to find outside help or hope that it will give you the best. These can be cultural traditions as well. The thing is that they have to educate your heart and build values, and show what to feel in certain circumstances.

Related Note(s):
- Genghis Khan found friendship to be the main driver for loyalty.
Source(s): The Road to Character by David Brooks

Reply via email | Reply via Mastodon | Comment

Love is submission

Mon, 05 May 2025 11:00:00 GMT

“Love is submission, not decision.” — David Brooks

When we love, we change. We lose ourselves, pieces of our personality. Love makes us do things that we wouldn’t do otherwise. We neither decide to love nor decide to submit; we simply go for it.

Source(s): The Road to Character by David Brooks
Related Note(s):
- Friendship is a form of love;

Reply via email | Reply via Mastodon | Comment

Pride deludes us

Mon, 05 May 2025 11:00:00 GMT

Staying humble is knowing that almost nothing is in our control and can change in a moment. Most of our lives are outside of our control; changes are driven by others in society, such as a boss at work, a politician, and even delays in the metro. Pride is thinking that we can control them all. It’s denying the truth and sitting in a creator of life chair. We are not the authors of our own lives. Neither has a divine power. Accepting that we have almost no control requires destroying this pride and breaking the delusion.

Related Note(s):
- Approach others with humility, not pride, to persuade them easily.
Source(s): The Road to Character by David Brooks

Reply via email | Reply via Mastodon | Comment

On Owning a Website

Mon, 05 May 2025 06:05:00 GMT

Something is different about owning a website—a palace on the web. Unlike a car or a house, unlike other hobbies, a website exists in a subtle space between the private and public spheres. Though you create it, nurture it, and spend countless hours making it beautiful and functional, it lives out there on its own. The magical part is that strangers across the globe (many people you will never see in your life) can leave their thoughts on the pages, creating connections impossible in other creative hobbies.

The Freedom of Creation

A personal website brings freedom. A sculptor can also say the same before they hit a chisel with a hammer to shape a block of marble, or a painter with a clean brush and endless color palette to use on an empty canvas. Yet, none gives the freedom the website provides.

On a website, mistakes are replaceable and fixable; nothing is permanent. A mischievous strike on an almost finished sculpture or a degraded color on a paint after it has been dried can’t be undone or changed. But on a website? Even after a significant amount of coding and designing a website, everything can still change. Not only the design, but your creative content can change at any time too. If a post written years ago doesn’t reflect your thinking anymore, you can revise it or retire it with a note explaining how you have changed.

The Flexibility of Presentation

A personal website brings flexibility for presentation. Today, you may create a chronological blog; tomorrow, you can revamp the whole website and turn it into a carefully curated knowledge garden. Today, you can design a static website (like this one); tomorrow, you can evolve it to an interactive experience.

The possibilities are endless. Unlike physical creative works, which are frozen at the moment of completion, a website breathes and changes—sometimes drastically, sometimes subtly—reflecting the growth as both creator and person.

The Connection and Conversation

A personal website brings connections across so many boundaries. When an artist produces a piece, they rarely hear others’ thoughts if they don’t put the piece on social media. Their work is mostly visible in the world of silent viewers. But a website creates an ongoing dialogue.

A piece written five minutes ago can be read by someone on the other side of the world. Imagine you share your personal grief on your blog before you go to sleep. Someone else, through the night, finds comfort in your words and shares their story in the comments. Or a piece you wrote to solve a technical problem can help others again and again, or the one you couldn’t solve can be solved by someone else’s suggestion in the comments.

These connections have a different quality than those formed on social media. They are centered around ideas rather than driven by the number of likes. That’s why an idea written five years ago can still find an audience and restart a conversation just like it was published a moment ago.

The Immortality of Ideas

A personal website gives an opportunity for survival. Unlike physical artifacts that decay or require careful preservation, digital thoughts can be perfectly replicated, backed up, preserved, and even later improved.

I built my own website first using Jekyll. I didn’t like the design that much and moved to Hugo, then to Ghost and later Astro, each time with a different design while preserving the pieces I’ve written.

The only thing that has a chance to survive is your ideas that fill the website. Although you must update your website’s infrastructure due to ever-changing technology, your ideas, thoughts, memories stay the same. A website provides intellectual immortality.

The Responsibility of Maintenance

Within all these opportunities and freedom, there is one downside: maintenance. A personal website carries a maintenance burden. A book doesn’t need any further effort from its author once published; a paint only needs occasional dusting. But the website needs ongoing attention.

Even keeping it alive without adding anything new demands time and devotion. The technical infrastructure keeps changing under the hood. If you don’t choose the simplest and plainest approach, you must keep it updated. This is why we have seen the rise of services like Substack, Medium, Ghost, and WordPress, offering solutions around maintaining a website.

While keeping the website alive needs time, the real cost comes from indulging in the pursuit of perfection. Making perfect websites shouldn’t be the goal unless it’s for an artistic approach. Otherwise, it should be about the freedom. Having a space to write and organize thoughts, artifacts, information and documenting the journey is the reason it exists. Many people, including me, lose a lot of time trying to make the perfect website, forgetting its real purpose.

Verdict

The website is ultimately more than just a collection of pages; it’s a reflection of self. It reveals who we are through content and how we present the content. It combines the narrative elements of writing, visual components of design, the structural thinking of information architecture, opening a true place of the mind to visitors around the globe.

Yes, it requires effort to build and commitment to maintain. But there is nothing like it; no other medium evolves with you, gathers connections around the world and preserves thoughts. That’s why it’s worth having.

Reply via email | Reply via Mastodon | Comment

Online social networks are worthless

Sun, 04 May 2025 16:00:00 GMT

Online social networks have passed their promise of creating a social network. It feeds the desire for attention in a competitive market. We seek the likes of people we didn’t know existed. This hyper-competitive side of social networking technology takes our time immensely in return for, simply put, nothing. The currency of likes is not worth a dime.

Related Note(s):
- Likes are driven by our inner drive to be accepted by a group. However, this time, the group is the one we don’t even know. It’s pure automatic, on autopilot.
Source(s): The Road to Character by David Brooks

Reply via email | Reply via Mastodon | Comment

No contest, no progress

Sun, 04 May 2025 15:01:00 GMT

When our lives pass without contest, conflict, or friction, when our lives pass without success or merit, we’re merely filling existence. Our lives become useless and purposeless. The person who commits, strives, conflicts, penetrates the hardship, seeks the inconvenient, and crosses the ocean of difficulties to build merit or succeed can say that they exist for good.

Related Note(s):
- Having good values and metrics in life is difficult, not the easiest.
- Self-doubts are part of the friction we create ourselves.
Source(s): The Road to Character by David Brooks

Reply via email | Reply via Mastodon | Comment

Imaginations are dangerous

Sun, 04 May 2025 14:30:00 GMT

Imaginations and daydreams are dangerous. They distance us from reality by envisioning ideals or triumphs over others or difficult situations. It forms fantasies and prevents us from celebrating our achievements; it forces us to focus on what’s left undone and makes us stuck on unattainable future possibilities.

Related Note(s):
- When you find yourself daydreaming because you were born into difficulty, you still have a way out.
- In ambiguous situations, we may drift to daydreams or imagination. Find a better compass than imagination.
Source(s): The Road to Character by David Brooks

Reply via email | Reply via Mastodon | Comment

FOMO is selfish

Sun, 04 May 2025 12:00:00 GMT

FOMO is selfish. It means that you must taste all experiences and always seek the newest, shiniest thing. It focuses on your experience. It spreads you too thin. You become a dopamine addict by tasting and trying everything. You can’t go deep into a specific topic because you say a lot of yeses and sacrifice your time with shallowness. You miss a lot for one big overwhelming yes, which can only be gained by saying a lot of noes to trivial things.

Related Note(s):
- No FOMO, only JOMO.
- Success is not about experiencing everything but consistently doing what you value.
- Stick to your commitments and how you define yourself.
- Defending against the popularity of something is difficult, but not impossible.
- Not everything in life has to be convenient. Resist your desire.
- When you have too many commitments, stop and analyze.
Source(s): The Road to Character by David Brooks

Reply via email | Reply via Mastodon | Comment

Selfish goals are unattainable

Sun, 04 May 2025 11:15:00 GMT

A selfish goal is unattainable. When you want people to love you, and if you try forcing your way in, you’ll never be loved. But only when you want to learn more about others and be genuinely curious, you’ll be loved as a by-product. Self-forgetfulness will bring that as a by-product—the same for acquiring knowledge. If you aim to learn more, you’ll never learn. You’ll gain knowledge when you love a topic and immerse yourself in it. You only get what you want when you don’t focus on it directly, but do it indirectly.

Source(s): The Road to Character by David Brooks

Reply via email | Reply via Mastodon | Comment

Wisdom is learning how to handle your ignorance

Fri, 02 May 2025 15:57:08 GMT

Wisdom is the moral quality of knowing what you don’t know; it’s learning and handling your ignorance and limitations. You can learn someone else’s knowledge, but it will be mere information for you. Turning that information into knowledge and then later wisdom, you must understand how much you don’t know.

Related Note(s):
- Uncertainty and open-mindedness are the elements to acquire and drive wisdom.
- Once you learn your limitations, you can start criticizing fairly.
Source(s): The Road to Character by David Brooks

Reply via email | Reply via Mastodon | Comment

Social Media Impaired My Learning

Tue, 29 Apr 2025 07:05:00 GMT

One lie I used to tell myself was that I was learning a lot from social media or content online. I used this lie as an excuse to keep consuming while lying down on my couch. Later, I realized that this was only a delusion. After shutting down social media, I realized my learning was an illusion, and it is also impaired. I’m still trying to fix it.

It’s hard.

The “useful” information we receive on social media looks useful at first. The pleasure and satisfaction come from seeing something we didn’t even know existed. Despite the dopamine rush that comes from discovery, we continue with our lives without any change. For example, when I discovered in-cockpit-view flight videos, I “learned” a lot about how to pilot an aircraft. I watched, again and again, how pilots lift off and land a plane. Yet, I still can’t even imagine myself piloting an aircraft. I built a mastery, but a false one.

The other example of false mastery is life hacks—techniques that promise to help you use your time and life more efficiently. Learning how to cut a cucumber in a way that saves 200 milliseconds is not something I should be worried about. The time I could save from cutting cucumbers in the next decade was already lost while watching that three-minute video. I’m not a professional chef, but I now have an illusion of competence. I consumed information, although I could already cut a cucumber.

Consuming information doesn’t equate to building knowledge. They are fundamentally different. According to Barbara Oakley, a Distinguished Professor of Engineering at Oakland University and the instructor of one of the most popular online courses, Learning How to Learn, building knowledge or skill requires focused and unfocused thinking, spaced repetition and deliberate practice with increasing levels of challenge while applying information, making mistakes and correcting them one by one. When I read online, watch a short video, or listen to a podcast, I do neither of these, but somehow, my brain remembers the stupid cat video I watched five years ago.

When I dig into the reasons, it’s obvious why; it actually involves elements of learning. I watch the video multiple times (focused learning), share the cat video with friends, and we watch it again (spaced repetition) and talk about it while creating a social bonding experience (applying information on different levels). Yet, we don’t do the same with any other information.

Most of the “useful” information we consume online becomes neglected and quickly forgotten because we see it when lying down on the couch—the moment we want to do the least—or right before we get off the bus, train, or taxi, making it impossible to act on new info. We don’t share these with friends or talk about them. We only delude ourselves with a crack of information, so we have something to say in social groups or compete in pub quizzes (if only we remember it).

Some claim that they use social media productively: following accounts that share great and informational content, and optimizing their feeds by following certain accounts and regularly blocking accounts that share either junk or useless content. However, they forget that the lack of information is not the problem anymore; the excess of it is. Content consumption is not the solution; learning selectively is.

I believe there is one group of people who solve this problem: using social media for inspiration, nothing else. For example, someone who is into pottery can be inspired by a new idea they see on social media and try the concept themselves later on. The real learning is still offline. Online is only the *inspiration***.** They have no intention of learning from there and don’t mix up two concepts with each other.

So, knowing these, how can I fix my learning?

Two steps I have already taken: quit social media and live without algorithms. I doubt these alone will fix my learning.

I’ll share when I take another step.

Reply via email | Reply via Mastodon | Comment

Living without algorithms

Mon, 28 Apr 2025 05:00:00 GMT

What started with an experiment of living without looking at social media turned into quitting it completely, changing my reading habits, and stopping consuming news daily.

As the new step of decluttering my life, I am changing my approach to using services that heavily leverage algorithms to recommend new content, such as Netflix, Disney+, Apple TV, Prime Video, YouTube, Amazon, Letterboxd, LinkedIn, and more. I keep my accounts on most services, but intend never to scroll the feed or jump from one piece of content to another.

My goal is to stop relying on algorithmic feeds to fill my time. Many people find these algorithms helpful, but I find them detrimental.

The Why

Not only do I waste a lot of time, but I am also not even aware of wasting it. Companies using algorithmic feeds aim to obtain my time to the fullest without me noticing it. They create a frictionless user experience, which in turn allows them to serve better targeted ads (or sell more subscriptions). This doesn’t make any of these companies evil; it’s how business works.

My goals and these companies’ goals conflict. What matters to them does not matter to me. Although most products use algorithms (and prediction models) to engage me with what I may like, it almost always feels like a toxic relationship. Sex is good, but life would be much better without all the manipulation.

I wanted to get rid of manipulation and keep the good parts.

What to do

I set out for myself a single goal: Never look at any screen if I don’t already know what I’m looking for.

This goal is a fundamental shift in how I approach anything (adding another decision here). If I don’t know whether I really need a new shirt, I don’t buy one. If I don’t know which movie I want to watch, I either don’t watch one or first decide on the movie before turning on the TV. Deciding first before looking at any digital service forced me to build up an inventory.

Although I’m still crawling on this topic, I began keeping an inventory of movies to watch, things to buy, books to read, questions to find answers to, articles to write, people to get in touch with, restaurants to try, food to cook, and many more. These are plain lists that live in a note on my Obsidian (except articles and newsletters to read, which are on Readwise Reader; I’ll share more about it in another post) instead of other digital services.

I tried and used various other apps to manage all these lists. Oku for my books, Letterboxd for movies and TV series, Amazon for shopping list, and more. They were all convenient as I didn’t have to type in so many details—with one search and a click, the item is added to a list. Yet, convenience doesn’t make everything better.

Having a plain list in a file (or even on paper) has certain advantages. The friction of manual writing is itself a selection process. While adding an item, you have to write the full name and any details you need. You have no autocomplete, no suggestions. Before writing these, I consider whether I really want to write them down. Despite a bit of friction, it’s still easy; once you write the name in the inventory, it’s done. Choosing something from the inventory, on the other hand, is where I replace algorithms.

Compared to any of the products (like Amazon or YouTube), the information in the list is minimal. Look at your shopping list on Amazon; you have price, reviews, shipping information, and more. When you keep your own list, you have as much as your own entry. The trick is using the list as an initial decision point. When I want to watch something, I don’t go to Netflix or Apple TV directly; I open my list first, choose one, and search for it specifically. This approach breaks the association of “being bored” with any digital service. I intend to do a specific thing and avoid filling a gap with algorithmic recommendations in my life whenever I get bored.

“People are drawn to the easy and to the easiest side of the easy, but it is clear that we must hold ourselves to the difficult.” — Rainer Maria Rilke

However, this was not easy (and still isn’t). I needed to break some habits.

I constantly checked my phone for LinkedIn to see if I had a comment on my last post, or opened a YouTube video without thinking about it. After I come home from work, I feel tired and the phone is “just there” to fill the evening and “relax.” So, I looked for what I could do to change how I use my phone.

The How

After researching a lot, trying various methods, I established two guidelines for myself:

No native apps on the phone; only the mobile browser will be used.
Use tools to break unwanted habits.

No native apps

I already tried this approach when I was experimenting with living without social media. I knew it worked, but I needed a few changes.

Native apps are the grand palaces of companies. Companies customize everything inside to their needs (ideally, users’ needs, but not always). Giving these native apps real estate on my phone, the device that I carry with me everywhere, and putting them in a very accessible position makes it easier to use them. I want the other way around. Reaching these services should be really difficult; I must put in an effort. There has to be a lot of friction.

Hence, no native apps on the phone. That’s the rule. This way, I have to log in on a mobile browser, which doesn’t have the optimal user experience (because most products don’t care too much about mobile browser experience). Yet, this alone is not enough.

The mobile browser is still within reach. Adding only a second delay, sadly, doesn’t cut the habit. One recommendation I read somewhere (probably from James Clear or Cal Newport) told me to log in and log out of these services every single time, which I did. I even added two-factor authentication. But it still didn’t work well for me.

So, I had to add the second guideline.

Use tools to break unwanted habits

I get frustrated with bad user experience (UX) design and stop using the product. The problem is that most of the products I mentioned have great UX design. They create a seamless experience. They optimize algorithms to show you the next relevant thing in the most convenient way.

For example, I don’t want to scroll my YouTube feed because recommendations are still tailored to what I searched and watched (only lately, YouTube started introducing new topics to me). One thing I want to use YouTube for is to help my life. Yet, every time I open YouTube, I find myself checking other videos. YouTube makes it compelling to watch more with features like autoplay. So, I needed to break the UX.

There is a browser extension app called UnTrap for YouTube that works on iPhone Safari. It enables you to remove almost any feature YouTube has, ranging from removing the main feed to gray-scaling the whole website or removing buttons. After setting up the app and adjusting the design, here is a screenshot of what my YouTube looks like:

I removed the features I didn’t want to use. Decluttered my YouTube and left what I use: search and my profile page to access my history.

I needed something similar for LinkedIn. Again, luckily, there was another browser extension app from the same developer: SocialFocus: Hide Distractions. If you’re using any social media (ranging from Facebook to HackerNews), you can customize almost everything for the browser. I only use its LinkedIn features as I don’t use other websites.

Here is a screenshot of what my LinkedIn looks like now:

(Once a week, I check my feed, but do it on my laptop)

Last but not least, I needed to declutter my home screen on the phone. I first tried having an empty home screen. However, the iPhone’s library quickly replaced it while I was trying to access a few apps I used for different purposes. Most products leverage visual associations (like app icons) to remind me that the app exists and reinforce my habits of using the product more. I wanted to break these associations as well. I found an app call Blank Spaces to use my home screen without any app icons.

Here is a screenshot of my home screen:

I also turned off all Siri suggestions on my iPhone search (where you pull down the screen to search something).

The second guideline builds on top of the first guideline. By combining the two, I finally began seeing the impact and changes in my life. I pick up my phone less and less. I am able to evaluate and understand what matters to me the most. All the noise is gone.

Yet, every decision is a loss. What matters is understanding the gains as well as the losses of any decision.

Where I lose

Similar to my social media decision, the social impact of this decision is high. Cutting the ties with algorithmic feeds means I’m no longer informed about popular topics. In conversations with friends, I can’t contribute to discussions when they talk about a new TV series or movie or any other popular culture topic.

When I tell this to people, they are sometimes confused about whether I become aware of any topic at all. I do get to know them, but I do so either way later than the majority of social media users or from other sources.

Let’s take any popular Netflix show. Everyone learns about the show due to Netflix pushing it to the front row in the app. Some people immediately watch and form an opinion. In its first weeks, everyone talks about it (great marketing success, Netflix 👏🏼). I get to know there is a new show and whether it’s a good one via the people I know whose taste in shows is closer to mine. Then I add the show to my watchlist on Obsidian. When I want to watch something next time, I look at my list. By then, the hype is often gone and I can reason to watch it by sheer will, not popularity.

This approach may not apply to cinephiles or others with a passion. I don’t have a strong passion for the most popular subjects. I enjoy learning about many things, but can’t consider myself deeply knowledgeable in a single topic (I’m a multi-potentialite). I enjoy a lot of topics, but not so deep that I become a geek about it.

I constantly look for new topics and say no to many. Any algorithmic feed is where I cut things out. I find popular and hype culture via algorithms to be detrimental. I still learn many of the popular stuff via my friends, family, or the people I follow via RSS or email. But these almost always come too late, usually after the popularity is over. That means FOMO for many, but JOMO for me.

Last Thoughts

People underestimate real-life media. Before social media was defined with Facebook and Twitter, word of mouth was how society operated, and it still does today. People are under the illusion that popularity on platforms is everything. However, we still talk about what we are interested in and what’s popular in real life. The only difference is that you have to listen to people instead of seeing what they say from a screen.

Additionally, things-everyone-who-uses-social-media-knows are overrated. When you don’t have any algorithms that feed you with these popular topics like funny videos, you can send to your friend via Instagram DM (and receive a ❤️ emoji reaction), you do it in real life! All my friends talk about what they enjoyed or liked or found funny and show them to me. Real-life socialization is not extinct yet. It’s the actual way of being social (both for extroverts and introverts).

By choosing not to use algorithmic feeds, I rely on the word-of-mouth recommendation engine. I don’t care about how many people have seen a video on the other side of the world. I instead invest my energy in being part of a community, either around me or around a particular topic. When you look closely, it’s what everyone wants. The key to getting it is spending time on what matters to you, not what’s popular.

The popularity these days is in the hands of a few products. As their goals are focused on maximizing their profits, I don’t see a reason why I should keep using their recommendation engines. I prefer making my own feed in my own way.

Reply via email | Reply via Mastodon | Comment

What I miss from Twitter and new commitment

Wed, 23 Apr 2025 05:20:00 GMT

Charity wrote a post. It’s probably one of the things I miss the most on Twitter as well. Having the tech industry yapping about things, being a close community where you get to know a lot of opinions, and sharing what’s on your plate without the hassle of writing a blog post.

That’s why I added a journal section to my blog to replicate what I’ve done on Twitter back then. Yet, I fail to write at a frequency similar to Twitter, just as Charity said.

So, Charity promises an article per week; I’ll join as well. One entry per week in either the post or journal section, mostly 750-850 words (excluding certain weeks of the year when I travel).

Like Charity, this is my public accountability post and commitment.

Reply via email | Reply via Mastodon | Comment

Writing is for everyone and no one

Mon, 21 Apr 2025 15:31:42 GMT

Isn’t the writing about nothing but everything at the same time?

Words are written for everyone, but most are read by no one.

If nobody reads them, then why do we write?

I claim that I write for myself, but I rarely read them again.

Writing is for the clarity of the thought, but 99.99% of thoughts are still cluttered.

99% of the writing is not writing; it’s editing.

Then why don’t we call it editing? Because being an editor is also the role of a writer.

So, why do we have to edit?

Because without editing, the words either confuse or mean horrible things.

Decluttering thoughts is getting rid of the confusion and putting guardrails on thinking.

If we put guardrails, how do we insist that we are creative?

Without bounding conditions, creativity can’t find the end of the tunnel.

So, writing is about dealing with limitations, editing for clarity with the purpose of helping myself, but the output is for everyone else.

Reply via email | Reply via Mastodon | Comment

Building Trust Methodologically with Right Tools

Tue, 15 Apr 2025 08:30:00 GMT

Leaders deliberately plan to develop products or deliver projects. However, they rarely pay similar attention to building trust. They see trust as “natural” or “part of being a decent human being.” What they don’t know is that if they take a few intentional steps, they can actually build trust more efficiently and recover quicker when the trust is broken.

According to DORA Research, building trust has a direct correlation to software delivery performance and contributes to a strong team culture. Why, then, do leaders not approach systematically? Because people don’t know where to start or how to approach forming trust methodologically.

Trust is like insurance. You have to pay upfront to use it when you need it. If you try to use it without having it, like insurance, you’ll get a big NO as an answer. So, how do we get a big YES when we need it? How do we find that premium insurance?

Trust has foundations. Understanding them—like knowing your insurance policy in detail—is a first good step. I’ve put a reasonable amount of time into learning and practicing these fundamentals to earn the trust across the organization. Let’s dive in.

Foundations of Trust

Before we start, I want you to think about 2-3 people you trust in your personal and work life. How did you form the trust? Which events led you to trust them? There is no wrong answer.

(Think about it for 15 seconds)

Done?

Did you form trust because they were reliable in what they said, or was it because you got to know their personal life and enjoyed spending time on personal activities?

I learned from Erin Meyer in The Culture Map book that trust can be put on a scale. On one side, we have cognitive trust (task-based); on the other, we have affective trust (relationship-based). How we form trust with people is influenced by our cultural background.

On cognitive trust (task-based), trust is formed by the reliability of the person. The more reliable a person does a task, regardless of the topic, the more trust is put in them. The more the person keeps their promise at work and reliably finishes their job as expected, the more trust they earn.

On affective trust (relationship-based), trust is formed by the closeness between people and the time spent on activities. The more people know each other at a personal level, the more they build trust. In these cultures, people trust each other more and even make verbal business contracts. The relationship itself becomes a contract—without writing things down.

Below, you can see some countries and where they are placed on the trust scale.

Forming trust scale. (Source: The Culture Map by Erin Meyer)

Türkiye (where I’m coming from) is on the relationship-based culture side, while Germany (where I’m living now) is at the edge of the task-based culture side. Imagine the struggle I had when I first moved to Germany.

The approach to forming trust should change depending on how the other person forms trust, not how we prefer it. While we form trust based on our expectations, others form trust based on theirs. So, if we want to earn someone’s trust, we should be aware of that person’s style and adjust our approach. However, some techniques work for the majority.

Either cognitive or affective, trust can be formed by being reliable, having empathy, showing vulnerability and authenticity and providing transparency. In some cultures (like Turkish culture), character and relationship have more weight; in others (like German culture), reliability plays the most prominent role. I’ve worked with people at both edges of the trust scale. Focusing on these fundamentals helped me earn their trust.

Once I understood which foundations were at the forefront for a person, I was able to leverage the right tools, which you need to know.

Tools to Form Trust

Leadership and building trust might come naturally to some, but adding new tools to the toolbelt helps everyone. Without knowing the tools, gaining the trust of the organization or a team won’t be easy. I have written about most of these tools in detail before. So, I don’t go into too much detail.

Here is the complete list I leverage to build trust (with people directly reporting to me):

Weekly, at least 30 minutes of one-on-ones: No manager monologue. One-one-ones are for the direct report, not for the manager. Listen carefully and act on what you promise.
Show empathy / Self-awareness: Be genuinely interested and put yourself in their shoes.
Share Different Types of Feedback: Start with appreciation, then move to evaluation and/or coaching. Be aware of what kind of feedback the other side expects at a particular time. The goal: say the hard thing, hear the hard thing.
Transparency over context: The manager’s job is to manage information flow. Sharing context allows people to do their job effectively while reducing secrecy, which helps build trust.
Delegation: Delegate the work you know best or the skill you can perform well to the person who can and wants to acquire it. There is no better way to grow talent. The more you delegate, the more you show that you trust.
(for more relationship-based people) Lunch / Dinners / Social Events: Don’t underestimate the value of a shared meal. Food brings people together.

When I work with my peers or my managers, I still leverage most of these tools, but the shape changes. With my peers, I rarely do weekly one-one-one but instead have irregular one-on-ones about a specific topic. I increase the level of transparency with them, including more personal details about my team, and I show them even more vulnerability. With my manager, I go all in on transparency and feedback, while delegation plays almost no role.

Although there is still so much to learn, these fundamentals and essential tools already give a good framework to approach building trust systematically. I’ve been using them with many people, and they simply work. If you haven’t done it already, give it a try.

Reply via email | Reply via Mastodon | Comment

Thinking Beyond the Desk

Fri, 11 Apr 2025 06:15:00 GMT

One of the things I miss the most in my software engineering job is being able to close the computer and stop doing the work. The work needs an external tool that you depend on. The manager’s job is different. You rarely need an external tool, and you can’t really turn off your brain, especially when you have a stake in a topic. You keep thinking about it because many problems neither need a computer nor a meeting.

People-related challenging topics, such as difficult feedback conversations, team restructuring and performance improvement plans are sources of stress. When under stress, the thought spirals are endless. The worry about how we will impact someone else’s life and how we will be seen in the social setting keeps the mind busy. Hence, it’s easy to ponder and have different scenarios play in the head long before the actual conversation.

Situations like these require neither a meeting room nor a desk or laptop. You simply continue thinking about it during cooking, walking, watching something, or any other activity you do. This is bad. I believe the root cause is not allocating the time correctly.

Manager’s thinking time during work is almost nonexistent, especially these days. Many managers (including CTOs) are expected to be the master of many trades, including hands-on work, strategy, business, people, psychology, software design, and many more. While trying to do all, there is no time left to think about that difficult feedback conversation.

Without having any space to work out the details of the conversation, the strategy and the arguments, there is no way that any of these will be done during the work time. Eventually, thinking shifts to the time we go out of work because, finally, all other things are out of sight.

I wondered how to stop. Meditation, journalling and mindfulness are things that come to mind. However, building mindfulness takes ages. It requires practice. Maybe the solution is to set solo work time at work and block it on the calendar. Then, use this time to journal, plan, and think about a topic in whatever format that fits. Writing or going for a walk is my default option. These don’t seem like visible work to anyone, but it’s a different type of job that helps all the visible ones.

Reply via email | Reply via Mastodon | Comment

Improving My Schedule as a Manager

Tue, 01 Apr 2025 08:30:00 GMT

One of my previous managers told me, “The manager’s work happens in meetings,” while I was complaining about the lack of uninterrupted time. Now, I can say that my manager was only half right. Considering one-on-ones, alignment, check-in, decision-making and many other meetings, it’s true that most of the work happens during meetings. However, a significant chunk of work—arguably the most crucial—is outside scheduled meetings: spontaneous chats, reflection time and solo work. Without them, no manager can succeed.

When I look at my calendar, 60-70% of my time, on average, is occupied by meetings. Regular and one-off meetings take most of my time. Realizing that I don’t have the luxury of having a half day without interruption and working with, as Paul Graham put, maker’s time after becoming a manager was an eye-opener. It’s also what my manager was pointing to.

Manager’s vs. Maker’s Time

Managers work with time slots like thirty minutes to an hour. Most slots are occupied with meetings. Meeting-free days are rare. I know there are organizations with meeting-free days, but I observe that it requires immense discipline from everyone. Most organizations default back to having fewer meetings on a meeting-free day.

Meetings are an unavoidable part of the work, a big part. It is where the manager gathers context, exchanges ideas, listens to others and ensures people are aligned and progress toward a shared goal. It is the work of the manager, which is different from the makers’ work.

Makers work with big-time chunks, like spending half a day finishing a piece of work. Any meeting—regardless of the length—disrupts this flow, and the quality of the output gets lower. Hence, they try to avoid meetings at all costs. The focus needed to complete the creative work overrules the importance of any work that’s done in collaboration. Most of the complaints of makers come from managers not being mindful of the maker’s time structure.

Although I avoid interrupting anyone’s flow (if they have headphones on or have a focus time blocker on their calendar or status on team chat), I also had a LOT of spontaneous chat makers initiated either via sending me a message (“Do you have a few minutes?”), reaching out to me on my desk or catching me while getting a coffee in the office.

Spontaneous Chats

Random chats bring so much value for both sides that I began having slack time in case any of these pop up. Moreover, having this slack time gave me an opportunity to have spontaneous chats with others outside of my team. Even though we don’t directly work together, knowing people in the organization proved to bring a lot of value later on.

As knowledge is power in our age, knowing who to reach out to to gather context for a project or connecting people who need each other is one of the superpowers of any manager. Spontaneous chats are the place to build that information map, so I know who to go to when documentation is not up-to-date (when is it ever up-to-date?). While these chats are random, my strategy is definitely not. I intentionally create slack time to have these chats. That requires setting uninterrupted solo work and reflection time on my calendar.

Solo Work

Solo work is what my manager failed to warn me to be mindful of (he actually told me, but way too late). It’s that work when you ask a manager about how their week was, and you hear them saying, “I finally got some work done.”

It’s hard to set time aside to write that document, plan an upcoming meeting to maximize the outcome or share well-written updates with stakeholders. I need at least a few hours a week to work alone to jot down my thinking, build arguments, and think about how I will approach problems that involve people and technical systems. I think hard about how I will set the environment for others to solve the problem. As this work is not visible on the calendar, many managers put an extra hour or two in a week to “get some work done.”

When I try to put this work on my calendar, I often get other meetings scheduled over them. Just because it’s solo work, people’s argument is, “It’s easier to move it compared to a meeting with ten participants.” I’m not going to dive into how to say no to that meeting, but solo work is one of the fundamental parts of the job. It should find its place on the calendar every week.

There is one more time category managers have, which often causes overtime work.

Reflection & Planning Time

I fall into a trap a lot. My mind wonders when I cook, walk my dog, run, or exercise, and I reflect on my work. I know I’m not alone.

Management is a lot about reflecting on yesterday and planning today and the future. It’s not only about meetings, writing a document, or sending a message in a team chat. It’s thinking about all of these before doing it, learning from past interactions, and reflecting on the last spontaneous chat or recent outcomes to prepare for the difficult feedback conversation in the next one-one-one.

This reflection time is the most neglected one, but in my experience, the most crucial one. When I neglect, I catch myself doing it outside of my working hours while walking my dog. It happens whether I like or want it or not. So, it’s better to make it intentionally part of the working hours. Work should stay at work anyway.

Whether solo work, reflection time or meetings, I also learned that a manager’s calendar is very dynamic compared to a maker’s calendar. When I look at my last 8-10 weeks on my calendar, none of the two are the same. Hence, it’s difficult to say these hours are for this work and those for that. Some weeks, meetings occupy the most time, and other weeks, there is solo work. When any category dominates my two weeks back to back, I know I’m not getting my work done and I need to change something.

How do you spend your time at work? What do you do to improve your schedule? Just comment or send me an email via button below. I read every email.

Reply via email | Reply via Mastodon | Comment

On Retaining People

Tue, 25 Mar 2025 07:05:00 GMT

The more I think about why organizational changes happen, the more I see that it’s merely an adjustment to the environment. The world is changing all the time. If you don’t adjust and evolve your organization with it, you’re practically falling behind and will eventually go out of business.

You have to keep the momentum in the team and constantly reiterate yourself and your team. You always have to adapt your strategy to macro and micro changes. Sometimes, you even have to be the change that forces others to adapt.

While doing so, not everyone will be on board with your direction. Some will yell at you to tell you that you’re going in the wrong direction. You’ll not listen to these screams and keep pushing in your direction because you’ve made your decision or are stubborn enough to think that “others are wrong.” In time, these screams won’t disappear but will be less annoying because most people will adapt to the new change and lower their voices. You’ll be surprised to see how people change and how flexible they are when you look back. But some…

Some will leave. You’ll want to convince them to stay, follow you and help you on your journey because they are brilliant. They are the smart ones in the “hire smart people and get out of their way” phrase. You’ll offer even more compensation for them to stay because they play a key role in your organization. You’ll take an extra mile and do whatever you can to keep them. And that will be a mistake. And that will be a mistake over another mistake you made earlier.

When you offer them a better deal for them to stay, you think you’re doing best for the team and organization because you’ll struggle when the person is not there and thing will fall apart. Then, you’ll remember a phrase you’ve heard before and ask yourself many questions.

As a leader, your job is not to retain people but to create an environment where they will want to stay.

You’ll pause. Will gain another perspective. Suddenly you’ll realize that offering more was a mistake. Then, you’ll be fine with the person leaving. You’ll realize the person wasn’t fit for the environment and the culture you want to form in your changing organization. Either way, you’ll be better off without them going forward. No hard feelings. Then, you’ll realize the impact of the person in the organization. You’ll see the mistake you’ve made way earlier.

You relied on one person too much. You built a castle with a very weak foundation: the castle was standing on one person’s shoulder. When the person left, the castle started to fall. Now, you have to build it again. But this time, you’re wiser. You’re not going to construct it on someone else’s shoulder. You’ll build standalone. That will be a good correction. You will start but will come across another roadblock.

You need to part ways with some people because they don’t help you build the castle in the way you want or consider best for your organization. Ideally, these people will leave themselves. But ideals don’t always happen. So, you’ll have these difficult conversations. You’ll blame and question yourself on how you couldn’t think about it before, how you couldn’t see it.

You can’t. Don’t worry. Things change around you, and you can’t predict and prepare for all of these scenarios. You’ll try your best to say a nice and grateful goodbye to the people you’re parting your ways with. However, circumstances might not allow you to have everything in the way you want. So, you might say a shitty goodbye. Everyone will blame you for it. Without knowing what you are going through, they will make you the villain. You’ll accept it. You have to. The mistake was yours; you have to own all criticism.

Sometimes, you won’t make it shitty, but the people leaving will do it. They will make everyone suffer unnecessarily while leaving. You’ll never know why they do this because your communication bridges are already shattered. You’ll pray to finish this mess as soon as possible and go back to your regular life.

When you get over this, you will start new. You spent some trust credits on the way. You have to earn more. You’ll start looking for new people who are motivated by your culture. As people always think, they bring a fresh perspective. Yet, they rarely do. They don’t have a historical understanding of what happened. They fit your new culture better. That’s all.

Once you are back to regular life, you’ll realize how quickly people adjust to the new reality. The ones who couldn’t adapt or were unwilling to do so left the organization. The remaining members are your real team.

Now, you have a second chance. You’ll start looking for ways to build a strong new culture.

It will be challenging, but one way or another, you’ll work on changing the culture by keeping in mind the phrase you remembered a while ago:

As a leader, your job is not to retain people but to create an environment where they will want to stay.

You’ll work tirelessly, thinking that you’ll reach that environment. However, that culture will only be half-working until the external environment changes again or until you make your next mistake. Once it happens, you’ll start all over again.

This time, you know the drill, although knowing it won’t make it easier. You’ll take a deep breath and begin.

Reply via email | Reply via Mastodon | Comment

Transforming Complaints into Actions

Tue, 18 Mar 2025 06:05:00 GMT

During one-on-ones or team meetings, people sometimes complain endlessly. Managers struggle to understand how to respond to their direct reports’ complaints. They become people’s venting sponges, having no idea how to react or take action on most complaints.

I’ve been in that place, and I know I’m not alone. I’ve also complained a lot to my managers. Some of them also had no idea what to do. I know it because I remember their faces. They looked calm. They tried to hide their frustration. They tried to listen to me and took my heat off about a topic that didn’t matter a week later.

I also listen to people’s complaints inside and outside of my team. As much as I try to listen compassionately, my mind wanders while I wait for my turn to ask a question. Most of the time, I ask a few questions to understand the person’s feelings and thoughts better. However, I sometimes ask ONE question to kick people out of their complaining cycle.

Not because I get tired of listening to them but because it’s my job (as a manager) to keep the focus on the outcomes while understanding people’s needs. Endlessly complaining has no outcomes. Zero.

Once I discovered one simple question that stops people’s complaints and remarkably moves them to a productive zone, I tested it on myself.

When I caught myself complaining to my manager, I stopped. I answered that one question internally and told my manager, “Complaining doesn’t bring any value; here is what I will do about this issue that I care about a lot: I’ll do X, then Y. If it goes well, Z will be the next.”

I realized that my complaints always had an underlying reason. When I asked myself that one question, I auto-magically tried to find what that reason was. Many managers fail to find the root cause because they rarely focus on truly understanding the person. For example, when someone constantly complains about never getting a chance to rewrite the legacy code, they often have another reason underneath. They may fear falling behind industry standards, which may create insecurity in their future, or they might feel that people don’t trust them.

Now, I tested the same question; I began asking my direct reports.

The question is, “What do you expect from me?”

When someone on my team starts complaining a lot, I ask, “What do you expect from me?” When I complain too much to my manager, I put myself in their shoes and ask, “What do I expect from my manager?” Then, I dive deep and try to understand what I really care about and what I need because if I’m going to ask my manager for something, it has to be worth it.

When I ask my team members the question, sometimes they answer, “Nothing. I’m just venting; I needed to take the heat off.” That’s great! Now, I know that’s what they expect, and I keep listening. However, the answer is often something else.

With that question, we open a conversation and start digging to find out what the person cares about. I once had an engineer on my team who was very unhappy about many decisions in the organization. I asked the same question while they were complaining. Their answer was, “Can you help me make my concerns visible because I don’t have the forum to do it myself?” Through our conversation, I realized that they cared about accountability. Back then, a manager could get away with many bad decisions. For them, it wasn’t about any bad decision itself; it was about the dynamics of the organization. They didn’t have a voice or a forum to raise a concern. What we did was set up a meeting with the C-level.

Today, I sometimes complain to my manager, and my team does the same to me. Complaining shows that we care about what we are doing; it’s a very human thing. But when it gets too much and is not actionable, it becomes frustrating, especially for managers. A simple question can sometimes change a lot of things. A slight nudge to others can change the whole team’s mood. But don’t forget: this question requires trust and asking with curiosity.

If the manager asks it with frustration, the team will close their communication doors. Even if the manager is frustrated, that frustration has to be hidden. The question should come from a place of genuine curiosity and be asked in a trustful environment. Without these preconditions, it’s doomed to fail.

Next time you complain to your manager (or anyone in your life, really), ask yourself what you expect from the person listening to you. Even if you don't answer loudly, this will help you clarify your thoughts and expectations, which will definitely lead to a happier and calmer life. If you find the answer, let the other person know as well so they don’t get frustrated.

Reply via email | Reply via Mastodon | Comment

L8Conf and DecompileD Conferences

Sat, 08 Mar 2025 15:25:42 GMT

In February, I gave a talk at the DecompileD Conference in Dresden, Germany, titled “Building Incident Management Skills.” I shared how we built and implemented the Incident Coordinator Role, which is focused on reducing the pressure from first responder engineers and coordinating the incident, allowing engineers to focus on resolving the incident quickly.

This month, I will be speaking at L8Conf in Warsaw, Poland. This time, I’ll talk about “Overcoming Bottlenecks of Platform Teams.” How a platform team should approach their workload and which thinking strategies they should use will be the topic of the day. Preparing for this talk takes much more time than I initially thought. I will be exposing my failures in the last two years. I’m excited and nervous at the same time.

If you want to join me and have a chat during the conference, you can use the L8_SPEAKER discount code to get 20% off on the ticket price. Buy your ticket here.

Reply via email | Reply via Mastodon | Comment

Act as if...

Thu, 06 Mar 2025 05:35:01 GMT

“Act as if…”

When you’re trying to get buy-in, share information and drive decisions, always put yourself in your audience’s seats while preparing. Ask yourself what they would expect from your presentation, as well as your strategy and approach. Act as if you’re in their seats and give yourself feedback. Look for what you’re missing and what you’re adding unnecessarily. Use this also to structure your talk: consider what they know already and what they don’t. Push yourself outside of your thinking bubble. If you’re giving a presentation to higher-level leaders or stakeholders, use this to anticipate questions they might ask and answer them in your presentation.

Related Note(s):
- Focus on making one point the key takeaway.
- You might need to audit your team in three pillars to present in higher-level meetings.
- Consider the medium while acting as if.
- This anticipating approach will help you move faster.
- Don’t forget to lay out the pros and cons and why you go with one direction.

Reply via email | Reply via Mastodon | Comment

People model you as a leader

Wed, 05 Mar 2025 06:12:01 GMT

People model you as a leader. How you do anything is how you do everything. People observe you and look up to you all the time. How you behave in a meeting, how you approach a problem, and how you resolve an issue will be reflected in people. Even when you want the least, like when you take a wrong action, it can change how people evaluate you in a way that reversing it will take years. Act thoughtfully, don’t impulse react and approach every single moment mindfully.

Related Notes:
- Say, “I don’t know,” when you don’t know, to build an open and trustful culture.

Reply via email | Reply via Mastodon | Comment

The Real Meaning of a High Bar

Wed, 05 Mar 2025 05:05:00 GMT

Many job descriptions, company websites, and leaders mention “having a high bar in performance.” Everyone talks about it, but few define it. Nobody is transparent and doesn’t explain what they think. Defining the high bar isn’t just an intellectual exercise—it’s about setting expectations for ourselves and those we work with.

I like clarity. So, here is my attempt to define the high bar—at least mine, at least the one I keep for myself, and the one I apply to people reporting to me.

To me, having a high bar in performance means constantly living with and demonstrating two key traits: an ownership mindset and an intrinsic drive for continuous improvement.

Ownership Mindset: The Foundation

I believe that people are motivated and driven by purpose when they own, truly own, what they do. Truly owning means taking full responsibility for all aspects of the work. It’s not like Gollum’s ownership of the ring in The Lord of The Rings but more like Sam’s mission of helping Frodo. Sam is driven with a purpose. He bears all the burdens on the road, sometimes more than Frodo. Even when everything is against him, he doesn’t give up and saves Frodo on various occasions. What he shows everyone is a true ownership mindset.

When people own the idea, put in the work, and drive themselves to the results, remarkable things happen. Every time I see someone owning a piece of work, I see the pride in their eyes when it reaches its end. They meticulously consider all the details, eliminate various risks, work hard and finally achieve an outcome.

Similarly, they own the failure, too. If anything fails, they never say, “Ah, this failed because of that person or this or that.” They approach with, “This failed; it’s on me and here are the things I will do differently from now on to ensure it doesn’t happen again.”

But the ownership alone isn’t enough—it must be paired with a relentless desire for improvement.

Relentless Improvement: The Second Pillar

The second pillar of the high bar is the unending desire to improve—known as the growth mindset. It involves a hunger for improvement and a curiosity to explore unknown unknowns, which keeps the person “awake” until all are discovered.

They rarely settle into a comfort zone at anything; they continually seek more—not for the sake of impressing others or for any external reason, but out of a genuine intrinsic drive. This is not because someone encouraged them to learn (though this can be a valid reason, too), but rather because, even without guidance, they actively, consistently, and relentlessly pursue opportunities to get better at what they do.

They also do it methodologically. They focus on getting the fundamentals right and strong, adjusting their learning techniques, and looking for ways to increase their overall productivity and speed of learning, concentrating on the holistic picture and specifics of what they do simultaneously. They keep their attention on the outcome and try to get rid of small frictions that prevent them from reaching it.

I once worked with an engineer who mastered every shortcut in their tools only to eliminate distractions while working and focus on achieving outcomes. They were annoyed when they needed to stop and find out how to use their tool. They paused, took note of that, and the next time we worked together on something, I saw them already using a new shortcut. They didn’t brag to others about how many shortcuts they knew. They were focused on learning and adjusting everything in their work to become better and faster. They were humble.

Humility

Both the ownership and growth mindsets demand humility. People with a high bar accept setbacks and take full accountability for them. They endure reality as it is, know that there are things to improve, and never show off what they have done while still celebrating their achievements.

Humility keeps them grounded as they strive for a higher standard. It allows them to admit and study their mistakes, seek feedback even when nobody is giving it, learn from others, and stay open to new ideas. Humility prevents their ambition from turning into arrogance.

This humility also shapes how they approach their work—not with burnout-causing hustle but with a sustainable focus.

Not a Hustle Culture; It’s a Long Term Game

Hustle culture glorifies overwork, but people with a high bar know better—they play the long game and avoid working more than necessary. The growth mindset, which involves adjusting every specific detail of work to prevent distractions, focuses on eliminating distractions and maximizing impact with just enough effort.

These people work intensely when they focus but take breaks to be ready for the next round. They aim to keep their pace and sustain it for a very long time, leaving the compounding effect to play its role.

They know they must sustain their energy and momentum because the moment they touch the high bar, the bar rises—all the time—because they set the bar higher themselves. They show everyone that the high bar is an intrinsic motive, not an external one, as organizations claim.

Yet, some people need guidance to unlock this approach and understand how the high bar works. That’s where managers or coaches come in.

The Role of The Manager

Sometimes, as a manager, I hear that I am constantly raising the bar, which may make people feel like they are always trying to do more, meet an impossible task, and fulfill unattainable expectations—making them feel like Sisyphus. However, my goal isn’t just to push people harder—it’s to help them realize their potential by gradually raising expectations based on their capabilities.

When I begin working with someone new, I start by observing where they are—how they approach their craft and what they’re capable of. Once the evaluation is done, we put a high bar together—high enough that it is not impossible to reach but definitely requires a good amount of effort.

When I see them touching that bar, I raise it only if they don’t. Because my job is to show people what they are capable of. They might not know their potential, but my job is to show them what is possible when they aim right and try their best. Incrementally raising expectations helps them build confidence while unlocking their potential step by step.

Of course, there is a catch. Once I discover that their bar is lower than what I would have expected at their level (according to the organization’s career-level expectations), the improvement steps can become a big challenge. However, we set the bar low first. Once we reach that lower bar, we start increasing again.

Once a person develops this intrinsic desire and learns to work to a high bar, they unlock a new world—a journey to becoming a corps d’elite.

Ultimately, people with a high bar redefine expectations—for themselves and everyone around them. They don’t just meet standards; they set new ones and inspire others to rise alongside them.

And that’s how I define a high bar in performance.

Reply via email | Reply via Mastodon | Comment

In ambiguity, use a compass, not a map

Sat, 01 Mar 2025 11:00:00 GMT

In uncertainty, don’t seek or move with a map but with a compass. You need to be alert to your surroundings more than relying on external guidance. With a compass, you have a direction to go and must adjust yourself depending on what you find on the way. You have to discover the territory yourself. A map does not fully reflect the territory. Someone else’s path is written on the map, not yours.

Related Note(s):
- The compass of a team is their vision.

Reply via email | Reply via Mastodon | Comment

Form teams around visions

Wed, 26 Feb 2025 07:00:00 GMT

As an engineering director (or executive), compartmentalize your teams around visions. What’s your vision for the group? You’ll not have full context on anything about these teams. Don’t try gaining too deep context unless it’s absolutely needed. Once the teams are built around a vision, the group can create context and use it to achieve their mission.

Related Note(s):
- Strong teams are motivated by goals.
- Use second-order thinking to analyze the consequences of these visions and teams.

Reply via email | Reply via Mastodon | Comment

Contain a workaround in a scope

Wed, 26 Feb 2025 06:05:00 GMT

Managing workarounds in complex situations is tricky. If an engineer negotiates about building a workaround (to avoid it), you’ll always have to pay the price sooner or later. As a manager (and also a software engineer), focus on how you can contain this workaround’s impact on the project and product. Try not to spread the workaround into the whole codebase and aim to contain it. Not only contain it, but make it obvious to the next developer (and your future self) that it’s a workaround that you shouldn’t overlook.

Related Note(s):
- ADRs are a good way to record the decision about a workaround.
- Open cultures help people surface the actual cost of workarounds.
- Workarounds create accidental complexity.
- Focus on conceptual integrity to contain a workaround.

Reply via email | Reply via Mastodon | Comment

Tears fall for a reason

Wed, 26 Feb 2025 06:00:00 GMT

“Tears fall for a reason, and they are your strength, not weakness.” — The Boy, The Mole, The Fox and The Horse

Make your weakness your strength. If you cry, that doesn’t show that you’re weak. It shows that you deeply care about something. When you cry, look for what exactly you are crying for. Once you find it, that’s your strength. Embrace it and turn it into a superpower for the rest of your life.

Related Note(s):
- In public speaking, excitement or nervousness comes from the same direction.
- Crying doesn’t shake your authority.

Reply via email | Reply via Mastodon | Comment

Withholding Judgment—The Forgotten Way

Thu, 20 Feb 2025 05:05:00 GMT

In recent years, I feel like we’ve been constantly forced to choose—agree or disagree, take a side, make a decision. Silence is often interpreted as agreement. But what about when we simply can’t decide? What about the time we deliberately step back and choose the third way, the forgotten one—withholding judgment?

Withholding judgment is freedom. It’s the tasting of a bottle of wine in a restaurant. When you order a bottle, you can send the wine back after your first sip. But you hold your judgment until that moment. Even after one sip, you might need a second. You swirl the glass, breathe in the aroma, and wait for the aftertaste. This pause, this act of holding back, isn’t indecision—it’s a deliberate choice until you gather enough information to decide confidently.

Withholding judgment offers us a chance to pause, assess, and experiment. It’s about opening the door to discovering overlooked possibilities and making better decisions in the long run. We must collect data and information to understand before forming any conclusions.

Any critical judgment demands a comprehensive understanding. This is also what Mortimer Adler captured perfectly in 1940, in his excellent book How to Read A Book:

You must be able to say, with reasonable certainty, “I understand,” before you can say any of the following things: “I agree,” or “I disagree,” or “I suspend judgment.” These three remarks exhaust all the critical positions you can take.

Adler’s insight is as relevant now as ever. We must pause and examine arguments holistically—not to agree or disagree but to understand them truly. This principle is especially crucial in today’s world, where the flow of information is rapid, overwhelming, and often misleading.

The Information Problem

How and where we gather information directly shapes the decisions we make. For decades, traditional media has been driving the direction of public belief, often mixing truths with half-truths and outright lies. Today, the Internet has taken its place as the medium, but it has inherited—and amplified—these same flaws. “The Internet,” as George Packer warns in The Atlantic, “which promised to give everyone information and a voice, has consolidated in just a few hands the power to destroy the very notion of objective truth.”

If objective truth is eroded once again, how can we confidently assess the decision and take steps—however small—based on what we read, hear, or watch online? The answer lies in strengthening our skepticism and remaining doubtful until the truth becomes undeniable.

This is easier said than done. Pausing a decision and seeking the truth to make a correct assessment can be frustrating. It requires patience, effort, and, perhaps most challenging of all, the ability to question our own biases.

The Nature of Truth

The objective truth, in its purest form, is rarely spoken aloud. It simply is. Truth does not require passionate advocacy—it exists independent of our belief in it. As Robert Pirsig explains in Zen and the Art of Motorcycle Maintenance:

“No one is fanatically shouting that the sun is going to rise tomorrow. They know it’s going to rise tomorrow.”

When someone loudly insists on “the truth,” it often signals doubt disguised as conviction. By contrast, dogmatic enthusiasm is a sign of doubt dressed in certainty. Pirsig further says:

“When people are fanatically dedicated to political or religious faiths or any other kinds of dogmas or goals, it’s always because these dogmas or goals are in doubt.”

Most decisions we face are blurred by uncertainty and driven by competing narratives and opinions. The only responsible way forward is to withhold judgment through action—at least on the issues that truly matter—until we can find enough clarity to act wisely.

Finding Truth Through Action

Seeking the objective truth is overwhelming. The complexity of ideas, the amount of information, and the conflicting narratives circulating in our digital world can intimidate us. Instead of aiming to understand the entirety of a big idea at once, we can take small, deliberate steps forward—steps designed to test, learn, and uncover truths incrementally.

For instance, consider social welfare programs. Opinions about their effectiveness are often deeply divided along ideological lines. Rather than diving headfirst into partisan arguments or overwhelming ourselves with conflicting statistics, we can start by asking smaller, focused questions, such as: Which specific welfare programs exist in my country? What measurable outcomes do these programs produce (poverty reduction, health improvements, employment rates)? Armed with these questions, we can break the research into steps.

Even at work, small steps can help us uncover the unknown. Promotions are often big decisions that demand a lot of time and preparation. Imagine prematurely promoting someone only to find that they’re unfit for the role. Since we can’t reverse the promotion, a better approach would be to delegate and assign interim responsibilities, allowing them to try these responsibilities and prove their capabilities without committing to a full promotion. This way, both parties can "try before they buy."

Another way to find a more minor decision at work, especially in product development, is actually a well-known one: experimenting. Instead of overthinking, planning endlessly, writing design documents, and collecting feedback on theoretical ideas, I’m all in on quickly building something small that agrees with the decision and something else that disagrees with it (though I must admit that the latter is rarely built). Hence, we learn the best decision as soon as possible and can refine our path.

By acting cautiously and experimenting with smaller decisions, we create opportunities to challenge assumptions, gather evidence, and refine our understanding. This approach transforms uncertainty into a tool for discovery—a way to progress while withholding judgment.

There is almost always a smaller decision hidden within the larger one, waiting to be uncovered. Once we find it, we can act on it—exploring it from every angle, testing it by moving right, left, forward, and back, gathering insights and gaining confidence. Then (only then) are we equipped to agree or disagree.

Larry Page, the former CEO of Google and Alphabet and who is known for his approach to bias for action and speedy decisions, championed this approach by asking, “Why can't this be done sooner?” With that simple question, he urged people to search for decisions they can make today rather than trying to make a significant decision tomorrow. He encouraged people to avoid getting stuck in analysis and to move in a direction that approaches the truth—experimenting and learning along the way.

We must acknowledge that sometimes, we lack the energy or bandwidth to pursue any direction. It’s easier to float with others’ decisions because we’re too tired or don’t care about the consequences. In these situations, I’m a big fan of consent-based decision-making. I hold my judgment—neither agreeing nor disagreeing—and let others drive. I trust their judgment will be “good enough,” and we’ll all bear the consequences.

Still, it’s crucial to be transparent. Explicitly telling others, “I’m withholding my judgment and trusting you to decide,” prevents misunderstandings later. It ensures that no one assumes my silence equates to an agreement if I later express my disagreement.

The Freedom to Evolve

Withholding judgment today doesn’t mean we avoid decisions forever—it shifts the timeline. Critics, like many business gurus, argue that delaying any decision makes you fall behind. They think that postponing decisions allows competitors to move ahead. While we stagnate, they act. However, with this approach, we lose nothing—neither money nor time. On the contrary, we gain a lot.

By withholding judgment, we create space for learning, experimentation, and deeper understanding. It’s not about indecision but about finding the path to truth through exploration. In a world obsessed with speed and quick resolutions, we must reclaim the freedom to think, to pause, and ultimately to evolve.

Reply via email | Reply via Mastodon | Comment

You can't always have the best of the best talent

Sun, 16 Feb 2025 06:00:00 GMT

️️️You can’t have an organization made up entirely of top-of-the-top performers. While this is feasible in a small startup, larger organizations must hire a mix of average individuals and will definitely end up with lower-performing individuals. It’s crucial to understand how to develop these employees and enhance their skills, as this is essential for the growth and success of the organization. ️It’s also crucial to cut the ties when things don’t work out.

Related Note(s):
As low performer they are, they can still pursue a single goal of the organization.

Reply via email | Reply via Mastodon | Comment

How to Delegate Successfully

Tue, 04 Feb 2025 08:05:00 GMT

I had been struggling to find the right approach to delegation at work. I had made many small and big mistakes. Some have caused others frustration, and a few have cost time and financial loss. Now that I have gained experience, it’s time to share.

My most significant learning in delegation is this: a leader must delegate the work they know best or the skill they can perform well to the person who can and wants to acquire it.

It’s unintuitive. The strongest skills are often the reason someone is brought to a leadership position. Perhaps these skills helped solve a painful problem by doing a particular type of work well. Then why must they hand over that work or transfer the skill to others?

A new level was unlocked when I realized that mastering a skill and getting positive feedback constantly was a strong sign that it was time to transfer. Strong skills also make it easier to teach others how to do certain things, recognize when they need a hand, and ask the right questions when they don’t even know which questions are out there to answer.

For example, I’m a good meeting organizer when it comes to planning, standups, retrospectives, and even workshops; it is my strong suit. Moreover, I like doing these things. Organizing and facilitating these meetings well brings me joy and satisfaction as a group progresses through a successful process that results in alignment.

However, once I establish these processes, I look for people who can take over the facilitation. The facilitator's role usually includes not only moderating the meetings but also doing pre-work, preparations and communication before and after the sessions. Moreover, the responsibilities also include following up on action items and other people’s work to ensure everyone follows the agreement. Last but not least, it also includes following the process itself and suggesting improvements and changes when the process doesn’t fit reality or starts to crack for various reasons.

Since I know all these expectations and how to navigate people around them, I can mentor or coach the person I’m delegating this work to.

Yet, many people (including myself) mistake delegation for a hands-off approach or delegate the wrong tasks to the wrong people. Let’s examine each one, starting with the last.

Finding the Right Person to Delegate

You shouldn’t delegate a task just because you want to do someone a favor. Understanding whom to delegate to demands skill mapping, career development, learning organizational constraints, careful staff planning, and proper decision-making.

If you’re leading a team, you must know your team members’ career plans, backgrounds, wishes, strengths, and weaknesses. Once you know who wants to go to the next level (maybe even your position) and which skills they lack, you can work with them members and train them.

Although all of these are necessary to choose, it doesn’t start with looking at people’s skills; it begins with—counterintuitively—you, the delegator.

You have to look at yourself first and answer the questions below openly, honestly, and transparently (for yourself).

What things take up a lot of your time and are trivial to do?
What are your strengths, and which initiatives use those strengths?
How much time would you spend when you delegate? How much time do you have available for the person?
What are the results do you expect?
If someone makes a bad decision, how bad can these decisions be?

These questions address the fundamental constraints: time, goals and risks.

People rarely consider their time when delegating, but it’s the most crucial element. Delegation is not about shifting a task and forgetting it (more on that below). As everyone is busy, you have to consider your time management and find the person with whom you can spend the right amount of time for the right thing.

If one team member demands an extra hour every day when you delegate, while another might be okay with 30 minutes a week, the answer may lie in your time. However, choosing a 30-minute one is not straightforward because you’ll need to invest in people equally, and each person's constraints will be different.

Once you answer the questions, you must turn your attention to the people who you want to delegate. If you have more than one person, think about each of them one by one. Evaluate them by answering the following questions:

How much time would this person require from you?
What are the skills you have that helped you do the job so far and that the other person doesn’t have?
What are the common skills you both have that can help with the task?
How is this work aligned with the person's career development?
Can this work be exciting for the person or draining their energy?

After answering these questions, you’ll know how much time you need to invest in the person and can plan your approach.

Understanding your needs and other people’s needs within your boundaries and constraints will help you avoid the most common mistake: defaulting to a hands-off approach.

Delegation doesn’t mean shift and forget

One of my mistakes after I delegated was not thinking about the work anymore. Even though I asked the person to reach out for help when they struggled, they rarely did. This is not because we didn’t trust each other or never communicated. Quite the contrary, I trusted them too much, and—I learned too late that—they tried to live up to that trust.

When people take on new work, they usually guess how to approach it. Based on an assumption, they try seemingly effective ways to make progress. Yet, they don’t notice that their methods are unsuitable. Because they have been trusted to do the work, they try whatever they can without asking for help. They think seeking help will make them look like they fail and can’t handle the delegated work. They think it’s their fault. However, we, the delegator, made a mistake, not them.

I see delegation as enhancing someone else’s tool belt. Everyone has skills (or rather tools in this metaphor) they know how to use. However, the world is full of tools they have no idea about. Delegation is like giving someone a tool as a gift and showing them how to use it well.

The first step of delegation is giving them clear directions and letting them try and fail within a safe zone. Once they fail and succeed a few times, they learn the basics. After some practice, they can do the job in the wild and develop their own style.

But how do we evaluate how much direction, safe-zoning, and freedom the person needs?

If someone is good at moderating the sprint planning, it doesn’t mean they will know how to moderate a retrospective meeting. Although both are team rituals, they are fundamentally different. So, handing over retrospective moderation will need some help to learn the basics. That requires understanding the task-relevant maturity of the person to whom you want to delegate the work.

Task-Maturity Scale

"How often you monitor should not be based on what you believe your subordinate can do in general, but on his experience with a specific task and his prior performance with it - his task-relevant maturity__...as the subordinate's work improves over time, you should respond with a corresponding reduction in the intensity of the monitoring." — Andrew Groove, Co-founder & CEO of Intel

The main goal is to stretch the person’s skills by helping them, not burn them out. If we consider the new work on someone’s task-relevant maturity scale, it should fall into the delegation zone.

If the job is outside their comfort zone and too easy for them, it will be cumbersome and bore them out. Delegation should aim to place the skill beyond their comfort zone and before “beyond capability” because we want to mentor them first but teach a skill that needs development from the fundamentals. Beyond the delegation zone, the person is burdened instead of given help for growth.

Within the delegation zone, the person will still need different levels of help, ranging from strong mentoring to passive coaching. The caveat of the delegation zone is that it’s different for everyone. Hence, finding the right job and person match and giving them the right amount of help demands a careful approach.

Once you find the right person and have an idea about the amount of help they need, you can kick off strong.

Starting with the correct foot

At this stage, you have put in a lot of work, and it feels like you’re nearing the end. Many people rush this part, wasting all their effort.

You must set clear expectations and have a concrete conversation. The conversation has to be open, transparent, clear and genuine.

First, explain the context of the work. Provide all the background information, allow them to ask questions, and clearly answer all of them. It is crucial to explain the context, constraints, and current status.

Once they know the constraints and context, discuss your expectations and whether you need to adjust them. Expectations are always mutual. Listen to their expectations as well. Talk openly and agree together.

Define how the success looks like. If you’re delegating the leadership of a project, don’t say, “The project is completed on time and within budget.” Go beyond that and focus on how they will make it happen. If the project is a success in the end, but everyone is burned out along the way, can we call the project a big success? Clearly define what success means and help them figure out how to achieve it.

Write all of these down. Verbal communication often has cultural misunderstandings. However, once agreements are written, people come to a shared understanding. A few months later, you can look at what you’ve written and evaluate the progress clearly.

Set recurring check-ins. If you already have one-on-ones, reserve the last five minutes for them. Taking from the previous example, don’t talk about the project itself during these five minutes but more about the experience of leading it. Look back at what changed from the last check-in, how the person has improved, and whether there is anything they can do better, need extra support, or need changes in expectations.

Conclusion

When leaders devote too much time to their strong skills, they don’t learn at work, which increases their dissatisfaction. They also limit their impact; instead of focusing on the bigger picture, they get stuck on smaller initiatives. They fear delegation will take their jobs away or make them dormant.

Just because they don’t know how or what to delegate, they keep doing whatever they are good at. However, the other side of the road is a path to increasing impact and job satisfaction. Once learned, delegation unlocks many different opportunities.

Although I discussed what I learned from my mistakes, you’ll still have to make yours. Without mistakes, there is no learning. And don’t forget: Everyone has a right to fail, including me, you, and the person you delegate the task to.

Reply via email | Reply via Mastodon | Comment

Bridging the Gap: Understanding the Illusion of Transparency in Communication

Tue, 28 Jan 2025 06:30:00 GMT

How many times has someone asked you, “What do you mean?” How many times did you think you described everything clearly, but it turned out that you couldn’t and had to take a different way to explain it?

How many times have you supposed everyone feels how nervous you are when you’re speaking to a group but they actually had no clue in the end? How many times did you think everybody saw how stressful you were before that meeting?

Those were the moments where you firsthand experienced the illusion of transparency. Until someone loudly asked you to rephrase what you said, you thought your sentences all made sense. Yet, they didn’t. Until somebody told you that you nailed the presentation and looked very calm, you thought everyone heard your inner voice and understood your nervousness. Yet, nobody had a clue.

When we talk, we think that everyone understands what we think, how we feel and what we intend. We feel all the spotlights on us, making our inner thoughts, feelings, and struggles clear as a day, and everyone grasps every word we say.

The gap between our subjective experience and how others perceive our thoughts and interpret our emotions is called the illusion of transparency. It’s the distance between our internal world and how people around us perceive it.

Understanding the illusion of transparency and the size of that gap determines our ability to navigate otherwise challenging situations. It’s beneficial at work and in our relationships. Acknowledging others who don’t have a clue about what we think and feel forces us to create more transparent communication.

It’s similar when we look at someone from the outside. Knowing that they struggle with the same things helps us build empathy. If we nudge others to narrow the gap caused by this illusion, we will understand them more clearly. Asking, “Are you okay?” when they feel down might not be enough. Our friend may not tell us while screaming inside to seek a hand. Besides personal relationships, empathy also helps at work, especially when dealing with difficult feedback.

Our Rules vs. The Rules

Two members of the Harvard Negotiation Project, Sheila Heen and Douglas Stone, focused on understanding and resolving the most complex negotiations around the world. They found out why people often can’t think straight when emotions are high. In their book Thanks for the Feedback, they explain how we fall into a trap when we confuse the rules.

One of the negotiating moments is exchanging negative feedback. We approach feedback with rules in our heads—what we think is right and how wrong the other person is. While receiving feedback, we pass it through our internal filters using our rules. We confuse the rules because we think that our rules are not only our rules but the rules.

We also think that our rules should be obvious. We act according to these rules; it was all our intention. So, why do people see them differently? Because there is a gap between our intentions and behaviors and how they impact others.

Everyone has values. From these values, we form thoughts. From our values and formed thoughts, we build intentions. All three come together and create our rules. We behave with these rules in any environment.

How we perceive our rules determines the differences in our subjective experiences and others’ perceptions. If we consider our rules the truth, we harm our relationships because nobody can follow them; everyone has their own. The only thing we can do is focus on what we can change—what’s in our heads.

Control, Influence, and Concern

In life, many things spontaneously and simultaneously happen around us. The sun shines or rain drops; a new pandemic starts; our relationships sometimes get worse, sometimes better; work becomes stressful or calm; we become sick or get healthier. As John Lennon says, “Life is what happens to you while you're busy making other plans.” The majority of events are outside of our control. However, there are some we can impact.

Stephen Covey, the author of 7 Habits of Highly Effective People, conceptualized the Circles of Influence. The outer circle is the circle of concern: things we have no control over, like natural disasters happening, war breaking out, a football team winning a championship, or Lewis Hamilton joining the Ferrari team. This circle is the biggest circle of all. The majority of what’s going on belongs here.

In the middle circle, the circle of influence, we have things we can influence for change, like our relationships, how we work, or winning the match in the team we’re playing in. Although we have no power over every piece of it, we can definitely influence the result.

In the inner circle, the circle of control, we can control everything, like the kindness we display to a random stranger, how we interpret someone’s reaction, what we eat at breakfast, our thoughts, beliefs, the TV channel we watch, and the newspaper we buy. We have power over all of them and can change or stop at any time.

The rules in our heads—the ones we confuse as everyone else's rules—live in the circle of control. Although we can’t change how people perceive our behaviors or actions, we can control how we behave and definitely control the narratives we create inside our heads.

Narratives and Self-Control

Considering the illusion of transparency—how people can’t perceive what we experience—we can focus on what we can control and not be victims of the narrative fallacy.

The narrative fallacy is the human tendency to create stories or logical explanations for events even when these stories have no basis in fact. We tend to produce tales to make sense of the world.

When we receive that negative feedback, our brains create chaos and build the worst narrative we can think of. Moreover, we consider it the truth. We may not control these thoughts on the spot. However, knowing the narrative fallacy and illusion of transparency already helps us notice our patterns. When we don’t immediately react to feedback and ask a few clarifying questions, we can prevent our inner narratives from shaping in the wrong direction.

Even when giving negative feedback, we can be aware of people’s tendencies and clearly explain our intentions and thoughts so that others don’t become victims of the narrative fallacy.

While giving a presentation, if we’re feeling stressed and nobody recognizes that due to the illusion of transparency, our stress would have no basis. In the end, the only thing we can control is our thoughts, not what people think. When we control ourselves, we act in alignment with our values and aim to eliminate illusions by explaining our thoughts and feelings clearly. Meanwhile, we can influence others by asking questions about their intentions, thoughts and feelings, helping them destroy their illusions and preventing ourselves from forming incorrect narratives.

Noticing alone prevents narrative fallacy and the illusion of transparency. When we see the gap and actively work to close it, we improve relationships. Better relationships and clear communication lead to trust and build success. When we focus on what we can control, we can define our success through a transparent perspective, clear communication, and trustful relationships. In challenging situations, nothing can prevent us from creating a narrative that we share with everyone transparently. In the end, success is just another perception of reality. How that reality looks is in our hands.

Reply via email | Reply via Mastodon | Comment

Influence—Book Review, Summary and Notes

Tue, 28 Jan 2025 06:00:00 GMT

The Review

It is one of the fundamental books everyone should read to understand how various marketers, salespeople, etc, have influenced them.

I loved every chapter more than the one before. The majority of the book applies to everything we buy daily and to our relationships at work and home.

Before reading the book, I had been thinking about some of the concepts for a while. I can recognize some automatic behaviors, try to be mindful, and improve my decision-making. However, I wasn't able to name what I was trying to do, and I didn't know the methods at all; it was all trial and error for me. Not anymore.

Now, I know at least a few influence techniques used on me. I recognize them day-to-day more and try not to fall into them if I realize the action is fabricated to exploit my automatic behavior. Once I do, I make a better decision.

Although it's a fantastic book, I started the book three times from scratch. First, I did inspectional reading (mainly systematic skimming), then analytical reading. I went back and forth, trying to understand what it told me, judge it, and reflect on my life.

Hence, it took me six months to read this book. In spite of the stories being entertaining, the book is not a page-turner. It's not difficult to read from a language perspective but a challenge from an intellectual perspective. Learning a new thing every few pages was definitely rewarding, though.

It's a phenomenal book, and I recommend that everyone have it, read it, digest it, and re-read it again and again.

Chapter 1: Levers of Influence

Click and Run

To cope with the current world's complexity, humans have built shortcuts, stereotypes, and rules of thumb to save time and energy. These create automatic responses or triggers that we can't control.

One of humans' "click and run” commands is triggered when a reason is given right after a request. Just adding the word “because” activates the mechanism in people's minds, and they obey the request. The reason doesn't really matter. We can say, “Can I pass you in the line because I'm in a hurry?” or even, “Can I pass because I need to pass?” Both will result in the same.

Perceptual Contrast

Contrast principle: We compare things with our first reactions. Our first reaction to something decides our judgment on the next similar thing. For example, if we see an expensive car first, buying a cheap car will be less desirable. However, if we look at an affordable car first, buying an expensive one will be more desirable, and we'll value that expensive car less in terms of money; it won't look that expensive.

Chapter 2: Reciprocation

The Rule of Reciprocation

“We should try to repay what another person provided us.”

The rule is so strong that it overwhelms the influence factor (whether you like the person or not).

Customized Favor Works Better

The Rule of Reciprocation works better when the initial favor is customized to the person's needs, especially when the influencer takes extra steps to fix a broken situation. When compared to having that situation proactively fixed, this broken situation may play better if handled correctly. This is where customer satisfaction works well after people reach out to customer support for the broken products; if they get a replacement or something to cover their needs, they are more likely to return the favor by purchasing more (when compared to having the non-broken product in the first place).

This customization power of the reciprocation rule makes it exploitable. The small first favor can force people to give even greater favors in return. By nature, we want to return the favor, and if the first favor was coming out of nowhere and fulfilled our needs, we take great distance to repay the debt and find ourselves paying 500% extra just to conform to the rule and not be seen as cheap or taker in the society. It is also making us part of the group/community.

Small Sacrifice to Reverse the Rule of Reciprocation

We don't have to give the first thing to get back something. We can also make a small sacrifice from our initial request, and then that forces the rule of reciprocation on the other side, so they also make a sacrifice. Even when they do something they don't want at all, they still obey and do that smaller favor. In this case, the person who makes the first request wins anyway. This can also be exploited or may not work in every case.

Exploiting reciprocation rule

The rule can be exploited or used by making the first request extra big or unacceptable. When the other person rejects the offer, they can accept the originally planned request. So, when asking about a favor that the other side might reject, exaggerate the initial request so your first request can be declined and you retreat to the original request. Then, the other side will retreat and likely accept your offer, which is what you wanted in the first place.

Reject and Retreat

The reject-and-retreat mechanism looks like manipulating others, and the other person might feel like a victim and not trust the person using the reject-and-retreat mechanism. However, all the parties in the research seem to be more satisfied with the approach. People feel they get fair treatment, and they also comply with future requests even more. A good example is blood donation: it's used to collect blood on school campuses. Students were asked to donate blood twice a year for three years and then retreated to once only. During the donation, they were asked to give phone numbers to be contacted next year. The majority complied compared to the control group.

Exploit the reciprocation exploiter

When we receive a favor or reciprocation, we can accept the first gift and reject the rest once we identify that the first favor was used as a trick. Once we understand that it's a trick, the rule of reciprocation doesn't apply, and we don't feel obligated to pay back the favor or debt we accumulated. In short, if people exploit the rule, we can also exploit the exploiters.

Chapter 3: Liking

Commercials exploit our friendships in any possible way. There is a simple rule. We like the things our friends recommend (or people we like, not necessarily friends). When we know that our purchase will benefit our friend in some way, we take the extra mile to help. Also, that's why many celebrities are in the ads and recommend the product; we are more likely to buy just because we like the famous person. Moreover, when people try to sell someone or a doctor doing something to someone, they become more successful if the other side likes them.

A salesperson who is liked and can offer a fair price is the best. A doctor is never sued with the “I really like the doctor, but I want to sue them” phrase. Who destroys or goes against someone they like?

Physical Attractiveness

Good-looking people enjoy a significant amount of social advantage. They are always associated with better traits and receive more help when compared to others. Whether we like it or not, the result came out of as a result of many studies.

Similarity

We like people similar to us. When people know the similarities between each other, they get along well. When people make decisions, they tend to lean on the side they like, relate or find similarities. That's also why so many ads use popular faces to associate their brand image with their likeness. It's also why testimonials work too! People can relate if they see someone similar using the same product, and they are more likely to buy it.

Compliments

When we receive a compliment from someone, we tend to like them more, regardless of whether the compliment is genuine or an obvious suck-up. It's also visible in job interviews. When an interviewee compliments something on the interviewer, they are more likely to pass the interview.

Compliments help to perfect someone's occasional good behavior. If they are doing something at an 80% level, complimenting them boosts their performance to 100%. They will try to do more of what others complimented. But make these compliments not on the behavior but on the trait. Be genuine and find compliments the person will live up to. (Hawthorne Effect?)

More Contact Generate Likeness

We like people we have more contact with. Repeating the same lie again and again can result in people believing in it. In the same way, the more contact points we have with people who are unlike us, the more we begin liking them. This is also observed in groups. The real rival groups only start seeing each other as friends after they cooperate on things together. We see this in football fans who unite and work for charity. The cooperation resolves all rivalry. We can use the liking principle by bringing people together and giving them tasks to resolve together. However, the task should require contributions from both sides. Collaboration is key. Moreover, we like people who are willing to cooperate with us.

Association of Good and Bad Things

We associate unrelated things with people. Similar to Pavlov's association of bells and food, humans associate good and bad things with people even when they have no relationship to an event. For example, bad weather and natural disasters are caused by nature. Still, due to weather forecasts being presented on TV, people relate these events to the presenter, who now isn't liked anymore because of the bad weather. Moreover, we associate good things with ourselves while pushing bad results away. Good examples are football fans associating wins with themselves while losing is always the team's mistake. This association is everywhere. If you have good and liked friends, you'll be liked too. If you've bad guys befriended, you'll be assumed bad, too.

Defense for Liking Influence

There is no easy way to find all techniques that are used to increase the likeness of a person and block these methods one by one. Instead, we can allow these methods to work, and right before making a decision, we should ask ourselves, “Do I like this salesperson more than I would have expected?” If the answer is yes, then we know there was something. Then, we can/should separate the decision from how much likeness the person has. Mentally separating the offer and the person does the trick. This should be the way we make any decision with money. In each decision, having more rationale than feelings is better.

Additional: Is it the same with leaders? Do we agree more with leaders we like?

Chapter 4: Social Proof

95% of the people are followers of others who are called initiators, and this number falls into the 5% category. Initiators start a trend, an idea, or an ideology, and if they convince enough people, they can become greater. The more people find the idea correct (or good), the more the idea is conceived to be correct. That is how social proof works. Initiators convince enough people to make any idea correct, and those, in turn, make it even easier for newcomers to believe the idea as they see many people think it's correct.

Peer-suasion

We tend to do things others who are similar to us do. The per-suasion is a strong driver. We want to be in the pack and conform to societal behaviors. But not with everyone. We follow people who are like us. For example, we buy similar stuff as a married couple if the other couple buys something. This is also true when we want to convince others to do a thing. I also observed this as a manager. When I mention someone in my team that their peer is also doing something I appreciate, they are more likely to follow it and replicate the behavior. When compared with something I do, they rarely follow me. Peers have more impact than me doing it.

Defense Against Social Proof

When exploiters use social proof, we can and should go to these exploiters' websites and force them to reveal that they used techniques to fool the crowd to lure them to their products. Moreover, if we are in line to get something just because there is a crowd, we can look around and ask ourselves why we are there. Are we driven by social influence or by our authentic desire to get that thing? I use this in real life a lot. Many testimonials, product reviews, and queues in front of restaurants/cafés don't come real to me until I taste the food myself. It's social proof that plays a significant role. Since I also stopped using social media and following popular culture, I can safely say I employed many techniques already. Yet, it's good to be aware of many other cases where exploiters use social proof to drive people to products. The main thing is always stopping for a moment and asking ourselves, “Do I really want this? Is this true? Do these people really want to be here?”

Chapter 5: Authority

People, willingly or not, follow authority figures. Sometimes even in a blind fashion. A strong authority figure who is perceived as an expert can make others follow orders without any thinking. I also see this at work and social life. At work, I see that people follow my authority as an engineering manager of the team, even if I am not an expert on the technology of my team. Even sometimes, my decisions are questionable, but people follow them. I also see detriments of it. My team follows what I'm saying sometimes without thinking by themselves (or sharing those thoughts with me). However, authority doesn't work when it is with command—ordering people to do things generates resentment. The authority should lead by being highly informed about the work and domain. Establishing authority also requires showing some vulnerability (otherwise, people don't believe), especially in the beginning, to build trust. Accepting failure and acknowledging mistakes help build trust and people follow the authority more.

Defending Against Authority

To defend ourselves from following the authority, we can ask two questions:

Is this authority truly an expert on the topic?
How truthful can we expect this authority to be?

These questions will help with purchasing products in the right way, getting the correct feedback from our leaders at work, and making better decisions.

Chapter 6: Scarcity

Especially under risk & uncertainty, people will try to avoid losing a thing compared to obtaining that thing in the first place. I can see this in the pandemic era when people hoarded a lot of stuff with the psychology that they won't be available anymore. Hoarding eventually led to unavailability and increased prices.

Moreover, this also applies to anything becoming less available than before or our access becoming limited to it; we desire that thing more than before. I can see this in my reaction to the decision to return to the office at work, where I desired to work remotely even more, though I had been going to the office for more than three days already.

New Scarcity

Most of the riots in black history started after blacks were granted more rights and then lost them again. Although the comparison is unfair, I observe a similar reaction when companies withdraw privileges they granted before, such as returning to the office after years of remote work practices. That is the strong scarcity principle: once granted or accessed, it is lost, and emotions build up to get it again.

Rivalry Makes Scarcity Stronger

Scarcity works even stronger in the presence of rivalry. When someone else wants the same thing that we barely wish to have, we desire it more in the presence of rivalry. Now, a scarce item becomes even more scarce because someone else has acquired it. We race it to own it and value it even higher.

Defending Against Scarcity

Defending against scarcity (in combination with rivalry) becomes difficult due to the emotions involved. Moreover, we mix up the value of the thing with us having the thing. The value of us having, eating, drinking, or using the thing doesn't change. However, our arousal to that thing increases. We need to listen to our emotions and try to separate them from each other. Once we understand scarcity principles are at play, we can recognize the value we put and eliminate the desire to own that thing.

Chapter 7: Commitment and Consistency

We automatically have to stay consistent. Sometimes, it's to our detriment, like staying stubborn in situations where we need to change our thoughts/behaviors. Sometimes, it's used against us, like asking for a small commitment to do something (trivial donation to something) and then getting a more significant request that supports the previous trivial commitment and makes it much bigger. We, whether we want it or not, try to stay consistent with our previous behavior. I see this as not really-willing-to-change people at work. Also, leaders (including me) remain the same, doing the same things the same way over and over again.

I think I can also use this at work to influence others when I need to drive decisions or projects. Not in an exploiting way to harm, but rather make things easier for everyone.

Defending Against Consistency Exploitation

When we find ourselves in a situation in which we made a small commitment earlier and are now trapped in a bigger one, we can listen in to our stomach, which gives signs about the trap. We feel it in our gut, and if we listen to it, we can leverage it to get out of the commitment. Another sign is listening to our heart of heart. Asking ourselves, “Knowing what I know now, if I go back in time, would I make the same choice again?” and if the answer is no, we can pull ourselves out.

Commitment is often used on older people who tend to follow their commitments more. Also, in individualistic cultures like the US and Western Europe, people individually decide on consistency.

Chapter 8: Unity

Politics, sports and personal relationships are heavily influenced by one principle: unity (and loyalty). This has also been used in business. We buy from places where we feel that the salesperson is “one of us.” We favor political parties that signal as one of us rather than their success and concrete plans. In sports, fans follow their team and are more partisan if there is a stronger sense of loyalty to other fans involved. Moreover, all these unities also alter our behavior. We do similar things as part of the group. The stronger our friendship or relationship, the stronger we influence people's behavior on our own.

Belonging Together Creates A Unity

The unity feelings can come from two categories: belonging together and acting together. With kinship and closeness in location, we feel united with our kin, people with whom we share genetics. But genetics is one source of this feeling; similar looking people also feel united under different umbrellas (through shared genetics in a distance). Moreover, the place or proximity to others forms a unity. When we open our homes to a few people, they feel closer because our homes are reserved for family. Welcoming them tells us that they are one of us. Inviting people gradually helps to form this feeling of closeness. Moreover, we also feel close and united if we share a common geological region of birth.

Acting Together Unites People

When we act together in sync, we start to like each other more and feel united. Whether dancing together, singing to the same song or suffering together. Especially when we do those in synchronous or complementary to each other, we feel more united. That's why military marches have to be in perfect sync, or businesses organize team events that require members to act together in sync and help each other to reach the finish line. Moreover, we like people who ask us for advice. When a waiter gives advice on which food to choose today, we also consider them on our side as one of us.

Co-residence Unites People

Length of co-residence helps to feel united. The longer we stay in the same household, the more we unite. The same goes for kids and their friends. If we invite kids to our house, they shouldn't be different from our kids; everybody should have the same responsibility to enhance unity feeling. The guest kid should also do chores and feel no different. The same is valid for adults, too. If we invite them for dinner, when they help set the table, they feel more united and closer.

United Diversely

People living in diverse neighborhoods feel more united as humans and are less prejudiced toward others. Not only in neighborhoods but also having a friend or someone closer helps reduce this prejudice and increases empathy, making it easy to unite with others. This unity doesn't even need to have a friend around; only putting ourselves in someone else's shoes increases the feeling of unity—a small step toward changing the world around us.

Chapter 9: Instant Influence

Technology evolved faster than our automatic responses. Our age is called the “Information Age,” not the “Knowledge Age,” for a reason. For any information to turn into knowledge, it has to be processed, digested, comprehended and integrated.

While we try to adapt to advancements, our brains and primitive automatic behaviors will try to use every shortcut possible. Due to the ever-growing information, these shortcuts will also increase proportionally with the cognitive overload in society.

We'll make decisions based on these automatic behaviors, and we need to be aware of their influence. Compliance practitioners (such as marketing and salespeople) will continue to try to abuse these behaviors. These automatic behaviors are not always exploitative. They are only harmful when they are fabricated instead of occurring naturally. It's crucial to separate the composed ones and reverse the effect.

Reply via email | Reply via Mastodon | Comment

Seek diversity

Sat, 25 Jan 2025 05:35:01 GMT

Tolerance and improving diverse living are not that difficult. They only require empathy. Putting ourselves in someone else’s shoes and trying to understand them already unites us as people. Moreover, if there are more diverse people in our neighborhood, we will unite with them more quickly and reduce or eliminate the prejudices we build in our heads because we belong to a neighborhood. Once we have things in common, it becomes easier to unite and feel comfortable.

Related Note(s):
- Authority figures must live in diverse neighborhoods. Often, they don't, and we face discrimination.
- Forming a neighborhood community in which people share responsibilities helps build a diverse living.

Reply via email | Reply via Mastodon | Comment

Helping with chores improves relationships

Fri, 24 Jan 2025 05:39:01 GMT

Homes are sacred places that belong to the closest family. When we feel closest to someone, it is the time we share residence. When we invite friends to our homes, they are already one step closer to uniting with us. When we want to get even closer, we can involve them in setting the table during dinners. It shows that (and makes them feel like) they are part of the family as they help. Sharing some chores belongs to co-residents and family. With a small gesture, we tell them we see the guests as part of the family. They also begin to be comfortable and share their feeling. That feeling remains for a long time.

Related Note(s):
- Asking guests to help might sound disturbing, but most of the joy comes from seeking inconvenience.

Reply via email | Reply via Mastodon | Comment

Acting together improves group cohesion

Wed, 22 Jan 2025 05:39:01 GMT

While doing things with others is already helpful in forming better relationships, doing things in synchronized movements like dancing or singing unites people even further. Doing synchronized activities brings people closer as they share the moment. That’s why all national anthems are sung out loud together, and armies march in perfect synchronization. The same is true for teams. Team events that require synchronized acting or even acting only get people closer. They find a common ground and feel they belong.

Related Note(s):
- In cross-culture culture collaborations, organize team events to increase team cohesion.
- When you do reorg, find activities that people need to act together to succeed.

Reply via email | Reply via Mastodon | Comment

Engineering Managers Leading a Big Project—Step by Step

Tue, 21 Jan 2025 08:30:00 GMT

When I peaked into the engineering management role, one of my biggest challenges was learning how to lead projects involving multiple teams.

Delivering a project from scratch to production is a big challenge, especially for big organizations. It takes months to move a needle due to the complexity. Clarifying the why and the what, identifying risks, setting expectations, and convincing people require a lot of time.

Although it can be overwhelming, there are strategies to ease the burden and organize this complexity. Many organizations expect Engineering Managers (EM) to develop strategies so they can lead complex projects. EMs learn how to fulfill these expectations over time.

When software engineers grow into senior roles, they are expected to deliver on their promises and divide the work into smaller pieces so that others can understand the scope and what needs to be done. They are expected to develop these skills further when they become EMs. Instead of splitting tasks into smaller pieces, they begin leading complicated projects and dividing the work into ambiguous chunks for which senior engineers can take responsibility.

Then, when projects involve many departments, EM’s job becomes understanding complexity and creating a high-level solution. This leaves some ambiguity for the teams to pick up, investigate, organize, and start working on.

I learned that once leading a complex project across a few teams becomes the responsibility, the work differs from leading a project with a single team. From then on, it focuses on setting and fulfilling expectations, clarifying open questions, driving other engineering leaders to shape up target software architecture, aligning timelines, prioritizing, negotiating, adapting to changes, and managing communication.

EMs are bridges between stakeholders, product managers, designers, and engineers. They guide engineers by helping them design better solutions, ensuring the right collaboration model is in place, and ensuring the team implements them in the correct order. They support product managers by providing input about feasibility, challenging their approach, de-risking the identified risks, raising the later-discovered unknowns during implementation and adjusting the course accordingly. They help other stakeholders by coordinating the work and constantly communicating progress.

How they do all of these things will depend on the organization. Some organizations rely on meetings to coordinate the work; some coordinate everything over spreadsheets, emails, or chat apps like Slack; some choose a mix; and some do everything via written and asynchronous communication. Regardless of the approach, EM’s job boils down to managing delivery, as their success is measured by what their team(s) deliver.

Success starts with knowing the fundamentals of project management.

Project Management

If there were a few silver bullets in project management, they would be to ensure everyone has the same understanding of the current status, find risks early and manage dependencies well.

Although all project management frameworks (Scrum, Kanban, Scrumban, Lean, etc.) aim to address those silver bullets in one way or another, what matters for an EM is when and how to choose one. As messing up on a project is a scary experience, I recommend learning different frameworks and discovering commonalities, having a conversation with an experienced peer in the same organization and asking for advice. Moreover, aligning with the leading product manager (PM) or product owner (PO) is the first and most fundamental step.

My perspective changed most significantly when I first aligned with the product and design counterparts on how we distribute the work between ourselves. As EMs can't lead projects without these partners, setting the expectations right in the first place makes a lot of things easier.

Agreeing on how we’ll manage the project is crucial because we’ll focus on the product and the problem together with them.

Product and Problem

Solving a problem end to end is a team effort; it doesn’t belong solely to anyone. Product and design teams often handle documents like product requirements documents, press releases, user story mapping, wireframe designs, etc., that explain what a product or feature should do in detail. These artifacts are the guideposts for understanding how everything should work from the user’s side. EM’s job is to explain the problem from a delivery perspective—the how part of the problem.

EMs focus on solving implementation problems, determining whether more feasible solutions exist and providing feedback to product and design teams so that they can adjust their solutions.

Pragmatic Approach to Problem Solution

The problem on the delivery side often starts with unraveling the details of technical solutions. While not all questions have to be addressed upfront, those considering how applications and systems will work together and how to avoid making any system or team a bottleneck should be answered.

This initial feasibility discovery should include a high-level technical design that shows what needs to be changed and where the significant risks are. If the risks need to be eliminated, the EM organizes further discovery with engineers to find a solution. However, it’s okay to lack some of the details on how the feature will be implemented in individual applications and systems. That part needs to be resolved within the specific team.

Together with the EM, a staff+ engineer can lead the system design. EM brings a complete understanding of the product and organizational context, and the staff+ engineer brings complete technical expertise. Furthermore, the EM can challenge engineers to find the best possible approach. Together, they can distribute the work into teams and decide on the parallelization and sequentialization of the implementation.

When each team starts implementing, engineers discover various challenges. As EMs can’t foresee every possible question before the implementation begins, they coordinate the product, design, and other counterparts and work with the engineers to answer each question.

EMs are at the center of all collaboration, primarily coordinating people and challenging solutions from a product and engineering perspective. As this work requires a lot of them, delegation and strong communication are the keys to success.

Delegation

An EM needs to delegate system design to engineers, implementation to teams, and problem-solving to others. Their job is to coordinate and resolve risks by guiding people to a solution and managing communication. Without proper delegation, none of these will ever work.

However, it’s common for EMs to manage everything themselves, try to be everywhere and have a say in every tiny decision, as their name is on the project’s success. This approach is a recipe for disaster. If every decision needs to involve them, they become a bottleneck.

I want to leave the topic of how and what to delegate for another post (edit: the post is here), but I want to mention a few essential things. While delegating, EMs should ensure that the expectations are clear and that the other side understands what needs to be done and the timeframe. EMs must answer every question when they delegate. Also, they must set enough guardrails; others must drive the work, but it’s okay to have a certain level of protection from possible mistakes.

After delegating work to the teams and other individuals, the work evolves into full coordination and managing communication as the project progresses.

Managing Communication and Progress

Unstructured communication is the real chaos-maker. When there is no information and communication structure, information flows in free form—the worst of all possible scenarios. Everyone has a little piece of information that the others don’t. They share the information in various mediums, and it turns into a game where you say the word from ear to ear, and what you hear in the end is different.

That’s why EMs must manage communication. They don’t always have to be in the room or attend all meetings. Yet, they must follow up, hold people accountable, share outcomes, progress, and problems with everyone and guide and redirect all information so that it accumulates in one place.

I use a living document to merge all information and links and make it a go-to document for all delivery-related topics until the project ends. Unlike the product requirements document describing the problem and what we are aiming for from the user’s perspective, the delivery document focuses on how we’ll approach the solution more concretely. It splits the project into milestones and clearly identifies what needs to be done and what is out of scope. Its purpose is to merge the information that has an impact on multiple work streams. It’s a go-to document when someone has a question about the how part of the project (not the what and definitely not the why part).

The delivery document is also a communication tool for stakeholders. When the project kicks off, it becomes the go-to document for all stakeholders to grasp the project’s current status, latest timeline, risks, open and answered questions, and all the necessary reference documents from a single place. However, delivery documents don’t keep track of the status of all the small tasks; that’s the job of a delivery board.

The delivery board is simple and has four columns: Backlog, Blocked, In Progress, and Done. It includes all tasks that are in teams’ roadmaps. The board’s goal is to give an idea about the progress of each team’s tasks without asking them to share a status update. I create a custom dashboard on Jira and ask all teams to label their Jira tickets with a specific label to make it easy to follow the tasks on the board. I’m sure other project management software has a similar functionality.

Conclusion

This approach may look like a waterfall, not agile, to some people. However, if you’re working with six or seven teams to deliver a project, you must manage the organization and communication overhead and find risks early by doing discovery work. Some organizations have program managers or release managers to do this job. If you don’t have one, this often falls on the shoulders of engineering managers (ideally partnering with product managers).

Although the responsibilities of an engineering manager differ from organization to organization, leading large projects is a core skill for any EM to develop.

Reply via email | Reply via Mastodon | Comment

People unite behind a common goal

Sun, 19 Jan 2025 06:42:00 GMT

One of the main reasons for the importance of teams in organizations is the sense of unity behind a common goal. When the goal (or other reasons for uniting people) are not apparent, people start going after one another. However, once they merge behind a common goal and feel “the whole team is one of them,” they do and achieve remarkable things. Moreover, people feel united and do more for the group. They go the extra mile and go out of their way to help others in the team.

Related Note(s):
- If you join a new team, audit in three pillars to understand how they formed unity by doing things together. Find what keeps them together.
- When structuring teams in an organization, try to find common elements between team members before putting them on the same team.

Reply via email | Reply via Mastodon | Comment

Too much collaboration is detrimental

Fri, 17 Jan 2025 00:00:00 GMT

Too much collaboration is detrimental.

Many leaders constantly recommend or guide their teams to collaborate closely with other teams. I know they have good intentions, but that’s harmful.

Good collaboration has a scope and time limits. If we give two groups of people a common goal to achieve, they “become” one team and can achieve remarkable results. However, if we tell a team to collaborate with five others simultaneously, that’s nothing besides chaos.

Great solutions require focus and dedicated effort. To achieve great results, you have to eliminate distractions.

Many leaders use Team Topologies to promote collaboration and fall into the trap of having strong collaborations with many teams. However, Manuel Pais and Matthew Skelton say in their book that there shouldn’t be an active collaboration with five teams.

If you want to streamline your team and resolve the puzzles, aim to minimize cross-team collaboration and reduce the scope of each collaboration, establish clear domain boundaries and reduce people's cognitive load.

Reply via email | Reply via Mastodon | Comment

Seek Goals That Will Change How You Live

Tue, 07 Jan 2025 09:30:00 GMT

While I was writing about goals for the first time, I challenged myself to reconsider the concept of goal setting. I tried setting goals in different ways and failed in almost all of them. During these four years, all my failures taught me a lot. Now, I know what I did wrong.

I’ll share with you how to negotiate with yourself to set the right goals. This post will also be a note for me to visit again and remind myself how the system works.

Everything starts with setting the right mindset around goals.

The Right Mindset

I learned that suffering is the source of happiness. This is counterintuitive, but we value things more when we bear the ups and downs of them. Think about a challenging process you went through, such as getting a new job or learning a new skill as a hobby. During the process, things might feel frustrating, but when we make it, it feels great. Our commitment and the distress we endure is directly proportional to the intrinsic value we assign to it. Hence, we feel happier when we spend our time with whatever we value more.

Besides happiness, success and achieving goals are unrelated. I can fail all my goals and consider myself successful. These two are entirely irrelevant even though society pushes us to attach them together more. A goal aims at the process within a timeframe; success aims at the definition of identity and feelings. A goal is a short-term investment, while success is a long-term personality trait. Therefore, a goal that says, “improve A by X% in Y months,” is not a definition of success, but it’s a progression.

Without tracking, we can’t judge the progress. Tracking goals is more important than achieving them. The primary purpose of having a goal is to track progress and adjust to changes; that’s it. Achieving the goals is in the second or third plan compared to monitoring progress. Tracking progress constantly reminds our brains to do something about it because tracking goals helps us build our identity.

In the two paragraphs above, I said that the definition of success should be separated from achieving goals. However, when goals are used correctly, they are powerful enough to form an identity. If I define an objective for myself that says, “Become a writer,” I add a new identity to myself. Although it’s not a great goal itself (we’ll learn below why), I can define specific sub-goals aligned with this identity, such as “publish 40 blog articles in 2025.” The magic happens when I call myself a writer. My brain automatically thinks: “What do writers do? They write. If I’m a writer, then I should write, too,” and I find myself writing this newsletter. Ta-da!

Now that we have established the mindset, let’s learn how to define goals.

Defining Goals

How we define goals changes the result and the success rate.

Define goals that will form habits rather than ones you’ll complete and forget about. Instead of saying, “I will read 20 books in 2025,” turn it into, “I will read >20 mins a day for 300 days.” If your reading speed is average, 20 minutes a day will quickly bring you ~20 books in a year. This way, the goal doesn’t seem too far, and carving out 20 minutes daily is easier than dealing with 20 books. In the end, you also form a habit that will stick with you for the rest of your life.

If you recognize it, I didn’t say to read for 20 minutes every day; I capped it at 300 days. While reading about economics and psychology, I learned about the margin of safety or margin of error. There should be a buffer on the goal for setbacks. Instead of, “Write every day in 2025,” which will be unsuccessful on the first day you skip writing for any reason, say, “Write for more than 300 days in 2025.” The remaining 65 days will be the margin of safety. Skipping three days a month or a whole month will still bring achievement.

Keep the goals as small as possible and as ambitious as necessary. What matters is the habits you form and the constant output it brings. If you’re not reading books at all, start by setting a goal for 5 minutes or a page a day instead of 20 minutes. The Kaizen way suggests that it should be so small that you have no option but to do it. For example, I started flossing one tooth a day years ago; that was my goal. It was so tiny that I could not not-do it. Now, I’m flossing all my teeth every day.

Much like flossing every day, small commitments bring consistency, as the author of the phenomenal book Influence and Psychologist Robert Cialdini says. In a tiny commitment, we create an identity, and without even thinking about it, we try to do more of what we committed. If we make an insignificant donation to a charity (like signing a petition on the street), the charity organization uses that commitment and a month later asks for a much bigger one. In the first signature, we identify ourselves as the supporters of that cause, we feel obliged to follow up and increase our donation. Hence, while shaping goals, find what fits your identity or define a new one and start small (for example, I’m a writer now).

While creating a new identity, you must also align your environment with the goals. In the book Atomic Habits, James Clear says setting up your environment is the primary enabler for changing habits. If you want to read more and spend less time on your phone, don’t put phone chargers in every corner of your apartment. Replace them with books and magazines. If you want to write more, put pens and notepads everywhere in an arm's distance. If you want to exercise more, get your exercise materials (e.g., yoga mat) out of the closet and put them into places where you can always see them. The more you have them around, the more chances you have to do something with them.

Another criterion is that the goals must be free of external influence and dependency. You must have complete control. A goal that says, “I will be promoted to X role,” is not under your control. You can’t decide on your promotion alone. However, “I will study A for three months twice a week, which will help me get promoted to X” is better and under your control.

The last thing I learned is to set goals publicly. When others see our promises, we push ourselves to follow up on our commitments (remember the charity example above? They work because the commitments we make are not for ourselves). You don’t have to share your goals on social media; you can share them with friends, family, and whoever you want. The more people know, the better. Your brain thinks it’s a public promise and forces you to do more.

Seek goals that will change how you live

I still don’t remember whether I achieved or failed most of my past goals, which shows that they didn’t introduce a fundamental shift in my life. Also, these changes happen over time; it’s difficult to see the long-term changes.

As humans, our brains can’t think in the very long term. We are stimulated with short-term gains for better survival, and our evolution speed can’t keep up with the advancements the human race has made over the last centuries. That’s why we underestimate the advantages of compounding (e.g., the exponential result of improving 1% every day) and long-term investment in anything.

Seek goals that will change how you live, work, study, invest, etc., rather than something you’ll achieve and forget about. If you improve by 1% every day, you’ll reach your goals much faster, and they will be permanent thanks to the compounding effect of a small thing you changed.

With all the learnings I shared above, I am (and you are, too) better equipped to introduce long-lasting changes that will result in incredible achievements.

*P.S. Paradise Paradox can help you plan the new year more realistic.*

Reply via email | Reply via Mastodon | Comment

Listen to your gut when you commit too much

Mon, 06 Jan 2025 11:00:00 GMT

When we commit to something small and that tiny thing gets bigger, we need to stop and analyze what’s going on and whether we need to keep the same direction. Strong consistency drivers push us to follow the same promises and thoughts more and eventually be the victims of the sunk cost fallacy. This, in combination with consistent identity drivers, can put us into situations we don’t want or expect to happen. Getting out of this situation requires us to listen to our gut and ask ourselves, “Knowing what I know now, would I make the same decision again?” If not, then get out.

Reply via email | Reply via Mastodon | Comment

Learning How to Lead with Transparency

Sat, 04 Jan 2025 06:39:42 GMT

Think about a company where you can find all the information you are looking for. Everything is written and accessible—from detailed analysis of company financials to notes from the board meetings, from all details of projects to who is doing what at any moment. It looks like a utopia. Why can't many organizations even get close?

People cannot figure out what level of transparency they should provide others. Leaders, in particular, keep certain information to themselves, sometimes with good intentions, like protecting someone else's privacy, but more often, they can't control their egos. When they receive feedback that says they need more transparency, they struggle to understand what that means.

Many leaders think transparency is something unattainable. You will also hear many of them saying, “We're as transparent as we can be,” although they are far from it. Many claim that company financials are available to anyone, thinking that brings transparency. However, most of the day-to-day information cascades privately, relying on people's preferences to share the information with others. People, beaten by their egos, don't make every information publicly available because it might put someone (or themselves) in a difficult position.

Sometimes, leaders want to control the decision-making process. They manage access to information, form groups and invite others as they see fit. As they try to influence or balance a group of people, uninvited access to information might jeopardize the group dynamics and cause problems.

Actually, many leaders get the idea of decision-making wrong. Leadership is about decisions, but not always making them. Leaders must work toward helping the whole organization make better decisions quickly. One way to do that is to lead the team by giving them full context.

The team, which must make certain decisions to progress, must be able to access the context, content and all the information it needs without waiting for someone to make that information available to them. Leaders must provide context to their teams and let the team of experts make a decision. Leaders should work toward creating—what Brie calls—content-level transparency.

Brie divides transparency into two categories: structural and content-level transparency. Structural transparency refers to information shared freely and openly across the organization, while content-level transparency refers to insights into the raw work as it happens.

Many people think only of structural transparency, but what they need is content-level transparency. Anyone in the company can follow up on the work without asking anyone for any information. If someone else needs information about a project, they can search the open conversation and catch up with the information by themselves instead of someone sharing information personally.

Although content-level transparency is a great approach, many organizations fail in this area. They manage information flow within hierarchical lines or social dynamics, which causes stress. People who cannot progress efficiently in their jobs also suffer from stress. Leaders (and managers) become bottlenecks of progress and cannot effectively delegate to their teams.

However, delegation is the main enabler of growth in a leadership career. pThe more effectively a leader can delegate a job](/how-to-delegate-anything-successfully/), the easier their lives will be. Successful delegation demands full transparency, so leaders must share all relevant information.

Contextual transparency is one of the main enablers of successful leadership. Any leader who wants to empower their teams and grow their impact must make context accessible so they can answer questions before they arise while allowing people to ask more.

Content-level transparency has cumulative benefits: People spend less time building trust (which happens naturally in the process), politics are reduced, collaboration focuses on creative pursuits instead of knowledge sharing, everyone stays honest, and people can freely observe what/how others are working.

It also helps leaders and prevents them from becoming bottlenecks of information. Instead of carrying information up and down and to the sides, they can focus on more critical problems.

If your organization lacks content-level transparency, start implementing it by sharing the context of all the work with the people who need it and bringing them into where the discussions are happening. If you are leading a project, instead of creating a private chat group, default to a public one. Don't worry about spamming people with unnecessary conversations. If they feel spammed, they will leave the chat.

Reply via email | Reply via Mastodon | Comment

Psychology of Money—Book Review, Summary and Notes

Mon, 30 Dec 2024 04:54:00 GMT

The Summary

The book is about how human thinking affects financial (or life) decisions. Different behaviors affect how people approach investing and increasing wealth. The book defines the most important ones while giving a holistic picture of how greed prevents people from improving their lives and how people can create or destroy wealth along with their happiness. Then, the book dives into eighteen different factors that affect human judgment on money, wealth and happiness.

Timeless Lessons on Wealth, Greed and Happiness

Your behavior with money is the most important compounding factor of your wealth or your loss. How you approach money, in good or bad times, can change the place you end up. It's crucial to get the priorities right, line up to them, and don't move the goalpost. What works for you will not work for anyone else. Everyone's motives are different. That's why you shouldn't listen to every piece of advice you hear. Make up your mind. How to make the best financial decision is, in the end, black and white: are you able to sleep well at night?

Chapter 1: No One's Crazy

Everyone's financial decisions or how they see money is different and doesn't always have logical explanations. It depends on the time they were born, the city/country they lived in their younger years, their and their families' financial status, and their family's approach to money have an impact. That's why everyone is unique. Also, for some reason, everyone's understanding of the economy and how the financial system works is different. Anyone's understanding can cover 80% of their financial knowledge but represents a fraction of how the system actually works. That's why when people spend/invest their money, there is no craziness; everyone sees differently. Why they spend money in a certain way probably makes sense to them, even though it might be completely wrong. So, don't think everyone is crazy or you're doing the wrong thing. There is no right approach. Considering the very short history of economic enhancements we had (like retirement system, stocks, etc.) compared to how long we exist as a species or how long we have money in the world, we still don't know what's the best strategy that works. There is no best strategy. We know very little and don't have a chance to understand or learn every factor that contributes to how money works.

Chapter 2: Luck & Risk

When we're in front of a successful person, we attribute their success to the hard work they put in, but when they don't hear us, we tend to talk more about their luck. When it comes to saying to others, we go easily and say, “They were lucky.” But when we are successful, we diminish the effect of luck ourselves because we see all the hard work we put in. We don't think that luck plays a big role.

The same applies to the risk. When we're successful, we see all the risks we have taken, but when someone else is successful, we diminish the risks involved. Similar things apply to failures.

The best way to cope with luck and risk is when things are going really well; we shouldn't fool ourselves into thinking that luck played no role there. The same applies to risk the other way around. When things go bad, we shouldn't think that all decisions are terrible; we took a risk and were not lucky. What we can do is to reduce the impact of the risks we take. For example, while arranging our financial life, we can try to ensure that a single financial investment will not wipe us out if things go bad there.

“Nothing as good or as bad as it seems.”

Chapter 3: Never Enough

The thing many rich people don't have is “enough.” They always push for more even though they may live very comfortably for the rest of their lives with the accumulated money they have. We keep moving the goalpost and become miserable while chasing it. Happiness is the results minus expectations. When our expectations are higher than the results, we become unhappy. In the chase to move the goalpost, some people try illegal things because they just want more—becoming stupidly ambitious. In the end, they ruin whatever they have built or accumulated.

The wisdom is to stop moving the goalpost. It's dangerous always to want more. Build a sense of enough, and it will make you happy and healthy.

Don't compare yourself with others. As we talked about in the previous chapter, everyone has their own luck & risk situation. If someone is much wealthier than you, don't get into the comparison game because there is no limit in that game. People like Warren Buffet and Bezos have even vast differences in their wealth that are unimaginable to the majority of the population.

Enough doesn't mean too little. You have to find what's enough for you, but it doesn't mean you shouldn't be ambitious. Learn your limit and which opportunities you should take because not all seeming opportunities are worth the risk. There are some that you should avoid, no matter the gain. Think about what's important to you in life: reputation, freedom, family, friends, happiness, love, etc.

Chapter 4: Confounding Compounding

Many don't realize the exponential impact of sticking to certain things for a very long time. Our brains can't grasp the exponential impact. Take Buffet; his wealth has accumulated over 75 years, and his $81 billion came after he was 65. But he started investing at age 10. He is skilled in investing, but his secret is time. Compounding works in many ways well. Any skill that is done well over a very long time brings success. It's just that humans have a hard time understanding (or thinking about) exponential gain in the long term.

A good investment earns pretty good (not necessarily the highest) returns over a very long time. Compounding wins much more than one-off highest returns.

Chapter 5: Getting Wealthy vs. Staying Wealthy

Many people get rich overnight and also lose everything in a short time. Getting rich is one thing; staying rich is another. Keeping the wealth requires frugality and humility. You need to accept that how you got rich can be gone in a day and acknowledge the luck factor. You also need to try not to lose the money constantly. You have to build a survival mindset. With the survival mindset and keeping money, you enable compounding to do wonders for you. Even that means you don't get the most significant returns all the time; while everyone is getting a lot of returns, you have to keep your focus on the long-term win. For that one, you have to plan with thinking things will not go according to the plan. As the world keeps changing, no plan can survive without adjustment. Nobody can foresee the future. That's why you have to build a buffer—a margin of safety.

You have to plan with room for error. For that, you have to have a frugal budget, think flexibly, and live happily with an extended range of outcomes. It's not about conservatism—avoiding risk. It's about increasing your chances of survival at a given risk. You have to be optimistic about the future but paranoid about what can prevent you from getting there. You need to have a short-term paranoia to keep you alive long enough.

Chapter 6: Tails, You Win

“Tails drive everything.”

In business, finance, or most of the things involving uncertainty, it's the tail that brings huge success. When you look at Berkshire Hathaway, you see that their fortune comes from their top few investments, the rest of the hundreds are average or loss. That's also true for businesses. Take Google or Amazon. Amazon introduced the Fire Phone, which was a huge failure. But Bezos said, “We're working on the next failure.” They can offset these losses with a few tails they have—Prime and AWS. The same applies to finance. You can be wrong half the time and still be rich. A few of your investments succeed, and you become rich. The rest can be average or fail. In fact, they will. Don't hang up on them too much. Look at the next. Ensure that you don't bet everything on that failure.

Chapter 7: Freedom

The real richness is how much you have control over your time. All surveys and research about happiness tell nothing about money. It's the ability to choose what you want to do when you want to do it and whoever you want to do with—having control over your life and time in general.

As our jobs evolved from laboring to office work, we are constantly working (even while not working, we think about work and problems). The freedom to not do that and have control over time is the real happiness. It's not the money you have, the size of your house. But money can provide you with that freedom. More money doesn't make you happy, but by using the money as a safeguard, you can free up the time to do whatever you want to do whenever you want to do with whoever you want to do with.

Chapter 8: Man In The Car Paradox

When you spend money to buy a fancy car thinking that people will recognize and respect you, look at you and think that you're an important person, you're putting yourself in the wrong place. When people see the car, they look and admire the car, not you. You're never the topic. They think that one day they will own a car like that and they will be respected. They never think that you must be a very respectful person. The car steals that from you.

Chapter 9: Wealth Is What You Don't See

Richness is what people always see. It's the visible part of money. If someone has a Ferrari, we can safely say that they are rich. It doesn't matter how they can afford it; they have the monthly payment anyway, either at the edge of insolvency or deep down in debt.

The wealth is different. It's the part nobody sees. That's why it's challenging to learn from others. Wealth is the car that hasn't been bought, the big house that wasn't moved in. It's an option not yet taken. Its value lies in the freedom and flexibility of one day purchasing more stuff than you can buy now. Building it is difficult because most wealthy people are also invisible; we can't learn from them. They might also be rich, but the wealth of the rich is also invisible. Nobody knows Bezos' portfolio or the opportunities he didn't take.

Chapter 10: Save Money

Investment returns are mostly out of your control, but your savings rate is. You can build wealth without high income after you cover your minimum life expenses. The value of wealth is relative to what you need. If you keep moving the goalpost, you can't save. However, if you keep the goalpost constant, you can save whatever is left after you cover expenses. You don't need to put hours of work into increasing your investment returns from 10% to 12% if you increase your savings from 1000€ to 1200€ (already 20%).

After a certain level of income, the rest is just your ego. How much you tame your ego tells you how much you can save. You can save more and spend less if you desire less. That simple. You also don't need a specific reason to save. It's okay to save for retirement, a house, a car, etc. But you don't have to. You can save money for the sake of saving. In turn, cash gives you flexibility. There is one thing you can't buy with money is time. If you save money, you build your flexibility muscles. Then you can earn back your time. More savings can help you if you know you don't like your job; you can quit and take your time to find a new job. You can also just sit on the money to wait for a great option to invest, especially when others who don't have the flexibility bring the opportunities to you. A while ago, everything was local. If you were the best, you made good money. Now, skill is not enough. Having control over your time and being flexible is the most valuable currency in the world.

Chapter 11: Reasonable > Rational

You don't have to be perfectly rational in investing. We're human, not a spreadsheet. As the whole investment system is complex and depends on humans, it's okay to be just reasonable and realize you can't win only with numbers. When you do, you have higher chances to stick to your plan in the long run instead of day trading. Investing in a company you love for any reason helps you stick to it when the market is going down. In turn, it helps the company to have capital and stay wealthier in the long run. On paper, it might not make sense to own that company but just because you like it, you keep the share in the difficult times. Once the difficult times are over, it usually pays back if the company's financials are strong. Being reasonable helps you stay on track when everyone is trying to guess the market in day trade, you can stay strong knowing that it's impossible to do (as much as day trade benefits look attractive on paper).

Chapter 12: Surprise

Studying history to replicate what worked back then will never work today. As the world is different, industries have changed, how investment is used has changed, and capital allocation and technology have changed. Hence, looking at historical patterns will never work. There is also the impact of big events nobody could foreseen, like World War II, 9/11, the 2008 crisis, etc. Every time these events were happening for the first time. All of them started/happened with a tiny event—a tail event that changed the world, moved the needle, and was an outlier. The problem is that we often don't use these events to guide our thinking when designing future investments. We think that they won't happen again. True, they won't, but we'll always see brand-new ones. So, we have to learn from being surprised, and the world is always surprising. We can't use past surprises as a guide; we can only expect that we'll be surprised again, we have no idea what will happen next.

Also, looking at the history to understand patterns is misleading too. We can't form future predictions using historical data. The structural changes happening all the time, making it impossible to compare today with the past. There was no venture capital money in the 1940s-1950s to do business. There were no tech companies, and there were recessions in varying cadences. Even Benjamin Graham, one of the best investors of all time, changed the formulas in his book in every new version. He admitted that what worked in the previous version wasn't working anymore. That's what made him great: not using the same methods but adjusting according to today. History can only help to get the bigger picture, such as psychological patterns and how people behave in certain events when they invest. That's what we can learn from historical data. But for the rest, we have to be ready to be surprised and plan our money to be ready for unknowns.

Chapter 13: Room for Error

In whatever you do, you have no certainty that everything will go as you wanted or expected. You can plan everything in detail but life will eventually bring you a surprise. To prevent being caught off-guard and being wiped out in a surprise, you must add/think about room for error. We can't predict the world as black/white; we have to consider gray areas where anything can happen. Any unexpected events can knock down the market 30% in a day/week. If you don't have any room for error in your investment plan, you might sell everything and lose a lot, which pushes you out of the game completely and you can't come back at all. You can't know how the stock prices will be on any day. Volatility is real and its impact is more psychological. If you have no room for error, you can sell everything in a 25% decline in the market.

The same goes for retirement plans. You can't know what the market will be like. You may retire in the middle of a bear market, leaving you with less money than you anticipated. Your future returns might be lower. If you have no margin of safety, you can't even retire. OR you might have to use your retirement savings for a medical mishap while you're 35. The golden rule is building room for error to prevent a single point of failure. If one event can knock you down so that you can't go back to the game, you have to build a backup of a backup. When you do, you'll have a chance to wait for the odds to turn in your favor. This can increase the chance of rare good events happening because you were able to stay in the game, or you win from compounding. If you rely on a pay-check every month to stay alive, build a gap between the money that arrives and what you use. The goal is to do what you want, when you want, as long as you want.

Chapter 14: You'll Change

We make financial (or life) decisions with the mindset that we'll be the same person in a decade or two. It's easy for us to see and accept how much we have changed in the past but challenging to realize how much we'll change in the future. The decisions made in the past define our lives today, and we either abandon them or stick to them without being happy. When we abandon, we interrupt compounding. Instead of choosing either approach, we can seek to find the balance between two ends. And we should strive to avoid the extreme ends of financial planning. Endurance is key here. Instead of living a very frugal life where we don't enjoy or earn a lot to live in luxury but at the cost of our time, we can find moderate living with moderate savings and moderate time for family and leisure. As we keep changing, that gives us the flexibility to adjust without interrupting compounding or starting from zero in our new decisions that change the direction.

Also, we should aim to accept the reality of changes in our minds. Some people stick to one career just because they studied that. It's difficult to know what you'll want in 20 years while you're still in college. It's also true now that we do not know what we'll want in 10 years. Instead, we should accept that we'll change and not let our future selves become prisoners of our past selves. We need to get rid of sunk costs in our lives.

Chapter 15: Nothing is Free

Many people try to get more money and more returns without paying the fee. The volatility in the stock market is a fee that you cannot avoid. In every investment, every gain, there is a fee. Most often, the fee is invisible but it's always there. You cannot avoid it. You might try finding ways to postpone it, but eventually, it finds you in the form of a fine. Accept that you'll pay the fee like in any entertainment center. The cinema costs money, while you can rent the movie at home. You go to the cinema to have the experience and pay the fee. Accept the stock market's fee (volatility) and be okay with it. If you're not, you don't have to get into the stock market and can stay with cash or other forms but your returns will be smaller.

Chapter 16: You & Me

Although everyone is playing in the same field, everyone plays a different game. We call everyone an investor, but a granny investing the retirement money differs a lot from the day trader who optimizes for very short-term wins. Big failures more often come from social influence, people looking at others and imitating their investments, who are playing a different game. If you're investing in the longer term and read investment advice aimed at the short term, eventually, you'll fail, or the other side will fail. Both of you can't win.

Chapter 17: The Seduction of Pessimism

Nobody notices a big change if it happens over 20 years. They are invisible. But if the market goes down 40% in a day, everyone starts bursting out disaster scenarios. This is also what gets attention. People look at warnings and alerts about pessimistic/dramatic scenarios. But if the market grows 200% over 10 years, nobody realizes it. It's tempting to pay attention to disaster scenarios, but we have to keep an attitude and stay on course even when there is a huge noise outside screaming doomsday.

Chapter 18: When You Believe Anything

When you want to believe in something, you find even more related things to believe. We find exaggerations and stories to move the wish to a bigger extent. Moreover, everyone has an incomplete picture of the world and builds narratives to fill the gaps. The problem is that everyone has a different view and narrative. We focus on what we know and discard what we know. This makes us blind to even discovering them. Especially in economics and investing, the worldview can't even be complete as it depends on others a lot. We have no clue or possibility to predict what others can think, let alone one person.

Reply via email | Reply via Mastodon | Comment

Separating Authority from Expertise

Sat, 28 Dec 2024 06:00:00 GMT

We need to separate expertise and authority to defend against the influence of authority. Simply asking ourselves, “Is this authority an expert on the topic?” and “How truthful can we expect this expert to be?” will help with the separation. Once the authority's influence is separated, it’s easy to destroy its influence and make a better judgment and decision. This method will help with purchasing products (as many products use well-known people to establish authority wrongly) and with following leaders at work (not every comment of a leader signals their expertise; sometimes, people have an opinion without knowledge).

Related Note(s):
- Separation of career paths is a good way to separate expertise and authority.
- The software architect is a role that sits between authority and expertise.
- When guiding direct reports as a manager, find the correct information to guide experts. Don’t be vague. When getting feedback, understand what information you’re missing.

Reply via email | Reply via Mastodon | Comment

Prepare better for removing access to a particular thing as a leader

Sat, 28 Dec 2024 06:00:00 GMT

When you’re changing rules (as a leader) and people lose access to certain things, create a proper decision-making strategy so they don’t rebel too much or become unsatisfied at work. Try to understand how you can control people’s emotions and develop strategies for situations that can go wrong.

Related Note(s):
- If you’re removing access to a perk or benefit, communicate clearly, explain the reasons clearly and avoid leaving people uncertain, as this will strengthen their emotions.
Create an open culture to hear criticism.

Reply via email | Reply via Mastodon | Comment

Separate your desire from the actual value

Sat, 28 Dec 2024 06:00:00 GMT

How we handle something to which we lose access or have limited access changes everything. Our perspective can increase our arousal or call it enough that we don’t seek it anymore. Separating the value from our desire for it gives us a much-needed perspective.

Related Note(s):
- When communicating decisions that remove access to something, explain the value of losing that access and the rationale behind the decision.
- Retrospective thinking makes the lessons apparent when we can’t separate the desire from the value.
- While purchasing/selling something, be aware of the scarcity driver.
- Desires make us submit and lose control.

Reply via email | Reply via Mastodon | Comment

Managers work anytime, anywhere

Sat, 28 Dec 2024 05:35:01 GMT

The manager (the heart of the job—thinking) does the job by thinking, not when they get information about something. Understanding the information requires reflecting and thinking, which can be done anywhere, anytime. Hence, managers work outside of working hours because the problems they try to solve need not focus but need to be unfocused to unravel and make sense.

Related Note(s):
- We can eliminate our doubts by thinking about the experience we gained.

Reply via email | Reply via Mastodon | Comment

Commitment brings consistency

Sat, 28 Dec 2024 05:35:01 GMT

We are consistent with how we define ourselves. We stick to our commitments toward others (not really for ourselves). In other people’s eyes, we do whatever it takes to live up to our words. It sometimes causes us trouble (like people in the street asking for a donation signature and then using it to scam), and sometimes it works like magic (like when we publicly commit to our goals). We work hard to live up to our commitments and ensure we’re perceived as consistent.

Reply via email | Reply via Mastodon | Comment

The power of negotiation during a scarce talent market

Sat, 28 Dec 2024 05:35:01 GMT

When talent is scarce in the job market, people can negotiate by telling companies that they have other offers standing. This will help them get a better counteroffer. However, it will work much worse for the hiring manager, as their emotions will be high when getting the person hired, and they might go over budget quickly due to the invested effort (interviews).

Related Note(s):
- The same applies to promotions. If there is a race for a promotion, people will fight for it more.

Reply via email | Reply via Mastodon | Comment

Authority without vulnerability doesn't work

Sat, 28 Dec 2024 00:00:00 GMT

Establishing authority with command doesn’t work; it generates resentment. Building authority demands showing vulnerability, accepting failure, and building trust. Then, people will follow the authority even more. The same applies to authoritative products (full 5-star ratings are too good to be true).

Related Note(s):
- Consistent writing establishes authority while showing your development.
- An open feedback culture ensures psychological safety when showing vulnerability.
- If you don’t see any downsides in someone’s arguments, how can you trust them?
- When we see products with a few negative reviews, we trust the product more.
- Know your limitations: Information you have doesn’t make you wise.
Source(s): Influence by Robert B. Cialdini

Reply via email | Reply via Mastodon | Comment

People follow authority figures

Sat, 28 Dec 2024 00:00:00 GMT

People follow authority without knowing. The authority doesn’t even have to be an expert in the field. They follow fake authorities, such as an actor with a lab coat playing a doctor role in advertisements, influencing people’s health decisions. People confuse expertise with authority signs. Titles also give clues about authority that make people follow them without considering expertise. I observe this at work, too. People sometimes follow what I’m saying even though I am not an expert in the area—just because I’m a manager.

Related Note(s):
- Don’t build up an ego when people follow you even though you are not an expert.
- Accountability culture ensures that expertise is separated from authority.
- When someone writes a book about a topic, it doesn’t mean they are right. The book gives them authority; however, it may not be the reality—the same applies to LLMs; they are not the authority.
- When listening to investment advice, be mindful about who advises you.
- To establish authority, some vulnerability has to be visible first.
Source(s): Influence by Robert B. Cialdini

Reply via email | Reply via Mastodon | Comment

More followers make the idea correct

Thu, 26 Dec 2024 15:35:01 GMT

Initiators use the social proof principle to make their ideas work, even when the idea is incorrect. Leaders in companies or political parties convince a group of people first about an idea. Using that group, they show others that they have support, believers, or what have you. More people start believing in the idea because they think it’s confirmed by just looking at the amount of supporters. The same principle applies to audience management, like adding laughs to sitcom shows. It convinces us that the show is funny. The same is true in social media: the more followers a person has, the more followers they attract.

Related Note(s):
- Doing public speaking works for social proof as it shows that people accept you as a speaker and authority on the topic.
- Especially tribal thinking has a significant impact on this type of influence.
- This influence method can help organizations move faster as the social proof will make people believe an idea (or decision) is correct. However, we need to be careful.
- While facilitating meetings, try to find initiators and get their buy-in on the topic you’re facilitating.
- As a leader, try to find the initial supporters of your idea and use them to create the image of the right decision when you want to convince people.

Reply via email | Reply via Mastodon | Comment

We conform to peers' behavior more than others

Thu, 26 Dec 2024 00:00:00 GMT

Peer-suasion is a strong behavior. We follow others who are like us. The similarity bonds even further, and people do even more similar things. This is also visible in teenagers; they rebel against their parents but strongly follow the rules in teenage groups. I also observe this as a manager and in my daily life. When I mention something I’m doing to my direct reports at work, they are less likely to replicate. However, if I praise their peers, they replicate the praised behavior more. I also do the same with my friends. I observe that we start using similar phrases or doing similar behaviors when we’re in the group and bond more if we share the same language. However, knowing the peer-suasion influence, I sometimes deflect using the exact phrases.

Related Note(s):
- Peer-suasion can be an effective strategy to improve the code review process.
- We can use peer-suasion techniques to invest in growing the team at work (forming groups with similar interests?)
- Finding similarities between people as a facilitator is the first step so they establish peer-relations. This can result in higher chances of success for action items taken during the meeting.
Source(s): Influence by Robert B. Cialdini

Reply via email | Reply via Mastodon | Comment

Defending against social proof and peer-suasion

Thu, 26 Dec 2024 00:00:00 GMT

Suppose there is a long queue in front of a restaurant or café, too many product reviews for a product, or many people rushing to buy something, and we follow them. In that case, we need to stop and ask ourselves: “Do I really want that thing, or do I follow these people without thinking? Do I really need that thing, or does the social pressure influence me?” Only when we stop for a moment, look around, and ask ourselves these questions can we truly grasp the impact of social proof. When we realize that exploitation exists, we should make it apparent to everyone that their behavior is “engineered.” Likes, shares, reposts, and other social media interactions are the prominent supporters of this phenomenon. Once something goes viral, everyone rushes to buy it.

Related Note(s):
- When growing in a career, don’t be fooled by the popularity of the roles (e.g., the popularity of a staff engineer). Evaluate them well.
- Asking these questions will break the convenience of following others. However, it’s a must-have to survive without going broke.
- In the stock market, when the price of a stock goes up, everyone rushes to buy it. The more people buy, the more it proves that the price goes up. Until it doesn’t. Don’t be affected by it.
Source(s): Influence by Robert B. Cialdini

Reply via email | Reply via Mastodon | Comment

Defending against a person's likeliness

Wed, 25 Dec 2024 06:00:00 GMT

We need to separate two things to make better decisions: the person who offers us something and the offer itself. Before agreeing with the person (be it a sales manager, leader or friend), we can ask ourselves, “Do I like this person more than I expected?” If yes, we can separate the offer and the person. This separation in mind helps uncover the impact of the likeliness of the person on our decisions. This way, we protect ourselves from people’s influence on us.

Related Note(s):
- When leaders communicate decisions with you, think about how much you like them to evaluate their decisions fairly.
- The feedback you receive is about you and the other person. That means how much you like each other (or you like the other person) will weigh the acceptance rate of the received feedback.

Reply via email | Reply via Mastodon | Comment

You're weakest when you're the strongest

Wed, 25 Dec 2024 06:00:00 GMT

Whenever you win a victory or succeed, that’s the moment you’re the most vulnerable. Your feelings of success blind you, and you underestimate luck’s role in your success. That’s the moment you make the biggest mistake. When you win, get yourself together, reflect on your success, and draw your strategy. What brought you here might not bring you there. You have to evaluate your rhythm and your emotions. Don’t let your emotions rule you. They make you vulnerable. Be aware of them and control the situation while recognizing your feelings. Your next step should come from your head, not from your heart.

Reply via email | Reply via Mastodon | Comment

Let all emotions out inside you to show vulnerability

Sun, 22 Dec 2024 11:21:00 GMT

Vulnerability is not what you think. You don’t need to communicate every emotion inside. But, inside, you have to let all of them out. You have to face all of them by yourself, find all your feelings, acknowledge them, and name them. You shouldn’t do this outside as it might disturb or annoy others. However, you have to do this one way or another by yourself. Only then you can understand yourself and make a better decision.

Reply via email | Reply via Mastodon | Comment

Metacognition: Thinking about thinking

Sun, 22 Dec 2024 10:15:00 GMT

The craft of leadership and management lies in metacognition. Not only leadership but decision-making in general. The right decisions will always be tricky, but real progress will come from reflecting on how we thought before and looking for ways to improve. Metacognition, as a concept, means thinking about thinking or above thinking. The wisdom, or knowledge, comes from one’s progress on metacognition. It’s also required in relationships, higher-level jobs (as decisions impact much more things), and a person’s self-perception. The best way to advance in metacognition is journaling.

Source(s): Lead Dev Berlin 2024 Engineering Director AMA

Reply via email | Reply via Mastodon | Comment

Strong dedication has many doubts behind

Sun, 22 Dec 2024 09:32:00 GMT

Whatever we talk about, whatever we preach comes from doubt. We never try to convince others about things that will indeed happen. It’s the things that we have doubts about. We don’t admit that we have doubts when we follow a strong idea almost blindly. We are sure inside ourselves but simultaneously full of doubts. We choose to believe in it. And we follow that doubt till the end.

Related Note(s):
- Ethical reasoning and tribal reasoning have strong connections to hiding doubts.;
Source(s):

“You are never dedicated to something you have complete confidence in. No one is fanatically shouting that the sun is going to rise tomorrow. They know it’s going to rise tomorrow. When people are fanatically dedicated to political or religious faiths or any other kinds of dogmas or goals, it’s always because these dogmas or goals are in doubt.” from “Zen and the Art of Motorcycle Maintenance: An Inquiry Into Values” by Robert M. Pirsig

Reply via email | Reply via Mastodon | Comment

What is cash flow

Sun, 22 Dec 2024 05:35:01 GMT

The main difference between a company (or business owner) and employees in terms of cash flow:

Employees pay taxes from their income first; then, they pay their expenses.
Business owners pay expenses first from their income; then, they pay taxes.
Employees pay the government and everyone else first, while business owners pay themselves first, then the rest.

While learning accounting, finance and investment, the biggest eye-opener for me was the above truth. I didn't notice the difference. Now, I'm looking for ways to pay taxes before I earn money. Real estate, bonds, and stocks are a few ways to do that. I learned that you can deduct the interest rate of your loan from the taxes you pay. If, in Germany, one buys an apartment to rent it to others, the interest rate, the yearly expenses, and deferred value are tax deductible. The exact calculation is a little complicated. There is still a social contribution you pay from your salary.

Reply via email | Reply via Mastodon | Comment

Keep track of your expenses

Sun, 22 Dec 2024 05:35:01 GMT

The other lesson I learned about financing is to keep track of your expenses. Once you do, you can see how much you spend, prepare for future payments, and spend the money where you want rather than randomly.

Reply via email | Reply via Mastodon | Comment

Compartmentalize your teams around visions

Sat, 21 Dec 2024 11:35:01 GMT

As an engineering director (or manager of managers at any level), you need to compartmentalize your teams around visions. Ask yourself what your vision for the group is. As a director, you don’t have full context on anything, so don’t try to gain too deep context.

Related Note(s):
- Without the vision, nobody will be able to feel ownership.;

Reply via email | Reply via Mastodon | Comment

Increase your strategic thinking as an engineering director

Sat, 21 Dec 2024 05:35:01 GMT

As an engineering director, you should reduce your time on operational topics and increase your strategic thinking. Create space on your calendar to see how much time you spend on operational topics, and then reduce it.

Related Note(s):
- 3: Being a Team Manager and Manager's Job;
Source: Lead Dev Berlin 2024 - Engineering Director AMA

Reply via email | Reply via Mastodon | Comment

Turning rivalries into teams

Mon, 16 Dec 2024 15:35:01 GMT

When you want people who don’t know or like each other to work well together, assign them tasks that require cooperation. These tasks should not be achievable by only one side; they must utilize the skills and knowledge of both parties. Once you identify the perfect task, you’ll notice how both sides begin to appreciate each other—transforming rivalry into teamwork. A successful team or relationship hinges on accomplishing goals together. Likewise, when you join a new team, ask questions, actively participate and collaborate with the group to foster camaraderie and achieve successful integration.

Related Note(s):
- When assigning tasks, specify goals rather than methods. Create clarity, guide them and allow them to determine methods.
Source(s): Influence by Robert B. Cialdini

Reply via email | Reply via Mastodon | Comment

Creating your image as a leader

Mon, 16 Dec 2024 05:35:01 GMT

As a leader, your name should be attached to good things so that people will like you and follow you more. Not only good things but good people, too. When presenting or talking with others, be careful with what you are attaching yourself to. If you’re known as the person of bad news or challenging or annoying questions, you won’t go too far. Try to find the balance between looking good and staying authentic. You shouldn’t lose authenticity or avoid accountability. Yet, you also shouldn’t form images in people’s minds about you that are related to negative things or people who don’t have a good reputation.

Related Note(s):
- When joining a new team, be careful with the image you create.

Reply via email | Reply via Mastodon | Comment

Be comfortable with yourself

Sun, 15 Dec 2024 12:13:00 GMT

The more comfortable you are with yourself, the less you need the approval of others.

If you know yourself and your strengths, weaknesses, and shortcomings, you’ll need less confirmation from outside. It’s a matter of awareness. If you seek external confirmation, you have doubts about something in yourself. Find and try to understand them. What makes you doubtful? Is it the imposter syndrome (and a false positive) or lack of knowledge or lack of experience? Once you find the root, you stop seeking the approval of others.

Source(s): Farnam Street Brain Food Newsletter Nr. 575

Reply via email | Reply via Mastodon | Comment

Transparency ≠ Saying everything

Sun, 01 Dec 2024 05:56:00 GMT

Transparency ≠ Saying everything

Transparency = Sharing the full context

Why do many leaders struggle with being transparent?

They fall short of their egos. They want to make decisions. That's why they became leaders, right?

Wrong.

The leaders' job is to enable the organization to make the best decision fast. How?

They have to make the context of the work accessible to the people who will need to make a decision. If engineers are designing a solution, they have to have access to all relevant information about the problem they are solving, even the financial and business information.

Leaders' job is to make ALL the information accessible to their teams even when the organization is not transparent.

Where do we draw the line and not share information? When it hurts someone's confidentiality or when the information is irrelevant.

Information such as organizational restructuring, personal improvement plans, compensation details, etc., can be sensitive. Also, there is no need to overload the team with irrelevant information as it will distract them from what's important.

Besides, nobody can get wrong by sharing the full context of the work with their teams.

Next time you think about transparency, ask yourself, "Does the information I am carrying bring context to the person, or does it create a noise?" If it's a noise, keep it. If not, share!

Reply via email | Reply via Mastodon | Comment

Organizational Communication Index

Tue, 26 Nov 2024 05:35:01 GMT

Entries:
- Communicating Decisions: 32
- Open feedback culture creates resilient organizations: 36
- Coupling system design with organizational communication lines: 56b
- Collaboration can be harmful if not intended: 56g1
- Organizations need an RFC process to manage communication around changes: 66
- How to choose RFC audience: 66e

Reply via email | Reply via Mastodon | Comment

Organizational (Executive) Leadership Index

Sun, 24 Nov 2024 05:35:01 GMT

Entries:
- Organizational leaders’ job is to bring clarity to everyone’s work 34;
- Continuous improvement means changing the system, not the goal: 1h;
- Open culture requires listening to people and addressing their concerns 54;
- If leaders don’t care about the culture, they will get a culture they don’t want: 54b;
- On how to create your image on others as a leader: 87; 20g; 87a;
- On the time management of director-level managers: 16d;
- Why do startups fail? 84a;
- How to create a tech strategy? 84b;
- Tools for managing managers: 76a;
- Learning from incidents: 99;

Related Indexes:
- Organization Design Index: 85;
- Organizational Communication Index: 86;
- System Design Index: 48;
Continuation sub-sections:

Reply via email | Reply via Mastodon | Comment

Organizational Design Index

Sun, 24 Nov 2024 05:35:01 GMT

Entries:
- Goals to set a direction and systems to find clues that distract from the goal. 37
- Structuring teams: 56; 56c; 56l;
- Communicating organizational changes: 32b;

Reply via email | Reply via Mastodon | Comment

Understand what you can change

Fri, 22 Nov 2024 09:00:00 GMT

In the circle of concern, there are many things over which you have no influence or control, such as economic changes, industry shifts, etc. This is the biggest group.

In the circle of influence, you can work with others like your peers and influence direction. You still don’t get the result by doing things in the way you need or want, but you can influence them.

In the circle of control, you have things like how you communicate your thoughts, think about things and perceive them. They are all within your control.

Many people think they can influence their circle of concern. Almost everyone worries about any changes in the outer circle. However, there is not much they can do!

Related Note(s):
Source(s): LeadDev Berlin Conference 2024

Reply via email | Reply via Mastodon | Comment

How to build a coaching mindset

Fri, 22 Nov 2024 05:00:00 GMT

You’re the torch as a coach that’s been used by a person in a cave. You’re not taking the journey by yourself; you’re there to light up the way for the other person.

Coaching is not about giving advice directly. It’s about taking the person through a journey and showing them the way. You’re not there to teach them a topic. You’re there to notice what the person does, ask questions, and give them a space to figure things out on their own.

Related Note(s):
- Especially when becoming a CTO, your job evolves to coaching more than direct commanding.

Reply via email | Reply via Mastodon | Comment

Techniques for coaching

Fri, 22 Nov 2024 05:00:00 GMT

Give three Mississippi pauses before talking or asking another question.
Use “I noticed…” and be a mirror to the person.
In the end, ask, “What’s your key takeaway here?” and ask what they will do when they will do it and how to ensure they have done it.

Related Note(s):

Reply via email | Reply via Mastodon | Comment

Giving feedback with a coaching mindset

Fri, 22 Nov 2024 00:00:00 GMT

Take the first step to share feedback. The rule of reciprocation can play a big role when you want to get feedback, too. Especially for the positive feedback, take the extra time to provide it in the most visible way. This favor will get its return when you need feedback, too. While the other person thanks for the feedback, don’t just discard it by saying, “You’re welcome” or “No problem at all,” use the opportunity to enforce the rule of reciprocation by saying, “If our positions are reversed, I’m sure you’d do the same.” When giving feedback to direct reports or mentees, ask what they could have done differently in a given situation. Ask them about what they learned instead of starting with giving feedback.

This will allow them to think independently before receiving any suggestions and will help them learn more than they would when hearing someone else’s feedback.

Reply via email | Reply via Mastodon | Comment

Improving Team Performance

Fri, 22 Nov 2024 00:00:00 GMT

According to the DORA 2024 Report:

Organizations that prioritize the end-user experience produce higher quality products, with developers who are more productive, satisfied, and less likely to experience burnout.

User centricity increases productivity, job satisfaction, team performance, and product performance while reducing burnout. Teams that understand users' needs gain fulfillment and job satisfaction when they solve user problems. In the survey, respondents explained what keeps them motivated and satisfied at their jobs. Answers show that helping users or others and knowing the solution they produce will solve someone's problem improves motivation and satisfaction, resulting in higher team performance.

Related Note(s):
- Management craft requires understanding where to invest time/energy.
- Defining quality goals with a user-centric mindset can help improve performance even further.
- While structuring teams, it's crucial to adopt a user-first mindset in all types of teams, including platform and stream-aligned teams.
- While monitoring the work of the team on various levels, don't forget to include the user-centric mindset.
Source(s): 2024 Final DORA Report

Reply via email | Reply via Mastodon | Comment

Measuring Engineering Productivity

Fri, 22 Nov 2024 00:00:00 GMT

As an engineering leader, your job is to convince the business to invest in increasing developer productivity. This investment often needs time to bring returns, and you have to make it clear to the business. Start by aligning the business before talking about productivity. Bring problems to business according to business plans. Find out what’s essential for you and what your expectations are from metrics (e.g., DORA). Having productivity metrics doesn’t work on their own. You have to set expectations with the teams right and align with the business on these expectations, too. In the end, engineering leadership is not about shipping code; it’s helping the company win by shipping code. Focus on how you can help the company win.

Related Note(s):
- Management craft requires understanding where to invest time/energy.
- Defining quality goals with a user-centric mindset can help improve performance even further.
- While structuring teams, it's crucial to adopt a user-first mindset in all types of teams, including platform and stream-aligned teams.
- While monitoring the work of the team on various levels, don't forget to include the user-centric mindset.
Source(s): 2024 Final DORA Report

Reply via email | Reply via Mastodon | Comment

LLMs = Ignorance

Wed, 20 Nov 2024 16:23:33 GMT

The TV and search engines made people think less. They killed intellectual curiosity. Constant access to information that nobody needs pushes people away from fulfilling their curiosity by research. LLM took this to another level. People trusting AI, the closed and opaque box, is breaking society apart by making people ignorant. People don't validate the information and follow it. They form opinions without correct information. LLM is revolutionary, and there is nothing that will stop it until it's too late. We should adopt LLM into our lives for sure. But should we trust? Hell, no!

Source(s): Thoughts after the Keynote talk in CTO Craft Con: Berlin 2024: Keynote — The Role of AI in Shaping Future Workplaces

Reply via email | Reply via Mastodon | Comment

LLM shouldn't be used for learning

Wed, 20 Nov 2024 00:00:00 GMT

TV changed the world in a way we can’t imagine. In the long term, we can see how much people trust what they see on TV. It became a single source of information for many as it changed people's habits. The Internet did the same. It took decades, but it steadily got its place to provide information. LLM is the next but the most problematic one. With each invention, people lost intellectuality. They trust whatever they see. The difference between LLM and the other two is that LLM is not able to know the source of truth. There is no way to validate the truth of output. That’s why it can’t be used in learning. You have to stay skeptical and research to validate.

Source(s): Thoughts after the Keynote talk in CTO Craft Con: Berlin 2024: Keynote – The Role of AI in Shaping Future Workplaces

Reply via email | Reply via Mastodon | Comment

On Job Promotions—Learn The Rules

Tue, 19 Nov 2024 06:10:00 GMT

Once in a while, I see someone struggling to get a promotion at work. They are frustrated and can’t figure out why they haven’t got the promotion. Questions like, “Why does it take too long? Why are they not promoting me even though I’m doing the job already?” fly in their heads. I was in that same situation before. Then, I moved to the side of “helping people get promotions” and learned a few things that helped me guide others and focus on the right things for my promotion.

I looked at the promotion cases holistically and brainstormed with a lot of managers. I learned a lot about how promotions work and how they are structured inside managers’ heads. Although some practicalities are different from organization to organization, the underlying motives are often the same.

Promotions are a lot of work, even just to get the process started. Showing the right skills, convincing people, presenting a case, or simply being in the right place at the right time takes a lot of energy.

Many people get sucked into the “I want promotion” mindset too much. If they can’t get it quickly, they start looking for another job and leave when their chances for promotion are the highest.

Some fall into the sunk cost fallacy and believe that if they stay a bit longer, they will be promoted, while their chances are very slim due to a lack of skills.

How we find the right track without falling into either edge is what matters. We'll learn the contributing factors for the promotions and find a way around them. But before we dive in, we need to talk about the most important thing first.

Money & Privileges

Promotion usually brings money. I say usually because it’s not always the case. I’ve seen people who were happy to be promoted without any compensation change.

If you need money and it’s the only reason you want the promotion or the title, it is wonderful. You know why you want it, unlike many people.

Also, whatever I wrote below will assume that you’re in a privileged position—money is not your main motivation driver. Even if that's the case, you can still get a holistic picture of promotions.

It’s good to get extra money in the pocket, but we must understand the trade-off. You get extra money, but what for?

Why The Title Matters

A title is proof that you earned it and have specific responsibilities. It doesn’t give details of those responsibilities when someone looks at your CV, but it gives an idea.

A title helps you pass the first stages of the interviewing process when you are looking for a new job. If you're looking for an engineering manager role and have never had the title, your chances are lower compared to someone who has had it for a while. Yet, it doesn’t solely prove that you have all the needed skills; interviewing stages are there to examine your proficiency in the role.

A title helps establish your position in the company. You may have already been doing the job, but the title acknowledges it. It gives you a degree of power.

Yet, businesses don’t give money or title if they have no return on investment. Understanding that return is crucial to set expectations right.

The Value for The Organization—Why should the org promote you?

There must be a business need for any promotion to happen, whether we like it or not. Reasons can range from keeping a valuable employee happy with a promotion to assigning an interim CTO to prevent an engineering organization from falling apart.

A lot of promotions come from someone leaving a job and the organization refilling the position internally. It’s the case when your boss leaves the organization, and you step up. It’s a common promotion method because internal promotions are cheaper and more effective compared to external hires, and employee satisfaction increases due to investment in in-house talent.

Internal promotions don't always succeed. When the promotion goes to the person who doesn’t want it and doesn’t have enough skills, promotions become detrimental. A lot of managers were pushed to the role because somebody had to do the work. Organizations, often without realizing it, end up with the worst-case scenario: an unskilled person doing a job they don’t want. However, if there is already someone willing to become a manager and is already working on improving skills, the opportunity becomes a gold match.

Another promotion type comes from organizational restructuring. Restructuring is costly to the organization and often has frustrating moments for many people affected. However, it’s also good for some people to change their focus and learn something new. A good example is doing the reverse of what we said above. Moving an unhappy manager to an individual contributor role in which they can be happier and more successful. The organization gains a lot of value by putting the talent into a good place—improving individual’s and the organization’s performance. Restructuring can bring a lot of opportunities for change, forcing people to move out of their comfort zones.

Also, many organizations have people they cannot afford (or don't want) to lose. That person can leverage the situation rightfully (this might not look ethical, but it’s the reality). As the employee-employer relationship is based on a contract, they have negotiation power and the right to negotiate.

If an organization has one person they can’t afford to lose, the failure is on the leadership, and they have to pay the price. Why didn’t the organization work toward spreading the knowledge or responsibilities in time? It’s a difficult question for many organizations. If you see someone getting a promotion because of this case instead of you, don’t dwell on it too much. Try pushing your organization to change the situation. And if you’re in the leveraged position, use it wisely!

There are many other cases in which organizations promote people, but the main idea is that there has to be a good return on investment for the business. Either keeping a valuable employee, reducing the organizational complexity, or improving individuals’ performance.

If you’re looking for a promotion, look for how you can increase your value to the organization: impact is key here. The more impactful you are, the more value you bring.

After you understand the organizational value, you can assess if it’s something you’d like to provide.

The Value for You—Your Return on Investment

When an organization requires you to take on more responsibilities, ask yourself, do you want to take on them?

Many people want the money but not the responsibility. Some people want the responsibility and don’t need the money. Everyone’s motivation is different. Look at yourself to figure out why you want a promotion.

Don’t hang up on the title too much. Look at the package underneath. Know what you’ll get with the title. A lot of people act quickly and accept promotions without thinking enough.

A good example is the old CEO of General Electric, John Flannery, who lasted only fourteen months in the CEO role after working at GE for 30 years. He probably couldn’t evaluate what he was getting himself into when he stepped into the CEO role.

Many first-time engineering managers try to go back to being individual contributors because they don’t know that it is a different role. They think that they can continue what they have done so far. There is nothing wrong with becoming an individual contributor again, but it’s a sign that the consideration wasn’t thorough, or there was no chance to practice without the title.

Promotions almost always mean extra responsibility or higher expectations. Know what will be expected from you. Ask about the responsibilities, challenges, and disaster scenarios explicitly. Learn as much as you can. If it’s not something for you, then you don’t need to stress over chasing it.

Let’s say you knew why you wanted it and what you would get with the promotion, but your promotion was rejected. Now what?

Promotion Rejected? Good!

It’s natural to be disappointed when you want something and don’t get it. However, you can change your perceptions about promotions. If your promotion is rejected, try to understand why.

Is it because the organization doesn’t need someone in that role? Or is the budget tight? Maybe it is because you don’t have enough experience?

If the case is rejected because you don’t have the skills or experience, it’s an excellent opportunity to keep the learnings while discarding the responsibility. Ask your manager to learn what exactly is missing. Then, you can work toward closing that gap.

If the case is rejected because of other reasons you can’t change, don’t get sucked into sunk cost. Yes, you invested a lot of time and energy, but life is short. If you don’t feel valued and you see that the situation won't change, make up your mind and say, “Thank you and goodbye.”

Even if you leave, keep the growth mindset. Learn, learn, and learn again.

When you look for career opportunities, don’t only focus on titles or promotions. Look for what you can learn and what problems you can solve, even if that means you jump on something you have no idea about.

Get used to being a junior and senior again and again. Being a junior is excellent. Constantly seek out being the least knowledgeable person in the group. You will learn something you didn’t know every day.

When you start applying what you have learned to solve the problems organizations face, promotion will come eventually. Of course, always ask for it, but don’t get too attached to it when you can’t get it.

Actual career growth happens when you solve problems, gain experiences, and build stories, not when a few words are written under your name.

Reply via email | Reply via Mastodon | Comment

Why do you micromanage?

Sun, 17 Nov 2024 06:00:00 GMT

A manager may micromanage a subordinate because they most probably don’t trust the person or they have control issues (which also relate to trust).

The manager doesn’t believe that the task will be done right or in the way that they would do it to high standards. Many managers feel that they are responsible for the work their subordinates do; they often confuse responsibility and accountability. They are accountable for the job. However, they are not responsible. With high trust, the manager can leave the job to the subordinate without micromanaging them.

Reply via email | Reply via Mastodon | Comment

Audit your team in three pillars

Mon, 11 Nov 2024 09:00:00 GMT

When you join a new team, focus on three aspects to understand its state. Audit to learn what’s right and what’s wrong.

Process
Technology
People

For each, try to analyze what you can change or influence and understand what you can’t change but are concerned about.

Related Note(s):

Reply via email | Reply via Mastodon | Comment

Compliments increase likeness

Sun, 10 Nov 2024 15:35:01 GMT

If you would like to improve your relationship with someone, compliment them on their good traits. Your compliment will open the doors for someone to like you. The compliment doesn’t even have to be true. But be careful when you give compliment to your boss. Try to do it via third person, like sharing your compliment with their assistant if they have one. On the other hand, when you receive a compliment, be aware of your bias toward liking the person and favouring them.

Related Note(s):
Source(s): Influence by Robert B. Cialdini

Reply via email | Reply via Mastodon | Comment

How being liked helps you to get your job done

Sun, 10 Nov 2024 15:25:01 GMT

While working as a leader, you have better chances to get compliance when people genuinely like you. Work toward offering your team and stakeholders fair judgment and being liked. Your stakeholders will especially try to go the extra mile to help you if they like you. Establishing this likeness early on will help you influence their decisions. I used to see this as bad politics in organizations; however, it’s human instinct. You need to learn how to play this diplomacy. You need to convert your target audience to supporters of your approach and ideas. For that, you start with creating a profile of being liked. The same is true of your team as a leader. The more liked you are, the more they will go the extra mile to comply with your direction.

Reply via email | Reply via Mastodon | Comment

Increase your physical attractiveness

Sun, 10 Nov 2024 15:25:01 GMT

Increase your physical attractiveness when you work. People give more social advantages to the physically attractive. You should not only dress nicely but also take care of yourself. Exercise to stay in shape and take care of yourself. In your organization, you may not be required to dress nicely; people may go to work in their pajamas, but just being more chic brings you social advantage.

Related Note(s):
- 11: How to move to the next level;
- 17: Public Speaking and Improving Skills;
Source(s): Influence by Robert B. Cialdini

Reply via email | Reply via Mastodon | Comment

Find similarities to increase likeness

Sun, 10 Nov 2024 15:25:01 GMT

Similarities create comfort; we like people who are similar to us. When someone we admire and consider, as they know everything, says, “I don’t know,” it creates a familiarity, showing that they are like us; they don’t know.

Creating familiarity and similarity brings people closer to you. Regardless of where and how you use this, you can turn this into an advantage. For example, when you present a topic in public, you can interact with someone known to the audience to increase their attentiveness.

Reply via email | Reply via Mastodon | Comment

Compliment to improve occasional good behavior

Sun, 10 Nov 2024 15:25:01 GMT

When someone gets compliment on something they are doing good, they try to perfect it. For example, if an engineer writing a good Pull Request description 80% of the time, compliment on how they care about doing these things that bring clarity and thank them. You’ll see that they will start doing it 100% of the time. Compliments help perfect someone’s occasionally good behavior. A small tip: don’t compliment on the behavior, but on the trait. Be genuine and find compliments the person will live up to. Don’t exploit it.

Reply via email | Reply via Mastodon | Comment

What affects your investment decision

Sun, 10 Nov 2024 15:25:01 GMT

When making an investment decision, try to understand why. Do you like someone working there? Do you like the leadership or the culture of the company? Maybe someone famous you like recommended the business? Do you know someone working there? If your friend is working there, you have a higher chance of liking a business. If your friend invested in a business, you are more likely to invest as well. It’s okay to invest in a company you like; you only need to know so you can make a better call.

Related Note(s):
- 20: Influencing Others;
- 72: Increasing Sales Through Human Psychology;
Source(s): Influence by Robert B. Cialdini

Reply via email | Reply via Mastodon | Comment

Build a product mindset in engineers

Fri, 01 Nov 2024 09:18:47 GMT

“It’s the product manager’s job to write Jira tickets.”

“I need to get full requirements before starting the implementation.”

What’s missing here?

It’s the partnership between engineering and product—a lack of product mindset and learning culture.

Engineers often don’t feel responsible for the product they are building. They focus on making the codebase healthy, using the new technology, or bringing a well-defined Jira ticket from “To Do” to “Done.”

They can’t see the forest for the trees, not because they are stupid, but because there is no incentive for them to look at the forest. They think it’s the product manager’s job to see the forest for them.

How do we change this situation?

The organization needs to set expectations and incentives correctly, take time to train engineers on product mindset and increase the level of transparency at every level.

Instead of putting all responsibility on one person to “manage” the product, the organization must invest in building a product mindset and learning muscles in engineers. Expecting engineers to learn by themselves can’t go beyond wishful thinking. As Kevin Scott once said, “Engineers’ job is not to ship code. It’s to help the company win.”

The organization has to increase transparency to help engineers understand the why, the context, and the background of what they are building. If the information is unavailable, they have no place to learn from. How can they help the company win without knowing why the company needs to win?

Then, the organization needs to “force” engineers to get to know the users they are building the product for. Having workshops, taking the time in each project to walkthrough user journeys, and showing the complete picture (forest) guides engineers in their learning journey.

After that, engineers can (and should) refine the ambiguous tasks themselves and even create new tasks with ideas.

You might say, “Who will do all of these?” and that person, in my opinion, is the Product Manager. They have to understand the users, create a vision for the product, and elevate everyone to know the product and its users.

Give an engineer a fully defined Jira ticket; you get your job done in a day. Teach an engineer how to understand the user, extract requirements, and write a Jira ticket; they get the job done without you for a lifetime.

Reply via email | Reply via Mastodon | Comment

Understanding Ex-pat life and discrimination

Sun, 27 Oct 2024 15:57:08 GMT

Going backwards in discrimination

Discrimination is hidden in seemingly small, invisible daily interactions. A short police control in an international airport, a small chat in a government office, a brief look of a local in the public transport. I know that it’s natural to have these uncontrolled moments. We tend to identify foreigners or outsiders. This mechanism was built over thousands of years; it helped the human race to survive. And the modern world is going against all our habitual patterns and tells us not to identify others as foreigners. That’s the root of our struggles as a community and species. We have to change much quicker than the evolutionary speed—thousands of times quicker.

Yet, it looks like we’re not only changing towards a better or bright future but going backward and getting beaten up by primal instincts. Everywhere, the right extremists are gaining power these days.

This is not the first time this has happened in history. We only see when we look holistically. Every few hundred years, history repeats a bit differently each time (that’s what makes it interesting, too). However, the underlying approach or events are the same.

Reply via email | Reply via Mastodon | Comment

Becoming a CTO

Sun, 27 Oct 2024 15:57:08 GMT

In recent years (2021-2024), the CTO role expanded from mostly operations to a business-driven approach.

CTOs are now expected to know how to run a business, including finance, product management and strategy, and people transformation.

The most significant impact of this change requires CTOs to do more on people transformation, structure and roles, managing and skilling up talent, hiring, and transforming processes.

Related Note(s):
- 3: Being a Team Manager and Manager's Job;
- 8: Growing in the Career;
- As a CTO, you need to be an enabler of growth and innovation, especially if your organization operates in a highly competitive market.
Source(s): CTO Craft Con 2024 Berlin, Füsun Wehrmann - CTO InPost

Reply via email | Reply via Mastodon | Comment

Meeting Facilitation Techniques

Sun, 27 Oct 2024 15:57:08 GMT

Connection before content!

As a meeting facilitator, your first job is connecting people before presenting any content. Focus on ice breakers at first. Connect people to each other as deep as possible.

Connection works best when people are face-to-face. If you’re hosting a workshop, use card games like Ask Deep Questions or We! Connect Cards.

Related Note(s):
- 17: Public Speaking and Improving Skills;
- 53: Guiding Direct Reports as Manager;

Reply via email | Reply via Mastodon | Comment

What I Need From You Matrix

Sun, 27 Oct 2024 15:57:08 GMT

When you’re hosting a workshop to resolve collaboration problems between teams, project kick off, or something similar that require teams (or even people) to collaborate, you can use “What I Need From You Matrix.”

What I need from you	Team A	Team B	Team C
Team A	x	A needs from B	A needs from C
Team B	B needs from A	x	B needs from C
Team C	C needs from A	C needs from B	x

The matrix allow each team (or person) to voice their needs from others. The goal is bringing clarity to expectations and aligning everyone.

Related Note(s):
Source(s): CTO Craft Con 2024 Berlin, Claus Höfele - Director of Engineering at On, Facilitation: A Superpower for Engineering Leaders.

Reply via email | Reply via Mastodon | Comment

Lightning Decision Jam

Sun, 27 Oct 2024 15:57:08 GMT

When you need to make a fast decision as a group, you can host lightning decision jam sessions. Phrase the problems you’re facing in “How Might We (HMW)” format, and ask everyone to write their answers silently into post-its. Then everyone puts their post-its to the wall and we prioritize the solutions and talk about them one by one.

Related Note(s):
Source(s): CTO Craft Con 2024 Berlin, Claus Höfele - Director of Engineering at On, Facilitation: A Superpower for Engineering Leaders.

Reply via email | Reply via Mastodon | Comment

Using Engineering Metrics

Sun, 27 Oct 2024 15:57:08 GMT

Engineering metrics should live with business metrics in the same system, not in another system. Engineering metrics are part of business metrics and they have to live together. These metrics shouldn’t stay in a system where only engineering leaders can access.

Related Note(s):
Source(s): CTO Craft Con Berlin 2024, Grygoriy Gonchar - CTO Eurowings Digital, Elevate Engineering Goals to your Company’s Genuine Priorities

Reply via email | Reply via Mastodon | Comment

Tracking Capacity Allocation

Sun, 27 Oct 2024 15:57:08 GMT

Track capacity allocation in retrospective rather than for future. This way you know what the team spent time on the last month(s). Categorize the work in three categories: tech debt, product improvements, and new features. Once you accumulate some data around how much time the team(s) spend on each category, you can bring clarity to the business around what the team is dealing with and the data can help you identify problematic areas where engineers spent a lot of time on tech debt.

Related Note(s):
Source(s): CTO Craft Con Berlin 2024, Grygoriy Gonchar - CTO Eurowings Digital, Elevate Engineering Goals to your Company’s Genuine Priorities

Reply via email | Reply via Mastodon | Comment

Managing Tech Debt

Sun, 27 Oct 2024 15:57:08 GMT

In all engineering problems like tech debt, focus on business case first. Telling executives (like CEO) or product management that tech debt has to be worked on will not work. You have to understand the business first and then find the impact of tech debt to the business. If people are complaining that the team speed is slow, find out why. Is it because of the tech debt or because of the lacking capabilities around continuous delivery. Once you found it, explain the problem’s impact to the business with clear impact evaluation and how you’ll make it better and how people will track that it gets better. Don’t start from the tech debt and explaining that you need time; it won’t work.

Related Note(s):
Source(s): CTO Craft Con Berlin 2024, Grygoriy Gonchar - CTO Eurowings Digital, Elevate Engineering Goals to your Company’s Genuine Priorities

Reply via email | Reply via Mastodon | Comment

Your job title depends on the organization you're in.

Fri, 18 Oct 2024 11:06:40 GMT

Your job title depends on the organization you’re in.

Get used to being a senior or junior again in different organizations. Don’t take the given seniority for granted—it's not like the PhD that gives you a Dr. title for your life.

Agencies often promote people to senior roles way earlier than other organizations because they can charge their customers more per hour. In banks, all titles are inflated. I saw many VPs doing team lead roles.

In software engineering, the differences between titles are not so sharp, and there is no unification across the industry.

Don’t believe in what you read on social media about senior engineers doing this or that.

Also, don't take yourself too seriously about titles. Look at the opportunities you have to learn how much money you make.

If you want to get more money, some organizations pay their mid-level engineers more than some other organizations pay for senior (or even staff) engineers. When you move to these organizations, your CV doesn't look bad, and you're not stepping down in your career. As long as you have a reason you can explain, there is no problem.

If you're good with the money you earn, then look at the learning opportunities. Don't think career opportunities mean only promotions or titles. Focus on what problem you solve and what you learn from it. That's the career opportunity because that's called experience. In the end, what brings title AND makes money is your experience.

That's why:

Career Opportunities = Experiences

Career Opportunities ≠ Title

Reply via email | Reply via Mastodon | Comment

On Good Software Engineers

Tue, 15 Oct 2024 09:45:00 GMT

Setting expectations for software engineers is tricky for all managers. Every company has different needs and a different structure, tech stack, and culture. Whenever someone joins a team, one of the manager’s challenges is aligning the organization’s expectations with those of the new joiner. As there’s no universal guidance on this subject, I set out to find a simple definition that would help managers frame the fundamental things they expect from software engineers.

I first found definitions of 10x engineers, superstars, or rockstar developers, which aren’t definitions of good engineers in any way. Someone may produce a lot of work but it’s often at the cost of team spirit and results in low-quality code. Ultimately, the team is demoralized and the organization bears the cost of substandard code.

I also looked at different career progression frameworks or career matrices (which aim to give engineers perspective on how to map their professional development to roles) to see how tech- or product-driven organizations define good engineers. I found that all were incomplete (I wrote about the good, the bad and the ugly of these frameworks here. In general, career frameworks are helpful in defining roles, but they don’t define a good engineer. After sharing my thoughts and findings with peers, well-respected engineers and on LinkedIn, I arrived at one definition of a good software engineer.

A good engineer is one whom I, as a manager or peer, can trust to progress a project, knowing that they will deliver a solution by working with the team and producing good quality, again and again.

This definition applies to software engineers at all levels (from junior to staff+). We can’t expect a junior engineer to drive a big project; their scope will be limited. Yet, we can expect them to deliver small, unambiguous tasks with high quality again and again. We can expect good senior+ engineers to drive and deliver a feature or project. When it comes to staff+ engineers, this expectation will span over big and long-term projects with many unknowns.

It’s a super simple definition but has a lot of subtleties around how a good engineer, at any level, will approach and deliver a project by using many hard and soft skills. Let’s delve into them one by one.

Good engineers know how to influence others and the organization to deliver a solution as a team. At any seniority level, a good engineer must know how to communicate well both in written and spoken form. An engineer’s work always depends on collaboration (code reviews, pair programming, RFCs, ADRs, feedback, etc.). Good collaboration demands clear communication, giving and receiving feedback, and listening with empathy. However, these soft skills are not enough.

Good engineers understand the processes they are operating in while taking a project from an idea to a solution. There are different approaches when it comes to doing code reviews or writing RFCs or ADRs. Each organization uses different methodologies like Kanban, Scrum, or Scrumban. Some organizations use Tech Radar to help teams make technology choices. Good engineers know the processes and guidelines so thoroughly that they know where they can bend the rules. They don’t stop there; they take their time to understand the organization as a whole.

Good engineers spend extra time learning the environment they’re in, going beyond the processes so they can independently drive the work. They learn how the organization works, about its culture, norms, and people. As they need to adapt to the organizational requirements to deliver a job of good quality, they have to develop not only hard skills but people and organizational skills. If the organization is hierarchical, they'll have a difficult time driving a solution when they face rejection from a more senior person. If the organization works with short-lived task forces instead of long-living teams, their work style will be focused on speed and getting things done quickly. In any situation, they’ll need to find how to implement quality sustainably.

Good engineers take a proactive approach and embed quality elements into their deliverables to increase consistency and velocity. There is no need to ask for extra permission to write tests when you do test-driven development; no discussion will be needed if you consider refactoring as part of the new feature implementation. A good engineer chooses their approach wisely. If they inherit a legacy codebase, they look for ways to make it better, step by step. If they work with giving estimations, they include all these to keep a good level of quality. But above all, a good engineer needs to understand what quality means in their current circumstance.

Good engineers understand the stakeholders’ needs and fine-tune their approach so they don’t unnecessarily delay the delivery. They might need to do a proof of concept first or a full solution design upfront. Even when working in the same place, the organization evolves and changes; good engineers adapt to these changes and adjust the project’s codebase accordingly.

Good engineers constantly work on reducing complexity in the codebase to consistently provide high quality. They seek a modular design, separate concerns at every level while keeping the right amount of cohesion, and have a good testing setup and strategy. These are quality levers, and they know how to adjust them according to the organization, the situation, and the people around them. Keeping the same implementation and delivery strategies rarely works; good engineers constantly adapt and have a learning mindset.

Good engineers are reliable in constantly changing organizations. They seek to learn at every chance, even if it puts them in uncomfortable situations, such as publicly admitting mistakes, holding themselves accountable, and looking for ways to prevent the same mistakes from happening again. If a good engineer doesn’t know how to tackle a problem, they don’t avoid tackling it. They have a growth mindset and eagerness to learn. But they don’t stop there.

Good engineers are team players regardless of personality type. They recognize a problem and offer a solution. They don’t throw the problem over the fence and ask others to fix it.

I’ve covered good engineers in detail. But what makes a great engineer? Great engineers do all of the above but proactively. If they see a broken process, they don’t walk past the problem or wait for someone else’s permission. They take action to fix it. If they can’t change the process themselves, they don’t complain without bringing solutions to the people who can change it.

These expectations will not be easy for inexperienced engineers, but their scope will be limited at first. They will gain experience in time. If they keep learning, stay reliable, and improve quality day-to-day, it’s safe to call them good engineers.

I already hear some of you saying, “Well, Candost, you expect a lot of things from a good engineer.” No, I don’t. I strongly believe all that I’ve mentioned is a basic expectation from any engineer. More generally, these expectations apply to, in fact, any good employee.

Reply via email | Reply via Mastodon | Comment

How to Read a A Book—Book Review, Summary and Notes

Sun, 13 Oct 2024 00:00:00 GMT

How Strongly I Recommend It: 10/10

How Likely I Will Gift It: 5/10

The Review

This is one of the most fundamental books, not to learn how to read but to increase the information you can extract from any book. The methods, ideas, and thoughts are profound and well-established. After reading the book two times, taking notes, and applying my learnings, the book changed how I approach books.

I always felt bad when I half-read any book before reading this one. However, I learned that I can read a book much more quickly without reading every sentence in it. It’s a matter of disciplined method combined with active reading.

I admit that I don’t follow everything in the book to the word. That’s okay. I sometimes do syntopical reading from the books I’ve read before in combination with the book I’m reading for the first time. Yet, I feel much more wealthy with the tools I have in my reading. It’s a matter of using the tool at the right time for the right thing.

I recommend this book to everyone.

However, I am not sure if I will gift this book to many people. You have to arrive at this book by yourself because if someone gifts you, you will likely not read it. The craving must come out from within, not nudged from outside.

Who Should Read It?

Anyone who has never thought about how to read books in a better way. I think the majority of the population doesn’t have the tools mentioned in this book. Hence, everyone should read it.

Why should you read it?

The book is more about getting the most out of any book in the shortest amount of time than reading a book. If you struggle to stick to a book or buy so many books but your reading speed falls behind, or you have difficulties reading non-fiction, you should read this to extend your reading toolkit.

Reading is rarely reading word by word, unlike what’s been taught at school. It’s a dynamic activity in which you have to change your reading style, speed, and mindset depending on the book and your knowledge about the topic. If you don’t know how to do these, you should read this book.

The Activity and Art of Reading

"...knowledge is not much a prerequisite to understanding as is commonly supposed. We do not have to know everything about something in order to understand it; too many facts are often as much of an obstacle to understanding as too few. There is a sense in which we moderns are inundated with facts to the detriment of understanding."

Reading for information vs. reading for understanding

Reading for understanding is more active reading that changes the knowledge level of a reader from less to more. It fundamentally challenges, not just gives information. Reading for understanding requires being ignorant or having a little bit of information about a topic. Reading for information is about reading newspapers, magazines or others that are intelligently through to us. These things may increase our information level but don't change our understanding of anything.

Writer vs. Reader

The writer must be superior to the reader, and that superiority should create an inconsistency. For a reader to understand while reading, this instability should be partially or fully resolved, and the reader should become superior in the end.

Reading as Learning

To be informed is to learn as much understanding as what you didn't understand before. We can learn the existence of information by reading it, but it doesn't necessarily mean we understand what it says and learn it. We just learn the information. We're informed, not enlightened. To be enlightened, we have to be informed first. But if we stop there, we'll never truly understand what we read. To understand, we may think about the information or ask questions. But both will demand us we answer those questions. If we have a teacher who answers these questions, it doesn't show that we have learned. Also, when reading books, we don't have a present teacher; we have to answer these questions by ourselves. That's what Mortimer calls learning by discovery. If we learn by instruction, we're only informed. We need to seek the next step and discover to learn. I also think that's the beauty of Feynman's technique: explain what you've learned to a kid.

Four Levels of Reading

Elementary
Inspectional
Analytical
Syntopical

Elementary reading is what's taught us in elementary school.; it's the simplest form of reading. Our goal is to understand what a sentence says.

In inspectional reading, we ask, "What is the book about?" Our goal is to understand the book in a limited time, be it 15 mins or 30 minutes. We have to learn as much as we can from the book in this limited time. Therefore, only skimming is not enough.

In analytical reading, we have unlimited time. It's the level we understand the book. We ask questions, converse with the author, extract its arguments, and learn; then, it's an insanely active level of reading that results in the book becoming a part of a reader.

The last level of reading is syntopical reading. The reader indeed reads many books together to understand a subject, not just one book. And the reader may create their own perspective that's not in any of these books. It's the most complex and rewarding part of reading.

Inspectional Reading

It's the reading we do to understand what the author says, its message and pivotal arguments, and whether it is worth our time or not. Inspectional reading consists of two parts. Beginner readers can do these parts fully detached from each other, but experienced readers can do it together. In the first part of inspectional reading, we call systematic skimming, and the second part is superficial reading.

You need to be able to answer the following questions after the inspectional reading:

What kind of book is it?
What is it about as a whole?
What is the structural order of the work whereby the author develops their conception or understanding of that general subject matter?

Inspectional reading is the reading we do before giving the book a full read. Our goal is to understand what the book is about, what's its argument and does it worth reading or not. Inspectional reading consists of two parts.

Systematic Skimming
Superficial Reading

Systematic Skimming

Systematic skimming is the part where we look closer at the book. The goal is to understand the theme of the book, whether it matters to you or not, if it requires more time to read, its pivotal arguments, etc. (for me: it's the decision point for buying the book).

It consists of multiple steps. Many people skip this and dive into the book that they regret quickly and, as a result, waste a lot of time.

Read the title page, preface, and foreword.
Study the table of contents.
Check the index. (and some passages that are cited—most crucial ones in the index)
Read the publisher's blurb.
Look at the chapters that seem pivotal to its argument.
Turn the pages and read here and there, a paragraph or two, a page or two, not more than that. Look for signs of the main contention.
Read the last 2-3 pages. Authors usually cannot resist not summarizing the book. That's the conclusion.

After completing these seven steps, you should have a broad understanding of the book and can decide if you want to read the book. Many books won't pass this stage, and that's okay. There are millions of books, and we cannot read them all. We have to choose what we read carefully.

Superficial Reading

In inspectional reading, the second step is superficial reading, which is reading a book without stopping and pondering its arguments. It's okay not to understand everything the book says. It's important to keep going, understand as much as possible, and be fine with what you can grasp. When reading a difficult book, you'll come back to it later. You'll try to understand all arguments in the second reading, and that reading requires you to read the book once.

While reading for the first time, it's crucial to read at different speeds. You need to be able to speed up and down. Many people read with sub-voice, and it slows them down and causes them to spend unnecessary time on parts that are not that valuable. Many books are worth not even skimming. That's why practice and learn how to read at different speed levels. In inspectional reading, you both read faster. Not only do you speed read, but you also read less of the book because you read with a different mind: understand the book holistically.

To speed up your reading, put your finger on the line and move it at a speed a little faster than your eyes can follow. That will help speed up because your eyes will have fewer chances to fixate themselves and only pause once or twice in a line while grasping multiple words at once. This method will also increase your concentration. But contrary to what speed reading courses claim, it doesn't improve your comprehension. Comprehension will come when we read analytically. It's not the purpose here.

The Essence of Active Reading

The active and demanding reader asks questions, takes notes, makes the book their own, and becomes better when they keep reading consistently.

An active reader asks four questions and writes down answers:

What is the book about as a whole? (What's the theme?)
What is being said in detail, and how? (main ideas, assertions, arguments)
Is the book true, in whole or part? (make up your own mind)
What of it? (why does the author think knowing these things is important? Is it necessary for you to know them?)

Analytical Reading

Rarely does any book need to be read analytically, and 99% of the books don't need this kind of reading. Only great books need to be read analytically, and these books are rare.

Analytically reading a book requires the previous steps that are described in the elementary and inspectional reading.

In analytical reading, we start with finding what a book is about and learning what a book says. Only after we can say that we understand can we criticize a book as a communication of knowledge. First, we need to read and understand without prejudice or holding any judgment. Only then can we criticize.

First Stage: Finding What A Book is About

Pigeonholing a book

Before reading the whole book, you must know what kind of book you're reading. Is it a scientific, historical, or philosophical book? Is it theoretical or practical if it's a scientific book? Identifying the book is crucial to approaching how to read it. You can learn this by looking into its title and front matter, but it's not always enough. You have to examine the table of contents (if it has one) and index it, and read a few pages, the intro, and the summary. Once you understand if it's theoretical or practical, you're already better. But how? I mean, what defines theoretical as theoretical or practical as practical? In short, practical books often talk with "you should do this" or use words such as "should" and "ought," "good" and "bad," "ends," and "means." In contrast, theoretical books keep saying "is," not "should." They try to show what it is instead of how to make something better or ways to change things.

Also, understanding what kind of theoretical book is not always easy. Some books say they talk about physics but are more philosophical, and vice versa.

Understanding historical books is easy, but separating them from novels is not, as history has to include good storytelling.

Scientific books talk about anything that can happen at any time and often outside of the daily routine life of ordinary humans. In contrast, philosophical books often talk about things that happen in ordinary human life that don't require extra knowledge than just an armchair to sit and think.

X-Raying A Book

State the unity of the book in a sentence; if not possible, in a few sentences, a paragraph. Unity is the theme or main point of a book. It's not what kind of book it is but what the book is about as a whole. To do that, you must understand the skeleton of the book, see beyond its clothes and flesh, and X-ray the book. And write that down. Just thinking about it doesn't suffice. If you can't express it, you're just fooling yourself.

As much as we need to state the book's unity (what it is about as a whole), we also must identify its sections and how the author identified what they wanted to say in each section. These sections don't need to be defined by the author. It's how the reader sees them. These sections would be identical if the author and the reader did their jobs well. Also, the reader should outline each section separately and each part of the section. This outlining goes on and on, but this doesn't have to be done for every book; the reader also should do it together with identifying the whole. The crucial part is knowing the structure of the book's sections, their relations, and their connections to each other. The reader can outline everything in detail and how everything ties together, but this should be limited to the book, not outline the subject matter the book is about. When getting into the subject matter, the outline will be unlimited.

Lastly, the reader must look at the author's intentions. What problem did the author try to solve? To see the book's unity, the reader must ask questions to learn what the book serves. Authors often don't make it explicit enough; the reader should ask questions to figure out the author's intention and the reason for the existence of the book.

Second Stage: Finding What A Book Says

Coming to terms with the author

The author uses words and phrases, sometimes interchangeable meanings. They use the same words for different purposes or different words for the same meaning. As a reader, our responsibility is to understand which words say what and what the author intended to use with what words. That means coming to terms with the author. We don't need to do this for every word consciously, but we can find the essential words and phrases the author used and come to terms with these. These will help readers to understand the arguments and the author's mind better. It will help us to understand the book better.

Determining the message of the author

The author's message can be embedded into words, sentences, and paragraphs. It's usually not hidden in fiction books but also can be unobvious; the author might reveal it as a whole. To understand a book as a whole, we, readers, must look for arguments in words, sentences, paragraphs, propositions, and problems the author solved. Our goal is to answer, "What is being said in detail, and how?" Here, we interpret the content. We must find the most important sentences that lead to the author's propositions. With these important sentences, we may clearly build the author's arguments. But sometimes, we need to construct arguments on our own as the authors might fail to reveal them or expect us to find them. The author's arguments and solutions they give (or failing to give a solution) should be out of the book in the end, so we can say we understand the book. Merely thinking about them is not enough. We have to ask questions, put effort into finding answers to what the author says, and form these propositions, arguments, problems, and if the author succeeded or failed to solve these problems. All that requires an active reader who adjusts reading speed and marks words, sentences, arguments, and propositions to extract them from the book.

Third Stage: Criticizing A Book as a Communication of Knowledge

Criticizing A Book Fairly

The next step after understanding the author's arguments, dissecting their propositions, and building up how they approach problems and solutions, we can judge and criticize what they are saying. However, to criticize, we must understand first; we must listen to their arguments as a whole, do our part of the work, and not cut their words before they finish. To be able to say, "I understand," we must be active and work through the book without judgment. Once we understand, we can judge, and it's our duty, as a reader, to judge and criticize (agree, disagree, or suspend judgment) the book. We must take a position, and while doing so, we should avoid contentious and disputatious behavior. We should be open to agreeing as much as disagreeing. To stress again, we must suspend judgment until we are considerably sure that we understand the author's points, and then, only then, we must criticize the book to learn, to agree, to disagree, or to judge what they are saying.

When we disagree with each other, we often don't understand the difference between personal opinion and knowledge. The same applies to books we read. We have to separate personal opinions and judge the authors' arguments by thinking about our missing knowledge or the authors' missing knowledge. When disagreeing, the ground should be open to learning. As we can also (hypothetically) teach the author, it's crucial to think of our arguments as either personal opinions or knowledge based on facts or can be explained by concrete reasons, not just mere opinions or prejudices we have.

Agreeing or Disagreeing with An Author

To agree or disagree with an author, we must first say that we understand. Without understanding, we cannot express any judgment or even suspend judgment. And understanding doesn't mean agreement with an author. Disagreement doesn't mean misunderstanding or not caused by it. We can only disagree if we understand. To say that we disagree, we must first identify our emotions and feelings. Do we disagree because we don't like the arguments? Second, if we disagree, we must explicitly state our own assumptions. Lastly, we must try taking the author's point of view. Without sympathy, we cannot disagree; it would be incomplete if we approach with impartiality. As a result, we can only disagree by saying one of these:

The author is uninformed.
The author is misinformed.
The author is illogical.
The author's analysis is incomplete.

Whole saying any of these, we, as readers, have to be precise and definite about why and where the author failed in information or logic.

When an author is uninformed, they lack sufficient knowledge about the problems they present or trying to solve. As a reader, we must show explicitly when an author is uninformed and present knowledge they lack that is relevant to the problem. When an author is misinformed, the real problem might be still missing knowledge, but here the author makes erroneous arguments by going beyond missing knowledge. The author presents as true or a fact that is contrary to a fact. The author claims the knowledge they don't possess. When an author is illogical, they use wrong reasoning with the information they have. They committed a fallacy in reasoning. They conclude something which doesn't follow the reasons they explained earlier. As a reader, if we fail to support any of these three, we must agree with the author; we don't have a choice. We might not "like" the author's arguments, but we have no free will to choose to disagree. The last point of disagreement we can make is about the author's completeness. When an author's book is incomplete, we can say that the author didn't solve all the problems they presented, didn't consider all ramifications or implications, or didn't use the material they presented well. The last point is about the whole book, while the first three can be about certain parts of the book. When we make the last remark, we are also obligated to present the missing points.

Using Analytical Reading

The analytical reading has three stages. First, learn the book and find out what it is about. The second, interpret the book and its content. The last stage is criticizing the book.

We went through the details of each stage. They represent the ideal of analytical reading. The ideal means it's something to aim for, but most people can't, and books don't need this. The goal is to approach the ideal as close as possible.

Keep in mind that if we do analytical reading, we can read a lot fewer books as it takes good effort and time. But only well-read books matter more, and not all books need to be read in this way. The majority of books only should be inspected. We should know (and learn) which style we want to use when reading.

Aids to Analytical Reading

So far, we talked about (and learned) reading a book alone, without going to other resources, singling it out, or intrinsically reading it without getting external help. That was intentional because without intrinsic reading, we cannot (and shouldn't) look at supporting material, reference books, or commentaries because they can alter our judgment, opinion, and criticism of the book. Focusing on understanding the book alone is the first thing we need to do. Then, only then, we can look for external aids to understand better or criticize the book fairly.

The first external aid is relevant experience. We talked about them before in the book: common and special experiences. Common experience can be brought to the table when we're reading a philosophical book. There is no laboratory needed, only a chair and time to think. The common daily experience can aid learning and understanding. In special experience, there is an additional great effort required. A historian might have spent years reading historical documents that not an ordinary person can access, or a scientist may work in labs and find results that an ordinary person cannot do. These special experiences can come into play when reading scientific books; as readers, we must follow (and be able to) the arguments and basis of what we're reading. If we can't, we need to go back to the basics and learn there to continue reading the book.

We can use other books as external aid (extrinsic) to our reading. Some books already require us to know earlier books as they base arguments on the previous work of others or the author's previous books. These cases can only be covered (and the author's point/arguments can only be learned) when we read these books in a certain order. We come across these cases more in history and philosophy than in science and fiction. Philosophers read each other's works more than others and build arguments based on them.

There is another category to use as extrinsic help: commentaries and abstracts. It's crucial to understand when and how these works should be used. Using commentary without reading a book and understanding by ourselves is dangerous. We are prone to errors in our judgment and limit ourselves to the point of commentators. If we use them to enhance our understanding and criticism, they are useful. Abstracts are also only useful when we use them to understand what the book is about when deciding to read it or not. They are unhelpful in reading and understanding the book as a whole. We have to form our judgments by reading the book ourselves, not by learning from others. Others (including the author's abstract or introduction to the book in the first pages) can only explain from their perspective and leave out many details about the book.

As the last category of extrinsic reading aid, we can look at dictionaries and encyclopaedias (reference books). Before using any reference book, you must have four kinds of knowledge. 1) You must have some idea about what you want to know. You cannot wander around. Even if it's vague, you must know what you're searching for. 2) You must know where to find what you are looking for. 3) You must know how the knowledge is organized in the reference you'll use. How the reference tried to arrange the information (alphabetical, chronological, subject-based, etc.). 4) The information you seek must be considered knowable by authors (You cannot find answers to "What do men live by?" as it cannot be stated as facts, but only unsupported opinions).

Dictionaries tell you more than you expect. You must learn abbreviations in dictionaries. They tell you the etymological and historical background of words and phrases. Every word represents a culture and historical knowledge. Understand them.

How to Read Practical Books

Reading practical books changes a few rules that we talked about before. Not just the rules but also how a reader approaches the reading. There are two kinds of practical books; one is like a guide (how to do a thing or a cookbook) that tells you how to do things to get a result. The other ones are concerned with the principles that generate rules that must be followed. Most books in politics and economics fall into this category. It talks about the theory of a practical thing, but we can say that it is practical.

There is a distinction in reading practical books. Whatever the book is about, the reader has to take action for the book to reach its purpose. If there is no action, the reader doesn't accept the book's methods or doesn't understand the book. The author also tries to persuade the reader by adding narrative to the book, but, in the end, it's on the reader to accept and act in the suggested way. If the book is about how to read a book, the reader will never learn if they never try the methods.

Agreeing with the author requires finding out what the author wants the reader to do and how the author wants the reader to do that thing, and the reader belongs to the audience the author intended to write for.

How to Read Imaginative Literature

Imaginative literature demands understanding behind its surface. If we ask someone why they liked a novel or what they liked in it, many become speechless. They know what they feel, but it's much harder to describe it. When they can't describe, they probably didn't read the book to its fullest.

There are some "don'ts" when it comes to imaginative literature reading. Don't resist the impact it has on you. Imaginative literature is about communicating experience, and their language is not as precise as the expository. The language often makes you feel something instead of removing ambiguity. The second "don't" is that you don't look for terms, propositions, and arguments. Imaginative literature teaches you only if you do your own thinking (learn from the story and experience), but you have to extract yourself, while expository literature demands that we must first try to understand the thinking the author had done.

The last "don't" is don't criticize the book for its truthiness, correctness, or consistency in communication. The author doesn't try to give you the truth. Or what happens in real life. The story might not reflect even anyone in the real world even though all the places they talk about in the book are real.

General rules for reading imaginative literature:

Structural (understand the structure)
1. classify the book in its category
2. Grasp the unity of the whole book. You should be able to explain the book's plot (even for poems) in one or two sentences.
3. Discover how the whole is constructed by parts. Find the individuals, characterization, incident, etc.
Interpret the book
1. Know characters, live through the events, and understand their episodes, incidents, thoughts, and speeches.
2. Be part of the story, put yourself in, and understand how the background is connected to the story. Live in it, befriend characters, and understand the connections between characters, events, and the background they stay.
3. Follow characters through their story and adventure. These rules help you understand the writer but don't press too hard. Experience and enjoy the story. These rules help you figure out what you like in a story and why you like it.
Don't criticize the book until you fully appreciate what the author has tried to make you experience. Don't criticize the world the author created. Criticize what the author made with that world, what they make of it. We cannot agree or disagree with an imaginative author; we can only like it or not.

In summary, you make an honest appreciation of the book (live through the experience the author created), then you're competent to judge (explain what you like/dislike and why).

Suggestions for Reading Stories, Plays, and Poems

Reading imaginative literature has its own rules, and here, the four questions also apply to stories, poems, epics, and plays that we must answer, albeit a bit differently.

What is the book about, as a whole?
What's been said in detail, and how?
Is it true or false, in whole or part?

These three questions are straightforward to answer, or at least similar to other literature we talked about before. The 4th is "What of it?" is trickier and often doesn't apply to poems and stories. There is no action to take (most of the time) after reading it. If any imaginative literature piece urges us or makes us react to a thing, we should do it with caution.

How to read stories: Read quickly with total immersion. Let the characters get into your mind and heart. Live with them, be part of their lives to understand them. Don't judge them by their decisions until you're sure that you lived with them. Don't criticize a character until you're sure why that character does a certain thing, and if then, stay unjudged as long as possible. Sometimes, you won't get to know every character in a long novel, but it's okay. Imagine you moved to a new town, and you're learning things and the people around you. It's the same. And if a book says something to your heart and you can't put a name to why you liked the story, look for your deep feelings, like what satisfied you? Justice? Love? Sadism? Masochism?

Epics are the most honored but least-read literature because it's very difficult for authors to end the story. Hence, it's challenging for readers to read as well. However, they are as great as other fiction pieces and need to be read as the same, and gains will be much better, if not amazing.

Reading plays: Plays are a special kind. As most of the time, they don't include how to direct it (lift it to the director). It's up to the reader to direct the play. And have to. While reading, imagine you have a bunch of actors waiting for you, and you give them directions on how they should play. When possible, read out loud if the play is old (e.g., Shakespeare's) so you understand better, even if the words are old.

Most plays are not worth reading. They are written for acting and should be acted. Especially tragedies (Greek tragedies) play a special role. As we know almost nothing about how Greeks directed the plays, we cannot fully judge. However, there are two things to keep in mind. 1) The time is limited in these tragedies, and it's reflected in the characters' decisions and how they approach the situations. If they had enough time, they could have decided better, etc. 2) Greek tragedy actors wore buskins and masks, while the chorus didn't. Buskins elevated them and made them look like giants (elevating tragedy).

When reading poems, we think that we won't understand them and that it's difficult to understand. Therefore, we often don't put effort into even finishing it. Most poetry doesn't demand that much.

The first rule is, like in other fiction, to read it through without stopping, even if you don't understand at all. Without seeing the whole, you cannot understand anything because a lyric poem is a whole, and parts alone don't give the picture, although they help build the message.

The second step: read again but read out loud. Your ear catches the nuances and rhythm your mind cannot catch while reading silently. It helps you understand better.

In lyric poetry, you don't come to terms with the author; you must discover keywords and question why those words came up.

Last, most lyrics are about conflicts. Conflicts with time or love, or both. Try finding and understanding that conflict. Sometimes, this conflict or that keyword won't be mentioned in the poem at all, but it's your job to discover that conflict.

The last tip is to read the poem again and again. It's a lifetime of work, and in every read, you'll discover new things you didn't see before.

How to Read History

To understand history or read it well, we must first settle on the term history. There are two kinds of history. One is the facts that happened in the past, and the other that tells some story about the happened fact. History is stories around an event, a fact. It's difficult to know the truth of what happened because the witnesses are dead, and we're only left with narratives. That's why historians leave no stone unturned before they make up their minds about an event. As we cannot do the same research, the first rule of reading history is to read more than one resource about an event or a period if we want to understand it. Also, history not only shows us what happened in the past, but it also shows what has happened up to now. An event that happened thousands of years ago still impacts today. That's why the second rule is to read history to learn how an event changed the world in years and how it still impacts now.

The questions we ask in history books are the same as in any expository work. Yet, we need to change our expectations and approach them a little bit differently. We need to state what the book talks about and what not. We need to understand how the historian decided to tell the events and what's the outline. Then we need to understand clearly what's been said. Only then can we criticize. We can criticize the work's facts only if we know if the historian is misinformed or uninformed. Otherwise, we can only criticize the storytelling. The last question, "What of it?" is the most applicable question. The answer lies in the practical and political actions we take.

How to Read A Biography

Biographies are stories of real persons. The definitive biography is a scholarly work about someone important. They can't be about living people. Definitive biographies are not easy readings. There is also authorized biography. But it's not unbiased; they are often commissioned by family and friends to show someone's life. As it has this characteristic, we have to be careful when reading. They are usually biased. The last group is ordinary biographies; we expect the person to know their work and responsibilities to tell the facts and do their research like other historical books.

How to read an autobiography: Take autobiographies with a grain of salt. A person cannot write fully about themselves because they probably don't fully know themselves. We might still learn about the person from their book and, how they wrote the book, how they approached writing events that happened in their lives.

If we want to learn about a person's life, we should read as many biographies as possible, including an autobiography (if there is one).

We should still ask the questions we ask in any book and don't criticize until we fully understand what it says.

How to Read About Current Events

We still need to ask the first four questions about the events we read. In addition, we need to know the author when reading about current events. We need to ask a series of questions to understand any author writing about current events:

What does the author want to prove?
Whom do they want to convince?
What special knowledge do they assume?
Do they really know what they are talking about?

The most important thing is: "Let the reader beware." The author can have an interest in you understanding things in a certain way. Be aware of it.

How to Read Scientific Books

You don't read classical mathematical or scientific books to become knowledgeable in the area; you read them to understand the problem author tried to solve. That's why the same expository questions apply, although their answers might be more challenging. That's why try to state the problem the author has tried to solve as clearly as possible.

You might face challenges when confronted with math in science books. But math is just another language that you can learn the basics to keep reading. It's not something to be scared of. Often the math in popular science books or classical science books is not that challenging. Again, don't try to be competent in the subject matter; your goal is to understand the problem.

Read actively (read math in elementary reading), try to understand the problem, and ask the same questions as for other expository work.

How to Read Philosophical Books

Children ask great questions, such as "Why are people?" Their questions are mostly related to understanding why, and it's remarkable. We mostly have no answers to those questions and somehow either dismiss them or do not even try to answer. Along the way to adulthood, we evolve this curiosity to a more practical side: how. We shape our minds with education (school and parental) and ask questions that are useful in everyday life. Philosophers are exactly asking the same questions as children do but trying to answer as wise adults.

Philosophers ask about being and existence, change or becoming (why things change, or what is change), and good and evil (and how they are separate from right and wrong). Philosophers ask these foundational questions in even more topics, such as knowledge, etc.

We can group these into two:

Questions about what is or happens in the world fall into theoretical philosophy.
Questions about good and evil, right and wrong, and what ought to be done or sought fall into practical or normative philosophy.

Of course, there are many sub-branches in these two divisions. What is right/wrong, good and evil, in the individual belongs to ethics. The same but for society and its relation to the individual belongs to politics or political philosophy. The knowledge questions (what's involved in our knowing anything, limits of knowledge, etc.) fall into epistemology. There are many more subbranches, but we have no space to explore all of them here.

Philosophy (up to 1930) was initially interested in first-order questions. These questions are the ones that can be understood by lay readers. These questions are related to everyday life, meaning they can be thought and understood, and tried to be answered by everyone. There are also second-order questions that are aimed at first-order questions. For second-order questions, try questioning the questions. That's where modern philosophy is interested. These questions can't be answered by lay readers or ordinary people. Today's philosophy is aimed at other philosophers like science does. It's not for ordinary people. As a reader, we need to separate the aim of philosophical work. As philosophy is nothing but thinking, philosophers also make mistakes and try to think about things that can be understood well by scientific methods.

There are five philosophical styles a reader of philosophy should be aware of:

The Philosophical Dialogue: The style Plato started, and probably there is no other greater than Plato. The work is read with a narrative and drama. Plato, or Socrates actually, discusses a matter with a group of people, and Socrates embarks on a series of questions—the fundamental ones—and tries to answer them and discover. Moreover, he tries to let readers discover themselves with narrative.
The Philosophical Treatise or Essay: This style has similarities with dialogue but missing the drama. It has a philosophical beginning, middle, and end. They state the problem first, go through the subject matter thoroughly and treat special problems along the way or last.
The Meeting of Objections: In this style, a question is asked first. Then the work goes over wrong answers one by one, and, at last, the philosopher gives their own answer. The objections are found to lead to truth. Or at least, that's the thought in this style. This style hasn't been used much.
The Systemization Of Philosophy: Spinoza and Descartes tried to systemize philosophy using mathematical techniques but failed so. These works are very difficult to write and to read. Also, this style is questionable: is it possible to write philosophical work with math?
The Aphoristic Style: This style leaves the impression on the reader that more is said than what is actually said; the reader does much of the thinking (e.g., Nietzsche, Thus Spoke Zarathustra). The author often touches on a subject, suggests a truth or insight, and jumps to another.

What should a reader do?

First, try to find the question or questions that a philosophical book tries to answer. That's the most crucial one.
Don't take the shortcut of reading books about philosophers, their lives, and their opinions.
Respect the terms and initial propositions of the books and understand them and share the same language.
Pay close attention to the philosopher's principles.
Read the book with the method it's written: a philosopher does nothing but think, and the reader has to do nothing but read, and, as we know, that means think about it.
Make up your own mind. When a philosopher disagrees with an argument, they have long conversations with each other. It shouldn't trouble you. You shouldn't disagree just because someone disagrees. You need to think about it yourself and judge on your own and for yourself.
When reading theology: Accept the fist-principles of the book while reading. If you don't have faith, at least accept the principles, and put your judgment aside while reading. After that, make your own judgment, much like any other expository book.

How to Read Social Science

To understand how to read social science literature, we need to define what is social science. There are many fields considered in social sciences such as anthropology, politics, and economics, and some are left out (especially in universities), such as law and education. Universities divide them according to educational purposes: Law schools educate professionals who will work in the field while anthropology and sociology are dedicated to the pursuit of systematic knowledge of human society. However, while defining how to read social science literature, we will include all in social sciences, such as law, business, psychology, anthropology, economics, sociology, education, and public administration.

Reading social science literature is both easy and difficult at the same time. It's easy because we often know the jargon, and narrative is something we're familiar with. But knowing the jargon and metaphors also makes it hard to read. Because these terms have a very wide meaning and they are sometimes convoluted. Even the authors are often confused, and, as a result, readers, too. Moreover, readers often have perspectives and stand on the subject. It's difficult to step back and read without judgment. Readers can't easily put their disagreement aside and hear the author's arguments as it is, accept them, and understand them fully. In hard sciences (math, physics, etc.) this is very easy to do because the terms and propositions are well explained at the beginning of the work (if not, they are concretely defined in the literature). In social science literature, it's quite the contrary. The authors don't define everything. Therefore, the first step of reading social science book is figuring out what kind of book it is. Then figure out terms and propositions, and arguments. But the question, "What of it?" requires considerable restraint on the reader's part.

Moreover, social science reading requires reading multiple books at the same time. Because it's difficult to just form a judgment reading only one book. As it includes narrative and the problems we mentioned above, we need another form of reading: Syntopical reading.

Syntopical Reading

So far, we have talked about reading one book. We abstained from exploring and reading multiple books. When we want to learn more about one subject, we must find books about it. Knowing multiple books are written on a subject is the first requirement of syntopical reading. Knowing which books to read is the second and much harder requirement. Meanwhile, defining the subject we want to read is a challenge. When we want to read about a topic, how do we draw the lines, borders, and limitations? We can start looking at literature, but where will we stop in our search for books to include without reading them? It looks like a paradox. Without knowing the topic, we cannot find books; without reading the books, we cannot draw the border in the topic. For example, if we pick the topic of love, how are we going to decide on the topic and create a bibliography in the vast literature about love? Without reading the literature, we can't also draw a border.

This paradox is the essence of syntopical reading.

When we gather the books we want to read on a topic, how are we going to approach them? If we have a hundred books about the topic, it will take ten years to read them analytically. That's why inspectional reading is an essential part of syntopical reading. Within those hundred books, you shouldn't read any book analytically before you read all of them inspectionally. Inspectional reading will give you clues about the topic you are focused on and help you in your analytical reading of some books, and it will cut down your bibliographical list into a manageable size. If you're good at inspectional reading, you'll shortly recognize if a book says important things about the subject or not. Once you have identified, by inspection, that the book is relevant and you want to keep it in your bibliographical list, you can proceed to read it syntopically (not analytically). Analytical reading is for one book only.

Five Steps in Syntopical Reading:

Find the Relevant Passages: In syntopical reading, your concerns come first. You are not reading the book to understand and learn the author's concerns and what they say; you are reading because you are trying to solve your problem. Therefore, after you identified the books, take another inspection and find relevant passages that fulfill your needs. Don't do this step together with identifying the books because your understanding of the problem is often quite vague while identifying the books. Furthermore, the passages you find can be totally unrelated to what the author wrote that passage for. The author's intentions can be different, but they are not the people in front here; you are the master of the topic, and you make the call. It's about how you understand and interpret.
Bring the authors to terms: While reading syntopically and facing various authors, we see that each uses different terminology. They may use different words for the same thing or the same words for different things. That's why we must force authors to use our language instead of using their language. This is very challenging as, so far, we have always tried to understand the author and put our thoughts and prejudices, and words aside. But we have to refuse to pick any author's terminology and take even one more step and also refuse that no terminology will be useful for us (author's terminology). That's why we must translate authors' language to our language and bring every author into our terms.
Getting the Questions Clear: After we face the challenge of getting authors to use the same terms and propositions, we still have a difficult job. The best way to ask them questions is to ask them in order. The questions must be framed in a way that helps us solve our problems, and simultaneously, all authors should be able to (imaginably) answer them. Most probably, authors have no answers in their books, but we have to think and assume as if they answer the questions, how would it be? What would they say? Moreover, the order of questions is important. While ordering questions, there are main categories in this order:
1. existence of the phenomenon or idea we're investigating.
2. how the phenomenon is known
3. the consequences of the answers we ask above. The order can differ from subject to subject; it is the general guideline.
Defining the Issues: If the questions are clear and we know that authors can answer in a way, then the issue is clear. However, we rarely see some problems: authors understand the question in the same way but answer in opposing ways. It's up to the reader to sort out these answers and group them. It's on the reader to relate these answers and join them as much as possible.
Analyzing the discussion: Our job as a syntopical reader is not merely to answer questions we prepared thoroughly. we have to accept that the truth can be found in opposing and conflicting answers, if it can be found at all. The truth can be found in the ordered discussion itself. To present this to our minds, we must ask questions in order, and we must be able to defend that order; we must show how the questions were answered differently and why. We must point to the feedback we examined to support our classification of answers. Only then can we claim that we analyzed the discussion and understood it.

The opinions in the discussion can all be wrong; none of them can be true, or each opinion can be part of the whole truth. It's possible that all conflicting opinions are also false.

If an analysis tries to prove or disprove any opinion or perspective in the discussion, it joins as another perspective or voice to the discussion and loses its objectivity. The syntopical approach tries to look at all sides but takes no sides. We must try to take all possible sides and try to exhaust them even though it's impossible.

While doing so, we shouldn't join the discussion as a new voice; we should refer back to the original texts of authors and read them again and again and present the results to the audience, and quote the author's opinions in their own language.

Good Books vs. Great Books

There are good books, great books, and books that don't deserve anything more than skimming. Good books and great books are less than 1% of all the books out there. Within millions (or billions these days) of books, >99% don't deserve more than skimming. <1% deserves analytical reading. And within that 1%, only less than around a hundred books demand returning to it after one analytical reading. Good books are books that stretch your mind. They make demands on you. Once you analytically read them, you can put them on the shelf and not return back because you milked them dry and got all you needed. It advanced and grew your mind.

When you come across a great book, and you analytically read and put it back on the shelf, something will call you back, and you'll want to read it again. You don't know what it is, but something inside you will tell you to read again, and when you do, you'll see/learn more than what you got the first time. That's a great book that adds more every time you read. And these books are very rare.

We should all seek books to stretch our minds. TV and radio just give information we don't need. It's like a drug: we use and want more of it without any gain on our minds. When we train our minds, we don't deteriorate. Instead of artificial probs like TV and radio, we should seek out activating our minds.

Reply via email | Reply via Mastodon | Comment

CTOs are expected to do more in 2024

Tue, 01 Oct 2024 17:01:42 GMT

There is also the other side of this. Let's not put everything on C-level people; we can build some empathy.

In the recent event I joined (CTO Craft Con Berlin), Füsun Wehrmann mentioned how the CTO role evolved and how expectations and role definitions have changed.

What I learned from Füsun's talk was that the CTO role expanded from mostly operations to a business-driven approach.

CTOs are now expected to know how to run a business, including finance, product management and strategy, and people.

The most significant impact of this change requires CTOs to do more about transforming how the organization leads/manages budget and people, aligning the organization structure and roles to drive better product development, managing and up-skilling the talent, and hardening the hiring process.

We can say that this is eventually the craft of executive leadership. However, I want to emphasize that CTOs affect organizational decisions; they are also under pressure to expand their knowledge to understand the business as a whole, including finance, product, etc., going beyond operational management and technical leadership. This is not an easy thing.

Reply via email | Reply via Mastodon | Comment

Employer market will turn into employee market in time

Fri, 27 Sep 2024 15:25:42 GMT

Currently, the tech market is an employer market, not an employee. Organizations are using this to their advantage. But don't forget this situation will change in time.

These days, during the interviews, employers can ask all candidates to fulfill two or three different roles, which they normally expect one person to do.

These days, it's okay to ask for a manager to do hands-on coding along with all their other responsibilities. Yet, employers are not careful enough what they are asking for. A hands-on manager rarely works (except for startups).

Employers can call everyone back to the office (hello, Amazon), expecting people to resign if they don't want to. Employers can play the cards, hiding behind "cultural investment," even if they know it hurts the diversity and inclusion efforts they spent so much money and effort on.

Employers have the upper hand because not everyone wants to change their jobs during these difficult times.

However, employers have to keep in mind one thing. Employer branding is like an insurance. You have to make your contribution first before you need it. When the market returns to an employee market[^1], it will be too late for you to change and adjust your plans in the game.

So, if you're holding interviews or planning to hire, think about your long-term plans. Hiring really good employees is still a big problem for everyone. If you're looking for a person who can do three roles simultaneously, maybe you should re-evaluate your strategy.

Whoever is interviewing for a job these days, good luck!! Don't forget that if you fail an interview, the problem is not fully on you, especially now.

[^1]: This expectation is a privilege. It doesn't apply to all markets; I can talk only about the tech market.

Reply via email | Reply via Mastodon | Comment

Short definition of a good software engineer

Sun, 22 Sep 2024 15:25:42 GMT

Forget about career levels, roles, archetypes, or whatever is written in career frameworks. I have one filter to define a good software engineer.

A good engineer is the one I, as a manager or peer, can turn my back on and leave after they get a task/problem, knowing that they will deliver the solution with good quality, again and again.

It's the manager's responsibility to explain why they are doing that work, give all the context, and clarify open questions. After that, a good engineer can take the job, request help when they face challenges, ask more questions, coordinate with others, and then tell everyone who needs to know they are done with the work. They are proactive and reliable. That’s it.

The size of the task or problem will vary depending on the person’s experience and knowledge level, of course. The expectations will definitely be different between junior and senior engineers. But even a good junior engineer—with very limited knowledge—can get a lot of work done and gain trust.

Use whatever career progression framework you want; it doesn’t matter. A good engineer will be a good engineer everywhere if they do whatever I said above. Work details, expectations, processes, and technical and social challenges will differ in different organizations. That’s why if someone can keep being reliable and deliver the work with good quality in different organizations, they are, by definition, really good (or one of the best).

Reply via email | Reply via Mastodon | Comment

Retiring from The Idea of Retirement

Sat, 14 Sep 2024 16:30:00 GMT

I'm not here to tell you that you should be working for a monthly salary for the rest of your life. Also, it’s not about passive income or financial independence and definitely not a promoter of a hustle culture. That's not the main idea. The main idea is this: accept that you should do things that bring you joy AND align your financial investment for them, and do this till your last breath without stopping and relying on a monthly retirement salary. Now that is out, let’s go into why.

People tend to think, at least in Germany and Türkiye, that they will suddenly stop what they are doing after a certain age and let younger generations pay for their salary. That’s something I struggle to accept.

The problem with this mentality is that people rely on it too much. They postpone their lives today and restrict themselves from doing what they want. Take me as an example. My retirement day is practically at least thirty years ahead. Until recently, I have been acting like my job was a disease that will go away in the future. I believed if I put in the effort, I could retire earlier. It was like a drug addiction.

However, I was addicted to being in my comfort zone. I was afraid of discovering what I wanted to do every day. I also knew I would work to make it happen if I could chase that. But, as I avoided that daunting task, I let myself slide into the comfort of being a hard follower of the system. I researched retirement mechanisms. The solutions I found were focused on making my retirement better or earlier.

The system is built well in Germany, where I live. All employees and employers have to pay a mandatory pension contribution. There are also government incentives to invest more—to increase my retirement salary. Yet, all of these force me to stay in the system. They don't even want me to look outside. The system is all I need, and as long as I stay inside, I’m “covered.” But actually, I’m not.

First, the system is facing struggles. The system is resilient enough to survive for decades with so many patches around it. However, as the world population ages, the system will eventually be overhauled. As the young generation is less interested in paying for the elderly, has less trust in the system, and wants to live in the moment more instead of getting delayed gratification, they don’t opt-in to the system. This shift alone puts the system under heavy stress.

We see new ideas and brave plans to solve the issues of the existing system, like universal basic income. However, as the minimum wage always falls behind the current prices, basic income will fall behind, too. People with basic income will have to work their whole lives to cover ever-increasing prices. This brings me to my second point.

The retirement system is not too old, actually, albeit it feels like an eternity. We don't need to go too far. Thanks to Otto von Bismarck, Germany introduced the first old-age insurance program in 1889. Simply put, my father’s grandfather didn't have the retirement option. He worked until he passed away. Although he probably had tons of problems, he never thought about retirement. He tried to raise kids who would look after him when he was old. That was the method back then. Now, we have replaced kids and relatives with government entities and private companies to provide support for old age.

The government providing this service helped people focus on other things beyond survival and getting enough kids to support them. At least, in theory. Similar to the idea of a basic income, when we added the retirement system, it wasn't enough to support anyone's dreams. It partially removed the necessity of having kids. Right now, in most cases, pension income is barely enough to provide food and shelter. Thus, people have to work toward having enough savings. Then, when they retire, they can maintain their standards (whatever they are). The system doesn’t aim to give you a comfortable retirement life.

The system focuses on getting more out of you while it can (when you are younger). So, you work more, save up as much as possible, and join additional retirement initiatives—bringing more economic value. The system wants you to contribute more at the cost of your time. That brings me to the famous Seneca.

He says, "In guarding their fortune, men are often closefisted, yet, when it comes to the matter of wasting time, in the case of the one thing in which it is right to be miserly, they show themselves most prodigal."

We waste our time like it’s an unlimited resource. It’s not new to anyone that life is actually short and can end anytime. From this perspective, investing in retirement that will come in 30+ years and sacrificing living fully today sound unreasonable.

Seneca continues, “Can anything be sillier than the point of view of certain people—I mean those who boast of their foresight? They keep themselves very busily engaged in order that they may be able to live better; they spend life in making ready to live!”

To me, sacrificing today to invest time for retirement is literally what he says, “…spending life in making ready to live.” So, how do we stop wasting time and begin living? First, we need to find out what “living” means.

It means having a purpose and accepting that time is limited. It means deliberately choosing what to do and what not to do rather than allowing others to steal time from our lives. Contrarily, retirement means you have found and fulfilled that purpose; it means you’re done. And that’s where I struggle.

For me, the purpose of life is searching for that purpose. That’s the job. The chase, the utter determination in the effort of search, the relentless seeking. It forces you to adapt to the changing world, not build expectations for the future that one day all struggle will stop. It demands training like an athlete for that purpose, enjoying the time with an ever-changing priority list. It asks you not to lose time with seemingly innocent but utmost time-wasters like Facebook, Instagram, or the latest news. It invites you to make the journey more enjoyable by building things that matter—like real relationships with family and friends and community around rituals—and seeking timeless ideas. To be able to do all, it also tempts you to make the journey safer.

This is where the government incentives and financial investments come in. The journey can only be safer with a flexible financial investment strategy. Instead of relying only on forty years of commitment to retirement schemes, the aim should be to build a portfolio to cover unfortunate events and have enough savings to cover detours during the journey. Building this portfolio is easier said than done. Learning where to invest always starts with a goal. Once the goal is set on making a safer journey, the rest is another journey—making mistakes and learning from them.

All moments, directions, decisions, steps, or detours are part of the main journey. All of them are expeditions full of surprises. However, once we focus on having the journey rather than setting a goal, life becomes more manageable. Even though some actions might be similar to those who work for their retirement, we can choose the activities we enjoy today, not those that drag us, and align our money to build a safer passage over high mountains.

Reply via email | Reply via Mastodon | Comment

Building A Strong Ownership Culture in A Team

Fri, 16 Aug 2024 08:43:00 GMT

I’ve been advocating for giving space to the people and creating an ownership culture in the team for a while. I’ve seen many managers fail in these and become micro-managers and get stuck in the same role, failing to grow as a leader, too.

I had some concerns about creating this culture when I formed a new team before. The real challenge behind forming a new team is the absence of a common culture, but it is not an empty canvas. The team members inherit the culture from their previous teams (even within the same company, teams have their own cultures). Yet, the team still needs to find its own. I did some research, observed other leaders, and learned from them.

The path I took and the applied strategies worked. I then reused some of these strategies in two other (existing) teams and also worked. My sample size might still be small, but I can say that it works for different organizations, teams, and people for a reason.

I realized that the strategies give people a purpose and motivation. Once they catch that hook, they become intrigued by what they are doing, and their engagement increases.

Of course, these strategies are still not everyone’s trait. We also had a few people who left because they wanted something else. And that’s okay—it will always be.

It is time to talk about our path and the strategies I used and still use. Each of these strategies can be found in books, nothing novel. I will keep them short and focus on their essence, as they can also become their own articles.

The best leaders I've observed aim to create a culture where people

take full ownership proactively (accountability + responsibility),
learn (growth mindset),
help each other (trust),
bring themselves to work as they are, and
help others deliver work effectively and efficiently.

If the team is immature or full of inexperienced people, creating this culture takes immense time and energy from the leader. Leaders have to let go of many responsibilities, one by one, to succeed. Without having experienced engineers helping, they won’t be able to delegate anything. However, they have to find a way to let things go to increase their impact on the organization.

I get help from individual team members to manage the technical side. I provide them with context, bring clarity to the work, and make prioritization clear. Then, I coach them to find their way around. It's not as easy as it sounds, and I’m still trying to find the balance here. However, it all starts with holding regular one-on-ones.

Leading Through One-on-Ones

A while ago, I wrote about how I hold one-on-ones with my team and what I expect from each team member. I won’t repeat it here, but I focus mostly on how to lead people through one-on-ones.

As an engineering manager, I put a lot of work and energy into one-on-ones instead of day-to-day hands-on software development (unless/until it’s needed). one-on-ones are the best way to build trust and rapport, exchange feedback, and create alignment.

After a certain amount of regular one-on-ones (my sweet spot is between 2-3 months), people start bringing up problems and sharing information without me asking anything. We discuss those problems and exchange opinions. Once I understand the person’s background, skills, and capabilities, these discussions evolve into a different shape as I nudge them to bring recommendations along with the problem.

If someone sees a problem, they almost always have an opinion on how to approach it. My goal, as a leader, is to quickly set the stage for them to share those opinions freely and seek feedback as early as possible. Then, I can guide and help them grow. If they don’t share any opinions and, instead, expect a command, it indicates that they either don’t have the skills and experience yet or are hesitating to share their thoughts. For the former, we invest in building their skills. For the latter, we go back to square one. Hence, one-on-ones are the single place where these things become apparent, and without one-on-ones, other strategies will never work.

When I said, “I put a lot of work and energy on one-on-ones instead of day-to-day hands-on software development (unless/until it’s needed),” it doesn't mean that I am away from discussions, problems, or building solutions. I still challenge their recommended solution, nudge them to consider alternatives, or offer an alternative if they can’t find one. I offer my help, and we work on it together until the team evaluates trade-offs and is comfortable with the solution.

Some people still feel lost with me guiding them. In this case, I handhold them, and we really work together as close as possible. However, if they know what they are doing and are experts on the topic, I leave them as free as possible.

Adjusting the one-one-one strategy is the demanding part of leading because every person is unique and needs different levels of guidance in different stages of their careers. However, the most rewarding part of this is seeing people grow with purpose.

Another side effect of one-on-ones is extracting new mechanisms that can be implemented in the team.

Implementing Mechanisms

I was inspired by the book Turn The Ship Around when I read, "Instead of preaching, implement mechanisms that will support ownership." I implemented several strategies, such as auto-vacation approval and expert decision-making. The team members are free to take a vacation anytime they want; they can make their own decisions with a condition: instead of asking for approval, they look at our roadmap and commitments and decide whether they can take a vacation or not. If they are unsure, they can ask for it anytime.

Expert decision-making was another strategy that allowed people to decide on the approach, solution, and next step on their own if they were domain experts. Everyone on the team has access to every system and data and can use whatever they need for their work. Moreover, they can also decide how a feature should be implemented. We, as a product manager or an engineer manager, rarely write granular requirements (except business rules) for the engineers; we want them to discover and ask questions. If they need guidance, they reach out. At first, this looks like wasting engineers' time, but it’s quite the contrary; once they understand why and what they are doing, they produce better work. And we give them the why and what part of the problem; they focus on how.

These are just two mechanisms and not the only ones. The trick is showing them that they have the power to decide on more than they think they can and guiding them through risks. This takes a lot of effort to establish and demands adjusting the team’s rituals and processes as well. But before all, it requires transparency.

Transparency Means Context and Clarity

Every time leaders talk about transparency, they struggle to understand what people expect from them. There is always a question in their minds: how much can I share?

The most suitable answer I've found to demystify transparency is about giving context and providing clarity. If people don't know what's around and what’s coming next, they can't decide whether to take a vacation or not. If they don't know the mission, strategy, and roadmap, they can't decide how to implement a feature or design a system. If the person has enough context to make an informed decision, that is enough. If their decision is too risky without knowing certain things, I focus on bringing them context and clarifying every open question they have in their minds.

I learned that giving a person every possible piece of information equips them to solve a problem (and that's what matters). Transparency is not about unhidden things; it's about sharing the proper context with people and equipping them to solve a problem or make a better decision.

Once they are equipped with information, the next intuitive step is setting clear goals and keeping people accountable.

Setting Goals and Accountability Cadence

In this stage, there are three aspects of a team: having individual goals, team goals, and, in their intersection, an initiative ownership mindset. These should be established simultaneously in a team. Only after having these established can we talk about accountability.

Individual Goals: During our weekly or biweekly one-on-ones, we focus on anything my direct report has in mind (I start the meeting with the question, “What’s on your mind?”). One-on-ones are sometimes day-to-day work and sometimes challenges they face. However, I set separate 30-minute one-on-ones recurring every 6-weeks dedicated to personal development. I first understand the person’s background, wishes for change, and lacking skills while assessing the organization’s needs in my mind (in the best scenario, they should be aligned; however, it’s difficult to always achieve this). Then, together with the direct report, we develop a maximum of two to three goals with a target date set after six months. During the six-month period, we review the progress in every one-one-one and identify if the person needs any additional support. Having goals and closing them after six months helps people form an accountability cadence. As they are responsible for their own development, when they don’t achieve goals, together, we look for “the why” and change what’s needed.
Team Goals: Besides individual goals, we have quarterly OKRs (Objective Key Results) set for the team. We often split an OKR into milestones. We then split these milestones into two-week-cycle (or sprint in Scrum) goals. The cycle goals are focused on achieving something by the end of the cycle. Having three levels (OKR, milestone, cycle) of team goals helps the people structure their work. Also, cycle goals give a constant feeling of achievement, which motivates people, drives them, and makes them feel valued. When we don’t achieve them, it becomes good feedback for which we can act.
Initiative Ownership: In staff planning, I assign a dedicated person responsible for an OKR and its progress, splitting the work into milestones (and correctly sized smaller chunks) and ensuring the milestones are achieved. Each quarterly Objective or Key Result has an owner from the team. These owners also own the project’s milestones, which are represented by Epics on Jira. Epics are a chunk of work that should be completed within a certain timeframe. The initiative owner is responsible for splitting the epic into tasks/stories together with the people working on the feature/project and reducing the risks by making initial discoveries. Furthermore, initiative owners also manage stakeholders up to a certain point (e.g., communicating blockers and sharing progress). The whole system helps the team learn how to lead without authority and be accountable for the milestone’s delivery.

While three parallel approaches stretch the team’s and individuals’ skills, bring a sense of achievement, and give them “a seat on the table,” not everyone has the skills to work in this system. Moreover, most of the individual goals demand acquiring new skills or learning something more deeply. That’s why we invest in building expertise.

Investing in Expertise

People are often left alone when it comes to becoming experts. Many managers don’t take the time to help others become experts at something. As the managers are less knowledgeable on the deep topics engineers do, they feel lost in supporting their team’s individual goals.

In our case, once people started building up an ownership mindset, I realized that they lacked expertise in various skills, albeit being good at their jobs. The knowledge they had was good enough for day-to-day work yet not deep enough for solving complex problems. Simply put, they didn't have enough tools on their tool belt. And that's where we put focus.

Defining individual and team goals helped us see where we lack the expertise. Then, we gave people time to research and learn and also created opportunities to mentor each other. When these were not enough, we found trainers within or outside the company.

In one example, we realized that a team was missing deep knowledge—a granular understanding of Coroutines work in Kotlin. While improving our systems, they struggled to find good solutions due to a lack of knowledge. We tried to find mentors at first, but we needed a quick solution that would work for engineers across teams. Mentorship wasn’t a good choice. There, we also realized that people spending their education budget on getting individual training would cost more than group training. This is why we organized a few hands-on workshops with an external trainer over a few days to ramp up the knowledge as a group. After the workshop, they were confident about tackling the challenges we faced, and this also gave everyone a base to talk about and solve common problems.

While we invest in people’s expertise through mentorships, workshops, and more, I believe the real deal is learning by doing. Anyone can learn the theory if they put in the time and energy, but if they can’t practice those skills, they will be unable to retain the information. This is the place where the delegation comes into play. It’s not easy, but it brings remarkable progress.

Delegation for Career Growth

Once people started building expertise and stepping up to lead initiatives, the next logical step was creating opportunities (especially for individual goals) through delegation. Delegation also has a side effect: investing in our own growth as managers.

As leaders, we often deliberately focus on things we do well. We take real care of our responsibilities, but these do not always necessarily contribute to our career growth.

Tasks such as meeting facilitation, backlog refinement, feature delivery planning, or technical refinement can be delegated to senior/staff engineers depending on people's career plans and skills. If the manager already knows how to facilitate meetings, refine the backlog, or plan the delivery and did it many, many times, it’s a good starting point to delegate. Once the team members work on these tasks, they also learn how to approach holistically, the complexity of work, the details of the feature/product, and how to manage stakeholders.

This delegation is not restricted to “soft skills.” For example, we delegated Observability improvements to one person who wanted to improve their knowledge around observability, monitoring, and alerting. That helped the person to develop, and the team closed their gaps. And now, when someone has a question or struggles with something in that area, this person jumps in and gives them help and mentors them.

(Side read: The Real Difficulty of Engineering Leadership is Not What They Say.)

Conclusion

All of these may sound like a lot of work. All I can tell you is yes, it is. It’s a long journey, and we put a lot of energy and time into working through all of these and more others that I didn’t mention here. We had many frustrating moments, failed remarkably in each section, learned a ton, and tried a few things differently. But isn’t this the work of engineering leadership? I think it is. You plan long-term, take a step, adjust it until it works, and take another step while keeping your head up and focused on the future. Once I put a holistic picture and long-term vision in my head, all of the small actions we took were aligned and aimed at the final picture.

Needless to say, the whole process is not (and will never be) a set-once-and-forget-it. It’s a continuous process and adaptable to anyone. You need to be resilient, relentless, and focused. Moreover, you have to have the people who want to put the work together with you. If you have a team of missionaries who just implement the code and don’t care about the rest, then you won’t get any results. Also, you have to have the right organization—not every organization is the best candidate to implement the whole system. However, if your organization develops its own product, then you can probably apply a few things from here to your team, if not the whole system.

I’ll finish with a quote I love and keeps me motivated to look and learn more things:

“If the only tool you have is a hammer, it is tempting to treat everything as if it were a nail.” — Abraham Maslow

Reply via email | Reply via Mastodon | Comment

Krishnamurti and Seneca on Freeing the Mind

Wed, 31 Jul 2024 10:40:00 GMT

Jiddu Krishnamurti, whom I admire for his ideas, talks about what binds a person.

“Cultures create religions but not the religious man. The religious man comes into being only when the mind rejects culture, which is the background, and is, therefore, free to find out what is true. […] Such a person is not an American, an Englishman, or a Hindu but a human being; he does not belong to any particular group, race, or culture and is therefore free to find out what is true, what is God. No culture helps man to find out what is true. Cultures only create organizations which bind man.” —Jiddu Krishnamurti

When Krishnamurti talks about the cultures, he doesn’t say anything specific to any culture or doesn’t choose anything fanatically. He says we must abandon—or reject—our cultural background to find what’s true. He points out that the influence we grew up with binds our thinking and how we see the world. Loosening our ties with our background seems like a solid path to understanding what’s true. Yet, we rarely see it happening.

Looking at the extreme right-wing politics that are popular these days. Most of the time, people stick to their cultures and object to any changes from a newly joining foreigner or an evolving world. Instead of loosening the ropes from the culture, people encircle their minds with whatever they have learned until now.

Therefore, as much as Krishnamurti’s way is an excellent challenge to think and understand ourselves, it is imperfect.

People cannot untie themselves from the culture they are in, let alone reject it. The culture represents their knowledge, experience, and life. It’s what it brought the person to today. Even though they might join another culture, change themselves, or even live in solidarity, they will always carry the remarks from a culture they are (or were) part of. Removing the cultural constraints from the mind is unattainable. I know it’s a philosophical approach and understand the intention, but I can’t agree with its applicability.

Also, the fish don’t know that water exists.

I think Seneca offers a better approach:

“Do you ask what you should avoid more than anything else? A crowd.”

“Clothe yourself in the mind of a great man; stand aside for a while from the opinions of the common crowd.“ — Seneca

This is easier to recognize and apply. When you follow any group fanatically and think that they are taking the truest approach, then you’re in danger. You must seek the right way instead of following a group just because it’s more crowded. When you do, you’ll often feel alone.

I often felt that I didn’t belong to a group I was in. Yet, it didn’t help me find “the right way” so far. Maybe finding it is chasing the impossible; it’s not achievable. When we get closer to it, we can feel that it’s wrong. We can think that life’s meaning should be something else. I don’t know.

However, I’m also happy to let this search go. Instead of seeking my life’s purpose, I’m happy to try getting rid of my cultural and religious backgrounds and waiting for life to show itself—accepting that I won’t be able to achieve everything in life according to any group’s definition and will never passionately follow a single path.

Maybe that’s what Krishnamurti talks about...

Reply via email | Reply via Mastodon | Comment

How to Give Feedback on UI/UX Design as an Engineer

Sat, 27 Jul 2024 09:20:00 GMT

We had a conversation with one of my designer friends, Maria, a while ago. We talked about the usefulness of engineers' feedback on designs and how to make it helpful. I pondered the topic after our discussion.

My friend was doing user research and experimenting with different flows to design a new feature with the best user experience. After a few ideas were shaped and passed the usability testing, they prepared some wireframes for different flows to talk to software engineers and get some early feedback. They walked through the ideas and were ready to take notes. The feedback they received varied, ranging from "I like it" to challenging users' behavior. That’s where we started our conversation and realized that many engineers approach design-walkthroughs incorrectly.

Engineers should approach the designs with two fundamentals in mind, in this order:

Understanding the users and their problems
Evaluating the designs’ feasibility

When it comes to understanding users’ needs, there is no distinction between the two groups. Many engineers can argue that it’s the product designers’ job and they should build solutions to solve users’ problems. As engineers are responsible for building that solution, they also must understand the user before giving any feedback on feasibility.

In my experience, engineers lack this part the most. It’s impossible to decide how to build a system correctly without knowing the user’s needs. Yes, it’s possible to implement a UI design without understanding the user. Yes, it’s also possible to give feasibility feedback. I have done both in my career. However, when it comes to making the feedback useful, it’s very difficult to offer an alternative solution to the design team.

Once engineers understand users’ needs, the focus shouldn’t be on “liking the design” or “finding it makes sense” (I heard these words from engineers many times) but rather on feasibility—thinking about how difficult it is to implement the solution. This is where the debate should be between design and engineering, bringing out the real value of collaboration.

Designers get early engineering feedback to measure feasibility without wasting too much time on small details. While considering implementation details, engineers should be able to offer solutions like, “Implementing this design is complex and will require a lot of time to get it right; how about we do this section a bit differently?” or “How about adjusting the flow in ‘X’ way and that can help us to resolve a few complex bugs too?” These comments have great value for both designers and engineers and focus on finding the best possible solution.

After that, giving overall feedback on designs is still useful and helpful. Any feedback can give insights and spark new ideas for designs. However, the main focus should always be understanding the user and then giving feedback on feasibility.

*P.S. I didn't focus why design teams hold these feedback sessions on this post but Maria later pointed out that they use the sessions to invite everyone to ideation and ensure the team is up to date throughout the intire process. I think it's a great addition to collecting feedback; aligning and involving everyone is always a good way to foster culture of innovation.*

Reply via email | Reply via Mastodon | Comment

Integrating Deep Work into Manager’s Life

Fri, 26 Jul 2024 15:57:08 GMT

In a manager’s life, the manager tries to immerse themselves in deep work but fails to do so and ends up in shallow work due to many meetings they can’t avoid. In everything they do, they try to restore energy that was depleted in sudden bursts of shallow but demanding work. That’s, at best, inefficient and ineffective.

They struggle (at least I) to find a way to organize their workload and time, but they are often not the owner of their schedules. The nature of the work demands adapting to other people’s schedules. Hence, they need to be extra mindful.

:::note[Note for myself as of 2024-07-26] I keep thinking about what I want from this world or my life. Yet, I also ponder if that’s even necessary. If there is an activity where I can feel satisfied, immersed in deep work, work on a better schedule (than many meetings every day), and not commute, it becomes easier to do deep work and not count myself as busy. Then the rest can be a real rest, and I can also have idle time to replenish my energy. Instead of a curse, I can embrace and enjoy busyness and even keep myself very active in it. :::

Related Note(s):
Resourced:
- Csikszentmihalyi, Newport, and Pressfield on Creativity, Time and Deep Walks in Remote Work;

Reply via email | Reply via Mastodon | Comment

Nature heals

Fri, 26 Jul 2024 00:00:00 GMT

Nature heals all the pains, sufferings, struggles, and challenges. Watching the sunset makes you forget the daily concerns; watching sunrise can give you another perspective.

Sitting idle on the beach adds no value to your life in terms of modern expectations; however, it’s one of the most valuable and precious moments you can experience. The sound of the waves, people chatting in a distance on the beach, and music coming from far away that you can’t even distinguish its genre; they all make you feel something—a feeling that is hard to name. Maybe, you don’t need to name it even; you only feel. You only experience.

Especially when you don’t worry about recording the moment on your phone, the moment you see with your eyes instead of seeing it through your phone’s lens, that moment itself becomes scratched to your brain, to your heart, and to your soul. That moment you never forget and can live anywhere again and again.

Reply via email | Reply via Mastodon | Comment

Two words to change mind

Tue, 16 Jul 2024 00:00:00 GMT

The reason I’m sending these emails is that I’m challenging myself to write my thoughts to make sense of the world around me. Also, I know that some people have only discovered this road. But it doesn’t mean they share the same experience. Many people travel to the same places, but everyone sees things differently.

Many methods and strategies are already out there waiting to be digested and turned into practice. Yet we don’t take the time to look outside, apply what we find, and make our decision-making easier and better, resulting in a less risky, more rewarding, wealthy, and delighted life.

But…

The situation often seems like a giant tangled ball of yarn threads—it is impossible to know where to start. Whenever we begin untangling a thread, another mess appears. However, I finally found a thread to pull, which split the ball into pieces.

A few years back, I learned two words that not suddenly but progressively changed the direction of my life. Researching what lies underneath these two words and practicing what I have learned enhanced not only my life but also those of others around me. Those two words were mental models.

Mental models are frameworks for understanding and interpreting the world around us. They help us reflect reality correctly, eliminate misperceptions, and guide our thought processes.

A good example is Chesterton’s fence: it tells you to understand the reasons behind an established practice. Software engineers tend to rewrite already working code to make it more modern. People often trust themselves too much and remove some seemingly unnecessary parts of the code during the rewrite, resulting in bugs. Thinking with Chesterton’s fence, they pause before deleting the old code and ask, “Why was the code designed like this in the first place?” And that question is the essence. The answer will reveal valuable information that is often missed.

Another mental model is second-order thinking, used to understand decisions' ripple effects and long-term consequences. In first-order thinking, we look for what would happen if we decide on something, focusing on immediate results. In second-order thinking, we look for the consequences of the results. We actively think about the indirect effects the first decision will cause later. In the above example, engineers can rewrite the code in various ways. Using this mental model, they can choose the best strategy to prepare the code for the future.

The existence of mental models was probably the best thing I’ve ever learned so far. Knowing various mental models across disciplines, such as physics, economics, psychology, business, and systems and complexity theories, helps me make sense of the world around me. (We’ll not get into all of them, but I’ll write about them from time to time and introduce you to a few crucial ones.)

As Charlie Munger, one of the best investors who have ever lived, says in his talk on April 14, 1994:

“You can’t really know anything if you just remember isolated facts and try and bang ‘em back. If the facts don’t hang together on a latticework of theory, you don’t have them in a usable form.”

The goal is neither memorizing the facts of the world nor mental models but to use these models to turn the information we have been bombarded with into well-shaped knowledge.

Here is a quick list of mental models from the Farnam Street Blog. Bookmark the link, skim it through, read a few models here and there, or indulge in them.

Until next time, Candost

P.S. A marvelous book is available free on a greatly designed website.

Some Things I Found Great

The Need to Read: I agree with Paul Graham, who says, "People who just want information may find other ways to get it. But people who want to have ideas can't afford to." The more I read and write, the more I think reading outweighs all other methods (e.g., watching a video or listening to a podcast).
Omnivore App: I've been using Omnivore for a few months now, and it has taken its place as my go-to reading list and content aggregator tool. I use it for RSS, email subscriptions, and saving articles to read them later.
Adaptive Socio-Technical Systems with Architecture for Flow: A good watch for the people in software engineering leadership positions if you want to learn how to combine several management frameworks with software architecture.

Recently, I published on my blog

Reply via email | Reply via Mastodon | Comment

An article about Biden's debate on TV and defining retirement

Sun, 07 Jul 2024 15:25:42 GMT

Recently, we were talking with a few friends about what we would do if we won the Euro Jackpot. With the same friends, we also talked about defining retirement, and in there, we tried to be specific with defining the goal for retirement to find out how much money would be needed. All we wanted to find out was how we should invest our money today and what risk portfolio we should employ.

I have no answer to any of those. I still struggle with answering the first question, “What would I do if I retire today from a job I love doing?”

Well, I read an article on The Atlantic (remove paywall here) that somehow touches these topics in the light of Biden’s latest debate on TV (I didn’t watch and also didn’t know about it until I read this article, and still don’t know how it went).

When I disconnect the article from Biden, the short interview gives food for thought in some other directions related to retirement.

A quote from which I learned Grihastha and Vanaprastha and related a lot:

“…that many successful people get stuck in a stage called Grihastha—which is where you enjoy professional success and adulation—rather than progressing to Vanaprastha, which is where one should become more of a teacher (“crystallized intelligence”).”

A short and good read. Recommended.

Reply via email | Reply via Mastodon | Comment

Embracing the Joy of Missing Out (JOMO)

Mon, 24 Jun 2024 07:00:00 GMT

A lot of events happen around us every day—at work, at home, in the city, the country, or the world. New movies come out, concerts are planned, and new books are launched day after day. We glance at them as we prepare our never-ending to-do list, which reaches an all-time high. We envy people who are lucky enough to cross those events from their list and who are not hesitant to let the world know that they did. Looking at our lives again after a look on Instagram, we feel that something must be wrong.

In our struggle to allocate time or money, we prioritize places where our friends go, read bestsellers or popular books, and watch TV series everyone talks about. That popularity-driven mindset lays off consciousness and puts FOMO (fear of missing out) into the driver’s seat. This journey often seems never to end. But there is a way to take back the seat from FOMO.

In the last few years, I began seeking inconvenience and reducing my interactions with attention-seeker pop culture applications. While everything is trying to get my attention by offering me convenience, entertainment, or a feeling that I (should) belong to a group, I stay away from many of them. I rarely watch movies, TV series, or TV itself. I don't read daily or the latest news. I try traveling less (it doesn't always work, but I try). I don't use social media like Instagram, Twitter (X), Facebook, or TikTok. After consistently doing these things, I discovered a new feeling: instead of living with FOMO, I now embrace living with the Joy Of Missing Out (JOMO).

As I miss out on a lot of things, my favorite phrase became “I don’t know,” and this gives me joy. The delight of not knowing what's happening in the world at any time is immeasurable. Life is much more fun when I don't spend hours reading the daily news that I forget in a week, scrolling Instagram to see a ton of ads and posts from accounts I don't follow, watching a mediocre but popular TV series, or reading an average but heavily marketed book.

Instead, I cherry-pick movies, events, concerts, and books. I can watch the things I love again and again (and again), knowing that they will give me exactly what I want. I also don’t watch any movies or TV series recommended by algorithms. Instead, I use the best gauge to understand anything’s greatness: time.

The key is waiting long enough for anything to reveal its excellence. 99% of the time, the hype is over in a few days, weeks, or months, depending on the marketing budget for the event, movie, book, etc. Once the first hype wave is over, I evaluate if I want to wait a bit more. More often—also to my surprise—wait dispels the mist and unmasks the real value. However, deciding the length of the wait has a learning curve.

The waiting time is weeks for “latest” news, a few months for some movies, a few years for some music albums, and a few decades for some books. It differs for each. Learning the waiting time is the learning curve of building JOMO. You have to control your emotions, let go of your urges first, and catch them again at the right time. There is nothing scientific. It’s a matter of practice; once you’re fine with missing out on a few things, you learn when and how to enjoy. However, I must admit that JOMO is challenging as it is against human nature.

Humans have evolved and succeeded as a species because of the harmony we form in groups. We are much healthier when we are part of a group or a community. On the other hand, JOMO (eventually) makes you feel like you are not part of a group. When people talk about a topic you have no idea about, you feel alone. After various times, you don’t feel like you belong to the group anymore. I learned a way out of this situation.

I look for sub-groups within communities. In each group of friends, there is a variety of interests that are not shared by everyone. Finding them and forming smaller sub-groups based on them works remarkably well. If the group is diverse enough, I always find someone who wants to do things similar to me. After doing this with a few people from the same group but separately, I eventually felt I belonged to that group despite not contributing to the common denominator topics.

JOMO is my new way of life. It’s about being fine with missing out on things and even embracing this mentality. The trick is learning when to get involved and push yourself to join others and when to ignore the urge that pops up inside yourself. Choosing intriguing topics requires self-discovery and a learning curve. But once achieved, life becomes easier and more meaningful.

The purpose is to enjoy life while being fully yourself. That’s what JOMO is about.

Reply via email | Reply via Mastodon | Comment

Learn How to Work with Average Talent

Fri, 21 Jun 2024 07:28:47 GMT

Any leader in a mid-to-large-sized organization has to learn how to run a team or an organization with average talent.

You can't always hire the best of the best. You can't scale a team at a good hiring pace when searching for the best engineers. Even if you try, you'll make mistakes and hire an average or low-performer. Or, the best ones will have life circumstances that will make them average at some point.

Working with average-performing talent is unavoidable. Therefore, any leader must learn how to work with them.

A leader's job is to grow talent and help the team bring out the best in them. That demands recognizing which skills are missing in a team member and setting up the proper mentoring or coaching arrangement. Moreover, it requires setting the team culture correctly to allow this growth.

Only then can team performance start increasing. Only then can the team start looking into how they can improve their systems. Otherwise, the team will be doomed to failure as they try to solve issues with half-baked or mediocre solutions.

Reply via email | Reply via Mastodon | Comment

Know where you spend your money on

Wed, 12 Jun 2024 00:00:00 GMT

There is no place or time in the education system for learning how to manage money. Nobody gives us this crucial education besides our families, so we have to take things into our own hands (as my family is not rich, I can tell they also don’t know how to manage money). So, it was time to get my hands dirty and learn how to manage money. Today, I will take you to the first step.

Forget about the stock market, accounting system, funds, bonds, or all the other mechanisms; I didn’t even know how I spent my money. I set aside some money every month to fool myself into thinking I would be safe in the future. I was delusional in thinking that my monthly amount would make me rich one day. I had no plans; even the amount I put aside was arbitrary.

My monthly savings was based on how I lived with the rest of the money. I followed some general convention that told me to save X% amount of my salary every month. Although I never found these constructive, I obeyed.

I didn’t know where to put that money; I kept it in a checking account (not even savings). I still don’t know how to invest money, BUT I know where I spend my money and how much I want to save and invest every month.

One of my friends recommended that I should get last year’s bank statements and go back line by line, categorize them, and look where I spent the money. I reserved some time on a rainy Sunday in Berlin and did exactly that. Luckily, my bank already uses categories and automatically assigns transactions to these categories, so I didn’t have to do everything. However, I still scanned line by line to ensure all categorizations were correct.

So, here is my spreadsheet, which I update every month. Of course, the numbers are not there because I will ask you to clone the sheet and adjust it to your needs: change categories, add new sub-categories, or do whatever you need. You’ll see that it’s simple—it should be. This first step won’t cover all the details, but it’s good enough to make the invisible visible.

My bank statements didn’t tell the whole story; as Germany still goes full gas on cash payments, I had to spend a lot of money cash. Yet, I was able to catch some details, such as the money I spent on subscriptions. Each looked small: 5-10 EUR per month—a coffee price, so to speak (remarkable marketing strategy). Yet I had many of them, and they reached a thousand euros when combined yearly.

At any given moment, you should be able to tell how much money you have and how much you spend on what. That awareness is the real deal. Once you know what you spend your money on, you can start thinking about all the rest. Learning that information requires collecting data. My recommendation now is to go back to your bank history and fill out the spreadsheet. If you rarely use cash, then you should be fine. Then, look for common patterns on which you spend your money.

Without looking retrospectively, it’s impossible to plan a future. Only looking at the past teaches us a lesson. In routine life, there are subtle and invisible differences we recognize only in retrospect. So, you might be rigorous with your spending today, but without a holistic look, you won’t catch the patterns. When you change some of those patterns, they will change your life, too. What did I change? I canceled my subscriptions (many of them), which I was using rarely. Also, I realized that owning a car costs a lot of money. I don’t have a car anymore (I was thinking of buying one again, but after looking at the costs and my rare usage, I realized it isn’t worth the money), and lastly, I reduced the amount of money I spend on impulse purchases on Amazon.

After this, I started keeping and planning a budget. Now, I have a budget that I track weekly. My next step is learning more about investing. Both budgeting and investing are our future mediation topics. As nobody teaches these topics, it takes time and energy to learn. I’ll share when I get there.

Meanwhile, I’m sure some of you already figured out those things more than I did. Do you have any recommendations for me on how to learn about investing? If so, just reply to this email.

Somethings I Found Great

No Wrong Doors by Will Larson: Don't use the phrase "It's not my responsibility." Rather, take a step and show the right door to the people.
Master Your Attention: Schopenhauer's Strategy Against Clickbait by FS.Blog: Although I don't use social media, I realized that my attention span is very low. It's always good to get some reminders of what I can try.
F1 Canadian Grand Prix 2024: Pure entertainment (once you know the details of F1)

Recently, I published on my blog

New notes on my Zettelkasten

P.S. I keep this website bookmarked and use it in the beginning of some meetings to break the ice.

Reply via email | Reply via Mastodon | Comment

Selective Learning

Mon, 10 Jun 2024 00:00:00 GMT

Annie Dillard He is careful of what he reads, for that is what he will write. He is careful of what he learns, for that is what he will know.

The things we read shape how we see the world. The books, articles, or newspapers we read are the words of others; they open someone else’s world. If we’re not careful of what we consume, we may let immoral or trivial ideas affect us. Especially when we’re writing—shaping our thoughts—others’ ideas will influence ours. And in turn, our text will influence our readers. The information we receive every day also comes at a cost. Selective learning is the challenge of our modern world. We can’t, and shouldn’t, turn all the information we receive into a piece of knowledge. We have to be picky and discard 99% of the information around us, especially what people call the latest ones. Then, we must discard the 99% of the remaining 1%. Only the remaining ideas will be worth knowing.

Related Note(s):

Reply via email | Reply via Mastodon | Comment

Click and Run

Sat, 08 Jun 2024 00:00:00 GMT

In small favors that are often invisible, we give a lot of automatic responses. If someone cuts the line, we become frustrated, but if they first ask to pass us while giving a weak reason, we give them the place. The reasons don’t have to be strong and logical. Any illogical reason also works as long as there is a reason tied to the request.

Related Note(s):
- 30: Scientific Thinking and Fact-Checking for A Better Life;
Source(s): Influence by Robert B. Cialdini

Reply via email | Reply via Mastodon | Comment

Perceptual Contrast

Sat, 08 Jun 2024 00:00:00 GMT

If you would like to use the perceptual contrast principle in practice while trying to convince people, offer them the worst option first if you want/need them to exaggerate a better option and evaluate it to be better than it really is. If you want/need someone to stay away from an option, show them the best option first, and then they will think the following options are much worse. A good example of this principle is real estate agents. They keep one or two bad houses in their portfolio and never sell them. They show these houses first to the people. Then, the next houses will look much better than they really are, and people will tend to overpay for those houses.

Related Note(s):
- 19f: Three Approaches to Decision-Making Styles;
- 32: Communicating Decisions in Organizations;
Source(s): Influence by Robert B. Cialdini

Reply via email | Reply via Mastodon | Comment

Feedback is mutual

Sat, 08 Jun 2024 00:00:00 GMT

Related Note(s):
Source(s): Influence by Robert B. Cialdini

Reply via email | Reply via Mastodon | Comment

The Rule of Reciprocation

Sat, 08 Jun 2024 00:00:00 GMT

We should try to repay what other person provided us.

We observe that the rule of reciprocation plays a big role everywhere. Almost all political environments work with this rule. We see a lot of corruption not because people are bad but because of the strength of this psychological rule. For example, with my not-so-strong knowledge, I can see that Tayyip Erdogan puts many incompetent people in certain positions, and those people become indebted to him. Then, they went to great lengths to repay their debt to Erdogan, doing whatever he asked of them. The people continue for a good length until they think they repaid the debt. Once they reach equality, that’s when they open their eyes, stay against him, and side with logic. Until then, the strength of the rule has even beaten the influence factor (whether they like Tayyip or not).

Related Note(s):
Source(s): Influence by Robert B. Cialdini

Reply via email | Reply via Mastodon | Comment

Life Priorities and I'm Back

Tue, 28 May 2024 00:00:00 GMT

I've been absent from your inbox, and I won’t tell you that I was busy. I'm trying to get that word out of my life. Busyness is only an illusion we create ourselves to avoid confronting our procrastination or an excuse to leave our commitments unfulfilled. It’s also a common justification for saying, “I have no energy to invest in this.” So, I wasn't busy.

I focused on my physical health, which was declining, and my emotional health, which needed much more care than I thought. This healthcare activity started two years ago by focusing on my sleep, but it’s still a work in progress. I was able to increase my sleep by up to seven hours (from a maximum of six). Meanwhile, we got a dog named Leda. I can't say that Leda made our lives easier, but she filled us with joy, love, and a little bit of purpose. Lastly, a big chunk of my time spent at work, along with my energy. Why am I catching you up with my life? Am I creating an excuse? No.

There are so many sides of life that try to pull us in a direction. When we don't take a pause and look where we are going, we find ourselves in a place we never planned to be.

It’s much like a good navigation algorithm going wrong at times. Once, I was using Google Maps to drive to another city. It took me out of the main road, thinking that it would be faster because it was short. I suddenly found myself on a gravel road, riding some distance, then connecting to the main road again. I didn’t zoom out or trust my instincts. Life is exactly the same. You feel something is off, you feel lost, but you must keep going until you find a way to return to the main road.

During this seven-month hiatus, there was something inside me that was pulling me to the writing. I felt incomplete. This pull—or rather hunger—got stronger over time, and I couldn’t resist anymore. So, I’m back.

I’ll take you on a journey where I negotiate between life’s different priorities. As my wife often points out, I am never satisfied with anything as they are; you’ll observe how I play the mediator role between many topics, find the little things I can optimize, and try to find the balance.

My goal is to ensure this is the most helpful email you get in your inbox.

If you don’t want emails but want to subscribe via RSS, here is what you’re looking for.

Some Things I Found Great

BBC Reith Lectures with Historical Fiction writer Hilary Mantel — Five lectures from 2017. Start from the first one; each is better than the previous one. I’m in the fifth and my favorite is the third so far. The best part? Hilary’s wisdom in answering audience questions at the end of each lecture. My best quote: “Facts are strong, but they are not stable.” Listen to it for joy, story, intellectuality, and endless wisdom.
A Diary of a Rikers Island Library Worker — Piece by Medar de la Cruz. Simply marvelous. (Won the Pulitzer Award for Illustrated Reporting and Commentary Category)
I’m the Word “Utilize” and I’m Loving Every Moment of Your Overblown Rhetoric -I wish I wrote this. I love the provocation and thinking about the nuances of the words we use.

Recently, I published

P.S. What a simple but difficult question.

Reply via email | Reply via Mastodon | Comment

Can you explain how you manage your team?

Fri, 24 May 2024 00:00:00 GMT

If somebody asks you how you manage your team, you have to be able to explain it to them clearly.

“If all you have is a hammer, everything looks like a nail.” — Maslow’s hammer.

That means you must have a goal, strategy, tactics, methodologies, mental models, and many more in your toolbelt and know how to use them.

If you answer, “I set up processes and let them do their jobs,” you are wrong.

Yes, ensuring the team has correct processes is your job.

Yes, letting them do their jobs is also a good step.

But there are more.

If doing individual contributor work brought you success and helped you become a manager, you can’t keep doing the same. You have to read a lot of books and/or articles, watch videos, and/or listen to podcasts. You have to take the time to learn the leadership craft.

So, how do you manage your team?

Reply via email | Reply via Mastodon | Comment

Saying Something Once is NOT Enough

Fri, 10 May 2024 00:00:00 GMT

Have you ever observed how many times a leader needs to repeat a message for others to follow?

In any change, saying something once never works (at least, I've never seen it work).

It's not because people are incompetent or careless. It's because they forget.

If we, as leaders, want people to change their minds or apply a new method, there is no other way than continually and consistently repeating the message.

People will eventually learn by hearing it.

When we want or need people to change or adapt to change, what alternative do we have?

I've seen some leaders change their message (sometimes soften it) or choose another direction because they didn't get enough followers. And that created more confusion AND a lack of direction.

P.S. It's also reaaaally important to form the first decision and its message/communication correctly. If it's nonsense, nobody will follow, regardless of how often you say it. 😅

Reply via email | Reply via Mastodon | Comment

Increasing Sales Through Human Psychology

Fri, 10 May 2024 00:00:00 GMT

In my experience, my Moonlander keyboard was broken, and I asked for support to see what they could do. Even though my keyboard was out of warranty, they sent a replacement unit for free. Now, I feel indebted to them and started writing a Moonlander review blog post. They solved my needs in a very customized way.

This rule is so strong and instinctually known by many sellers they always use it. For example, we have various stalls we go to nearby farmer’s markets. And they always add one or two gifts without us asking. Later on, we found out that we went there even more and started buying some other products, too. While they are easily exploiting the rule, I’m happily going there because every time, I get yet another gift.

Related Note(s):
- 20: Influencing Others;
- 37: Setting Organizational Goals and Processes;

Reply via email | Reply via Mastodon | Comment

Vier Schritte für einen Neustart

Wed, 08 May 2024 19:07:42 GMT

Nachdem ich in meinem Text erklärt habe, wie ich die Nachrichten lese, habe ich viele Kommentare erhalten. Ich dachte, dass die Ideen so normal oder gemeinsam sind, dass ich sie nicht geteilt hätte. Aber ich musste sagen, dass ich viele Jahre lang meine Lebensgewohnheiten geändert habe. Die Zeit, Energie und kleinen Optimierungen haben mich so viel gelernt. Hier sind die ersten vier:

Klein ist groß: Man kann ohne Ziel leben, aber man muss jeden Tag lernen und verbessern. 1 % Verbesserung: Es gibt keine kleinen Schritte, jeder zählt. Kleine Schritte ziehen unwichtig aus, aber ganz und gar nicht. In langer Zeit kommt das Obst. Ob du keinen Schritt machen kannst, such die kleineren Schritte.
Schneide den Faden ab: Irgendwas hat dich festgehalten. Für mich war das Twitter/Instagram. Ich dachte immer, dass ich ohne Instagram/Twitter keine Freunde haben würde, aber ich lag falsch. Nachdem ich meine Instagram- und Twitter-Konten gelöscht hatte, habe ich meine Freundschaften verbessert. Wir sprechen jetzt viel mehr über persönliche Themen. Mein Fokus liegt dabei auf der Diskussion, nicht auf dem Handy.
Die Kontrolle muss in deinem Hand sein: Wenn du keine Kontrolle hast, übernimmt jemand anderes die Kontrolle. Du solltest nicht zulassen, dass Medien, andere Personen oder Algorithmen deine Aufmerksamkeit steuern. Danach kannst du die Kordel durchschneiden.
Alles braucht Zeit: Du kannst nicht alles gleichzeitig machen. Schritt für Schritt. Wenn du etwas perfekt gemacht hast, geht es mit dem nächsten Schritt weiter.

Reply via email | Reply via Mastodon | Comment

Consuming News Weekly, Instead of Daily

Wed, 01 May 2024 17:07:42 GMT

I pondered how I consume the latest or daily news and changed my habits (over the years).

I used to be glued to my phone, constantly scrolling through the news and feeling overwhelmed. But I realized I needed to take control. So, I decided to cut back on checking the news every day and instead set aside time once a week or every other week.

It was a game-changer. I no longer felt bombarded by the latest headlines or at the mercy of social media algorithms and lousy journalism.

As Schopenhauer said, "Not all writing is worth reading. Just because someone can put words on a page doesn’t mean they are worth reading or add value."

Instead of daily news, I started seeking good journalists who take their time to develop an article. I also began reading articles that went deeper into the issues.

Moreover, I read them in my own time (instead of when they are sent to me).

And you know what? It's made a world of difference. I feel less stressed and more in control of my own thoughts. Instead of getting caught up in the noise, I'm able to focus on what really matters to me.

So, if you're feeling overwhelmed by the constant stream of news, maybe it's time to take a step back. What do you think?

Reply via email | Reply via Mastodon | Comment

Ending My Debate with Latest or Daily News

Wed, 01 May 2024 00:00:00 GMT

In the book Digital Minimalism, Cal Newport talks about how we can live a focused life in a noisy world, and he says, “Humans are not wired to be constantly wired.” I quoted the book, but I haven’t read it yet. I guess you thought, for a split second, that I read the book because I’m quoting it here.

That itself is the problem we all have. We form a view on many things we read. We intuitively connect two dots and form an opinion. It’s the same regardless of whether we read a tweet, article, or book. And it was also one of the main reasons for me to detach myself from daily news.

The news created anxiety and forced me to worry about things that I could never change. Hence, I decided to change a few things in my life. I started consuming the news weekly or biweekly instead of many times a day. As Newport’s quote says above, I wanted to cut some wires to set myself free.

Before all these changes, I usually consumed the news via Twitter and news websites. These platforms decided how I should have perceived the world. Twitter deluded me because I thought I read different news from various sources. Later, I learned that was my flaw. What I needed was more time, not more sources. Let me explain.

Every minute, many voices come from everywhere in the world, making it almost impossible to grasp the truth. As people rarely sift the information through a sieve to eliminate their emotions and unnecessary thoughts, whatever they say will always be biased. We can’t estimate the correctness of the information, which makes it unusable.

If I can't judge whether anything is correct or not, it becomes irrelevant to my life.

Moreover, while everyone flocks to the web with unfiltered thoughts, social media lately has gotten even worse. Everyone abruptly transitioned to a journalist. Everyone interprets the impact of the war in Ukraine or the conflict in Gaza, albeit nobody can comprehend what's going on. Without any research, analysis, or even reading contradicting sides, many feel entitled to write a summary of the situation with their commentary. This is utter nonsense; just because they have a voice doesn't mean we should listen.

"Not all writing is worth reading. Just because someone can put words on a page doesn’t mean they are worth reading or add value." — Schopenhauer

I can't endure the people who make a rumpus anymore. Instead of hearing news from everyone who has an emotional attachment—thus, false assessment—to the events, I prefer to read news from professional and independent journalists who do research.

I'm a big fan of good journalism. Proper journalism opens minds, creates awareness, and pushes you to think something differently. It doesn't always comply with your thoughts. It provokes them from various angles but leaves the decision to you. And it's rare because it's difficult. And that's what I'm after.

Thus, I stopped using social media, cutting the primary source of my news habit. The next stop was news websites, the evil of a society.

There is a reason why the 'who do research' and 'independent' are bold above. Most of the news agencies are a lost cause. They are pursuing the wrong goals and steering the crowd (and journalists) in the wrong direction. They focus on speed rather than quality. Being the first reporter on any event is more important than what they say. That hasty nature of the agencies (evolving with TV and making a giant leap with the Internet) destroys good journalism. They forgot that it takes time to comprehend complex events and write about them.

That's why many journalists have introduced their own newsletters (e.g., in Substack), which they send only once or twice a week. They take the time to analyze, investigate, and write down what they find.

Thus, I stopped checking out websites focusing on the latest news, cutting out the evil from my life.

As a result of this revamp, I also realized a shift in my thinking, which made this new habit stick and helped me compound the benefit of deep thinking.

The fundamental change was how I perceived news and what I could do with it. I usually read the news as it has been published. I found myself sitting on my desk or couch, reading everything, thinking it was better for me to know these things. That was inherently wrong.

Do you remember Cal Newport's quote above?

Knowing all these events is the worst-case scenario. I am aware that they happen every single second around the globe. Although the economic crisis makes people’s lives miserable, wars affect people from close and far distances, or all environmental and education problems are present everywhere, I can't do anything about it when I read the news from my couch. I still care about problems, but I can only create an illusion for myself when I share that news with my commentary. That doesn't contribute to any solution. At all.

Also, if we look at the events, nothing has changed in the world for decades. Problems take different shapes, but they are identical. There are always economic hurdles, novel diseases, violence, wars. It's the reality of our world. If we worry about all this, there is no good living—even in prosperity.

Hence, I decided to live my life on my own terms, not on others. This change is a slow shift but a fundamental one. I still read newspapers and newsletters. The difference is I read them when I want instead of when they are sent to me. I sometimes buy paper-based weekly magazines. I often read them a few weeks later and learn everything late. And that’s OK.

If any news survives more than a week, then it’s worth knowing. When a new war breaks out somewhere in the world, it will be in the news for years (e.g., Afghanistan, Syria, Ukraine, Gaza. Pick one) and impact everyone’s lives from various angles. It's possible that I can find myself in the middle of the war, or the country I live in decides to support one side of the war. If that’s the case, I’m sure it will be impossible to escape any news. Only then will I opt to follow that specific news more frequently. Until then, it's much better to live in my small echo chamber. Some people can consider me as ignorant or this approach as bullshit. I’m aware that it’s not for everyone. And that's also OK.

These shifts are not sudden. Changing behaviors takes time. This journey took me a few years. Meanwhile, many governmental elections happened, an earthquake struck my home country (Türkiye), the Ukraine war started, the global economy was shaken, the Gaza massacre happened (and is still happening), and many more. I still know all the big events, but life is much better without knowing every single detail. Yes, I'm not so strong on day-to-day news anymore. And yes, I fall behind in casual conversations around whatever is hot. I consider the latest news part of pop culture, which I'm consciously staying away from. One last thing I can tell you is I don’t think I will look back.

P.S. This change was another addition to my decision list.

Reply via email | Reply via Mastodon | Comment

Hawthorne Effect

Wed, 01 May 2024 00:00:00 GMT

It's a psychological phenomenon that indicates humans change their behaviors if they know they are being observed.

At the Western Electric plant, a study was conducted in the 1920s to explore methods of enhancing workers' productivity. The experiment involved manipulating the lighting conditions in the factory. Workers were divided into two groups, one working under varying light levels and the other under normal light. Surprisingly, both groups showed increased productivity, regardless of the light conditions. This unexpected result led to the discovery of the Hawthorne Effect.

Related Note(s):
- 37: Setting Organizational Goals and Processes;
- 41: Characteristics of Creative Work;
Source(s): Outlive by Peter Attia, p.325

Reply via email | Reply via Mastodon | Comment

Leveraging Hawthorne Effect at Work

Wed, 01 May 2024 00:00:00 GMT

I think this phenomenon shows itself when working with any employee. When we invest time and create tracking methods to follow direct reports' career progress and improvement areas, they know that they are being observed, and they try to improve the parts we have our eyes on. This phenomenon coincides with Goodhart's Law ("when a measure becomes a target, it ceases to be a good measure"). When we (as engineering leaders) try to put a true metric to a team to measure productivity, that metric will improve because people know we will be watching that metric and will try to improve that result. The important part is figuring out how to turn this into a positive effect. This is where I see the individual development plans have the biggest impact. Once we (together with the employee) clearly define and agree on which skills they need to improve, they will focus on it and get better even when they are not directly focused on putting in extra effort to improve. It happens in the background.

Related Note(s):

Reply via email | Reply via Mastodon | Comment

On Listening to Audiobooks

Sun, 21 Apr 2024 00:00:00 GMT

As of November 2023, I have a new ritual. We have a new dog, Leda, who accompanies us in our lives. I take her out for a walk every morning. That morning walk became one of the most peaceful moments in my life.

Walks have a magical nature. They help me ponder things that I haven't found time for elsewhere.

For a while, I used the silence to think about a lot of things. I was walking with Leda at 5 a.m. for a reason; it was the most soundless time of the day.

Later, I changed the walking time to 8:00. As the city woke up and the noise filled the streets, sounds of people and cars started roaring in my head, and with it, broke the peace and my thoughts all together.

To silence the city's outcry, I started listening to audiobooks.

I managed to finish six books already. I can't say that I learned well what I listened to. I think I understood some ideas from the books, but I still need to figure out how I learn from them.

Without converting those ideas into writing, it's challenging to learn anything at all.

Verba volant, scripta manent

"Spoken words fly away, written ones remain"

I, at least, need to try to explain what I have learned. Recording my thoughts using speech-to-text might help, but I rarely use speech-to-text and haven't given it a try during an audiobook session.

That's why, if I liked an audiobook, I also bought the paper version and added it to my library. Then, I started reading the book. Building a personal library is very important to me, and the books that pass my inspectional reading (listening to an audiobook at 1.7x speed is a kind of inspectional reading) will always have a place on my bookshelf.

Anyway, audiobooks are now becoming part of my life, and I'm looking for a proper audiobook app other than Audible. It would be ideal if the authors and narrators get the most money I will pay for an audiobook. I still couldn't do a proper research. If you have any recommendations, just reply to this post.

Reply via email | Reply via Mastodon | Comment

Defining Transparency in Organizations

Sat, 23 Mar 2024 16:26:36 GMT

What most people are talking about when they talk about ‘transparency’ is what I would call structural transparency. This refers to what information is shared freely and openly across the organization and with whom. But, another critical part of transparency norms comes down to what I would call content-level transparency, insight into the raw work as it’s happening.

Content-level transparency is easier to achieve and helpful for anyone to find information easily. There is less hidden information and individuals don't need to talk to anyone to learn what's going on as the work is happening. The content is public, accessible, readable, and searchable to anyone anytime, not when the information holder decides to make it available. I think it's the ultimate culture change that can boost structural transparency. If anyone can find and read whatever is going on in an organization's other corner at any time (in the raw form), it will also push other parts of the organization to increase their content-level transparency, and the organization can increase their structural transparency.

The benefits are also cumulative: people spend less time building trust with each other, politics are reduced, collaboration focuses on creative pursuits instead of knowledge-sharing, everyone stays honest, and people can observe what/how others are doing freely.

Reply via email | Reply via Mastodon | Comment

Good and Bad Transparency in Organizations

Sat, 23 Mar 2024 16:26:36 GMT

...there is such a thing as good or bad transparency. Good transparency answers questions before they come up, brings people along, and encourages consistent and principled decision-making across the organization. Bad transparency distracts people, invites the wrong questions, treats information as currency, embraces gossip as truth, and results in politicking.

The main goal for transparency should be answering the questions before they arise. It's impossible to answer all questions by default; however, the good of transparency should encourage people to ask those questions. Then the person can enhance the level of transparency by clarifying unclear parts. Transparency is a framework for decision-making; it should focus on enabling everyone to make better decisions.

Related Note(s):
Source: Structural and Content-level Transparency by Kool Aid Factory;

Reply via email | Reply via Mastodon | Comment

Why Urban Design Matters

Sat, 23 Mar 2024 16:23:33 GMT

I've been reading Monocle since last summer, and I always love how different perspectives can find their place in the magazine. In March's issue (#171), Des Fitzgerald wrote a commentary about why parks and recreation areas are developed in the first place. He says:

The aim of the city park was never the benign provision of green space for recreation. Its aim was to guide and control — to nudge — the behavior of the urban working classes; to get them out of the pubs and into the air where they could see, and indeed keep an eye on, one another. Most importantly, park was there to maintain that most valuable of assets, the physical power of muscle: the actual productive capacity of industrial capialism, now encased in these men's suddenly valuable bodies.

I don't want to believe in this statement. Yet, my ignorance of the topic pushes me to the edge here. Recently, I started reading about managing the commercial and financial world, and my beliefs and thought lines are shaking from the ground. Thinking about why anyone would build a park if there was no commercial gain now makes sense. Although Fitzgerald doesn't offer any evidence besides one report from the 1833 UK Government committee, what he says can actually hold true: build parks to get people out of bars, boxing games, etc., so they stay healthy and can work more. Although this intention is not something I want to believe, I know that governments always incentivize commercial gains over pure public gains. I wish that governments would ensure that their people are healthier, wealthier, and happier. But I also know that there is no point in being a Pollyanna here. Truths and reality often hurt.

Source: Monocle's March issue (#171)

Reply via email | Reply via Mastodon | Comment

Weekday/Weekend Concepts are Useless

Sat, 23 Mar 2024 12:46:56 GMT

Every morning, I wake up around 5-5:30, even on weekends and holidays. Till 9:00, I don't have any routine differentiating working days or weekends. That means I don't have weekdays or weekend concepts in my mornings. When people hear me saying, "I don't see any day differently from the other. Days are in a continuation. Why would I treat any day differently?" they find it weird and difficult to understand. Here, I want to explain why.

Weekends are often considered as the time to sleep more and do things that don't get a chance during the week (e.g., going out on Friday and sleeping in on Saturday). This concept helps people relax and enjoy life. I agree. It feels good to leave the routine life and do things differently. Recovering the energy that's depleted during the working days is crucial so we can survive one more week. And here, I tend to differ from many.

Concepts like weekdays, weekends, and anniversaries are not for me. They don't bring anything to my life other than breaking my rituals (not routines). Let me explain why I see each day the same.

The problem lies in putting weekday/weekend concepts at the center of our lives.

If I have a workout plan centered around going to the gym (ideally) five times a week, I have to stick to the weekly concept. I can regularly go on Tuesday, Wednesday, Thursday, Saturday, and Sunday and plan my routines based on weeks; then, the program gets broken if I skip one day. Let's say I skipped Tuesday. Which workout am I going to do on Wednesday, then? Wednesday's original one or Tuesday's workout that I skipped?

However, if the focus is on continuing the program regardless of the week concept, I can continue where I left off. If I need to skip the gym on Sunday, I can continue with my Sunday workout plan the next day I'm at the gym.

The other factor is my sleep, the center of life. As we must sleep every day, focusing on circadian rhythm is the real deal. Sleeping in on weekends breaks my body and brain. Then during the week, I try to recover and can't get my shit together.

Weekday and weekend concepts are brought by someone in the past to help with something. And they are helpful for various things (e.g., workdays are useful for everyone working on the same day). But they aren't helpful for many other things. Instead of forcing myself to follow the process, I want to leverage them only when they are beneficial.

I still work on weekdays and spend time with family and friends on weekends, but I don't sleep in on Saturday mornings just because there is nothing to do (and there are always some things to do). I wake up at the same time on Sunday as on Wednesday because my sleep routine is more important to me than the "Friday night fun," and sleeping in is worse for my health. Of course, this is not a rule I must obey; there will be exceptions. And they have to remain an exception.

Reply via email | Reply via Mastodon | Comment

There are No Analytics on This Blog

Wed, 31 Jan 2024 06:35:42 GMT

When I read Rachel's post about analytics, I realized that I wasn't alone in this journey.

After starting to blog regularly on Medium in 2015, I became obsessed with analytics—how many people read my text, where they come from, and how many pages they have read. Then, I moved to my own website, which made things worse after I installed GA. I started playing with GA features to analyze whatever small traffic I had. It came to a point where I stopped writing, like Keenan.

I moved to Plausible Analytics to reduce the amount of data I had. Well, I thought that was the solution, at least. Naïve.

I struggled a lot with little data. I tried to make sense of what people like more so I could write more about those topics or try other formats that didn't suit my writing.

Over a year ago, something clicked in my mind, and I turned off all analytics. I realized I didn't want to become a content creator; it was such a relief.

That helped me to write even more. But, more importantly, be myself more. But when I moved this website hosting to Netlify, I (once more) turned on Netlify's server-side analytics. It collects very limited data (and that's why I opted in). Although it helped me in the beginning to learn so many 404 (not found) errors and broken links, it's not helpful anymore, and I'm not checking the data at all (maybe 2-3 times a month).

Today, I also canceled Netlify's analytics subscription (thanks Rachel for the reminder). That means no more data on visitors.

Analytics of any kind are not helpful in my journey. It's harmful because it impacts my writing (hence, my thinking).

What matters is the journey full of high-quality ideas shared with people who are kind enough to follow this blog and let me know when they have comments/thoughts on what I wrote.

P.S. This decision goes into my list of decisions that remove hundreds of decisions.

Reply via email | Reply via Mastodon | Comment

New Books for Systems Thinking and Software Architecture and Strategy

Tue, 30 Jan 2024 07:59:47 GMT

New members of the library.

Weekend will be fun!

Reply via email | Reply via Mastodon | Comment

Reading a QR Code without a Phone or a Scanner

Sun, 28 Jan 2024 14:43:28 GMT

I always wonder how QR codes work and if I could understand myself. But I never even googled it (sometimes, it’s better to stay curious instead of directly reaching for information). While “walking” around the blogs and mastodon accounts, I came across a post that literally explains how to read a QR code without any scanner. It’s fascinating to have people interested in and writing these kinds of things.

Did I need to know this information to continue with my life? Absolutely no. Did I really learn it and can decode a QR code? No. I will probably never try to decode a QR code by hand, but it was a fun read!

In response to: https://qr.blinry.org

Reply via email | Reply via Mastodon | Comment

Added Decap CMS, finally

Sat, 27 Jan 2024 17:07:42 GMT

I just added Decap CMS to my blog. It's straightforward and helps me to post more on the go. I don't need a computer and commit everything manually to git. Decap syncs everything to the repository of this blog (which is publicly available here).

Then Netlify picks up the deployment and deploys the blog.

The authentication to CMS is also configured via Netlify and GitHub, making me love Netlify even more.

To add Decap to this Astro blog, I followed this tutorial and used a few examples from this blog article from Vercel to experiment.

I don't know why I waited so long and did not add a CMS to the blog (I must admit that I liked writing blogs in VSCode, but a head-less CMS makes it easier to post things on the go).

Reply via email | Reply via Mastodon | Comment

ADRs and RFCs: Their Differences and Templates

Mon, 22 Jan 2024 00:00:00 GMT

When I wrote about Request for Comments (RFC) documents a few years back, I hadn't tried Architecture Decision Records (ADRs) yet. Although both concepts have existed for years, their popularity has increased in recent years. I finally had a chance to try working with ADRs. When I did, I realized that many people struggle to decide which one to use and when. Although there is some guidance on the Internet, I don't see any consensus on how to approach them. I want to share how I separate both and the small nuances that make the two very different.

Let's look at their names first, which I observed people forgetting and going to conceptual or wishful thinking. When I read "architecture decision records," it also clearly says that it's a decision record, so there has to be a decision to record it. When I read "request for comments," it clearly states that the main goal is collecting feedback. With these in mind, I see the natural sequencing of the RFC-first approach in significant changes. The team can start anything by writing an RFC. Then, an accepted RFC can result in multiple ADRs that explain implementation strategies and the architecture of the change.

But not every change requires an RFC. Most of the time, you need to move fast, and an RFC might take a long time and can produce a lot of noise, even though it should stop endless discussions. Or, most of the time, a team decides on a solution together that doesn't impact anyone else. Or, a few people get together and find a solution. They don't need to convince the team; instead, they ask if there are any strong objections. These are the cases for ADR instead of RFC.

I think listing down the differences and asking a few questions will help everyone better decide which one to use, RFC or ADR.

Differences between RFCs and ADRs

RFCs	ADRs
For influencing/driving a change that may (but not necessarily) take time to finalize.	For making/recording a decision that can be executed quickly.
Driven by the community culture.	Driven by the team culture.
Help to get people on board for a change.	Help make onboarding easier by giving context.
Aim to validate or challenge the idea.	Aim to remind the idea.
Help uncover hidden knowledge in other parts of the organization (by getting feedback from people) and make an unknown unknown known.	Help make better future decisions by making implicit decisions explicit.
Aim to get feedback similar to incremental product delivery: get feedback early and find the best possible way.	Aim to keep discussions short and on point.
It can be small, but the impact should be significant enough in the context.	Are small, and the impact doesn't need to be significant.
The more people contribute to RFCs and give feedback, the better the result will be.	Only the people who are needed are involved.
Should be part of general documentation.	Should stay close to the codebase.
Consensus-based decision-making is commonly used but can be consent-based as well.	100% consent-based decision making.
Longer feedback periods	Short feedback period to gather strong objections
Mostly asynchronous process	The process can be synchronous (by pairing) or asynchronous
Has one of the statuses: Draft, Collecting Feedback, Accepted, Rejected, Abandoned	Has one of the statuses: Draft, In Discussion, Decided, Implemented, Abandoned, Superseded

When do we use ADRs? When do we use RFCs?

It's better to start with an end in mind. That demands asking the question, "What's our goal?"

Do you want to introduce a change? Yes.

Does the change affect others and require buy-in? If yes, write an RFC (you have to collect feedback).
Is the change itself small, but the impact is significant? If yes, write an RFC (you still have to get feedback).
If no, write an ADR.

You collected feedback on an RFC and decided to move forward. What do you do? Write ADRs—as few as possible, as many as you need. Have you decided to introduce a change with everyone together (maybe in a meeting) and don't need to onboard anyone else? Write an ADR. Do you need to record a past decision that you still remember the details? Write an ADR.

That's it. Focus on the end result. There is no need to overthink it. Start now and evolve the processes in time. Done is better than perfect.

Templates

We also need to reduce the difficulty of writing a document and clarify expectations for everyone. Both ADR and RFC processes should be as lightweight as possible. That's where templates come handy. Templates nudge people's thinking and encourage them to structure their thinking.

Feel free to use and adapt the templates below.

ADR Template

ADR-XXX: Title

Status: Draft, In Discussion, Decided, Implemented, Abandoned, Superseded Authors: Decision Date:

Context / Problem

// Define the problem and explain the context driving the decision. What was the need? Link your text with relevant materials. Don't write a novel; keep it as short as possible but as long as necessary.

Decision & Rationale

// Explain your decision in one sentence. Then, explain your rationale in bullet points—focus on why you made this decision.

(Expected or Known) Consequences

// Explicitly list down the consequences. If you can, also think and write about the consequences of consequences (second-order thinking).

Considered Options (and why they haven't been chosen?)

// List down all the other options you considered with their pros/and cons. Explain in one sentence why didn't you choose that option.

Appendix / References

// Add additional materials that can give more context or are relevant to the decision.

Update Log: (not needed if the ADRs are committed to the repository)

// After the ADR moves out of Draft status, log changes here. A good analogy for this log is having them as meaningful commit messages.

Example Log:

2024-01-01: Moved the ADR to In Discussion
2024-01-02: Added an extra considered option: XYZ
2024-01-03: Abandoned the ADR. The problem is invalid; no solution is needed.

RFC Template

RFC-XXX: Title

Status: Draft, Collecting Feedback, Accepted, Rejected, Abandoned Authors: Feedback Deadline: Last Update Date:

Need (Context / Problem)

// Why do we need to have this change? What was the main reason why you came up with this proposal? The explanation should be as detailed as necessary to present the need. Use examples if possible.

Approach

// How are you planning to satisfy the need defined above? The explanation should be as detailed as necessary to fulfill the need.

Pros & Cons

// What are the benefits of the proposed approach? Focus on the factual benefits rather than personal points of view.

Alternatives (and why aren't they the chosen one)

// Write down at least two alternatives together with their pros and cons.

Appendix / References

// Add additional materials that can give more context or are relevant to the decision.

Update Log:

// After the ADR moves out of Draft status, log changes here. A good analogy for this log is having them as meaningful commit messages.

Example Log:

2024-01-01: Moved to collecting feedback
2024-01-10: Added a missed disadvantage for the proposed approach
2024-01-21: RFC is accepted with minor changes

Reply via email | Reply via Mastodon | Comment

Rituals, not Traditions

Mon, 15 Jan 2024 00:00:00 GMT

Last week, I suddenly had to fly to my hometown in Turkey to attend my uncle's funeral. Although this wasn't the first funeral I attended, it was the first one that I helped with organizational work. This experience taught me so many tiny details I wasn't aware of or never realized that they happened in funerals. I still don't know why we did many small things that way; I also didn't ask. Even if I asked, I know nobody could have answered logically.

After the funeral, I was talking with a German friend. I told him that I learned many things about my culture in three days. While I was explaining the traditions I wasn't aware of, he said those are more rituals than traditions. I couldn't agree more. They are better than traditions.

One example is carrying the coffin. After the special funeral prayer, people grab the encoffined body from its resting table to carry to the burial place. In a matter of seconds, tens of people try grabbing the coffin and putting it on their shoulders. While people are rushing, they also race with each other to carry it at least for a few seconds. The coffin moves very slowly, but everyone acts quickly. Nobody thinks or talks; no one has priority to carry the coffin; everyone carries it for a few seconds and hands over the duty to the next person giving a hand. This goes on until the coffin is in the burial place. This act means they show their respect and love by carrying the person on their shoulders, above themselves, on the person's last journey before they become part of the soil, going back to Mother Earth. This behavior is not a tradition. It's a ritual. It shows the relatives of the person inside the coffin that the person was respected and loved.

These kinds of rituals are beautiful and meaningful. They bring people together and close. They help form the community. When things become rituals, we do it regardless of how it goes and still feel grateful, joyful, and respectful. And that's how things are supposed to happen.

Reply via email | Reply via Mastodon | Comment

Learnings on Dealing with Ambiguity

Fri, 29 Dec 2023 00:00:00 GMT

This post is about something I learned that helped me set my expectations in various situations right and position myself better in ambiguous situations.

Since I became an engineering manager, I had more chances to observe what makes leaders better in chaotic situations. Be it an organizational change, shifting culture, or dealing with layoffs. Despite many unknowns, they solve problems in one way or another. They stay calm, focus on the problem, evaluate the constraints, and lead people to a solution. The solution might not be ideal, but in any case, I observed how they do it, their behaviors, and their secrets. Here are my observations.

It all starts with accepting the reality. Let's take an organizational change as an example. It's one of the most ambiguous situations as many teams break up or change some of their members, and nobody knows how people will react to these changes. There is a big risk of turning high-performing teams into low-performing ones. With all that, many people struggle to accept changes, except for good senior leaders. They know there is no other way than to go through that rough time. Let me repeat because this is not obvious when you're dealing with a change: there is no other way than going through it. And truly understanding that sentence helps a lot to change the mindset. Instead of arguing with reality (as Tamara Levitt says, "It hurts when we argue with reality"), leaders see ambiguity as a difficult puzzle to solve and dedicate themselves to finishing it.

As something becomes a puzzle, every piece leaders place builds the picture. Instead of putting every piece together simultaneously, they find the most important and obvious problem and solve that one first. Then, they go to the next. What they do is not new to me or (probably) you. The learning for me was realizing how this process repeats until the puzzle changes again. The puzzle rarely changes as a whole, but some parts definitely evolve and shape differently. The puzzle will never be completed, but an evolving organization demands understanding its constraints.

I don't want to dive into organizational constraints and how to understand them here because it's a big topic in itself (good reads: The Goal by Eliyahu Goldratt and Thinking in Systems: A Primer by Donella Meadows). I observed leaders have quick, deep dives into certain areas to learn more about what constraints they deal with. While they can see the big picture and approach problems holistically, they have the disadvantage of relying on others in every detail. That's why they gather people around them to learn more details quickly and untangle the puzzle's complex parts. While doing so, instead of taking the decision, they bring their holistic thinking and big-picture vision to their teams so the teams can find a way out of uncertainty.

Their actions reduce the ambiguity today and build for tomorrow. This one is easier said than done. They build a culture, change it, and rebuild it. And most of the time, they explicitly admit that they don't know. How these leaders approach the future is similar to a drawing by WaitButWhy with a tweak.

The only difference to the picture above is the leaders know where they want to reach but don't know how to get there. That's why, when asked, their answers are often vague and lack concrete solutions. Until now, they brought people on a path. And there are countless paths ahead. They can't predict the future, yet they will lead others in one path of the many ahead. That's why they focus on finding the best way in every junction and admit that they don't have all the answers.

These are not the traits I observed, but they are the ones that make the difference and show how mature a leader is. The next time when you find yourself in an ambiguous situation, come back and read this. Accept the reality and tackle problems, as Anne Lamott put it, "Bird by bird, buddy. Just take it bird by bird."

Reply via email | Reply via Mastodon | Comment

Number One in Formula One

Sun, 24 Dec 2023 00:00:00 GMT

It's a race where a millisecond can change the result. It's a race where the engineering is living on its edge. It's a race in which excellence is not sought but required. And that starts from the entrance of the building and goes deep to the screws in the car. F1 is not only a race on the track but also a competition in construction, engineering, culture, and mentality. Winning a race is only the result of millions of dollars and countless hours of work in designing materials in millimeters of precision. Yet, building that precision doesn't start in engineering. It starts with the tidiness of the reception desk, the cleanness of the toilets, and the outlook of every individual's appearance. Mercedes, who dominated the formula year after year between 2014 and 2021, is where we see the excellence. When Wollf joined Mercedes, he saw the problems right in the reception. He saw the dirty toilets. Instead of avoiding them and focusing on the car, he showed how to clean toilets perfectly. He showed how to bring the best of everyone out, and he expected an organized and clean workplace. Because he knew only then people could focus on what really mattered. Wollf showed that leadership starts with the environment and taking action instead of blaming others. Toto Wollf created a blameless culture by defending everyone in the team who made mistakes but showed authority not to tolerate unwanted behavior. The inclusive environment, where he believed in the good in people and didn't tolerate bad behavior, won the constructor's championship for eight and the driver's championship for seven consecutive years. That's the leadership we should seek out. Start from the obvious problems, solve them, and go to the next. Create a culture where everyone does the same. Once we solve the simple problems, we can focus on the more complicated and complex ones. In this culture, keep all the people who try their best without blaming anyone for mistakes, and set your paths apart with people who don't behave in the way that this culture needs.

Related Note(s):
Source: Number One in Formula One;

Reply via email | Reply via Mastodon | Comment

Using the Promotion Process to Grow as a Manager

Sun, 24 Dec 2023 00:00:00 GMT

Managers have to shape their skills according to the team's needs and the constraints under which they operate. As each team has its unique context, it's quite challenging to put all managers into one career path. Moreover, many organizations lack clarity and direction about career development for managers. That's why applying for promotion is one of the guaranteed ways to get feedback. While preparing for promotion, detach yourself from the result of the process. The process can be successful or not; it doesn't matter. If you don't get the title, you'll learn what you are missing clearly. If you get the promotion, then you know you did the right thing. If you get a negative result, don't get frustrated; use it to learn more about what's needed for the next step. Focus on your career growth over the long run.

Related Note(s):

Reply via email | Reply via Mastodon | Comment

Passing Down The Experience

Sat, 25 Nov 2023 00:00:00 GMT

When I was in the tenth grade in high school, a man appeared next to our math teacher at the beginning of a class. I barely remembered his face then, but soon after introducing himself, I knew who he was as I had heard of him many times. He was one of the most successful graduates from our high-school, just graduated before I started.

That day was a surprise for me to see that guy because the lecture was Math, not a meet-with-graduates event. He answered a lot of questions coming from us. This conversation was one of my main reasons for choosing computer science. One guy, taking a bit of time from his life and answering random questions, had such a great impact on me.

Sixteen years later, I appeared in a class next to the same Math teacher (in Spring 2023). Although I am not as successful as the other guy, I still wanted to answer questions that students might have about computer science, programming, working abroad, and life in general. I wasn't surprised to see students' questioning eyes like I had had years ago. When I introduced myself and told them I'm a 2009 graduate, their eyes broadened because it's been so long. Their graduation year would be 2023. I told my short story and career. Then, we started an AMA.

So, many questions. About computer engineering. About university. About life. About Germany. About expat life, my salary, and even racism. I answered as much as I could with full transparency. I also shared my perspective on what lies ahead in front of them, just like the guy did when I was a student.

On my way back to Berlin, I thought about this experience I had while sharing what I've learned in sixteen years. Also, I realized how much fun our conversation was. The guy who appeared next to the same Math teacher probably had the same intentions as me as I passed down the experience to students who were about to become adults. We had the same experience.

Because they knew nothing about work.

Because they have seen only a little.

Because Turkish culture doesn't allow them to be adults until they reach their 20s.

Because they have a huge exam in front of them and racing with another million people and their only job is to study.

Because their only knowledge comes from people around them, who are biased by the environment.

Because they never get someone external to share knowledge.

Because they never expect to reach a person who once was sitting in the same seat.

What I shared and what the guy shared years ago was unbiased. I had no idea about any student's life situation. They asked me questions and the only bias I had was my life, which they wanted to learn anyway.

Some of the students had curious eyes and were carefully listening to every single word coming out of my mouth. Those curious eyes reminded me of something else.

Way way back when I was again in the same high school, but in my first year, we had a project for boarding schools in my hometown. These boarding schools consist of small kids coming from villages and living in dormitories to get an education when they are seven years old. Our project was going there in the evenings and helping them with their homework and explaining some topics they didn't understand in lectures during the day. The kids were poor, there were not enough teachers, and they didn't have access to enough resources. They also didn't have parents nearby. When we arrived there on the first day, their eyes were shining because they realized they were not alone in the evenings anymore. Instead of being alone in a fifty-bed room on their beds trying to spend time or study, they were with us, getting help on doing homework.

I saw the same shining curiosity and hunger for attention and information. When I passed down my knowledge and experience, both high school and boarding school students were smiling and all looked happy.

Last spring, I once again realized how valuable it is to share what I learn and experience in life. That was the reason I started this blog, newsletter, and podcast. The same reason why I went to my high school. Holding AMAs, talks, and sharing an experience brings information about the things you can't google.

It's such a motivating interaction to meet with others and talk about life, experiences, and leanings. I am fortunate and privileged to be where I am today. I'm also aware that many people pursue my road. The only way to continue on my road is to make it better and easier for people coming after me. And the only way to do that is by sharing what I learned and experienced.

Reply via email | Reply via Mastodon | Comment

Using Delegation Checklist

Fri, 10 Nov 2023 00:00:00 GMT

When I try to delegate a job to people, I mostly consider their skills, where they want to go, the timeline of the work, the risk of the person failing, and how mature I am at that piece of work so I can help the person. I know there are more systematic ways and more things to consider. I mostly leaned on my biases in these delegation decisions and failed. I researched and asked my mentor and a few other leaders around me. Most of the time, the result was what I was already doing. I couldn't find any systematic way that can apply to my position as an engineering manager. Whenever my quick internet research doesn't give satisfying answers, I turn to my small library. This time, I found a great set of questions (in Management 3.0 book) to use as a framework. Answering these questions before delegating a piece of work should eliminate all my biases and give me the right mindset.

Is the risk factor of delegating this work adequately addressed?

Do the people have the right empowerment skills and discipline?

Have you considered and selected the right level of authority?

Have you considered the question of delegating to individuals or teams?

Is what you are delegating a discrete chunk of work?

Do the people have the skills to do this particular kind of work?

Do the people have the right format for the work products to use?

Do the people have the tools necessary to be successful?

Do the people know what the results should look like?

Did you set the boundary conditions for the work (for example, budget, time, resources, and quality)?

Do the people know when the work is due?

Do the people know what progress looks like?

Do the people know how often to report to you on progress (adhering to interim milestones)?

Is someone available (you or another person) to coach or mentor the people in case they need help?

Related Note(s):
Source(s): Management 3.0 Book by Jurgen Appelo

Reply via email | Reply via Mastodon | Comment

Essentialism Book Review and Notes

Sun, 29 Oct 2023 00:00:00 GMT

How Strongly I Recommend It: 5/10

How Likely I Will Gift It: 7/10

Who Should Read It?

Anyone who is pulled into too many directions in their lives and wants to change the situation and no idea how.

Why should you read it?

I read it because I felt the pressure to do everything, do everything right, and do whatever is expected of me. I didn't really stop and consider what I really wanted or what really mattered. I tried and struggled to accomplish many things. I read it not because I had no idea what I could do but because I needed a think-along partner in this. I already knew many things mentioned in the book, and maybe only 5-10% was new to me. However, it helped me debate ideas and reiterate what I had forgotten. If you're like me, if you have already read many productivity things and know what you can do but are still pulled into many directions, then it can be a good book to accompany you while thinking.

Reding Notes

Create a space to think, ponder, explore—a space to escape. That will help you retrospect on what happened and find what's important.
Read timeless ideas and create space to read more. Reading helps you find ideas, learn them, and debate with authors.
Listen to what's NOT said, read between the lines when people communicate, and focus on finding what their main point is.
Keep a journal. You can start with short entries every day. Read your journal every thirty or ninety days to see the bigger picture of what happened. We tend to be shortsighted with daily situations and don't see the progress or changes that happened in longer periods.
Sleep for high performance and clear thinking. 7-9 hours sleep boosts your performance. (I read this so many times and also tried to increase my sleeping hours from 6 to 7.5, and I can say that it's true.)
Clarify your essential intention. What's the one thing that you want to do? What's the one thing that will eliminate nonessential things? What's one decision you can make that will remove hundreds of distractions?
Say no to things that distract you, or you lack the capacity for. You don't have to say no directly; you can learn nice and kind ways to do it.
Be aware of biases and try removing commitments one by one if they don't add any value to the essential thing in your focus.
Limit yourself to liberate yourself. The boundaries you put allow you to be free and do more of what matters instead of everyone pulling you in different directions.
Make progress with small steps instead of a big-bang approach. Do an MVP (minimum viable product) for whatever you're doing. In the end, reward yourself with something you can see. It can be the simplest thing, like giving yourself a reward sticker or so. But make it visual.
Find your routine or rebuild yours so you don't have to think about the essential thing every single time. It should become part of your routine and turn it into a ritual that you do no matter what.
You can't focus on two things simultaneously. Focus on the essentials. And be in that moment to fully live and build the essential thing. Being present while doing what's essential is the most essential thing.
Build your life with essentials in the center and let them grow and kick out nonessential things from your life. You'll find a better life and peace and feel the progress you made with what really matters.

Reply via email | Reply via Mastodon | Comment

Building A Personal Library

Sat, 28 Oct 2023 00:00:00 GMT

Recently, I did some book shopping. All the books are related to work: leadership, coaching, behavioral psychology, and dealing with difficult conversations. However, neither the book's details nor how I am going to read them is what I want to talk about here. Today, I want to talk about why I buy books while many others are waiting for me to read.

While buying books, I had one thought in my mind: I need to have resources under my hand whenever I need them. I'm not going to read all these books during the next year or two, or some of them will be unread for years. Although I skim every book I buy to understand what it talks about, I don't think most of the books should be read cover to cover at all. Most of the business books do not deserve more than an hour or two. Yet, we should have them, know what's inside, and take them off the shelf when needed. They are there to learn quickly and get suggestions in specific situations. And that's the essence of building a personal library.

My personal library is there to offer me an escape. It gives me a hand to get out of difficult situations—be it something related to work or personal life. Both fiction and non-fiction books are my way to converse, learn, and widen my perspective. In the books, I can find myself, relate to characters, and develop my personality and professionalism. The library is like no other thing that you can have.

People often compare the internet with books and argue about having everything on the internet. To me, it's like comparing potatoes and grapes; both can feed you, but you need to cook the potatoes first. The high-quality books are like grapes; you can eat one grape without cooking. The internet is like potatoes. You must put in extra work to cook those potatoes. The internet is full of junk, so we have to do more research to validate an idea. I'm not saying that the internet is useless; it's super powerful, but it's also full of garbage, and we have to work through it to find the gems. For books, finding gems is much easier.

I must also admit that 90% of the books are also garbage. However, it's easier to identify them. Even though the book publishing business is ruthless—editors criticize the ideas in a book and make sure that the whole content is sound and clear, it's still much better than the internet. The internet is full of people like you and me, and there isn't any review process. Everyone can write whatever they want wherever they want.

That's why my library is my way of Googling. When I need to learn something, especially about topics like psychology, leadership, philosophy, and business, books are the best way to acquire that information. Many people search for a mentor but can't find one. I found my mentors in the books. They are one step away from my desk and 7/24 available. I will keep growing my library and always have at least 80-90% of the books waiting for someone to read them. But I'm fine with this because I have other plans for these books.

My suggestion to you is to start building your library if you don't have one. If you have one, try to enrich it. That's the most important thing you can do for yourself. Not reading the books is okay. Not every book deserves to be read cover-to-cover. Skim the new books to understand what they are about so you will know where to look later. The good thing is books never complain, and they will be waiting for you when you really need them.

Some Things I Found Great

There are only a few things this time. I don't always find great things online. Saying something great is difficult. Sometimes, I spend my time with crap, and that's okay. Without knowing what's bad, I can't judge what's good.

"It hurts when I argue with reality." is a sentence I heard while meditating using the Calm app, and I took a note.
Finding the World's Loneliest Person — I usually enjoy Yes Theory's videos. This one was special because it reminded me that solitude doesn't mean loneliness. Many people feel lonely while surrounded by people (like I sometimes do), and some people don't feel alone despite living solo in the middle of nowhere.
Strangers Meet Without Seeing Each Other - Pure Impressions Episode 4 — It's an emotional video. It reminds me how everyone has something going on in their lives, and we never learn until we really ask and listen. I not only loved the questions but also admired how deeply and honestly people answered these questions.

Recently, I Thought About

how I can apply second- and third-order thinking more.

While making a decision, I'm trying to remind myself to look at the second and third-order consequences of the decision. Thinking about the immediate consequences of a decision is first-order thinking. First-order thinking is often biased. That's why we need to look at what would be the consequences of consequences of the decision—second-order thinking. So, we take one more step and try to judge the side (and longer-term) effect of a decision. But if the decision is quite important, we need to also think about the third-order consequences. I learned that if I don't set some time aside, I will never think about these things. That's why I decided to change a few things in how I think and work and ensure that I have time for the right things.

Reply via email | Reply via Mastodon | Comment

My wish list for the world in 2050

Sun, 08 Oct 2023 00:00:00 GMT

I was watching a video from Easy German (as I'm learning German), and they did a street interview and asked a question to the people: "How will the world look like in 2050?" While watching the video, I started thinking about how the world would be in 2050. But unlike the Easy German team's goal, I didn't want to guess the world in 2050. So, I wanted to create a realistic wish list that I believe would move the world in a better direction.

I wish the world would:

Have banned automobiles from using fuel everywhere.
Have improved the power storage systems that can be used in commercial aviation.
Have started supporting and funding environmentally friendly implementations in under-developed countries and started saving the planet.
Have made many services digital-only, such as government and life administration services.
Have figured out the dichotomy of social media and real-life relationships, and social media has evolved in a way that helps to harden real-life relationships instead of killing them.
Have no more wars (but I know there will be, as there was no time in history without a war).
Have closed the gender pay gap, and gender inequality is not an issue anymore.
Have got to a point where everyone can live freely without any oppression from others, such as issues LGBTI+ people face and racism no longer exist.
Have closed the strong division between poor and rich a little bit while the middle class has less crash in between.
Have made cities more relaxed, chill, and liveable without traffic and stress, and urban planning evolved in a way that promotes healthy living without depending on cars and travel.
Have recycled most of the materials.
Have cleaned the oceans and rivers from trash.

I know most of these things will either not happen or will be in progress. Wishing is free, and if I'm wishing for these things, I also feel responsible for taking steps toward supporting these changes. I don't know what that support looks like, but I'm starting to think about it as the first step.

Reply via email | Reply via Mastodon | Comment

Blocking crawlers for training language models

Tue, 03 Oct 2023 00:00:00 GMT

If you look at the footer of the website, all my content is licensed under CC BY-NC-SA 4, Attribution-NonCommercial-ShareAlike 4.0 International. That means none of my posts can be used for commercial purposes.

Not that I'm against AI or using language models; I just don't like the idea of any company using my text to train their language model for their commercial purposes without asking for my permission. Looking at my server-side metrics on Netlify, robots.txt has been requested ~1.5k in the last 30 days, so, some of these are asking for permission or at least looking for something.

After reading Jim's, Chris's, Manuel's, and Jeremy's posts, it was the time I set up robots.txt.

Also, I know from Manuel's experiment that most bots don't care about whatever you put in robots.txt. Even Manuel says,

So, what's the takeaway here? I guess that the vast majority of crawlers don't give a shit about your robots.txt. As for me and this site, I think I'm gonna revert back and allow bots to just do whatever the hell they want. This seems a worthless battle to fight for no real benefit to my general mission which is to connect with other human beings.

Then why do I still put in the effort? I want to choose a different way. I am not putting a worthless fight against AI, but I'm choosing the naive way and doing minor things while hoping that people will play rightly.

The only thing I can do is add robots.txt and block the following User-Agents (maybe others in the future) that I took from Jeremy's post:

User-agent: CCBot
Disallow: /

User-agent: ChatGPT-User
Disallow: /

User-agent: GPTBot
Disallow: /

User-agent: Google-Extended
Disallow: /

User-agent: Omgilibot
Disallow: /

User-agent: FacebookBot
Disallow: /

I still know that these are useless. The main problem is with the whole system as Neil put it well:

These companies should be prevented from using data that they haven’t been given explicit consent for. Opt-out is problematic as it counts on concerned parties hearing about new or modified bots BEFORE their sites are targeted by them. That is simply not practical.

It should be strictly opt-in. No one should be required to provide their work for free to any person or organization. The online community is under no responsibility to help them create their products.

Although the system is opt-out and robots.txt is useless, I still want to add it. I know that these companies are not just, but the least I can do is play the game right.

I know that the system is not gonna change anytime soon. So...

Welcome my new weakest friend, robots.txt.

Reply via email | Reply via Mastodon | Comment

Real-life vs. Online Relationships

Tue, 03 Oct 2023 00:00:00 GMT

I've been silent for a while because I was on a late-summer vacation. During this trip, I had the opportunity to reflect on my daily routines. Those who are close to me know that I have been making some changes in my life recently and trying to reduce my digital interactions. I have been writing regularly about these changes on my blog as well.

I have realized that my attention span is quite low, and this realization has made me fight against my digital addiction in order to increase my attention span. Activities such as checking my phone, scrolling through social media, and reading emails or messages on Slack provide a tiny dopamine rush that encourages me to continue with these habits. Although some might argue that staying connected with friends and family on social media can be beneficial, I feel that the overall impact of these activities is not worth the time and energy they consume.

In fact, I believe that these shallow digital connections can even weaken our real-life social connections. When we meet up with friends, we often have nothing new to talk about because we already know everything that’s going on in each other’s lives through social media. Our conversations become superficial and meaningless. While meaningless chats with friends are okay, I have found that the healthiest relationships are built on a certain level of mystery and not knowing everything about the person.

That’s why I have decided to stop using Twitter, deleted my Facebook and Instagram accounts, and reduced my reliance on the internet. Instead, I am seeking out ways to connect with others that have been proven to be effective, such as face-to-face conversations, emails (if you want to connect with me, just send me an email at candost[at]candostdagdeviren[dot]com), chat apps, or even physical letters (I would if anyone would like to try 😅).

Rather than silently following the lives of my third-level cousin's life or a friend I've never seen in the last 15 years on social media, I want to learn more about the lives of my close friends and family members. I reach out to them, call them, and ask them about their lives. I have realized that dedicating even four seconds every day to people I don't communicate with regularly can add up and take time away from the people I love and want to spend time with today. And that's not fair to anyone.

Some Things I Found Great

On Learning to Read Generously — Recently, I read Molly's great piece. I shared my notes and thoughts here.
I am leaving West Africa |S7E60| - Itchy Boots — I have been following Noraly for a long time. Her resiliency is legendary. She not only amazes me with her journey but also with her kindness to everyone and surviving (physically and mentally) alone, mostly thanks to her kindness and smiling face to strangers in foreign lands.
Aardvark'd: 12 Weeks With Geeks is a movie from 2005 that features so many people we know today in the tech world, including Jessica Livingston & Paul Graham (founders of Y Combinator), Aaron Swartz & Steve Huffman (founders of Reddit), Joel Spolsky (co-founder of stackoverflow.com). When I see all these people together, I understand the network effect on founding a business. By the way, the movie itself is terrible and very amateur.
Aaron Swartz — The movie above reminded me of the life of Aaron Swartz. A prodigy, a geek, an activist. Aaron was a remarkable person who is mostly unknown outside of the tech world (and probably many folks in the tech world also don't know). He made a significant contribution to the web, such as co-creating RSS Feeds and a Creative Commons license (e.g., I use both on my website), besides co-founding Reddit.
some people who make programming easier by Julia Evans is a fantastic zine acknowledging so many unsung heroes impacting software engineers' lives every day.

Recently, I Thought About

a team's commitment to their goals.

We always talk about a team's performance as how they achieve their goals: processes, automation, team happiness, and technical capability and knowledge. Yet, a more important driving force is achieving the goals themselves—making a commitment and fulfilling it within the committed timeframe. When a team commits to a goal, it's their promise to the organization. Regardless of the goal, they must achieve it to gain trust in the organization. When they reach the goal, they also trust themselves (and each other in the team) and work toward improving their performance.

Reply via email | Reply via Mastodon | Comment

Today I published all my notes in my Zettelkasten

Fri, 22 Sep 2023 00:00:00 GMT

Today marks a day for me. After days of manual labor and a lot of editing, I finally published all my notes in my Zettelkasten on my blog.

You can find all of them here.

It feels like it's opening years of work to the public. Although nobody will notice them, it's relieving to make them available for free to anyone. Hopefully, public notes will also nudge me to add more and more and keep better notes.

Reply via email | Reply via Mastodon | Comment

Reading and Criticizing with Enough Generosity

Wed, 13 Sep 2023 00:00:00 GMT

Today, I've read Molly's great piece called, On Learning to Read Generously;. Here are my notes and thoughts.

I am too generous with books. Instead of spending enough time with books, I spend more than a book deserves, especially for non-fiction books. So, I'm on the other side with Molly. Although I know there is no need to read every word in a book if I already get the idea, my most lacking skill is reading with just enough generosity. That's why I try to follow one motto these days: "Strong books, loosely read." Finding a strong book and ensuring that it's strong requires an inspectional read. Once I've done it, then I can do an extensive read and be generous with my time.

Molly also talks about reading critically and compares it with bad faith reading. Reading critically is another skill I want to hone. I've had too much good faith as a reader and easily accepted the arguments of the authors I've read. Because I thought if they had spent countless hours writing a book about it, they must have thought it well, and it should be closer to the truth. My thoughts became the thoughts of people I've read, and now my brain is like a weird soup. I have strong ideas coming from people I've read in certain areas, and no idea at all in others. This ties pretty much to Molly's argument of mixing up bad faith reading and reading critically. Reading critically is a fantastic skill every reader has to build one way or another. While learning that skill, I mixed it up with being unjust to the book and its author. I also thought, "Who am I to judge if a person wrote a book about it?" Molly separates them well and also pushes me to read more critically while maintaining a beginner's mindset. I now feel much better while reading because I am not trying to destroy an author's argument; I'm trying to make it even better by filling in the gaps they have missed.

Related Note(s):
- 64: Why Inspectional Reading?;
Source: On Learning to Read Generously;

Reply via email | Reply via Mastodon | Comment

Taking Better Notes

Mon, 21 Aug 2023 00:00:00 GMT

Recently, I walked through engineers in our team about how I take notes with Zettelkasten and P.A.R.A. note-taking methods. I also wanted to share here, without going into much detail, how I've been using both systems.

Zettelkasten was born to build articles, books, or posts from the ground up. Whenever you come across a piece of information, you transform this and add a small note to your Zettelkasten system, give the note a number, and link the notes to other notes by using this number. There are no folders or categorizations. Every note is placed right after another. Ultimately, you can realize which thought or information lines are getting long enough to write an article about it.

How do I use Zettelkasten for work? I keep two Slip-Boxes: one for my knowledge-based notes (sneak peek into my Zettelkasten) and one for work. Whenever I'm in a meeting, I keep notes in Meeting Slip-Box. I don't need to worry about categorization or folders. I link the new note to the main project notes, which is the most helpful move that helps me find all related notes later.

Meanwhile, P.A.R.A. was born to know where to put a new note in a system. It aims to organize notes much better. P.A.R.A. stands for Projects, Areas of Responsibility, Resources, and Archive. How do I use P.A.R.A.? Projects are where I keep work-in-progress and ideas for articles, podcasts, and newsletters ideas. Areas of Responsibility are my daily notes, career notes, and notes related to my hobbies. Resources are things I saved online, checklists, and some more informational notes that I use as a resource. The Archive consists of notes I don't need daily, such as published essays, blog articles, templates, etc.

How do I combine P.A.R.A. and Zettelkasten? I have six top-level folders: the P.A.R.A. folders, the Zettelkasten folder, and the Work folder. Zettelkasten is my knowledge-base folder and could actually fit into the Resources folder, but I keep it separate. And lastly, the Work folder includes another Slip-Box, my brag document, my Kanban board, project notes, and others.

Whenever I add a note about something I have learned, I don't want to think about where to put it; I want to think about how it relates to my previous thoughts and knowledge. That's why it directly goes to Zettelkasten. If it's connected to a project I'm working on (in the Projects folder), I link the note to the project instead of putting it in the Project folder.

I'm planning to write in more detail about my note-taking system. In the meantime, I already wrote about changing my mindset about note-taking to come to this place.

Maybe P.A.R.A. and Zettelkasten methods are something you've been looking for for years; who knows? Let me know what you think by replying to this email!

P.S. I use Obsidian for everything: knowledge management, daily notes, permanent notes, checklists, journals, and task management tools.

Some things I found great

Subscribe Wherever You Get Your Content - I thought about this post lately. That was one of the reasons I moved back to my blog because now, I have various RSS feeds that allow anyone to subscribe to my blog wherever they get their content.
Honest Guide - Last week, we went to Prague. I remembered a few tricks I learned from this YouTube channel, and it has proved its usefulness again!
The Monocle Companion: Fifty Essays For A Brighter Future - I bought this book recently, and I really enjoy reading essays in a book, like reading blog posts offline (so far, my favorite is "Have a Repertoire" by Rubert Bound).
Dot-on Calendar - The calendar I use to track my most important habits (writing, exercising, and practicing bass guitar) every day.
Modern Wisdom #662 - Gurwinder Bhogal — 18 Shocking Psychology Lessons to Understand Yourself — This podcast episode gave me a lot of things to think about. Will definitely listen to it again.

Recently I thought about

I continued my thoughts about seeking inconvenience since the last week. I'm unsure how fast people move from one idea to another, but I keep returning to the same things for some time. It helps me construct my arguments, habits, and thoughts more concretely.

On the topic, I looked at where I am after some convenience: my exercise routine. I want to get stronger. The only way to do it is by lifting more weights correctly. I can lift the same weights three times a week and live healthily, but I want to improve my strength to achieve better health and life span. So, I have to go out of my comfort zone regularly while exercising to live longer and healthy in my last days of life.

The next step will be putting my eating back in order. I already took a few steps and am changing my eating habits (more plant-based). Changing eating habits is more complex than exercising for me. Meanwhile, what are your routines regarding exercising and eating?

Reply via email | Reply via Mastodon | Comment

Retrospectively look at what you do and change your strategy

Sun, 13 Aug 2023 00:00:00 GMT

James Clear says,

"You're more likely to unlock a big leap in performance by trying differently than by trying harder. You might be able to work 10% harder, but a different approach might work 10x better. Remain focused on the core problem, but explore a new line of attack. Persistence is not just about effort, but also strategy. Don't merely try harder, try differently."

I'm unsure about how much it holds true but it makes sense to retrospectively look at what you do and change your strategy.

In response to: https://jamesclear.com/3-2-1/august-10-2023

Reply via email | Reply via Mastodon | Comment

Thinking Retrospectively Helps to Correct The Course

Sun, 13 Aug 2023 00:00:00 GMT

James Clear says, "You're more likely to unlock a big leap in performance by trying differently than by trying harder. You might be able to work 10% harder, but a different approach might work 10x better. Remain focused on the core problem, but explore a new line of attack. Persistence is not just about effort, but also strategy. Don't merely try harder, try differently."

I'm unsure how much it holds true, but we gain a lot of advantages from retrospectively observing what we have done and seeking changes where needed. Stopping the action, powering it through, and looking into what has been done so far brings many benefits and helps us to course-correct.

Related Note(s):
Source: 3-2-1 Newsletter on August 10 by James Clear;

Reply via email | Reply via Mastodon | Comment

Seeking Inconvenience

Fri, 11 Aug 2023 00:00:00 GMT

Mediations Newsletter is becoming a curated newsletter where I will share what I've been thinking about recently and a few things passing from my screens, eyes, and life.

The style will be between James Clear's 3-2-1, Cassidoo's rendezvous, and FS.Blog's Brain Food, and the content will reflect the complexity of life. Therefore, I won't niche into one area like software engineering, productivity, or psychology. I don't want to be a content creator in a certain niche.

Here, I want to form relationships over these emails. The best way to do that is to show you what's passing in my life.

I often advise others, and people find them useful. Yet, I don't always follow my own advice. Because giving useful advice is much easier than applying it to your life. We see what others can do better easily compared to what we can improve ourselves. Here, I want to share those bits of advice that I usually give to some people in my life.

Feel free to just reply to the email you get at any time. Also, all issues will be available on my blog too. If you want to follow the blog and my notes besides emails, there are separate RSS feeds for each.

The Mediations Newsletter has no cadence, but I will send it a maximum of once a week, not more.

Anyway, let's get to the first issue.

Some things I found great

These links won't be the hottest or newest links but rather what I recently spent time on and/or recommended to someone.

How Can You Get Closer to the People You Care About? — While I listened to this podcast episode, it reminded me of a conversation I had a few months ago with one of my best friends. We talked about how much we know each other and how much we actually don't because we never speak about deep personal values. I don't know if you have tried to make your relationships better, but I want to get better at this. This podcast episode already taught me a few things I want to try.
Just normal web things. — Heather Buchel wrote a great piece about how websites manipulate our web experience and how we should keep things a certain way. The most frustrating one for me is her last point—a website hijacking my browser shortcuts. I hate it.
Julia's Latest Video covering Dua Lipa's Dance The Night — Julia, again, made an awesome bass cover.
Lee Ritenour & Dave Grusin Live at Java Jazz Festival 2013 — While YouTube was playing one video after another in the background while I was writing something, this video came up. I had never heard of these people before, but I enjoyed every second. What a wonderful concert.
The Most Important Management Concept You're Missing: Task Relevant Maturity — I'm trying to improve my staff planning skills, and this post helped me to think about when I plan who should do what in our team(s).
Honest, Candid, and Frank — Should I give honest or candid feedback or be frank? Now I learned the difference. From now on, I'll give candid feedback, always be honest and talk frankly often.
Team Topologies — I keep coming back to this book lately because I'm thinking about how we can structure teams to better collaborate with other teams and increase the flow of value.

Recently, I thought about

seeking inconvenience.

How much time and money do we spend in our lives to make everything convenient? Does everything have to be convenient?

Convenience destroys the joy in any action. Inconvenience brings out the beauty.

For example, writing must be done on paper with a pen at hand instead of on a computer. Writing is not about efficiency; it's about evaluating ideas, reshaping them, and slowing down the thought stream so that we can catch the good fish in a dirty river of thoughts.

Choosing which movie to watch shouldn’t be done by algorithms while we’re lying down on our couch. It should be by referrals and recommendations from people we know and trust. We should go to the movie theater, watch a movie our friend recommended and hate that movie. We have to feel the waste of time in that movie. We shouldn't optimize for watching great movies all the time.

Also, we must be fully present while doing these activities. Who drinks coffee and does nothing else anymore? How many people have you seen sitting on a couch and listening to music without a phone or book at hand? Or when was the last time you did that?

Look at your life; find where you don't need comfort and convenience. Seek inconvenience in activities that you like to do. If you like drinking coffee, try only drinking coffee without a side activity. If you like listening to music, try sitting on a couch and listening to the music your eyes closed. You'll recognize the difference. You’ll see what exactly you like in them.

And reply to this email about how the experience was.

Reply via email | Reply via Mastodon | Comment

No Prioritization, No RFC

Sun, 06 Aug 2023 00:00:00 GMT

All organizations have problems that everyone knows, but nobody has time to fix it. The time never comes to tackle those problems. Every product has other problems that need to be solved, features that need to be implemented, and changes that have to be made. If someone decides to solve that long-lasting problem without prioritization and writes an RFC to collect feedback, the solution is doomed to fail again.

For RFC to serve well, the solution has to be prioritized correctly. If a team cannot get to solve a problem due to other work packages, developing a solution by writing an RFC won't change the situation. If the team cannot tackle the problem immediately after the RFC is accepted, they will fail. The systems evolve, and decisions made a month or two months ago has to be revised, refined, and adapted to the new changes. The RFC will likely lose its validity by then. Implementation of the RFC should start right after it's closed for feedback. And that requires clear prioritization of the topic.

Related Note(s):
Resourced: How and Why RFCs Fail;

Reply via email | Reply via Mastodon | Comment

Don't Use RFCs as A Decision-Making Mechanism

Sun, 06 Aug 2023 00:00:00 GMT

Similar to the business need we talked about above, the business decision has to be made before writing an RFC. RFC focuses on how, not what—deciding on what has to be done earlier.

An RFC can't drive a business decision; however, it can bring out risks that were not considered before. Thus, it can urge people to reconsider their decision. But that shouldn't be the goal of an RFC; it's only a good side effect.

Related Note(s):
Resourced: How and Why RFCs Fail;

Reply via email | Reply via Mastodon | Comment

Don't Even Try to Form A Consensus

Sun, 06 Aug 2023 00:00:00 GMT

As the business decision has already been made, the RFC authors can decide which piece of feedback they will accept and which ones they will reject. If a team writes an RFC, they don't have to agree or accept every change request, but they have to acknowledge every comment. They have the right to veto by giving a reason. And the reason can be simple: "We're aware of its drawbacks, we acknowledge it, but we're willing to take this risk. We'll continue with the existing design."

There is no need to form a consensus for every topic. The RFC system works with consent-based decision-making by default, and teams should seek consensus only and only when they need it.

Related Note(s):
Resourced: How and Why RFCs Fail;

Reply via email | Reply via Mastodon | Comment

Choose Your RFC Audience Correctly

Sun, 06 Aug 2023 00:00:00 GMT

Not every RFC has to be shared with the whole company. Push RFCs to related people but be open to random people commenting on them.

Related Note(s):
- 32b: Communicating Organizational Changes;
- 43: The Role and Responsibility of Software Architect;
Resourced: How and Why RFCs Fail;

Reply via email | Reply via Mastodon | Comment

Give Enough Time for RFC Reviews (Please, Don't Rush)

Sun, 06 Aug 2023 00:00:00 GMT

If everything is urgent, nothing is urgent. I see people share an RFC to collect feedback and tell the audience that they will close the RFC for comments in two days. If everything is urgent, how can people read an RFC while other urgent tasks are waiting for them?

Of course, it depends on the RFC. If an RFC is circulating in one team, it's okay to have two days because there are only a handful of people who need to review it. The problem occurs when an RFC impacts more than one team. As every team's priorities are different, people cannot jump into reviewing an RFC when it's shared. Authors have to give enough time for others to review. How much is enough will always depend on the topic and the RFC's impact.

Resourced: How and Why RFCs Fail;

Reply via email | Reply via Mastodon | Comment

Don't Publish The RFC and Forget; Follow Up

Sun, 06 Aug 2023 00:00:00 GMT

If you publish an RFC and announce it only once, you practically fail.

If there is one thing I learned in organizational leadership, it's this: if you want something, you have to repeat it. If you want to collect feedback for an RFC, you have to remind people constantly that you're looking for feedback.

Give people signs regularly on when you'll close it for feedback. Be proactive. To be honest, be annoying if needed. When you close an RFC for feedback, you should feel comfortable that you got enough feedback. Nobody should be able to complain about the solution when the time comes for implementation. And if they still complain, you should be able to say, "Well, we collected feedback and announced it everywhere, pinged many times. Sorry, we're following the decided strategy."

Related Note(s):
Resourced: How and Why RFCs Fail;

Reply via email | Reply via Mastodon | Comment

Don't Build an Extensive RFC Template

Sun, 06 Aug 2023 00:00:00 GMT

Organizations should influence people to write RFCs, and the guides to writing them should be simple, clear, and concise. If an RFC template has ten sections that have to be filled, it ceases to help.

An RFC template should be flexible. It's there to guide people's thoughts. A template should not only make writing easier but also understanding easier.

I still recommend the NABC Model (Need, Approach, Benefits, Competitors) that Stanford introduced. It's short and guides people in a direction where it's easy to understand.

Resourced: How and Why RFCs Fail;

Reply via email | Reply via Mastodon | Comment

Build The Right Culture First Before RFCs

Sun, 06 Aug 2023 00:00:00 GMT

The whole RFC process requires a blameless and trustful environment. If the organization operates with bad politics and secrecy, forget about RFCs. If an engineer doesn't trust others and doesn't believe people have good intentions, why would they seek feedback? Even if they did, would they accept feedback? I don't think so.

Another cultural challenge for RFCs is the stage of the organization. If the product is pivoting or an engineering paradigm shift is going on, RFCs cannot survive. Especially while trying to find product-market fit and runway budget is limited, RFCs are not the right strategy.

Engineering paradigm shifts depend on the organization's maturity. If the organization is mature enough, RFCs are a great way to shift the engineering paradigm. However, it won't work in an immature organization where there are long discussions and fights everywhere.

Get your culture right, and people will naturally bring the RFC process by themselves. Use RFCs to create a feedback culture and enhance your engineering strength and stamina. It's one of the best ways to break silos and build a healthy engineering organization that communicates and collaborates.

Related Note(s):
Resourced: How and Why RFCs Fail;

Reply via email | Reply via Mastodon | Comment

Seek Inconvenience

Sun, 06 Aug 2023 00:00:00 GMT

How much time and money do we spend in our lives to make everything convenient? We optimized our lives so much that we had a lot of time to do many things. Yet, we lost the joy in them.

Does everything have to be convenient? Some things should be inconvenient. The beauty hides in inconvenience. Writing must be on paper with a pen at hand. For example, I spend so much time on the computer and keep all my notes on it. So, I stopped writing by hand. However, writing is not about fast typing or convenience, it's about evaluating ideas, reshaping them, and slowing down the thought stream so that we can catch the good fish in a flowing river.

It's the same with choosing movies: it has to be with our friend's recommendation, not with algorithms. We have to go to the movie theater and hate a movie, swear for the time we spend. If we watch great movies all the time, doesn't it become boring? Take Netflix as an example; it fills every moment that we spend in the living room. We watch whatever Netflix recommends. We sacrificed joy for convenience.

We must be there while doing any activity. Who drinks coffee and does nothing else anymore? How many people do we see sitting and listening to music without a phone, computer, or book?

The joy, learning, and growth come from enough uncertainty and being open to new things. Convenience kills creativity by making everything in order.

That's what I'm leaving you with.

Look at your life; find where you shouldn't need comfort and convenience. Seek inconvenience in activities that you really like to do. If you like drinking coffee, try only drinking coffee without a side activity. You'll taste and start experimenting with your brewing method. If you like listening to music, try sitting on a couch and listening to the music. You'll understand what exactly you like in a song. If you enjoy watching movies, go to a movie theater and ask the staff for recommendations. You'll recognize the difference; you'll remember.

Related Note(s):
Resourced: Mediations #1;

Reply via email | Reply via Mastodon | Comment

How and Why RFCs Fail

Sat, 05 Aug 2023 00:00:00 GMT

Creating knowledge silos and building software in a team without involving others is unavoidable in growing organizations. That's why organizations create RFC processes to break down silos, collect feedback early and prevent impediments that can come out later in development, which usually are costly. Later these organizations aim to create governance around the RFC process and give guidance to the people through templates and a refined RFC process.

Even though I love the RFC process and have even introduced it to an organization before, I see a lot of traps that organizations (and people) fall into. I want to explain what I have learned and observed in other organizations.

No Business Need, No RFC

We introduced RFCs as one way to allow engineers to propose an idea to the business. It was a complete failure. Although we introduced RFCs as a way to promote ideas and create a feedback culture, engineers who tried persuading others felt lost on how to gain support for an idea. Ideas popped up, but they couldn't gain support because there was not a strong business need.

If there is no strong business need for an idea, there shouldn't be an RFC. When I say business, I count both product and technical problems and features. When an RFC is written, there has to be direct support from all directions in the business to solve a certain problem. I say all directions because the need has to be prioritized.

No Prioritization, No RFC

All organizations have problems that everyone knows but nobody has time to fix it. The time never comes to tackle those problems. Every product has other problems that need to be solved, features that need to be implemented, and changes that have to be made. If someone decides to solve that long-lasting problem without prioritization and writes an RFC to collect feedback, the solution is doomed to fail again.

Don't Use RFCs as A Decision-Making Mechanism

Similar to the business need we talked about above, the business decision has to be made before writing an RFC. RFC focuses on how, not what—deciding on what has to be done earlier.

Don't Even Try to Form A Consensus

There is no need to form a consensus for every topic. The RFC system works with consent-based decision-making by default, and teams should seek consensus only and only when they need it.

Choose Your Audience Correctly

Not every RFC has to be shared with the whole company. Push RFCs to related people but be open to random people commenting on them.

Give Enough time (Please, Don't Rush)

Of course, it depends on the RFC. If an RFC is circulating in one team, it's okay to have two days because there are only a handful of people who needs to review it. The problem occurs when an RFC impacts more than one team. As every team's priorities are different, people cannot jump into reviewing an RFC when it's shared. Authors have to give enough time for others to review. How much is enough will always depend on the topic and the RFC's impact.

Don't Publish and Forget; Follow Up

If you publish an RFC and announce it only once, you practically fail.

If there is one thing I learned in organizational leadership, it's this: if you want something to stick, you have to repeat what you want. If you want to collect feedback for an RFC, you have to remind people constantly that you're looking for feedback.

Don't Build an Extensive Template

Organizations should influence people to write RFCs, and the guides to writing them should be simple, clear, and concise. If an RFC template has ten sections that have to be filled, it ceases to help.

An RFC template should be flexible. It's there to guide people's thoughts. A template should not only make writing easier but also understanding easier.

I still recommend NABC Model (Need, Approach, Benefits, Competitors) that Stanford introduced. It's short and guides people in a direction where it's easy to understand.

Build The Right Culture First

Reply via email | Reply via Mastodon | Comment

RFC Process in Organizations

Sat, 05 Aug 2023 00:00:00 GMT

Many organizations adopt the Request for Comments (RFC) culture. Creating knowledge silos and building software in a team without involving others is unavoidable in organizations. That's why organizations create RFC processes to break down silos, collect feedback early and prevent impediments that can come out later in development—which usually are very expensive to solve.

Many mid-to-big organizations later aim to create governance around the RFC process and give guidance to the people by templates and defined RFC phases. In some organizations, the RFC process is also used as a decision-making mechanism, in which the whole process is doomed to fail. Even though I love the RFC process and have even introduced it to an organization before, I see a lot of traps that people fall into.

Reply via email | Reply via Mastodon | Comment

If there is no business need, there shouldn't be an RFC

Sat, 05 Aug 2023 00:00:00 GMT

If we ask a group of four software engineers what changes are needed in our system to improve its quality, we will get at least twenty ideas. When the RFCs are used to get support for any idea, it's a complete failure. This was one of the reasons why we failed. We introduced the system to promote ideas and get feedback on them. Even though our intention was to improve the feedback culture, engineers who tried persuading others felt lost on how to gain support for an idea and turn it into implementation.

If there is no business need for an idea, there shouldn't be an RFC. When I say business, I count both product features and technical problems and features that have to be implemented. When the RFC is written, there has to be direct support from all directions in the business. If every idea is written as an RFC to collect feedback, the whole process is doomed to fail.

Related Note(s):
Resourced: How and Why RFCs Fail;

Reply via email | Reply via Mastodon | Comment

What I Learned About Getting Better at Giving Talks and Presentations

Wed, 19 Jul 2023 00:00:00 GMT

Many organizations have knowledge-sharing sessions where people present what they have learned or found interesting. Software engineers are sometimes expected to be on the stage to level up in their careers, as this is one of the most tangible ways to showcase they're trying to grow others. However, engineers are not professional speakers. They rarely spend time getting better at speaking to an audience. For many, explaining how something works is less exciting than learning how that thing works. For me, I was always fascinated by both.

While working as a software engineer, I also improved my presentation skills by reading up on the topic, seeking feedback in every possible way, and talking with the best presenters I've ever listened to. These days, I get good feedback on my talks and podcast episodes, and people ask me to pass on my knowledge of being a good speaker. They ask the same questions I asked a long time ago to the best presenters. It's time to pass the baton.

Here I want to share the key points for improving public speaking—a business presentation, tech talk, podcast episode, knowledge-sharing talk, or what have you. The below points are not an exhaustive list, but I learned over the years that they are the most crucial ones.

And it starts with choosing a message for your talk.

One and Only One Message

What is the one message you want to leave your listeners with?

What is the one thing they can try after they hear you?

Leaving your listeners with many ideas will make them overwhelmed and confused. Hence, they will never take any action. Give them one clear message. They should not doubt that they understand and can try after your talk.

Don't hide the message when you give it—say it out loud. Make it crystal clear. You can even say, "If you want to get one thing out of this talk, it's this," and give them the key point. Even if they don't try, they will think about it. You'll make someone think and challenge what they are already doing and nudge them to do it differently. That's how to impact someone's life—the real power of public speaking.

But you won't be able to give that message if the message is not coming from you.

The Talk is About YOU.

If you're speaking about a topic, that shows you care. Although you're talking about a topic, the talk itself is not focused on it. It's about how you explain the topic.

Let's go over a simple example. If you're presenting a book you read and liked, the listeners are interested in learning more about the book's details, for sure. However, they are even more interested in what you learned from the book and how you applied it to your life. Because they want to know why you're presenting the book and what you gained from it. How your life has changed after reading that book is more important to the audience than the book's full content.

You must add your talk some pieces from you. If you don't talk about yourself at all, if you don't involve your experience with the topic, the talk will be blunt. People can learn any information from the internet, including what you present. But they chose to listen to you. That means your audience wants to hear that topic from you instead of others.

Therefore, you must put yourself at the center of your talk instead of your beautiful slides.

Slides are Only Helpers

Most of the "X tips for better presentations" articles I've read talk about how the slides should be. I've seen many different recommendations, such as six words per line and a maximum of five lines of text in one slide or using only images and no text. All of the tips are mostly useless.

I remember a fantastic presentation I watched at SwiftConf in Cologne. Each slide had either an image or a single word on it. There were hundreds of slides, and the speaker had only twenty minutes! How?

They used the slides to help themselves present the topic. They built a story and used slides to guide people in the story.

Slides are tools to help you. They are not the center of the talk—you are. Once you move the center of the talk from slides to you and make the talk fully yours, the presentation will automatically improve.

Don't add thousands of words to slides unless you have a good reason. The aim is to move the audience's focus from the slides to you. The audience looks at your eyes when you talk, and slides shouldn't distract them from your beautiful eyes.

What you put on your slides is still your decision. There is no silver bullet.

Sometimes, a blank slide is better than a slide with ten words on it. A blank slide moves the focus to you and helps with one more thing.

The Hidden Power: Silence

The silence is awkward if it's beyond four seconds. Right around the third second, people become curious about why you say nothing and focus on you again. If your audience is distracted, pausing for a few seconds is a good way to put yourself in the center.

Silence is unintuitive, especially when you suppose to talk. But it gives you and the audience time to think. When you present pieces of information back to back, people can't digest most of it. They can't internalize whatever they hear, especially when the talk includes sub-sections.

If you jump from one section to another without a pause, the audience cannot close the chapter in their minds and get confused. Pause for one or two seconds to make them think about what you said and allow them to connect the sub-chapter to the main subject.

Remember, the talk is about you; you also need to focus, and a second of silence helps you gain focus when you're distracted. Taking a slow, deep breath into your stomach relaxes and enables you to remember your next lines.

One caveat: don't overuse silence. As it grabs all the attention, it needs to be used wisely. That's why you must create the storyline to support that silence.

Connect the Dots in the Story

Most presentations have a main topic and sub-topics. We often hear, "There are four categories of X. Let's talk about them." Nothing is wrong with that if you have to present four categories of X. How you connect those four and the main topic is what matters.

The goal is to create a single message in listeners' minds—the key message of the talk. You must build the story around that message. Whenever there are sub-topics that give more details, you have to create good segues back to the main topic. These sub-topics are supportive ideas of the key message. Listeners should see the connections between them because they will try to connect those topics in their minds. Don't leave this job to them. They should spend their energy listening to you and understanding what you're talking about. They shouldn't build up the topic on their minds; you must connect the dots for them.

So, if you explain four sub-topics one by one, you have to create good segues while switching from one to another instead of taking big jumps between them. You have to connect all sub-topics to the main message. Creating a good story is challenging, and there are good books and tons of videos about it; I will leave it out of this post.

Having a good story gives you one more advantage. Once you create the storyline right and connect the dots, you don't have to worry about your notes anymore.

Never Read From Your Notes...

Unless you're rehearsing or you're such a professional speaker that people won't recognize that you're reading.

For example, newscasters read the news from a prompter, but we rarely notice. If you're not that professional, never read from your notes, regardless if your talk is in-person or online.

If you really need your notes, have a few keywords or short notes under your hand as a reminder.

In a well-prepared talk, you shouldn't need any notes at all. You have to build that confidence, and that requires rehearsal.

Rehearse, Rehearse, and Rehearse Once More

Rehearing is the best way to improve your presentation. There is no magic; practice makes it perfect.

I learned a few common rehearsal techniques from stage performers, which can also help you have effective rehearsals.

I remember we were preparing for a theatre play years ago. We first read the whole script with everyone reading their lines when their turn came. Then, we started working on small sections of the play and tried to improve that part (only that part) while still reading from the script. But we never did a full rehearsal before practicing sub-sections at least once or twice.

When it was time for the whole play rehearsal, we never stopped. We made mistakes and called them out but didn't take it from the top; we just kept going. We had to see the whole play to understand how to change or improve a single part without disrupting the theme or the main message. We did this again and again, and again and again—first, parts, then the whole.

Use the same while preparing for your talk. Start small—practice sub-sections of your talk. Once you're ready with all sub-sections, do a full rehearsal. While doing it, never stop in the middle and start from the top. Take note when you make a mistake and finish the rehearsal. Return to that mistake later, fix it, practice that subsection, and do another full rehearsal. Your rehearsal goal is to see and improve how the subsections help to build the key message.

In stage performances, people do a dress rehearsal: an all-in rehearsal with their stage dressings and all decor right before the show starts. Often while the audience is waiting at the door—do the same. Right before your show, do a dress rehearsal.

Now, it's understandable that there is so much you can do. You might feel overwhelmed, but you don't have to do it all at once. Actually, you shouldn't make all improvements at once.

One Step At A Time

Like every skill, improving public speaking takes time and a lot of practice. Your first preparation will take longer, but the next preparation will take less time once you learn the fundamentals. You will have many bad presentations but don't give up and focus on one and only one improvement each time. After a few talks, you'll already be much better than the majority.

Don't forget; if you make one improvement, you're already taking one step further than most of the population. And your first step should be deciding on the key message of your talk. The next steps are easier to follow.

Reply via email | Reply via Mastodon | Comment

On The Purpose of Life

Tue, 27 Jun 2023 00:00:00 GMT

Finding a purpose in life is a difficult journey. Is the journey itself the purpose of life? Or is it something else? Well, this is the Mediation, and I continued searching for why we exist.

These days, whoever I talk to splits into two sides. One group has no idea what to do with their lives, and the other group is busy with their kids, so they have no time or energy to think about what to do with their lives. I'm in the former group, even though I want to join an invisible third group—a group full of people who found their purpose in life. Maybe even there is a fourth one that consists of people living in peace without a purpose while life takes them wherever it wants.

Let's stop here for a second. I don't aim to explain those groups (as I wrote about them before), but I want to discuss the fundamentals of belonging to any of these groups. I probably won't arrive at any conclusion, but I will leave you with something to think about.

The problem is in the dichotomy between having a good life and not knowing what to do with it (which, in turn, makes life feel meaningless). Take me as an example. I have a good life (I think). I know I am very privileged and have a good income and comfort. I have a happy marriage, good health, and social life. Yet, I still don't know what to do with all of these. It feels like I should do something with it. I tried various things like helping others (which mostly made me happier), sharing what I learned, and a few more things that there is no need to mention here. But none was sticky enough to form a new road in my life. The only thing I can shape my life around is work, which takes more than eight hours a day. And that's sad.

I work to have a good life, but this good living is not fully satisfying and doesn't give my life meaning. I know I'm not alone in this. We're all stuck, looking for something. Something we don't know. The search is killing us.

But I wonder, is the life that search itself? Is this quest the goal, the purpose of life? Are we going to spend our whole life in search? Or is it better to have a kid and simply ignore the search?

Or should we sit under a tree as Buddha did and wait for days until we find enlightenment? In his enlightenment, he explains how suffering in life comes from cravings (for a better feeling). For example, if we want to be successful, we won't be happy until we can feel successful (which is not easy). He teaches us how to get rid of these cravings to eliminate suffering.

Accepting that suffering is part of life and walking life's road without craving looks like the way. Or is it?

I want to follow my own path instead of Buddha's. But I look for what others say.

In one of his talks, Krishnamurti says:

When the mind is free from all conditioning, then you will find that there comes the creativity of reality, of God, or what you will, and it is only such a mind, a mind which is constantly experiencing this creativity, that can bring about a different outlook, different values, a different world.

Krishnamurti tells us to eliminate all conditioning we put ourselves in. Do we want something because someone else has it and we don't? Do we judge ourselves because we simply want to become better than who we are now? Do we not like ourselves as we are? If we want to know ourselves, we must go deep, he says, remove all conditions we created around our minds and hearts and look at ourselves without judgment, conditioning, evaluation, comparison, or condemnation.

It looks like the cravings that Buddha talked about comes from conditioning in our minds. Is getting rid of all these conditioning the way to find purpose in life? Will removing conditioning also remove the confusion of what to do with our lives?

In his other talk, Krishnamurti says:

Can you and I be free of all this turmoil and confusion? What is confusion? ... Confusion exists only when there is the fact plus what I think about the fact: my opinion about the fact, my disregard of the fact, my evasion of the fact, my evaluation of the fact, and so on. If I can look at the fact without the additive quality, then there is no confusion. ... Confusion arises only when I think or insist that the road leads somewhere else—and that is actually the state that most of us are in. Our opinions, our beliefs, our desires, ambitions, are so strong, we are so weighed down by them, that we are incapable of looking at the fact. ... Being confused, to acknowledge to oneself that one is confused requires, not courage, but a certain clarity of thought, clarity of perception. ... When a confused mind acts, it can only produce further confusion; but a mind that is aware that it is confused and understands this whole process of confusion need not act because that very clarity is its own action.

How can we see the fact that shows where our lives are going without our opinion about the fact? If the confusion arises only when we insist that the road leads somewhere else—other than where our lives would go—then how do those with purposes in their lives know that their road leads to a place (but not somewhere else)?

I want to learn from one of those people who had a purpose in their lives—the third group. Let's take Wangari Maathai, the first African woman and environmentalist, to win the Nobel Peace Prize.

Wangari Maathai fought against a colonial culture that exploited agriculture and destroyed the ecosystem in Kenya. Colonial forces planted the most profitable plants that didn't belong to the habitat. She sought to resurrect the ecosystem and culture by planting local trees and training local communities that voluntarily worked in plantations. She knew that Kenyans must follow their own journey, not a dictated one. She dedicated her life to this purpose.

In her memoir, she wrote:

What I have learned over the years is that we must be patient, persistent, and committed. When we are planting trees, sometimes people will say to me, "I don't want to plant this tree because it will not grow fast enough." I have to keep reminding them that the trees they are cutting today were not planted by them but by those who came before. So they must plan the trees that will benefit communities in the future. I remind them that like a seedling, with the sun, good soil, and abundant rain, the roots of our future will bury themselves in the ground, and a canopy of hope will reach into the sky.

Should we persistently and patiently remove all the conditioning from our lives and expect a road to be visible over time? Maybe.

Is the tree we're planting today actually the action of thinking about it? Possibly.

And how long could this road be? Maathai answered in the same memoir:

I have always believed that, no matter how dark the cloud, there is always a thin, silver lining, and that is what we must look for.

It looks like dark clouds are our conditionings, cravings, and confusions that result in suffering. We need to learn how to find that silver lining.

When Maathai said, "We need to honor the past but look to the future," she perhaps meant honoring the past is observing it but not creating conditions from it. If we have a good life now, maybe we shouldn't condition ourselves that life needs to lead somewhere. Perhaps stopping the search is actually looking to the future.

In his novel Castle, Kafka said, "If a man has his eyes bound, you can encourage him as much as you like to stare through the bandage, but he'll never see anything." Perhaps, our search for meaning is our bandages. Maybe, we'll see our future when we stop looking for it.

Maybe Krishnamurti is right.

Maybe Kafka is right too.

Maybe the journey itself is part of the experience.

Maybe the solution is stopping the search of why we're on this road and looking around to see where the road leads.

Maybe looking back at the road we took so far and honoring it but opening ourselves for a brand new step without any conditioning we built from our previous steps will help us to new journeys.

Maybe one of those journeys will be the one. The one that is not created around cravings. The one we didn't expect, search, and want.

Perhaps, we have to live this through to reach what we seek. Not to search for it, not to have a goal for finding it but to simply pass the stage in our lives at least to see where it leads.

I didn't expect to find something when I began writing this. These thoughts were already inside me. There are a lot of maybes and perhaps above. But I have more clarity than before. Perhaps these ambiguities will slowly fade away.

This is a journey that I started discovering a few years ago. It taught me different things. It has ups and downs, and I often write about it.

I hope I somehow take you on this journey as well and give you something to think about.

Reply via email | Reply via Mastodon | Comment

Reflexive Psychology to Learn More About Yourself

Mon, 26 Jun 2023 00:00:00 GMT

In a dinner with a colleague, we talked about psychology in leadership. They were going to therapy and told me the impact of group therapy (I never had one): you see yourself through the eyes and stories of others. When you listen to someone else, it makes you think about yourself and how you relate to their story and how you had similar experiences in your life, and how you interpret your own stories. Reflexivity is a known concept of psychology and is widely known in the scientific community.

Related Note(s):

Reply via email | Reply via Mastodon | Comment

Pass your words from three doors before you speak

Mon, 26 Jun 2023 00:00:00 GMT

Before you speak (or write a message to someone), pass your message from three gates that ask these questions, as Rumî said, "Is it true? Is it necessary? Is it kind?" The first door eliminates the things your mind makes up. The second door eliminates the thoughts that arise without a filter, the thoughts you have but don't contribute to the common good. The third door ensures you don't break hearts with your words because once a heart is broken, it's impossible to repair it.

Related Note(s):

Reply via email | Reply via Mastodon | Comment

Sometimes, it just needs to be felt right

Tue, 20 Jun 2023 00:00:00 GMT

When Patrick Rothfuss wrote about Auri, he didn't tell a story. He defined a person. Auri is still a mystery and will always be. She figured things out in her world away from everyone, and she often understood how things should be. Everything has a purpose. Not every nice thing has to be used and owned by someone. Some things belong where they are, but finding exactly where they belong takes energy and time. When Auri finds something new, she spends good thinking about giving it to the right place where that thing can serve a purpose even though nobody knows the purpose; that thing just feels right to stay at that place. That's perhaps how things should be. We just need to feel right where we are or where we belong without explaining why we feel right.

<details> <summary>Background story</summary> When Auri found a new room and inside a drawer full of clean and high-quality sheets, I loved how she didn't touch them. Because she knew that it was going to corrupt her and break her spirit, some things were supposed to be that way—choosing not to own every beautiful thing while knowing you would definitely benefit from it. </details>

Related Note(s):
Source(s): The Slow Regard of Silent Things;

Reply via email | Reply via Mastodon | Comment

Why don't they leave the software to software engineers?

Fri, 16 Jun 2023 00:00:00 GMT

Every time I see an engineer gets headroom to make some improvements in the system, I get worried. Even though they can turn complex tasks into complicated ones and solve them, they often struggle with freedom. Even though they know exactly where the problems are or where the team needs to improve, they get lost easily without guidance. I have seen this many times, and as an engineer, I also was the same. When I became a leader, I learned that the problem is not with the engineer. Whenever I see an engineer focus on something wrong or try to over-engineer something these days, my worry comes from me not doing my job.

When an engineer tries to over-engineer something, they appear to lack some skills, such as not identifying the most pressing tech debt. They look for what they want to change instead of what needs to be changed. I also did the same: there was a new technology that I wanted to use, and I tried it at the first chance I found. It was often neither required nor needed. It was me learning something new, which was cool and totally okay. However, the problem was precisely here: "I tried it at the first chance I found." And the chances were not always aligned with the biggest problems.

Identifying the most significant problems on the codebase requires analytical thinking and finding a way in ambiguity, and I thought most engineers lacked these skills. They couldn't prioritize which issue was the most pressing one and couldn't tell when exactly that issue could become a blocker and a real pain for development. I started helping engineers to find these issues by listening to them, asking questions to help them approach better, and understanding the technical challenges. Although it initially helped, it didn't solve the root cause. To make things worse, I thought it was my job (as a leader) to hand-hold all engineers in these situations and help them figure out why they should avoid over-engineering or solving the wrong tech debt.

That guidance mindset is dangerous. In hindsight, it looks like something that a leader should do. It is tempting to guide engineers because that is the shortcut that brings quick solutions and leads to better outcomes in the short term. However, it limits engineers' autonomy. At some point, it only satisfies the leader's ego. In the worst case, it leads to micro-management.

The problem appears to be on the engineer, but it is actually on the leader. If the team doesn't have clarity around where they want to go, what they need to build, and why they need to build that, they will struggle. They will build unnecessary solutions that only bring joy to engineers and have no use now or in the future. They will over-engineer things or take very opinionated approaches, which will create conflicts or cause complaints from the next developer. All of this will lead to the "everything needs to be rewritten" conversations.

If the leadership lacks strategy and clarity on the goals and fails to communicate them with the most junior engineer, there is nothing an engineer can do besides over-optimizing wrong things. If that's the case, the team needs a lot of hand-holding, and that's why they don't leave the software to software engineers.

Leaders should seek clarity in the team's goals and ensure everybody understands why and what so that engineers can focus on how. If any leader finds themselves involved in the how part of the work a lot, that means the leaders are doing something wrong. When that is the case, the leader should start by NOT leaving the software to software engineers. The leader's job is to ensure the team is building the right things. However, they shouldn't stop there.

Most problems occur when the leader stops there and falls into "always guiding mode," where they help the team with every single problem. Even though they should not leave the software to software engineers in the first place, they never change that behavior. They don't work on creating strategy and clarity. They get stuck in organizational work and don't extract themselves, and never help people learn how to navigate within some ambiguity. Although this looks like a problem for the team's leader, the problem often goes up in the leadership chain.

Leaving the software to engineers requires a good amount of work from the organization. Not a single leader can do it alone in their teams. If the organization doesn't provide transparency, clarity, and a good communication culture, the leader can do only so much. Even though the front-line leader may or may not succeed depending on the organization's culture, they should still seek to bring clarity to the goals.

Of course, leaving the software to software engineers won't work all the time. Junior engineers need that guidance to learn where to keep the balance. In these cases, senior engineers should provide this guidance. And for senior engineers to do that, they have to have autonomy. It's like a rolling ball; clarity and transparency start from the top leadership in the company and roll down to the most junior person.

In the end, engineers can't be left alone to decide the software's destiny unless they know exactly where they are going. The last thing any leader wants is people working on the wrong things. That's why leaders involve themselves a lot in every process. However, they should aim to bring transparency, clarity, and good communication and leave the software to engineers. If none of these exist, the software won't be left to software engineers.

Reply via email | Reply via Mastodon | Comment

Task-Relevant Maturity

Mon, 12 Jun 2023 00:00:00 GMT

Task Relevant Maturity is a concept that helps the leader to understand how much they should monitor their subordinate and guide them.

"How often you monitor should not be based on what you believe your subordinate can do in general, but on his experience with a specific task and his prior performance with it — his task-relevant maturity... as the subordinate's work improves over time, you should respond with a corresponding reduction in the intensity of the monitoring." —Andy Grove, High-Output Management

One of the mistakes I made (not a big one but an operational mistake) was giving one of the team members work they had never done before and leaving them alone there while thinking that they were working as senior engineers and should be able to work autonomously and drive the project forward. Even though they delivered projects before, their task-relevant maturity (TRM) was low. They never worked on projects with ambiguous business analyses. Most of the things they worked on were clearly defined and scoped, and all they had to do was ensure it got done; most of the tasks were on the technical implementation, not on figuring out the business rules. In the new project, their TRM was low, and they needed more guidance from me, their manager. Yet, I didn't adjust my working style according to this and let them struggle. At first, this was unclear to me as we still get to know each other. However, there were many signs that told me to be more involved.

My learning from this situation is to adjust your involvement according to the TRM of the person. If they are the master of similar work and have done it many times, then I don't need to be involved. However, if the work is new to them, I should try handholding in the beginning and reduce the amount of involvement later on.

There is no one-size-fits-all approach at any given time to lead team members. Instead, careful planning considering people's TRM is a must. The leader should play on people's strengths, give them tasks that they are using those strengths, and occasionally give them work where their TRM is low and ensure that they get good support while learning it. Playing to people's strengths will help with morale, and they will better learn and grow.

The last piece of the puzzle is adjusting one-on-ones. When people's TRM is low, handholding requires more frequent one-on-ones and changing the content of the one-one-one to a more guiding mode. If the TRM is medium on the task the engineer is working on, the one-one-one frequency can be much lower, conversations can go more bidirectional, and the emphasis can be on support and mutual reasoning. When the TRM is high, the manager's involvement should be minimal, and the engineer can do most of the talking while the manager helps to establish objectives and how to monitor goals.

Reply via email | Reply via Mastodon | Comment

Maximizing Personal Growth by Understanding Feedback You Get

Thu, 08 Jun 2023 00:00:00 GMT

In 2014, Douglas Stone & Sheila Heen, from the Harvard Negotiation Project and the authors of Difficult Conversations, came together and published a book called Thanks for The Feedback. In 309 pages, they talked about how to receive feedback well. They didn't focus on software engineers or any specific profession. But they doubled down on receiving aspect of feedback.

A while ago, I gave a talk about how to receive feedback to maximize your growth based on their book. And today, I want to write down what I talked about to answer three questions.

Why should we focus on receiving feedback?
Why do we become defensive when faced with negative feedback, and how can we lower our walls?
How do we understand the feedback we get? And what to do with it?

Why is receiving feedback more important than giving feedback?

I have never met a person who wants to stay as it is. Everyone wants to change a thing or two and knows there is no better way than to get constructive feedback. However, what constructive means changes from person to person. Also, focusing on how to get feedback well is not everyone's trait, as it's uncomfortable: we prefer telling people what they should do instead of hearing what we should be doing.

Receiving any kind of feedback is hard—positive and negative. When we get a compliment, we often don't know what to say besides thank you. We deny it and stay humble even though we like the words we hear, and we deeply know that we deserve them. On the other hand, when we hear any feedback that aims at altering our behavior, we see it as a threat, and somewhere in our chest, anger/sadness/frustration pop up. Our mind tells us to calm down, but it's challenging to push back these negative feelings.

Due to this discomfort, we focus more on giving feedback. The responsibility for improvements is not on our shoulders anymore. It's the other side who has to deal with it; it's the other person who has to change their behavior.

If everyone focuses on giving feedback and nobody tries to get better at receiving feedback, how can the given feedback be effective? If everybody talks exceptionally well, but nobody listens, what's the purpose of talking? What thrives groups or communities is valuable confrontation and mastering the feedback-receiving skills or even finding the feedback even when there is no one giving feedback.

As it's promoted in many ways in the business books and behavioral psychology, feedback drives our learning. When we focus on receiving feedback, our curiosity grows with every word we hear. Extracting the best from any negative feedback feeds the growth. The growth mindset looks for feedback but easily builds up walls when we hear criticism.

Even though we need feedback, seek it, and ask for it, we go behind the fence when faced with a harsh one. We can learn how to grow only when we lower our walls and break down fences. Only then can we understand what we lack or do wrong. But why do we put up walls or build fences around ourselves in any criticism we hear?

Why do we become defensive when facing negative feedback?

Because we have an inner voice that never stays silent. Whenever we hear negative feedback, it lights up and starts firing back. Something triggers these blocks and prevents feedback from going through. According to Douglas and Sheila, three triggers erect these walls and block feedback: truth, relationship, and identity.

Truth

We build walls when the other side is—simply put—wrong. For example, we get feedback that says we didn't take responsibility when there was a failure. In fact, we took responsibility and did a great amount of work to recover from failure, yet, they didn't see. So, the other side is wrong; there actually is no feedback. But still, the other person thinks that they give us feedback. So, what's happening there?

To uncover the case, we need to understand three different kinds of feedback:

Three Kinds of Feedback

I wrote about these three kinds of feedback before. In short:

Appreciation: It's the feedback we love when it's authentic and given on time. Examples: "Great job!" "I appreciate the feedback you gave last week. I was able to improve thanks to it." "You're a great team player."
Evaluation: The feedback is to evaluate our skills, align expectations, and clarify consequences. Examples: "We increased your compensation by 30% because you did an amazing job on the last project." "You exceeded our expectations last year." The goal is to rate against standards and expectations.
Coaching: The feedback is to give direction. It aims to help us learn, grow, or change. Examples: "You should work on your debugging skills." "To improve your communication, please read these two books." The coach is aimed at fixing a problem.

We need all three of them. But we feel disappointed or become defensive when we expect one but receive the other. In the example above, we got evaluation feedback that indicates we didn't meet the expectations while we were waiting for the appreciation feedback.

How to Understand The Differences

As we expect something and get something else, there is a mismatch. It's often caused by differences in behavior and intention.

Behavior and intention are two sides of the coin. We see someone else's behavior, but the intention is often invisible. On the contrary, we always know our intention and aren't often very careful about how we reflect it to the other side. If someone is taking the time to give us feedback, they have an intention we must uncover. How they give feedback (their behavior) might trigger unpleasant feelings on our side, but we must actively listen to understand their intention.

Instead of getting into defensive mode and responding with, "That's not true," we must hold the thrust in our internal drive and approach with, "Tell me more." We should insist on asking clarifying questions and getting more information until the person giving feedback has nothing left to say.

A very unintuitive thing to talk about when the truth triggers are working is talking about the purpose of the feedback and figuring out the type of feedback. If they wanted to give appreciation feedback, but it turned into coaching feedback, we can explain these three types of feedback and ask them if they wanted to give coaching feedback or appreciation feedback. Making it explicit and talking about it also helps the feedback giver deliver it correctly.

This was about the truth that blocks feedback from reaching its destination. We also have two more triggers that prevent us from growing. Let's look at the relationships.

Relationship

Sometimes, feedback doesn't reach us because our relationship gets in the way, even though what the other person says is true (most of the time, it's true). When we hear negative feedback from someone we care about (or someone we're frustrated with), we get defensive. We react to who they are, not what they say. What we think about the person and how they treat us causes us to build defense walls.

When our parents told us, "You never tidy up your room," we often said (or thought), "That's my room; stop putting your nose into my life." Our reaction was based on our relationship. Our room was probably a mess, but what we understood was not about that; it was about them intervening in our lives.

At work, when one of our peers we're frustrated with tells us, "Your code is not working," we answer, "Well, it's your problem. It works on my machine. 🤷" It becomes their lack of skill that they can't figure it out. What triggers us to react this way is not the feedback but how we set up our relationship.

While the feedback is about the code not working, we move the discussion to the relationship and push the responsibility to the other side. We switch the track we're on.

Don't Switch The Track You're On

When our moms tell us that we never tidy up our room, it's about our room. When our colleague tells us our code is not working, it's about our code. But our response is about how our mom always interferes with our lives and how our colleagues cannot run the code. We change the track we're on. Our colleague wanted to discuss code, but we moved the discussion to their incapability. When we change the track, we immediately create conflict because that's not what our colleague meant. They then have to explain themselves with frustration or get into defensive mode.

Getting out of this cycle requires us to take three steps back and figure out the relationship system we are in.

Understand The Relationship System

There are three elements in every relationship: two people and the relationship itself. We often forget the last one. To lower our defense walls for feedback to pass through, we need to take three steps back to uncover three elements of the relationship.

The first step back is uncovering two elements: us and the other person. We each have our unique personalities that can create conflict when working with different personalities. In the first step, we should identify how each of us contributes to the problem.

The second step is understanding the relationship: the role clashes. We have our roles in the team and organization. Many role definitions are largely invisible, even if they are well-defined. These invisible boundaries are the hidden source of conflicts. After understanding our roles, we can take the third step.

The third step is looking with a bird-eye view: the big picture in the organization. We should identify how other people, project and hierarchical structures, work processes, and other relationships influence and constrain decisions and affect the outcomes we get.

Side note: Understanding the relationship system also helps to correct our tendency to absorb blame. For more detail, you can read this post.

The first two triggers (truth and relationship) were focused on both sides of the feedback. There is a third, and the most fundamental one, that not only causes us to take a stance against feedback but also pushes us to go offensive—identity.

Identity

Imagine getting feedback that says, "You are always late to the meetings." If punctuality is part of our identity, this feedback will be threatening. As a result, we will feel it in our bones and create walls to mitigate the pain. Or we accept it and dodge the feedback with an answer, "Yes, that's who I am."

While even the best of us makes mistakes and do things that don't match how we define ourselves, how do we prevent the feeling of threatening our identity? How can we lower our guard and accept the feedback?

Side note: This part requires a lot of self-reflection and work on ourselves more than any other situation we talked about above.

We start with learning ourselves and our story.

Know Yourself and Find Feedback Footprint

Learning ourselves is a tricky process. But without it, we cannot comprehend the feedback we receive. We must understand our thoughts and feelings and don't hang up on stories we built for ourselves. Instead of living in the past or focusing on the future, we can take feedback at that moment.

When someone gives us feedback, we shouldn't tie it to our past. When we respond to feedback with, “I was always like that, and I don't think I will change,” we get stuck in our past.

On the other hand, we also shouldn't focus on the future. If someone says, “You don't know how to behave in a meeting,” we shouldn't think in our heads, “I will never learn to work in a team,” which focuses on our future selves who, in five years from now, still don't know how to behave in a meeting.

Instead, we need to take the feedback at that exact moment. To do that, we must discover how we react to feedback, which requires asking ourselves questions and finding our feedback footprint.

Our reactions to feedback define how the feedback giver perceives our feedback-receiving skills. When we surprisingly react with anger or cry in facing harsh feedback, it creates a picture of how we cannot handle the feedback. These various behaviors are the feedback footprints that are unique to the individual. Many people are unaware of their feedback footprint and are not ready to face harsh feedback. Asking ourselves, "How do I typically behave when I receive feedback?" is a good strategy to help us learn our unintentional behaviors. If the answer is crying, then explaining this to the other side can help with the whole situation and the perception we leave on others. After learning our reactions, it will be easier to prepare for any kind of feedback, easily handle difficult situations, and embrace a growth mindset.

Embrace A Growth Mindset

Whenever we build a growth mindset, we see negative feedback as less threatening and more of an opportunity. The growth mindset means looking for cues to learn, finding opportunities to improve, and being open to change. For example, instead of saying, "I am a procrastinator," we can embrace more complexity in our lives by saying, "I try not to procrastinate if I can," and be open to changing our identities.

When we build this growth mindset, we begin taking the extra mile and start looking for cues to learn, even when there is nothing around. We will begin pulling feedback even if there is no feedback at all. This mindset creates a path for us to grow.

So far, we talked about learning how to receive feedback instead of building walls and acting on it to grow. We haven't talked about the other side of the medallion yet, and it's as crucial as accepting feedback.

Drawing Boundaries to Block Feedback Intentionally

Sometimes, we get too much feedback than we can handle. Or we get the feedback at the wrong time. It doesn't mean we should push ourselves to improve on many fronts, which can have a detrimental effect. If we cannot take feedback anymore, it's also okay to draw boundaries and acknowledge feedback and gently deny it. Not every feedback is correct or on time. If we understand the feedback but have no time or energy to take action, we must be clear with the other person, explain why it's not the right time, and thank them for the feedback and the time they spent on it.

Here is an example answer to the feedback we can't take at that moment:

"Thanks a lot for the feedback. I appreciate you taking the time to consider it and give me this feedback. However, I'm currently not in the best position to act on it. I have to figure out some other things that currently require my attention. When I'm done, I will consider your feedback and approach you to talk about it. I hope it's okay for you. Once again, thank you so much."

Learning how to take feedback well is a delicate and complex process. However, once we know the basics, it's much easier to handle any feedback and grow as a person. Even the best of us make mistakes; nobody is perfect. Taking feedback well is not aimed at becoming a perfect person; it's aimed at building a healthy habit of growth, identifying the growth path, and keeping the balance while walking down that road.

Reply via email | Reply via Mastodon | Comment

DDIA: Consistency and Consensus in Distributed Systems

Tue, 23 May 2023 00:00:00 GMT

This article is part of my notes from Chapter 9 of Designing Data-Intensive Applications by Martin Kleppmann. You can read other chapter notes as well.

Chapter 1: Reliability, Scalability, and Maintainability in Distributed Applications
Chapter 2: Data Models and Query Languages
Chapter 3: Data Storage and Retrieval
Chapter 4: Encoding, Decoding, Schemas, and Data Evolution
Chapter 5: Data Replication
Chapter 6: Database Partitioning
Chapter 7: Transactions
Chapter 8: The Trouble with Distributed Systems
Chapter 9: Consistency and Consensus
Chapter 10: Batch Processing
Chapter 11: Stream Processing
Chapter 12: The Future of Data Systems

What we discussed so far has built our understanding of consistency and consensus. In this chapter, we learn how to build fault-tolerant systems. We'll assume all troubles and problems we mentioned in the last chapter can occur, try to find ways to prevent them, and sometimes let the system fail. That's why we need to understand what is possible and what's not. We will learn our limits to provide consistency and learn how to build consensus (it's sometimes better if everyone agrees that things are wrong).

So far, we heard about different consistency levels, such as eventual consistency. In this chapter, we'll learn stronger consistency models and their trade-offs.

Linearizability

The idea behind the linearizability is to make the system appear as if there is only one replica without any replication lag, even though there are multiple replicas behind the scenes. There are subtle details or nuances that impact how linearizability works, but the main idea is that once one client has seen a new value, all other clients should also see that new value and never the old one. Hence, wherever two clients concurrently request data from different replicas, they should see the same data.

Situations such as selecting a leader in a single-leader system demand linearizability. When [discussing](/books/the-trouble-with-distributed-systems/#The Truth Is Defined By The Majority) single-leader systems, we mentioned that leaders acquire a leader's lock. There shouldn't be any two nodes acquiring the leader's lock simultaneously. All replicas should accept the node which acquires the lock first as their leader.

Other use cases include choosing a unique username in a user system, selecting seats in a theatre, or booking a seat on a plane. Although these situations are based on one channel (e.g., one service), there can be cross-channel timing dependencies that require linearizability, such as saving an image and using a message queue to resize it to get a thumbnail in parallel (full-size image must be stored before requesting it to resize) to show in the user creation process.

One confusion is quorums. Quorums in leaderless replication seem linearizable, but they are not. If we use a quorum of two (within three nodes), one client can write a new value to node-1, and another client can read from the other two nodes (node-2 and node-3, satisfying quorum of two) concurrently while the writer is processing writes in node-2 and node-3. When a client reads, they see the old value. Quorum is satisfied, but linearizability is not.

Multi-leader systems are by nature non-linearizable (they concurrently process write operations).

The Trade-Off of Linearizability

If we want linearizability, we have to understand its cost. When we think about keeping data in multi-data centers, we must consider network delays between the data centers. If everything runs smoothly, we can offer linearizability (with synchronous cost). If we use a multi-leader approach, linearizability can be provided from each data center, even if the connection between them is interrupted. Each data center can synch data asynchronously once the connection is restored.

If we use a single leader, we have more problems because the leader can be in the other data center (not in the one the client sends the request). We must return an error because linearizable read and write operations will require the leader. If clients can get data directly from followers, we won't provide linearizability.

The CAP theorem is often mentioned with linearizability with its availability property. But picking two out of three doesn't work; the real solution is "either consistent or available when partitioned." A system can either provide availability or consistency (linearizability), not both. But also partitioning is different in the CAP theorem. It refers to network faults, which is something we cannot avoid at all.

Additionally, not many systems provide linearizability, not because of availability but because of performance. Even when network delays are insignificant and have a reliable network, it is still costly in performance to provide linearizability.

Ordering Guarantees

We have seen the ordering and learned about concurrency in many places across the book. The information about which operation happened before another helped us to offer different levels of guarantees. This happened-before is a comparison operation. When we want to put everything in total order, we should be able to compare certain things somehow. Yet, not everything is comparable.

For example, two mathematical sets are incomparable: how can we compare {a, b} and {b, a}? We can only say they are partially ordered and can think about causally ordering them. So what's different between total order and causality?

The total order is linearizability. One thing happens after another. There are no concurrent operations. Causality is having causally related operations; we can order them but can't compare them whether they are concurrent or not.

That shows that there are different ordering guarantees. In linearizability, there is no concurrency (it's a stricter consistency than causal consistency). Also, linearizability implies causality: if everything is in total order, it's causally correct.

So, how can we implement these ordering guarantees?

Sequence Number Ordering

It's difficult to track ordering operations and identify causality. If we track every operation and determine which ones are causally dependent on another, we would create a large performance overhead. Instead, we can use sequence numbers and timestamps to bring total order to the operations in the system.

If each operation is assigned a unique number, we can use these numbers to order operations. For example, if the system has a single leader, this leader can assign each operation a sequence number or timestamp and use these numbers to order operations. In multi-leader or leaderless systems, each node can assign a number together with a unique node id to make these operations uniquely identifiable. However, we still have the problem of ordering (or causally relating two operations) across nodes if the system doesn't have a single leader.

Before we solve the problem across nodes, let's look at non-causal sequence number generators. Imagine we have two nodes: one can generate and assign odd numbers, and the other even numbers. This way, we can get unique numbers for each operation, but one node can be used more, and the other node's number can stay behind. Thus, it still doesn't tell us which operation came first. Another method is using timestamps generated by a time-of-day clock. However, it's subject to clock skew, as we learned before. Another method is using preallocated numbers in each node (e.g., node A uses 1-1000, node B uses 1001-2000). But again, same as even-odd numbering, using preallocated numbers doesn't ensure a causal relationship.

To solve all these issues, we have Lamport timestamps. Lamport timestamps are presented as (counter, node-id). As the pair will always be unique, Lamport represents the total order. If the counters are equal, the higher node-id will be greater. As this structure is the same with even/odd numbering, the system uses an extra parameter to satisfy causality requirements. Every node and every client keeps track of the maximum counter it has seen so far and includes the maximum on every request sent.

Although using Lamport timestamps brings total order and makes a system consistent with causality, it doesn't solve the problems such as choosing a unique username. Even if we can decide who came first, we can only tell after the order is finalized. If the order is not finalized yet, we cannot tell if a client making a username request can/should succeed. And for that, we need a total order broadcast.

Total Order Broadcast

Total order broadcast is, as the name tells itself, ensuring operations are executed in order across partitions and nodes. Using total order broadcast makes a system act like it has a single partition with a single-core CPU. Systems provide this guarantee with two qualities: reliable delivery (no matter what happens, every node gets the message) and total order delivery (no matter what happens, every node gets the messages in the same order).

In total order broadcast, the message order is fixed at the time messages are delivered; no node can intervene and retroactively insert a message in between if the subsequent messages have already been delivered. We can think of delivering messages like creating logs (transaction logs, write-ahead logs, etc.): we append any incoming messages to the end. As all nodes have to deliver the same messages in the same order, the nodes can get the logs and process the same message sequence.

Linearizability and total-order broadcast are related but not the same. Total order broadcast guarantees that messages will be delivered in order but doesn't guarantee when they will be delivered. In contrast, linearizability is a recency guarantee: a read operation is guaranteed to see the latest written value. We can implement linearizable storage using total order broadcast and total order broadcast using linearizable storage. Actually, both solutions are equivalent to a consensus that we were building upon. If we solve one of these problems, we can build another solution using similar (or sometimes the same) techniques.

Distributed Transactions and Consensus

Until now, we learned about transactions, replication, system models, linearizability, and total order broadcast. These were useful to know before tackling the consensus problem, which seems simple on the surface but more complicated when diving deep. Consensus is important in especially a few cases, such as leader election and atomic commit. If there is no consensus in the leader election (meaning, two leaders accept writes in a single-leader configured system), the data becomes inconsistent.

Atomic Commit and Two-Phase Commit (2PC)

Two-phase commit (2PC) separates from single-node transactions by providing atomicity by implementing two phases: prepare and commit. A transaction manager (or coordinator) manages this process to ensure all nodes are either committed or aborted. The 2PC process starts with all nodes reading or writing data as normal. When nodes are ready to commit, the coordinator sends a "prepare" message and asks nodes if they can commit. If all nodes answer "yes," then the coordinator sends another message (the second phase) and tells them to commit. If any node says "No" to the prepare request, the coordinator aborts the process and sends an abort message to all nodes.

How does the system work in detail? After reads and writes (like in a single-node transaction), the coordinator asks if all nodes can commit. When a participant says "Yes," it has to wait. The node waives all abort rights by saying, "Yes." This is a critical point of no return. Until the node receives the commit message, it has to wait in an uncertain or in doubt state. Once all nodes say yes, the coordinator decides to commit/abort by appending a log message to the transaction log on disk. Right after the log is on disk, it sends a commit/abort message to all nodes. If the commit/abort message fails, the coordinator must retry it forever. If a participant fails at any time, it will commit when it recovers. That log on disk is another critical decision point; there is no turning back. So, in reality, 2PC is actually an atomic transaction in the coordinator. What happens if the coordinator fails? If the coordinator fails before sending the "prepare" message, all nodes can safely abort the transaction. But once the participants receive the "prepare" message and vote "yes," they cannot abort unilaterally until they hear back from the coordinator. If the coordinator fails at this point, the participants have to wait for the coordinator to recover. This is why the coordinator must write the decision to its transaction log before sending a commit/abort message. Once the coordinator recovers, it checks its transaction log. If there are any transactions without commit messages, it aborts all.

Distributed Transactions In Practice

Distributed transactions have a mixed reputation due to their impact on performance and causing operational problems. Much of the performance problems come from disk syncing that's required for crash recovery and extra network round trips. On the other hand, they provide safety features that are hard to reach otherwise. Although performance is usually what we optimize for, we still have things to learn from distributed transactions.

There are two types of distributed transactions.

Database-internal
Heterogeneous.

In database-internal distributed transactions, databases implement according to their needs and use protocols as they wish. Distributed transactions are used for data replication and partitioning, and databases use the same software or protocol across the whole database. Database-internal transactions work well as they don't need to be compatible with other systems. We face most challenges in heterogeneous distributed transactions.

In heterogeneous distributed transactions, systems use different software and, sometimes, systems are also not databases, such as message brokers. Here, distributed transactions must ensure commits are atomic within this variety.

The most important piece in heterogeneous distributed transactions is atomicity. Let's say we have a message broker that sends a message to a service. The message can only be acknowledged if and only if the database transaction, which is processing the message, was successfully committed. The system must ensure these two operations (acknowledgment and database write) are successful by using atomic commit. If any of them fails, the transaction is aborted, and the message broker can send the message again. If there is no atomic commit, every retry can cause side effects. For example, if we're using an email delivery service, every retry can send an additional email. Distributed transactions ensure the side effects of a message happen if and only if both operations (ack and database write) are successful.

XA Transactions

X/Open XA (eXtended Architecture) is not a protocol but simply a C API for interfacing with a transaction coordinator. Participants of a distributed transaction offer XA API.

The application that needs distributed transactions uses an XA transaction coordinator living in the same process or machine as the application. The coordinator can ask participants to prepare and commit/abort via a client library or network driver that the participants implement for XA with its XA API.

The major problem is if the coordinator dies (e.g., the process is killed or the machine crashed), all the participants will be stuck in a locked state waiting for the coordinator. When the coordinator recovers, it can read the logs for transaction decisions. The database holds locks at the whole row that the transaction will write, preventing dirty writes (we talked about it in read-committed). Also, if a transaction includes reading and we want serializable isolation, then the database will hold locks for read transactions as well, practically blocking all other transactions that want to access that data. These locks will stay until the coordinator recovers or is manually resolved by an admin.

When the coordinator fails and its recovery logs are corrupted or lost for any reason, the admin must look at all the participants and check if anyone committed the transaction. Then the admin must decide and apply the decision to all participants. Many XA implementations have an escape hatch called heuristic decisions: a unilateral decision by the participant of a transaction to decide on commit or abort. As the participant decides, the heuristic decision breaks atomicity. Thus, these cases are intended for catastrophic situations only.

Limitations of distributed transactions

If the coordinator is not replicated but runs on a single machine, it becomes a point of failure.
Many server-side apps are stateless these days and save their states in a database. However, when the coordinator is part of the server, the server becomes stateful as it should keep coordinator logs on the state and should recover from failures by using these logs.
XA cannot detect deadlocks across systems and is incompatible with Serializable Snapshot Isolation.

Fault-Tolerant Consensus

Consensus means getting several nodes to agree on something. Formally, one or more nodes may propose values, and the consensus algorithm decides on one of the proposed values. Any consensus algorithm must satisfy the following properties:

Uniform agreement: No two nodes decide differently.
Integrity: No node decides twice.
Validity: If a node decides value v, then v was proposed by some node.
Termination: Every node that does not crash eventually decides on some value.

The first two values are the basics of consensus; everyone decides on the same value, and you cannot change your mind later. Integrity property rules out trivial cases, such as an algorithm cannot decide on a value not proposed by a node. The last property, termination, is there to formalize fault-tolerance. Also, it prevents having dictatorial setups where only one node decides on everything. The termination property ensures that if any node fails (and assumes that it won't come back online), the system can continue making decisions. (that's also why 2PC is not a consensus algorithm; it requires every node to be online, including the coordinator. If the coordinator fails, the system comes to a halt.) Of course, there is a limit to failures. Any consensus algorithm requires at least the majority of nodes to be functioning (have a quorum). However, most consensus algorithms ensure that the first three properties are always met, even if most nodes are crashed. This way, the system may not process requests, but it cannot corrupt the consensus system by making invalid decisions.

The most known fault-tolerant consensus algorithms actually don't make decisions on a single value in each round, but they agree on a sequence of values, which makes them total order broadcast, as we learned earlier in the chapter.

Total order broadcast requires messages to be delivered to all nodes exactly once, in the same order. This strategy is equal to several rounds of consensus. All nodes decide to deliver the same messages in the same order (agreement). Messages are not duplicated (integrity). Messages are not corrupted or created out of thin air (validity). Messages are not lost (termination).

Epoch numbering and consensus

The consensus algorithms we talked about above don't guarantee that there will always be a single leader. However, they guarantee a single leader for each epoch (a round), a number defined by a protocol, and it's monotonic and ever-increasing.

Each time a leader is dead, a new selection starts. This election is given an epoch number, and there can be only one leader with this epoch number. If there is another leader (maybe a node remained from the last round but was thought dead), a higher epoch number wins.

Before doing anything, the leader checks if there is another leader with a higher epoch number. However, it cannot decide on that itself. Thus, it requires a quorum of nodes' votes. For every value leader proposes, the leader sends the value to a quorum of nodes. A node accepts the proposed value only if it knows no other nodes with higher epoch numbers exist.

We have two rounds of voting: one round for selecting the leader and another for voting on the leader's proposal. The key is the attending nodes on two rounds must overlap: there has to be at least one node that is present in both rounds, even though quorums can consist of different nodes. This rule ensures that there is no other leader in the process.

The algorithms we discussed look similar to Two-Phase Commit (2PC) but are different. 2PC requires all nodes to vote "yes'' while consensus demands a quorum. Also, 2PC is not fault-tolerant like consensus algorithms, and the 2PC coordinator is not elected.

Limitations of consensus

Voting on a proposal process is very similar to synchronous replication. The committed data can be lost, as we saw earlier chapter.
The consensus requires a strict majority of nodes to operate (as we learned quorums in the data replication chapter before). If we have three nodes, we can tolerate one node's failure; in five nodes, two failures. If any network failure happens, the non-majority can be blocked.
Adding and removing nodes to the system is difficult. Consensus requires a fixed set of nodes (There is dynamic membership, but it's not well understood in the industry.).
The consensus relies on timeouts to detect failed nodes. Unbounded delays can cost performance due to frequent leader elections.

Membership and Coordination Services

Zookeeper and etcd are eventually key-value stores, databases that fit into memory (but still write to disk for durability). However, they implement consensus algorithms. What makes them useful is the features they provide, even though application developers rarely interact with them directly (they are used indirectly; e.g., Kafka and HBase use Zookeeper). They provide an interesting set of features:

Linearizable atomic operations: Atomic compare-and-set operations allow implementing a lock: if several nodes try to write, only one will succeed. The consensus comes into play and guarantees that the operation is atomic and linearizable even in node failures (leases are used in locks).
Total ordering of operations: With fencing tokens, Zookeeper prevents clients from conflicting with each other. Zookeeper uses total ordering and assigns each operation a monotonically increasing transaction ID and version number.
Failure detection: There are periodic heartbeat checks between Zookeeper and the client. If heartbeats fail above timeout time, the client is considered dead (it's called an ephemeral node in Zookeeper).
Change notifications: Clients can subscribe to changes in Zookeeper instead of requesting information regularly, so they can be notified when a new client joins the cluster. Even though only linearizable atomic operations require a consensus algorithm, combining these features makes Zookeeper worthwhile.

Also, Zookeeper can be used to allocate work to nodes. While partitions can join and leave the cluster, they can register or be declared dead on Zookeeper. Using the combination of features listed above, we can automatically implement mechanisms to recover from failures without human intervention. However, this implementation is complex and difficult. That's why Zookeeper and etcd are often used for service discovery. This service discovery doesn't require consensus. However, leader election requires consensus, and knowing the leader (discovering) becomes important, and other services can discover the leader via Zookeeper. Hence, some consensus systems support read-only caching replicas. They do not participate in voting and asynchronously receive the all decision log of the consensus algorithm and serve read requests that are not needed to be linearizable.

Reply via email | Reply via Mastodon | Comment

Resilience comes from recovery

Sun, 21 May 2023 00:00:00 GMT

Resilience comes with recovery, not endurance. You won't build resilience when you push for one more time if you're already exhausted. Your productivity will be depleted. Resilience comes from recharge and recovery. Professional athletes (like LeBron James) spend extra time on recovery, and the best ones consider it part of their training. Recharge doesn't mean resting. If you dive into politics on your phone while lying down on your bed, you're not recovering. You need to spend time with friends (not talking about work), meditate, watch a movie, or do other activities you enjoy in your life. That's how you build resilience, by keeping your energy level in control so you can push more exactly when needed. Otherwise, you burn out.

We can see the same in weightlifting. If you need to do three sets of ten repetitions, you must choose a weight that you can lift thirty times with a break in between. You can't lift it without a break. Also, choosing a weight is important too. If you add heavier weight, you probably can only lift it ten to fifteen times, not thirty. You need to build the muscles in time to increase your weight.

Related Note(s):
Source(s): Resilience is about how you recharge, not how you endure & Calm App's Lessons: Train Your Mind - Vol. II with LeBron James

Reply via email | Reply via Mastodon | Comment

Bet on things that won't change

Sat, 20 May 2023 00:00:00 GMT

"Bet on things that won't change rather than predicting how things will change." — Jason Cohen

Many experts fail to predict the future because many things change constantly. However, there are a few things that never change, and we know that they will always be there. For example, customers will always want low prices and high-quality customer service (that's what Amazon bets on). Find what doesn't change on your product, domain, or even life, and bet on them. Be strong on that front and follow what life brings you, and adapt to changes.

Related Note(s):
Source(s): Navigating the unpredictability of everything;

Reply via email | Reply via Mastodon | Comment

Love the Constraints

Tue, 16 May 2023 00:00:00 GMT

When I look back at the topics I covered in Mektup, I wrote about energy and time management, habits, multitasking, mentoring, remote work, process thinking, and many more. If I take one step back, a challenge becomes visible: I'm in the middle of all, trying to navigate, mediate and negotiate within some constraints to find my way. That's why I renamed my newsletter to Mediations (not Meditations), and on this post, I want to talk about how to understand and work with constraints in our work life.

If we look at constraints from a higher perspective, time, people, and money are the biggest ones. Whatever we want to do, we are dependent on time and other people. We all have working hours (constrained by how much money we earn, less money = less time) to achieve a goal. How much a team achieves in these hours decides the team's success. Moreover, anyone in the team is also constrained by others to deliver their work in collaboration. Thus, we must find ways to understand these constraints and find an optimal solution, just like we do in software engineering.

While building any software, we have limitations, such as memory, CPU power, the maximum number of parallel processes, accumulated tech debt, network latency, programming language limitations, and many more. If we make a pass at building anything, we must consider all of these constraints. For a mobile application, battery consumption is a concept we must consider and plan not to consume too much. For a backend application, we must decide the size of the database and not waste money by buying the biggest machine (and sometimes, they are also not enough). If the aim is to serve a million requests in a second, we have to find ways to eliminate failures and increase the resiliency of the system. It doesn't stop there. The same applies to organizational design.

Deciding how many engineers are needed for a project is one of the most fundamental challenges. Amazon uses the two-pizza team analogy (two pizzas should be enough to feed the team), while startups don't have this chance to hire that many people. The companies in between two scales (startups <-> MAANG) struggle with finding the right balance. I've worked in teams with sizes ranging from two to ten. In almost all teams, hiring is a big topic because there are always more things to do than we can handle with the existing team size. We never have enough engineers on the team (even with ten people), and projects are always late or delivered on time with accumulated tech debt.

Organizations still add more engineers to already-full teams by thinking that the delayed project will go faster, the accumulated accidental complexity will be resolved, and everything will be alright. And this mindset always proves wrong and often makes things even worse.

The team culture and health of its members will face troubles when there are more than ten engineers on the team. It's challenging to agree on anything with ten people; any small change in working agreements needs to be followed up with everyone, the number of meetings increases (while productive meetings decrease), unhealthy conflicts emerge, and solving them becomes much more difficult. Eventually, leading the team to a halt instead of speeding up the delivery. There is one (but not the only one) reason behind adding one more engineer to the team.

We were taught the economy of scale: the more, the merrier. Especially industry evolving from manufacturing taught us the bigger the capacity, the less cost of producing an item. However, in software engineering, it's the contrary; we have a diseconomy of scale. The bigger the organization, the bigger the cost of delivering anything. Startups can deliver products and features with light speed, while MAANG takes years to produce anything. The bigger the team, the quicker the software complexity increases. Once the software is big, it takes more time to add new features due to its complexity. Thus, reduces the delivery speed. There is one way to calm our minds in this complicated world and put all constraints into a picture.

We can think about everything we do as a system that operates independently. The global economy is a system in the same way a country's economy or a company is a system. Each system is part of a bigger system, has its subsystems, and, at the same time, works semi-independently of other systems.

A software engineering team is also a system. It has its own processes, projects, working style, resources, people, rhythm, and limitations. The output of this system is what the team delivers. Adding one more engineer to an already-full team will increase only one parameter—the number of engineers. However, it may or may not increase delivery capacity due to increased complexity in processes, communication, and team rituals.

Many organizations assume they will operate well if they hire more people. I believe this thinking is flawed. If a team has enough engineers, the constraints are somewhere else. If the team is staffed, they will still have many other challenges in delivery.

"Having “enough” engineers for a project is usually a terrible idea; you want to be constrained, you want to have to make hard decisions about where to spend your time and where to invest development cycles." — Charity Majors

The increasing communication overhead will balance the system and prevent growth in delivery. Understanding the system, its inputs, outputs, and parameters impacting these inputs and outputs helps us understand our constraints. Yet there is one more caveat: the constraints change all the time.

Changes in the economy after the pandemic altered companies' strategies (link paywalled). The desired growth mindset left its place for financial stability and profitability, leaving teams working with a different set of constraints. There is no more adding another engineer to the team, growing teams, and splitting them into multiple. Instead, there are new strategies (but not so new; the world economy always had ups and downs) to increase delivery with fewer people. Adaption to new constraints is now mandatory.

In the post's title, I said, "Love the constraints" because these constraints drive creativity. Adapting to a different economy and life demands dealing with various challenges. As these challenges are evolving, we have to find other ways. Finding new paths is a creative process. "Best" practices to increase delivery with limited staff and resources have been there for decades (The Goal by Eliyahu Goldrat is a great book to read for understanding bottlenecks and throughput relationships). We only need to find which practices fit our situation, the people on the team, and the company culture and strategy.

There is no other way than to love all these changing constraints if we want to lead people to success in turbulent times. Any leader (or aspiring leader) must spend time finding out the constraints (albeit they won't find all, some black boxes need to stay as black boxes). Once the constraints are visible, creating a strategy and driving the team to success is much easier. Knowing them is like seeing the path and obstacles clearly in a hurdle. We might not become the winner and get a gold medal in every race, but we can definitely complete the race without falling.

P.S. I recommend reading Thinking in Systems by Donella Meadows to learn more about how systems work and how to understand them and not be victims.

P.P.S. After two and a half years and 53 issues, Mektup says goodbye to its readers. Mediations will be the only newsletter from now on (including occasional book notes). The archive of Mektup is always available.

There are no separate systems. The world is a continuum. Where to draw a boundary around a system depends on the purpose of the discussion. — Donella Meadows.

Reply via email | Reply via Mastodon | Comment

Why Inspectional Reading?

Thu, 27 Apr 2023 00:00:00 GMT

The questions that we need to answer after inspectional reading shows how much we need to get to know or understand the book. I say get to know because some books cannot be understood in the first reading and demand analytical reading. However, the majority of the books require only part of the inspectional reading—systematic skimming. Looking at the title, subtitle, preface, table of contents, index, publisher's blurb, and reading a few pages here and there (the chapters pivotal to arguments) can already help us understand what kind of book it is, what the book as a whole about and what's the structural order of author's ideas and how they are presented. When this is not enough, we need to read the book quickly from cover to cover. There are also not so many books that require reading even once. When we read, we shouldn't stop and ponder on arguments; just continue and finish to get to know the book as a whole.

Related Note(s):
- 39: Increasing Quality of Systems;
- 65: Learning and Understanding;
Source(s): How to Read A Book Book

Reply via email | Reply via Mastodon | Comment

Sometimes Saying Nothing Tells Everything

Tue, 25 Apr 2023 00:00:00 GMT

We were having dinner with a friend, and in the middle of it, he said, “Candost, why are you so silent?” I was confused because we were in the middle of a conversation, and I was actively participating. When he clarified that he meant silent in life in general, I was yet surprised again. Because I always considered myself someone who talks too much.

Then I remembered one scene from a Turkish movie where this exact question is asked. And I gave the exact same answer to dismiss the question. I said, “I talked too much. I didn’t see any benefit. So, I stopped.” I wasn’t ready to go into a deep conversation, and I needed to observe myself and reflect. Even though my friend was clearly unsatisfied with my answer, he let it go. But, in my mind, I couldn’t. And this was around four years ago.

Over the years, I wondered why my friend and I saw my behavior differently. Why do I consider myself talking too much, meanwhile others perceive me as silent? And how it reflects in my professional life as a leader?

I thought about the early years of my career. I remember talking too much with my limited knowledge. I assumed I knew things. The more I learned, the more I realized how much I didn’t know, and I started to listen and only talk when needed. Isn’t it the same in life? The children talk too much, but the adults listen. As we grow, we get more silent. It’s fascinating to see the same trend in professional life.

Reducing my over-talkativeness tremendously helped me learn more because others had space to share their thoughts and experiences. When I started listening, I also realized many smart people are often invisible because of the loud voices (in my early career, that was me) getting the most attention.

When I became a manager, I had to learn how to stay silent to make invisible people visible, hear all voices, and create space for discussion without actively participating in it. People expected me to create that space for them to talk, not for me. However, this expectation was unintuitive for me. All my professional life as an engineer, people expected me to talk and give input, but now they want me to shut up—quite literally. I had to let go of all my instincts, urges, and learned behavior.

It was not easy. However, once I did, the world became more peaceful, and I finally felt that I was helping people. It was so controversial; how could I help people while saying almost nothing?

I brought this question to my manager back then and asked how I could balance staying silent and giving the right direction or coaching to people. That’s when he said, “Sometimes, saying nothing tells everything.”

My mind quickly responded with, “What bullshit.”

But I reminded myself that I needed to listen. And I actually wanted to learn. What could I lose if I tried?

Oh boy, I was wrong.

It took me a while to figure out how, but once I did, it was magical. People solved their problems when we were talking, and the only thing I did was say less than ten words and mostly ask a question within these ten words.

There were awkward silences, for sure. In any of these moments, I counted up to ten (or, rarely, up to twenty) within me. Silently. People usually started talking when I was around five or six. They either brought up an extremely valuable insight that I was missing, revealed what they honestly thought about a situation, or just thought out loud and solved their problems without me saying a word.

That first four seconds gave people time to digest what we were talking about and light up new thoughts in their minds. While I was keeping my mind busy by counting up to ten, people usually couldn’t resist the awkward silence after that four seconds.

I had to bite my tongue and not fill that silence even though how much difficult it was. That silence was an investment in people’s growth (as I learned from the book The Coaching Habit), and I had to make that investment. When I did, I finally understood what my manager meant.

There is a big word at the beginning of the title that I haven’t talked about yet. And that is: “Sometimes.”

While staying silent is unintuitive and challenging, learning when to shut up is even tougher. You can’t just stay silent when you are expected to give input, and you definitely shouldn’t talk at every chance you find.

Oysters open completely when the moon is full; and when the crab sees one it throws a piece of stone or twig into it and the oyster cannot close again so that it serves the crab for meat. Such is the fate of him who opens his mouth too much and thereby puts himself at the mercy of the listener. —Leonardo da Vinci, 1452–1519

Learning when to talk is a long experiment, and I’m still progressing because it also changes from situation to situation and person to person. Especially in our one-on-ones with people who report to me, I feel more comfortable with awkward silences because I’m not facilitating the one-one-one meetings; the ownership is on the other side. So, if there is an awkward silence, they usually bring up the next topic, and I often talk last.

In group meetings that I’m facilitating, it’s also not really challenging because I’m in that facilitator’s seat, and the responsibility of the moderator is moderating the meeting. The biggest challenge is when we discuss a problem or brainstorm solutions with a group.

That’s where my software engineer brain plays its tricks. The years of education and cemented behaviors of I-share-my-knowledge-and-contribute-to-the-discussion-and-work-hands-on kick in and push me to talk more. Whenever I feel this compulsive need to take action, I try remembering how my previous leaders didn’t jump in and gave me space to share my perspective when I was an engineer (lucky me). However, it’s challenging as a leader because I see two things as my job: doing (making things happen) and being (observing and reflecting)—as Michael Watkins put it right in the book The First 90 Days.

Effective leaders strike the right balance between doing (making things happen) and being (observing and reflecting). But it is challenging...to let yourself "be"...and the pressure to "do" almost always comes from inside the leaders than from outside forces; it reflects a lack of confidence and a consequent need to prove yourself.

I have that lack of confidence in me (hello, my inner critic). That insecurity is my main urge. When I recognize this urge, I try to remember Watkins’s recommendation:

Remember: simply displaying a genuine desire to learn and understand translates into increased credibility and influence.

In general, I have a huge desire to learn and understand. That’s where I leverage it: I wait to hear all opinions first and then, only then, try a few things.

I play devil’s advocate. It’s one of the most useful things I learned while reading The Culture Map by Erin Meyer. If you have a controversial idea or want to challenge people, just tell them, “Let me play the devil’s advocate here,” and continue, “So we discover other options. How about we do X? What would be the consequences?” Once people hear that I’m not approaching with authority but a discovery mindset, they often show a healthy debate attitude and can clearly tell me why my idea sucks. Playing the devil’s advocate helps to reach a better result.

Another thing I learned from Turn The Ship Around was telling people, “I’m thinking out loud; here is where we need to be and why,” and I encourage them to think out loud with worries, concerns, and thoughts. This approach not only creates a debate environment but also helps me learn what I actually think. When I think one solution is better than the other and I want to bring it up, I use this approach and end the sentence with a question to others (e.g., “What is missing or what you see wrong?”), so they can also correct me on the way if I misunderstand something.

Meanwhile, there are a few necessities for any kind of silence to work. It won’t help you if the trust is not built in or nobody knows you yet. So, you shouldn’t be a mysterious person, and people shouldn’t be hesitant to talk to you because they have no idea what you think. This staying silent only works after people get to know you and trust you.

As we don’t—and shouldn’t—have the authority of the French King Louis XIV, we have to learn the balance.

Ministers and nobles would spend days debating on the state’s issues and finally arrive at a moment to present two different sides to Louis XIV. They were also spending a lot of time on how to best present, wordsmithing every sentence and deciding on what time of the day to approach Louis. Once they present, Louis would only say, “I shall see,” and walk away. Nobody would hear anything about the issue from him for days, sometimes weeks, and they would only see the results when he came to a decision to act.

Acting like Louis is not an option for me and, I strongly believe, for other leaders in software companies. Silence is a balance to find, and it’s challenging. However, after you have the relationship built in and have trust, leveraging the silence and creating room for others both in team meetings and in one-on-ones get easier.

Lastly, whenever you talk, choose your words wisely. Because their impact is almost always invisible to you.

"Words should be scattered like seed; no matter how small the seed may be, if it has once found favourable ground, it unfolds its strength and from an insignificant thing spreads to its greatest growth. Reason grows in the same way; it is not large to the outward view, but increases as it does its work. Few words are spoken, but if the mind has truly caught them, they come into their strength and spring up. Yes, precepts and seeds have the same quality; they produce much, and yet they are slight things. Only, as I said, let a favourable mind receive and assimilate them. Then of itself the mind also will produce bounteously in its turn, giving back more than it has received." — Seneca, Letters from A Stoic, p. 218

Remember, “Sometimes, saying nothing tells everything.”

P.S. I heard the French king’s story from the book The 48 Laws of Power.

Reply via email | Reply via Mastodon | Comment

Learning and Understanding

Sun, 23 Apr 2023 00:00:00 GMT

When we come across information, we mistakenly think we have learned something new. However, we just learned that that specific piece of information exists. We didn't learn what that information tells us. To understand the information, we have to actively think about it and apply it if it's applicable. When we read a newspaper, it increases our information level but rarely changes our understanding of anything. Reading for understanding requires being ignorant or having a little bit of information about a topic. It demands active engagement with the topic. It's where most people stop. Once they receive information, they consider that they have learned something new. Actively engaging with the topic requires us to ask questions and try to answer them with the information we receive. Once we're informed (read/watched/listened to a piece of information), we need to take these extra steps to understand it. Once we do, we become enlightened. To differentiate between an informed and enlightened state, consider yourself in a classroom where a teacher is explaining one topic. When learning by instruction (that's what the teacher does), we're only informed. We need to take the next step and learn by discovery: that's when we try answering questions that come after instructions and solving problems that the teacher has asked.

Related Note(s):
Source(s): How to Read A Book Book
Resourced:
- Moving to Substack;
- How to Get to The End of a Pile of Unread Books;

Reply via email | Reply via Mastodon | Comment

My Experience Living Without Social Media

Thu, 13 Apr 2023 00:00:00 GMT

On January 23rd, 2023, I started an experiment and stopped all my social media usage. I didn’t read anything on Twitter, Mastodon, and LinkedIn. I occasionally checked my automated article sharing to see if they had been posted correctly, and during that checks, I read LinkedIn and Twitter messages from people I knew in real life.

The experiment lasted until April 1st, but I’m happy to say that I don’t think I will use any social media as I was using before. And I am quitting any consumption on Twitter.

Before I get to the results and the decisions that will somehow affect my life, I want to explain why I tried this experiment and how I approached it.

Why?

For a while, I’ve been trying to reduce distractions such as emails, SMS, and notifications. They occupy many moments in my life, interrupting my real-life conversations and resulting in moving my focus to my phone in the middle of a chat in a café. As I get irritated when people look into their phones while we talk, I also want to stop doing the same myself—walk the talk.

Besides, I was spending hours on social media without realizing it at all. I was not under control. In a blink of an eye, I easily spent one hour scrolling through my feeds endlessly. This behavior cost me a lot, and I started sacrificing important things such as family time, reading, writing, and music. However, there is a much bigger reason for me to reconsider social media.

As social media gave voice to everyone (including me), it became overwhelming. We never had this in our lives for thousands of years; we lived in much, much smaller circles. We valued our community’s opinion within that circle and wanted to belong. When social media entered our lives, we also applied the same behavior there. Now, we value the opinions of people we don’t know and follow. Whenever a jerk makes us feel bad, we feel it in our bones even though we don’t know the person and don’t want to hear (or read) what they say. For me, I only want to talk to people who are kind (not jerks) and don’t draw my energy.

As much as I want to hear diverse thoughts in my life, I definitely don’t want to hear a lot of voices I see there. Also, diversity is terribly represented in social media, and the whole experience creates filter bubbles instead of promoting diverse opinions. That’s why we also never get what we expect.

Meanwhile, I can’t deny that there are also people that I got to meet on social media, such as Michele, Roberto, Nick, Benedicte, and Fatih, whom I have never met in real life, and they are always great to talk to. Social media also gave me a chance to meet with people (also in real life) who read what I write, such as Baris, Kemal, and Daniela. As I was lucky to form new kinds of relationships with these people and many others, my real-life relationships were ebbing and getting shallow.

I have good friends that I don’t know what they value in their lives even though we talk regularly. We only send each other tweets and interesting threads but don’t talk about deep topics in our lives at all. We’re just considering each other and have a touch base over social media. Of course, it’s not a big issue to have a few of these friends. However, I realized that more of my relationships were evolving in that direction while I was seeking high-quality relationships in real life.

Furthermore, my real-life relationships started becoming shallower because all of my life started to evolve around social media. When we met to have a coffee, we started asking questions like, “Have you seen this post?” or just showing each other funny posts. I’m not diminishing the effect of creating shared language or experience; however, I’m questioning the quality of that shared moments. Whenever we conversed with my friends without involving any technology, I had the most fulfilling and thoughtful conversations.

Last but definitely not least, I realized that my ideas were becoming more shallow. When I saw a spontaneous tweet from a random person, that tweet was in my mind for a while, and I was thinking about what this person said. Probably, even the person didn’t think about what they wrote as much as I did. As Twitter’s motto is “What’s happening now,” it promotes an always-on and being-liked culture through its algorithms. Instead of writing quality ideas, I also fell into the trap of getting involved and tweeting more controversial and interesting tweets, even though it’s definitely not my style. Therefore, I had inner conflicts.

I sought to think deeply and share what I found (the reason why this blog exists). Although these ideas can still be shrunk to 280 characters, they never stayed on the platform and were only read by people who were online. What I have written so far is now deep in my profile, and I can’t even find what I said two years ago. This “popular” and “happening now” is an awful combination that creates hype, which I’m trying to avoid everywhere.

All these struggles led me to take a few actions over the last few years, even before starting this last experiment. I reduced my following count to prevent endless scrolling, deleted my Instagram and Facebook accounts, and turned off all social media emails and notifications. The time came to pull the band-aid off.

How? (The Setup)

All the struggles I explained were present for the last two years, and I was already discovering what I could do differently. In my research, I found good books and articles and followed a few authors who helped me build the setup I will explain below. Cal Newport, James Clear, and Shane Parish are the most impactful ones. Cal’s books Deep Work, Digital Minimalism, A World Without Email, his podcast, and James Clear’s Atomic Habits fundamentally affected how I changed my environment and created the setup.

Environment Design

I learned that designing our environment in a way that will nudge us to act in the way we want has more impact than searching for motivation or having discipline. So, instead of waiting for motivation, we change our environment. For example, if the television is always visible and on reach, we’ll open the TV more often. If we have the Twitter app on our phone’s main screen, we will open the app whenever we look at our phone. If we see it, we do it. If we don’t see it, we forget it.

That also applies to behaviors we want to build. For example, my bass guitar was sitting in its case for years. I pulled it out and put it in the middle of the room. Every time I entered the room, I saw my bass guitar. Eventually, I started picking it up and practicing more. Another example was building a reading habit. To read more, I put books in every corner of the apartment. Wherever I sat down, I had a book within arm’s reach. Seeing books reminded me to read more, and eventually, I grabbed books one by one and read 1-2 pages here and there until my habit was formed. While forming these habits, I started very small.

In One Small Step Can Change Your Life, Robert Maurer talks about the small steps to build lasting habits. For instance, all my young age, I never flossed my teeth. At the end of my 20s, I really wanted to build this habit. In the book, Maurer recommends starting as small as possible so that you cannot avoid doing it; not doing it would be silly. For example, I started flossing only one tooth. I couldn’t procrastinate because it was so small that I couldn’t convince myself to not do it. Saying the procrastination word out loud took more time than flossing one tooth. Once you start that small and build the habit, it’s easier to add the second tooth. After 8 months of gradually increasing the number of flossed teeth, I’m now fully flossing my teeth every day.

I tried the same strategy in lowering my social media usage. Instead of dropping instantly, I’ve reduced my following count and muted people and keywords one by one. I now have a long list of muted words on Twitter (e.g., eth, bitcoin, NFT, Recep Tayyip Erdogan, football). Designing the platform in the way I want to use helped me a lot to reduce my overall usage. However, Twitter and LinkedIn allow you to a certain extent. Their algorithms are still in place to feed you with new content all the time. That’s why I needed to take many more extra steps and design my environment.

Apps and Devices Setup

I looked for tools and systems to design my digital environment better suited to my needs.

First and foremost, I removed all social media apps from my phone, including Twitter, Mastodon, LinkedIn, Discord, and Polywork (I had already deleted my Facebook and Instagram accounts in June 2020). I also logged out from all these accounts on my mobile and desktop browsers. Once the apps were gone, I didn’t see anything related to social media when I picked up my phone. Whenever I wanted to log in to social media, I had to use the browser. I logged in, checked the feed, and logged out every single time. I also set up two-factor authentication (2FA), and that also made logging in difficult whenever I tried. When small things require extra effort, it gives the brain time to reconsider the action. I actually changed my mind many times during the 2FA process and just killed the tab on the browser.

I wanted to take that environment design one step further and suppress my urges. I was already using Freedom App for a while to focus and block certain websites during my writing time. This time, I set up a daily recurring session that blocks all social media on my phone. Freedom works remarkably well, and once enabled, you cannot bypass it (in its Locked Mode) in any way. Freedom helped me to break my habit of reaching social media without recognizing my own behavior. Later, I extended Freedom to cover my personal and work laptops but with less strict rules.

Freedom App and removing social media apps didn’t help with certain things, such as notifications. I actually wanted to reduce my phone addiction simultaneously with my social media usage. I was often getting distracted by notifications from various apps (other than social media). That’s why I turned off all possible notifications (except calendar notifications, Telegram, WhatsApp, and a few other apps that I use for habits, health, and finance). On my Apple Watch, I turned off all notifications except calendar and on-call pager notifications. I’m living by my calendar; it’s not a chance for me to turn off calendar notifications. The on-call notifications are also not random; I only get them when I’m called for production incidents. I must admit that turning off notifications is probably one of the best decisions I have made in my life so far. It’s so revealing not to have any notifications coming in (and I’m considering turning off ALL notifications, but I will come to that in another post).

All said, I still wanted to share my blog articles on social media. Hence, I set up automation using Zapier to send a tweet and post a LinkedIn message when I publish a new article. That’s why I logged in to the platforms from time to time during the last two months to check if the posts were displayed correctly. (Twitter character limit was often the problem. If you’re following me on Twitter, you might have seen some tweets with broken links.)

Supporting my FOMO

I was still curious to hear from people I follow and didn’t want to miss out. I reduced my following count a year ago to the max. 100. So, I only followed the people I personally knew or valued what they shared. Right before the experiment, I checked whom I was following and if they had blogs. If anyone had a blog, I subscribed to their blog (with RSS if possible) and unfollowed them on social media. That made me sure that I still heard from them at the time I wanted to hear, not at the time decided by algorithms. I also unfollowed them because I cared about them as a person, not what they were doing at that exact moment. I know not everyone writes on their blogs regularly, and they often tweet something rather than blog about it. However, I was fine with this limitation, and I thought if something important happens I would definitely learn from other mediums (e.g., word of mouth) anyway (Edit: I followed on this with JOMO, Joy of Missing Out).

Results and Discussion

Since I lifted the restriction, I have been logging in to either Twitter or LinkedIn not more than once a day. Checking them doesn’t come to my mind. And whenever I do, it usually takes me 1-3 minutes to scroll my Twitter feed as I only follow a handful of people, and the majority of them don’t even send a single tweet in months. Therefore, I can safely say that I broke the social media habit. (Edit: Later I realized, it also impaired my learning)

After the experiment, I thought about deleting my Twitter account. I’m still thinking about it because from now on, I will probably rarely tweet something other than automated tweets of my articles. And Twitter never likes links and doesn’t promote these tweets to anyone. Yet, when I look at the statistics of my articles, I see a few people are reaching out to articles from Twitter. Hence, I’m intended to keep the account and only share links to my articles and occasionally check my inbox for new messages without consuming my feed. (Edit: I deleted my Twitter account in December 2023)

Meanwhile, LinkedIn is a nightmare. There is no control mechanism on it at all. I tried to unfollow people on LinkedIn, and, oh boy, LinkedIn literally doesn’t want you to unfollow people without notifying them. I can see my connection list, but it doesn’t give me an option in that list to unfollow people while staying connected. I don’t want to remove connections with people; I want to unfollow them so I don’t see them in my feed (I don’t care about the posts they liked or found insightful). I can only unfollow them if I go into their profiles and LinkedIn sends the notification “Candost viewed your profile” when I do that. It looks like it will be a constant effort on LinkedIn to unfollow people whenever I see anything from them. Considering I have above 1000 connections, it will take time. I accepted my defeat on this front, but I won’t close my LinkedIn account as I use it for “professional” reasons. (Edit: I found a way to work with Linkedin)

Up to Mastodon. As I was still new on Mastodon, I don’t think I will build a habit of posting regularly on Mastodon or consuming anything there. I follow a handful of people who are only on Mastodon, and my feed is not that dynamic. Also, I have control over my feed—unlike Twitter and LinkedIn—and it gives me confidence that I can manage easily and not become addicted to it. That’s why I decided to keep Mastodon as my main social media platform.

Within all, if I consider the Dunbar number, I want to keep how many people I follow as little as possible. However, I don’t think setting a concrete number is a good idea anymore. I only want to follow people I either personally know and want to learn more about what they think at that moment or people who share knowledge that adds value to my life. I know even this definition is vague and can consist of thousands of people. Also, the question, “What adds value to my life?” is a challenging one to answer correctly. I want to take this thought with every person I follow. If I even begin to doubt that someone doesn’t add value to my life, I will unfollow them. It’s not personal; I like a lot of people in real life more than on social media.

For example, seeing an old colleague in real life makes me happy, but I don’t want to see what they like on social media every day. It’s better to spend one hour over a drink or dinner, maybe even once a year, rather than spending 10 seconds every day on what they liked on the platform without them knowing. I want to reduce these unidirectional relationships and convert them to bidirectional ones where possible.

There are a lot of deep thoughts and perspectives behind what I wrote above. I believe that this post can easily become a booklet or even a book. These thoughts didn’t form within two months; they were shaped within the last few years and supported by other surrounding actions and techniques. Thus, I will pause here and maybe share each topic more deeply in the future.

By the way, how is your relationship with social media?

P.S. Meanwhile, if I unfollowed you on social media, again, it’s not personal. It’s not you; it’s me.

Reply via email | Reply via Mastodon | Comment

Moving to Substack

Mon, 10 Apr 2023 00:00:00 GMT

I started Mektup on Substack. Right after the first issue, I migrated to ConvertKit, where I hosted Mektup for 36 issues, and then moved it to Ghost, where I hosted my blog to merge everything into one place. Ghost was a great host providing enough flexibility for me to be creative on the website using templates. At the same time, it took care of many things I didn’t want to deal with, such as infrastructure, emailing, security, and spam.

I have been using Ghost Pro since December 2021. I have seen its development, direction, and growth. Although it has been great—and I’m sure it is still great for many people—it’s not working for me. I realized I don’t fit into their audience, and the new features are going toward content creators with big audiences.

Also, the freedom in the design of the website brought me a lot of burdens that I didn’t want to deal with anymore. I am okay not working on customizing my home page, footer, or website font. I often found myself working on my website’s UI while I actually wanted to do something else. That moment has passed, and I want to focus on writing.

Therefore, I moved to Substack today, where I fit into their target audience, “independent writers and podcasters.”

I also renamed my online space to “Mediations with Candost.” For a long time, I realized that I’m trying to mediate the multiple aspects of my life that are pulling me in many directions. Every day, I debate with myself and try to find common ground where I can satisfy multiple aspects of my life, such as work, writing, leadership, software engineering, health, music, family, friends, reading, etc., which all have importance, and I want to get better in each front. So, “Mediations” is a better name that reflects my life.

Meanwhile, Mektup and Software World with Candost will keep their names, and I will keep writing Mektup in the same way.

In theory, this move shouldn’t change anything for you. However, there are limitations of Subsctack and, thus, consequences for all of us.

Due to Substack’s setup, all my mailing lists (that you’re part of it) will start receiving every post I write as an email. And Mektup is now an additional newsletter. You may have subscribed to either Mektup or podcast or each blog post only previously on my website. You will also start receiving other posts I write even though you didn’t subscribe to receive every post. You will get all emails regardless of your previous subscription.

I’m sorry, but Substack doesn’t allow me to subscribe you to the right newsletter list, but YOU CAN. Click the unsubscribe button at the bottom of this email to unsubscribe from lists you don’t want emails for.

There are four email lists to which I will distribute:

Mediations with Candost This section includes all posts I write (excluding Mektup and book notes).
Mektup This is the bi-weekly newsletter that I send as casual letters reflecting my learnings and thoughts about software engineering leadership and life, arriving every second Tuesday.
Book Notes (BRAND NEW) I decided to separate book notes from my main articles and created a new section on my newsletter that you can subscribe to separately.
Software World with Candost (podcast)

I don’t think I will send more than two emails per week overall; mostly, it will be once a week. Feel free to unsubscribe from any list you want. By default, you’re subscribed to all of them.

Thank you for staying with me through different journeys.

P.S. If you see any broken links in any article, please let me know.

Reply via email | Reply via Mastodon | Comment

Mektup #53: Was Tuckman Wrong?

Tue, 04 Apr 2023 00:00:00 GMT

Recently, I read Tuckman Was Wrong by Doc Norton. It's an old piece (yes, 2017 is old now).

The article talks about how teams don't go from one stage to another in the order Tuckman defined: forming, storming, norming, and performing. The research that's been done over 50 years showed that teams instead jump from one stage to another, not in any particular order, skip one stage entirely, or consistently show elements of one stage, and are much more dynamic; sometimes, it's even impossible to tell which stage the team is in. Then Doc talks about team stability and the power of fluidity.

I am one of the Tuckmanites in terms of using team stages as a tool, and I always leaned toward stable teams as a software engineer (although I must admit I never got it). The problem was that the most stable teams I had changed their members often. After I became a manager, one of the biggest challenges I faced was other managers pushing for fluidity. It was unintuitive for me because of the required context switch and the time and money investment (such as great onboarding, documentation, knowledge sharing, etc.) we had to make for people changing teams to become effective.

When I think about my previous teams, it wasn't the stability that made them perform well. It was the ownership, autonomy, inclusive environment, people-first, and full-of-feedback culture. It was the no over-time and no over-commitment policies we had.

That's where I agree with Doc Norton. Doc says,

"Stable teams creates a constraint that limits the bad behavior of over allocation and multiple assignments. If we don't have this bad behavior, we don't need the constraint of stable teams."

It's easy for leaders to think that the team consists of experts in their domains and that their throughput should be really high. They want faster teams and more and more features to be delivered. Well, it doesn't really work when the team cannot choose what to work on or differentiate what is more important than the other and cannot keep their focus.

Doc adds in the article,

...companies are discovering that allowing people the autonomy to move from assignment to assignment and from team to team, is not only increasing productivity, it is accelerating learning, and improving retention.

It's true that autonomy brings a lot of advantages and actually improves retention (people leaving the organization is one of the highest costs). When people clearly know what's important and can decide what to work on for that important thing, they are more engaged with the work and create higher-quality products.

Although I agree with Doc on the fluidity of teams and people, I still think that stages are a useful mental model. This is where Doc tries to convince me to change my mind.

If you're a Tuckmanite, right now, you're probably searching your mental reserves for a way to accept this new information AND hold onto your belief that Tuckman's is correct or at least correct enough to still be useful. That's cool. Rationalization is one of our brain's defense mechanisms when our truth comes into question.

Even though I normally change my mind quickly, this time, I will stick to my mental model but with some adjustments. I am not saying that Tuckman is correct. From my experience, not necessarily a team does have to follow these stages one after another. It's the culture that follows these stages. The culture has these stages, but it's also not in sequence. The autonomy, accountability, ownership, feedback, inclusivity, and lack of overcommitment drives teams to the performing state. If the team culture is norming, adding a new member or removing one can alter everything. However, if the culture is strong and stable, a new team member can easily adapt and start performing with the team.

I also still think that people go through these stages by themselves when they face something new. When anyone joins a new team, they start learning things (forming). After some time, they either accept without deeply understanding and critically judging (a dangerous thing) and jump into the norming state, or they ask questions and challenge the status quo and move into a storming state. Once they learn things around, they start performing. And anyone in the team can (and will) go into the storming state anytime. That's where I still want to keep the mental model alive.

Reply via email | Reply via Mastodon | Comment

Measure What Matters Book Review, Summary, and Notes

Thu, 30 Mar 2023 00:00:00 GMT

How Strongly I Recommend: 6/10

How Likely I Will Gift It To Somebody: 4/10

What is the book about? (summary)

The book is about OKRs (Objective and Key Results) developed by legends at Intel. OKRs are effective business measurement systems to improve performance and job satisfaction, resulting in better company achievements.

The book first explains the OKRs and talks about its superpowers: focus and commitment, teamwork, accountability, and having stretch goals. Then it ties OKRs to individual performance, career growth, and company culture to close the loop.

In short, having transparently defined three-to-five objectives and each objective with 3-5 key results provide everyone clarity around the most important thing for the company. Once the goal is clear, people can align their own teams around the goals to achieve better results. When the teams cannot reach their key results, they mark them as yellow (at risk) or red (cannot achieve). The difference between OKRs and other goal systems is reds and yellows are welcomed in OKRs. If all OKRs are green, it shows they were not great OKRs. OKRs should stretch the goals and the team but still be attainable.

All these work-around OKRs cannot succeed without having great personnel management and strong leadership. When compensation is tied to feedback and achievements (OKRs), the culture won't allow OKRs to thrive. The compensation has to be separated from OKRs and how much the teams achieve OKRs. Individual performance feedback cycles should be shortened and also disconnected from compensation. Managers must have one-one-one conversations with their direct reports to track their career progress, help them unblock and move forward at their work, and bi-directionally coach each other. This culture will build trust and transparency at work. Once we have the environment right, OKRs can thrive.

The Review

OKRs are great on paper. And the book is enthusiastically written. There is a lot of marketing within the book to sell the idea. Although the idea is simple, the application takes a lot of time and effort. As also explained in the book many times, every company will apply OKRs a bit differently than each other, and it's okay. There is no right way to use OKRs; everyone must adapt to themselves.

However, reading this book cover to cover is a waste of time. I'm glad that I skimmed most stories instead of reading them. Stories showed me that the marketing of OKRs is strong in this book. The language is like fuck-up night: we failed, but hook how we got it right. I understand why these stories are there, but anyway.

OKRs are not a silver bullet, and it's impossible to apply 100% correctly, much like any other metric system. Building the OKR culture demands much more work than using OKRs.

Another problem comes up if the company is really big. The coordination work and team alignment becomes messy, and more than one team will be working on the same or similar projects to contribute to company-level OKRs. Identifying these cases is possible, but eliminating them or making two teams work together is challenging. Therefore, I would say OKRs are more suitable for smaller companies. Yet, they have their place in big companies, too; I just don't keep my expectations too high and use them as a tool to understand what's important and what has priority.

Who Should Read It?

Anyone who works with OKRs or wants to work with OKRs.

Why should you read it? (Why I recommend it)

I don't recommend reading this book cover to cover. If you're curious about OKRs, take this book and skim over it. Once you understand what the OKRs are about, only read the book if you are sure you'll implement it. Even then, don't read cover to cover. Just get your hands dirty with OKRs and read the book for certain points (you can use the table of content and index at the back to find what you're looking for).

Chapter Notes (Summary by Chapter)

Introduction

OKRs are not a silver bullet. If you have strong leadership, creative culture, and sound judgment, OKRs can only lift you up.

Goal setting is not new, but studies have found that when the goals are not used well, they are recipes for disaster. However, once the goals provide clarity and are clear and freely shared with everyone, they create job satisfaction and motivation.

So, What is OKR?

OKR stands for Objective and Key Results.

Objective: What will be achieved: concise, clear, action-oriented, and inspirational. Destroys fuzzy thinking and execution. Key Results (KRs): Answers the question, "How do we know we reached the objective?" It is measurable, time-bound, aggressive, and realistic. There's no grey area in KR; you achieve it or not. If all KRs are completed, the objective is achieved.

There shouldn't be more than three to five OKRs at the company level; less than five OKRs are always better. OKRs shouldn't be top-down but bottom-up. There shouldn't be any dictating: after agreeing on an objective, key results should become contracts between people.

Company and teams should be flexible: if the environment changes, OKRs can charge as well. People should be open to failure. OKRs are a tool, not a weapon. Everyone (especially leaders) should be patient; adapting to OKRs and leveraging them takes time and practice.

How do OKRs Help Teams?

OKRs have four superpowers that help any team increase performance and bring trust.

Focus & Commit to Priorities

OKRs provide focus and commitment to the right priorities. To figure out the priority, leaders should ask, "what are the most important things we have to focus on in the next three months?" The answer will be the objective.

A leader's job is to make the most important thing—the objective—clear and communicate it with everyone clearly. Everyone in the company must clearly understand the top-level leadership's perspective—goals and what they mean. Leaders have no chance but to repeat and communicate both what is important and why that objective is important until everyone gets it. (commitment)

Key Results are the measurable part of OKRs. They are the measurement against the objective. They can be defined yearly at first when organizations transition from hierarchical goals to OKR goal setting. Also, there is no one-size-fits-all approach; every company is different, and everyone can define their OKRs in a different cadence. Keep OKR cycles short to keep receiving feedback on long-term goals. As there is no one-size-fits-all timeframe, experiment with cadence and find your own rhythm. The aim is to get early feedback on the goals. Therefore, monthly, 6-weekly, or quarterly OKRs are usually good ideas.

There should be three to five key results for each objective, and we need to be careful about them. Some KRs can be taken alone and optimized while keeping the quality out of sight. Therefore, KRs should have matching quality KRs. For example, if one of the KRs is to have 30 sales calls in a month, there should be a matching quality KR that will indicate the quality of these sales calls.

Moreover, focus means fewer OKRs; the number of OKRs should be minimum. When there are many OKRs, nobody understands what matters the most. That's why saying no, having fewer OKRs is better to focus everyone and have them commit to the OKRs.

Commitment means leaders must ensure people understand what the OKRs are and why they are there (instead of other OKRs that are left out). Leaders must also follow up with people (sometimes even chase them) so that everyone not only creates their own OKRs but also keeps them up-to-date and uses them daily. One way is making OKRs public: even the individual OKRs the leaders have on their own.

Align and Connect for Teamwork

Transparent OKRs create alignment. When goals are hidden, people don't know the most important objectives, and they work on the wrong things. That's the worst thing that can happen to any business.

Having visibility prevents people from going off-track. The most important becomes visible. While defining ours, we need a healthy mix of a top-down and bottom-up approach. There is no one way to implement the mix; it will be based on trial and error in the process. If we only follow the top-down OKR setting, we break agility and flexibility, and it becomes difficult to connect cross-department work and make front-line contributors speak up. This micromanagement shuts down ideas and feedback that should flow from first-line contributions to leadership. When there is a healthy level of bottom-up, people become more engaged and align their OKRs to very top-level OKRs. They bring feedback that makes us more adaptive to changes happening around business. This way, people can also achieve their goals already aligned with top-level OKRs. So, everyone wins.

Moreover, since the OKRs are transparent, departments and teams can check what others are doing, offer help, or identify whether they are working on the same thing and decide to abandon or merge. Transparent OKRs help teams to foster better collaboration.

Track for Accountability

OKRs bring accountability. Scoring OKRs publicly and telling everyone how much the OKRs are achieved (or at risk) brings accountability into the game. Scoring OKRs are usually measured by how much is achieved in the KR, but no mathematical rule exists. Scoring the OKR as 0.9 out of 1.0 while completing the target by 70% is possible. That judgment makes the scoring effective. It's not about how much we reached the target; it's about the quality and effectiveness (as it's also mentioned before, quality is important). We can reach the target 100%, but if the results are ineffective, we can rate it by 0.7 out of 1.0.

Accountability also has another side: reflection. This judgment element and also alignment in an action-oriented OKR system demands reflection. After every OKR cycle, we need to look back and ask ourselves what contributed to our success and what obstacles we've seen. If we would rewrite the goal, what would we change, and what did we learn that can change our approach in the next cycle? This reflection will help in every OKR cycle to get better at not only defining the goals but learning how we work, our delivery speed, and our missing capabilities.

Stretch for Amazing

OKRs shouldn't be comfortable to reach and not easy to complete. The well-chosen metrics and high-quality OKRs ensure we look at the right thing. However, we also need to understand and make it clear how we look at that thing. "OKRs should be uncomfortably exciting." They shouldn't be kept conservative. They should stretch to a level where the goal is still attainable, but it pushes everyone to their limit. They should create excitement in people, and the team should clearly follow them. If they are too stretched, the team loses their belief and trust in leadership. An OKR can be 70% reachable; in certain situations, we can consider it successful if it's reached 70%.

The leaders should be comfortable with having yellow or red OKRs in their OKR list and should never hesitate to stretch the goals (while being informed by their people and ensuring the goal is still attainable).

Continuous Performance Management: OKRs and CFRs

CFR stands for Conversation, Feedback, and Recognition.

Having yearly performance cycles doesn't really work because most of the actions have passed, and the feedback doesn't provide value. Many people get good performance reviews but not good enough compensation. The whole process creates disappointments, and people leave the company. The main problem is that the feedback is not timely and tied to compensation. We need constant Conversation, consistent and timely Feedback, and Recognition of great accomplishments.

The first action is disconnecting performance review feedback from compensation. The compensation changes should occur once a year (or every six months), while feedback and recognition should be part of daily work. It all starts with one-one-one conversations between the manager and the direct report. Research shows that regular (weekly or bi-weekly) one-on-one meetings save time for the direct report (each hour saves two weeks from employees). These meetings should be aimed at the direct report. It's their meeting, not the manager. The manager should talk to the max. 10% of the time. These meetings should be used for goal setting and reflection, ongoing progress updates, two-way coaching, career growth, and lightweight performance reviews.

As we ditch yearly performance reviews, we need consistent positive and negative, timely, specific, and clear feedback. It should be 360: between manager and direct report, between peers, and between cross-collaborations.

The last missing part is recognition; we need to recognize smaller achievements—shout-outs of simple things—so that people get pride in their work. It contributes to team performance as a positive reinforcement. The recognition shouldn't always come from the manager but also peer-to-peer. There can be stories in recognition, too; they provide authenticity and relatedness. Recognition should be frequent, authentic, and tied to company goals and strategies.

Culture

The culture of the company is crucial to make OKRs work. If people's hearts are not in the right place, if there isn't trust and transparency, and if accountability and responsibility are not present with vulnerability, then nothing will work. Use CFRs to build the culture, positivity, enthusiasm, and daily improvements. Promote peak performance and stretch thinking with collaboration. Only then start using OKRs to boost the performance.

Reply via email | Reply via Mastodon | Comment

How to Get to The End of a Pile of Unread Books

Sat, 11 Mar 2023 00:00:00 GMT

Reading books is an attractive concept that nobody teaches, but everybody somehow knows how to do it. I started reading books at the university around 2010. It's been more than ten years. During this whole time, I read whatever people or online algorithms and bookstores recommended. After getting into the habit and embedding reading into my life, I always struggled to drop the book if I didn't like it.

In some cases, it also had a huge impact on my reading habit. When I didn't like the book, I forced myself to continue reading it. I don't know who put this idea in my mind that "you have to read every book you started, cover to cover," but I became miserable and even stopped reading for a while to accept that I was not going to return to the book. I'm not counting the psychological burden it had on me: not completing a task and regretting every day, blaming myself that I couldn't finish a thing.

After having these struggles, I learned a method that solved this fundamental problem: cross-reading—reading multiple books simultaneously. I usually read 3-6 books; picking up whatever I'm in the mood for helps me read more and keep the habit. I put these books in different places in the apartment to have a book at reach at any time. Keeping this strategy for a while boosted my reading habit, and suddenly, I started picking up books more than ever. Yet, this habit also created its own problem.

After some time, I formed another pile of books: currently reading. Three books became fifteen. When I didn't like the book, I simply switched to another, and the boring book stayed in "currently reading" mode in one corner of the apartment. I was back where I started, with an additional toll because I was still not "finishing" what I had started.

During this whole time, I learned the obvious—I cannot read every book. I buy more books than I can read. I'm not counting my wish list even. I have enough books to keep me reading for the next five years.

This comes with a drawback of psychological burden. I want to read the books I buy, and I'm overwhelmed by the number of books I want to read. To overcome this, I decided to learn how to read books properly, as it's something that nobody taught me. When I realized that school only teaches reading, but not reading books, I looked for where I could learn it.

I found the famous "How to Read A Book" by Mortimer Adler. In one section of the book, the authors talk about Inspectional reading, which I want to emphasize here and leave out other parts of that book (although they are equally helpful) because Inspectional Reading is what helps me most to get the idea of a book, to decide if I need to spend hours reading the book cover to cover, to clean up my to-read pile, and to abandon books that don't need cross-reading.

Inspectional Reading

Inspectional reading is the high-level reading before giving the book a full read. Understanding the book as a whole and digesting its ideas is not the aim. The goal is to understand what the book is about, its argument, and if it is worth reading or not.

Inspectional reading consists of Systematic Skimming and Superficial Reading.

Systematic Skimming

Systematic skimming is the part where you look closer at the book in multiple steps. In my previous struggle with not finishing books, I skipped this step and dove into the book that I regretted quickly and, as a result, wasted a lot of time trying to finish it or abandon it with shame. Once I learned systematic skimming, I was relieved. The stages of systematic skimming below help me understand if I want to read a book with my full attention and spend my time on it or not.

How do I do Systematic Skimming:

Read the title page, preface, and foreword: Try understanding the book's goal. What problem does it solve, and what is its value?
Study the table of contents: Try understanding how the book solves that problem. Does it use an inductive or deductive approach? What are the sections that present the book's core arguments? Which chapters look more interesting than others?
Check the index: Look for the most used words, phrases, and terminology to understand how the book can connect various terminology with the titles in the table of contents.
Read the publisher's blurb: It's often pure marketing but sometimes gives some insights from others. It also gives some information on how to relate to others' opinions.
Read the introduction: It's the part where the author actually introduces the book and its arguments. Try understanding the author's writing style and high-level arguments. Look for clues indicating something new for you or contradictory to your knowledge. Can the book bring value to your life?
Look at the chapters that seem pivotal to the book's argument: Turn the pages slowly. Read here and there, a paragraph or two, a page or two, not more than that. Look for understanding arguments and how the author supports them.
Read the conclusion (or the last 2-3 pages): Almost authors summarize the book in a conclusion chapter or the last few pages. They recap what they have talked about and mention the most important parts so the ideas will stick with the reader. Read to close the loop in the arguments.

After completing these seven steps, I usually have a broad understanding of the book and its arguments. It helps me decide if I want to read the book. You may think it destroys the narrative author tried so hard to put into the book. To me, it doesn't; it simply helps me decide if I want to spend many hours studying the ideas and arguments in the book. Tell you what, many books can't pass this stage, and that's okay. There are millions of books, and nobody can read them all. You have to choose what you read carefully. And this is the major test any book has to pass. If a book doesn't pass this test, it goes to my bookshelf and becomes either a reference book or just part of my small library.

One thing I'm currently trying is writing down my notes after each stage. Reading with a pen in hand is the habit I'm trying to build. It's challenging, but I will update here once I get the habit up and running. My goal is to ask myself four questions after systematic skimming: 1) What is this book about as a whole? 2) What's being said (as much detail as possible)? 3) Is the book true, in whole or part? 4) What of it? (Why does the author think it is important to know these things?)

For example, Lencioni's Five Dysfunctions of a Team book didn't pass this test. Not that the book is bad. The framework in the book is great, but I grasped its message and ideas within thirty minutes without reading the whole book. It didn't make sense to spend hours on it and study the book. Even though the book is short, I didn't need to read every word. I counted it as read and moved on. I got its value out.

As most books cannot pass the systematic skimming test, I count them as read and move them from my to-read to done list.

Another advantage of systematic skimming is that I can do it in a bookstore even before buying the book. Many bookstores have seats or chairs to dig into the book, and this technique usually takes less than 30 minutes to complete. Once I'm done, I don't need to read the book anymore.

Systematic skimming made the whole difference. Suddenly, I stopped feeling guilty that I didn't finish a book. It was about perspective: I counted the book as read and moved on.

Superficial Reading

If the book passes the systematic skimming test, it is worth spending some time on it. That's where superficial reading comes into play: reading the book without going back and pondering the arguments. This is the first read to understand the holistic picture, the book's structure, and its arguments.

I'm learning the book. In the first reading, I don't stop to look up things I don't understand. I keep going. I know I will have time to think about the arguments when I return. You can think about it like watching a movie: if you see the movie for the first time, you never stop in the middle of it and think about it; you watch it from the beginning to the end. Once you see the messages it gives you and the feelings it transfers, you want to watch it again (or not).

There is much to say about reading speed in detail, but I don't want to clutter this post. In superficial reading, your reading speed should vary depending on the book and chapter. Some books require reading fast while others demand slow reading. Also, within the same book, some chapters demand slowing down, and some can be read quickly. You should be able to adjust your speed according to the text. There is only one rule: don't look back. If you don't understand an argument, keep going. You will probably read the book again. This reading is just the get the idea and structure of the book. Without seeing the book holistically, it's not possible to understand it.

Although Adler recommends superficial reading a bit differently, I adapted it to myself and now use it as a second test. I read books with superficial reading and take chapter notes as much as what's left on my mind. I still don't look back while reading or taking a note; I don't quote but use my own words while taking notes (that's why Kindle never works for me, highlighting is great, but note-taking is painful).

In the end, I have a few pages of notes that help me understand what the book is about. After that, I can make up my mind to give a more thoughtful and careful read. Many books can't pass this stage and don't require another read. Their ideas and arguments are not very deep and don't demand pondering.

Inspectional reading (systematic skimming and superficial reading) helps me reduce my to-read pile. Not all books need to be read thoroughly. The majority deserve little time, and the minority demand reading them with complete understanding and pondering on their arguments. Having multiple stages of reading and eliminating books in each stage to get the most out of them in my limited time has worked for me so far.

Reading non-fictional books is an interesting concept that nobody teaches. Much like any other process, the ideal way of reading is still far away, and my current process needs improvements. Yet, it's enough for most books and helps me figure out how I want to spend my time on books.

Thanks to this process, I finally learned to make peace with a book when I got everything I wanted from it. It helped me to mark books as "finished" or "read" after skimming them systematically and not reading them cover to cover and word by word.

I will probably keep using this process and improve it at any chance.

Reply via email | Reply via Mastodon | Comment

Chesterton's Fence

Fri, 10 Mar 2023 00:00:00 GMT

(Looking at the picture below)

What (the hell) is that fence doing here? It serves nothing. Let’s remove it.

That’s what many people agreed on without asking a straightforward question: Why is there a fence here in the first place? What’s the rationale behind putting a fence?

That fence is called Chesterton’s Fence. If you remove it, Chesterton will cry. Less jokingly, Chesterton (writer and philosopher who died in 1936) invites us to think about the rationale behind an earlier decision and take action only after we understand why there was a decision in the first place. It goes even beyond and encourages us to practice second-order thinking: thinking about the consequences of the consequences of our decisions. (it’s not a typo, yes, consequences of consequences of decisions).

Everyone can do the first-order thinking: if I do X, the result will be Y. Only a few considers the consequences of Y because that consideration often requires greater effort, and we don’t have time.

What can we do as leaders?

While making a decision that is not minor, we can stop momentarily and practice second-order (or even third-order) thinking. This strategy helps us to learn why a specific (and seemingly stupid) decision is made earlier, and then, only then, we can safely change it or conclude that they were wrong.

Want to learn more? Read this article or grab the book Great Mental Models Volume 1.

Reply via email | Reply via Mastodon | Comment

Mektup #52: Multitasking hides design flaws and lowers the quality

Tue, 07 Mar 2023 00:00:00 GMT

When I wrote you the last time about the myth of multitasking, I talked about our attention limit having a value of only one cognitive task. Today, I want to double-click on that attention-demanding creative task and connect it to the quality of results.

In Mythical Man-Month book, Brooks talks about the importance of execution in software engineering. Much like in any other creative task (writing, painting, etc.), an idea has full of hidden flaws until the execution. Software engineers don't realize the inconsistencies in their proposals before implementing or at least writing the approach down. Without the execution, the flaws in system design will never surface. The discrepancies in component design will only come out with the coding. It's especially true with legacy systems. The majority of us work with codebases or projects we didn't develop. We design new components that fit into systems we cannot 100% comprehend. That's where I want to take Brook's statement one step further. Multitasking conceals all the design flaws even deeper.

While reviewing our peer's code, we remember one thing that needs to be done and jump to it. We fix a bug in a meeting; we refine the next ticket while listening to the all-hands meeting. A Product Manager asks for something urgent that needs to be done now. We pick up multiple tasks with the intention of gaining a more holistic view. With a high workload, it often looks like we have no time and no choice. That's also what's expected from experienced engineers, right? Join meetings, finish tasks, drive initiatives, mentor others, and do more simultaneously. Within all this absurdity, we try to move our focus from one component to another, jump from meeting to meeting, and have three-four tasks assigned to us that are currently "in progress." But if our mind is everywhere, it's actually nowhere.

"How can I do less while the business expects more from me?" I hear you say. Here is the misunderstanding: organizations want you to achieve more, not to do more. The more you do, the less you achieve. Not output, the outcome. You may finish a small thing here and there while listening to a meeting, but it can only be a small output while the actual outcome awaits.

We can differentiate the outcome from the output by looking at the results. In multitasking, you will definitely produce some work, so your output will be high. And that is the main confusion point. As the output is high, you're inclined to assume you're doing a great job. Only when we look at the results of outputs can we understand the impact you make.

If we forbid multitasking, you have to choose one task while the others await. This selection forces you to understand the expected result; hence the task that gives a better outcome precedes the tasks with minor impact. We see these effects only by looking with second-order thinking: instead of "I will do X, and Y will happen," ask, "what will be the consequence of Y?" to think beyond. Ask yourself why that task matters and what would be the expected outcome. This strategy has another consequence we often overlook and sacrifice for speed: quality.

Multitasking lowers the quality of the work you produce. Software engineering demand understanding tiny details, seeing their effect, planning a solution, and ensuring that the solution works. Because of a high cognitive load, working with multiple contexts in parallel, and shallow focus, multitasking hits hard in every single step, resulting in bugs, poorly written and unmaintainable code, and piled-up technical debt that becomes clutter in the backlog as leftovers.

If we go back to Brook's argument, the wrongly-gained holistic knowledge results in learning fewer details. That turns out to be missing the intricacies of bad design. The more parallel work you take, the greater the loss of quality on the finished product. While growing in careers, many folks make a mistake and take more stuff on them in parallel. It seems reasonable, but it's not.

Within all the complexity Brooks discussed, we have no choice but to do things in order. When we stop and try to single-task, we begin to focus, increase quality and outcomes and start growing. It's hard, true. And yes, it requires saying no and demands better stakeholder management. And that's one of the reasons why software engineers are in high demand, and not everyone can do this job without dedicated training, focus, and discipline.

Until next time, Candost

P.S. What I'm doing now.

Reply via email | Reply via Mastodon | Comment

These (damn) Annoying Tenure Engineers

Fri, 03 Mar 2023 00:00:00 GMT

Many tenure engineers get frustrated with various small things if they have stayed in the same team or done the same job for a long time. They start getting annoyed by new people bringing not-so-new ideas that were already proved wrong two years ago. They had seen the projects put into the trash and, after three years, brought up like they were brand-new innovative ideas. They had been frustrated and demotivated and started creating a lot of friction in those projects. Or they are left behind and moved to another team because they create conflicts. The whole situation results in lost knowledge and the organization making the same mistakes again. I was one of them, and I knew I was never alone. Now, I want to talk about the case with Annoying Tenure Engineers™️.

These engineers are annoyed because they have seen various things: they have experienced how a system is developed, and maintained, witnessed the (good and bad) decisions made, contributed to them, and how the system evolved to the point that it accumulated tech debt and accidental complexity and needed to be rewritten, but there was no time. They have seen projects succeed, fail, evolve, and pivot. Within the same organization, they have seen good leaders who elevated everyone and bad ones who looked like good leaders but pulled everybody down. They worked with people who were frickin' smart yet made such mistakes because they couldn't see why something was built in a certain way in the first place.

You name it.

They have seen a lot.

But they still didn't leave.

They are valuable assets because of their accumulated historical and domain knowledge. They are long-time supporters of the mission. They are the sense-makers and challengers for new decisions. Although organizations aim to have more tenures—having these people is a tremendous asset to the company—they can quickly become drawbacks because they have seen a lot.

They can become blockers of innovation. If they just float around the same area without clear priorities, they prevent new things from developing and seeing the light. If you approach them to get their idea or learn why a particular feature of the product is built that way, they surface all the accumulated problems to your face and demotivate you. They suck the energy out of you by bringing up thousands of issues you couldn't foresee.

Yes, you still learn why something has been built that way, but if these tenures are advocates for staying still instead of being consultants for sensible development, you have a hard time changing them. Once tenures are in their comfort zone, getting them out is challenging. Moreover, when they get out, it is often not easy for them to let old things go.

"I can't stay silent and ignore what's happening when people do all that stupid stuff to the services I designed and developed for years. I created them; these applications are my babies."

— A random annoying tenure engineer.

As their strong ownership attitude was appreciated for a very long time, it is challenging for annoying tenure engineers to let things go. That reinforced ownership easily becomes a pain for everyone. They frustrate everyone around them and cause others to leave the company. Or these tenures can also abandon ship and move on to their next job in another company when nobody listens to them anymore.

Of course, not all tenure engineers are like that. Some will seek change and be open to letting others drive the ship they have built. When they want to change their position, team, or role, that's a great advantage for the company to keep their employees and leverage their knowledge in another functionality. This cross-boundary knowledge transfer can increase innovation and produce incredible results that nobody could think of. And that's the best scenario for tenures to become Counsel Tenure Engineers™️.

Counsel Tenure Engineers are like your best lawyers. They tell you exactly what would work and what wouldn't while doing everything they can to win your case. They follow your dreams while pulling your feet to the ground.

Leading tenures through change is a big challenge. When they say, "It won't work; we have tried that before," or "Why are we going around the same things again that we did two years ago?" you, as their leader, have to stop and turn things around. You must show how things have changed since then and why you're not in the same environment anymore. You must encourage them to see the holistic picture. Instead of coaching them with "give it one more try," you should approach with "let's use your knowledge and experience and figure out how to make it successful this time."

Organizations must turn these engineers from advocates of endless stability to consultants for experimentation and counsels of innovation. Their accumulated knowledge must be extracted and used in cross-border domains. If the documentation is not that great (like most organizations), these people are the knowledge your organization has, and you have to treat them as historical non-fiction books, not historical novels; read them to learn what happened instead of getting stuck in a story.

If these engineers changed their domains or moved to other projects, make them consultants to their old domain. Draw clear boundaries that the decisions are not on these tenure engineers anymore, and they are sitting in a consultant seat. You want their ownership attitude on the mission, not the services they have built.

As a leader, it's on you to make annoying tenures counsel tenures. If you don't, they will be one of the most detrimental people to your organization, and you'll have to make decisions that nobody will like.

Reply via email | Reply via Mastodon | Comment

Mektup #51: There is still hope; there will always be hope

Tue, 21 Feb 2023 00:00:00 GMT

Hey friend,

This Mektup is a personal one.

You must have heard what happened in my home country, Turkey. Two earthquakes took the lives of thousands of people (40k+) and impacted millions. (just yesterday, two additional earthquakes took another set of lives) Although my family and friends are physically healthy, nobody in Turkey feels good these days. Everybody tries to help in one way or another. We ended the search and rescue operations in most cities and saved thousands of people but also caused thousands of lives due to organizational failure in AFAD (Disaster and Emergency Management Presidency of Turkey), which couldn't reach the disaster area in the first 48 hours. Yet, we heard survivors coming out of the debris after 296 hours (that's ~12 days). We had hoped for weeks that we could save many, many more.

We also hoped things changed after the 1999 Gölcük earthquake that killed ~18k people in Turkey. Some things are changed; new legislations and taxes are introduced to take precautious steps. Earthquake insurance became mandatory if you want water and electricity at your home. Yet, we didn't consider the quality of monitoring of the legislation applied in practice. Corruption, nepotism, favoritism, and a one-man country were the reasons why these natural events became disasters/catastrophes.

Now, I do not want to talk about problems that test our nerves and make us hopeless. Thousands of people lost their lives, and millions won't be able to live in the same way anymore, and I can't change anything about it. 😔 That's why, instead, I want to focus on how it feels to be an ex-pat while one part of you is still in another place dealing with many struggles. I want to talk about how it feels being here, in Germany, far away from all of the impacts, how shameful we feel for our warm apartments, and—more specifically—why we feel this way. Not in a selfish way that moves focus to my problems in warm apartments but to think more about what we can do from here.

When I first moved to Germany, I moved here to have a better future and support my family better in turbulent times. All these hopes and excitement of living abroad caused hiding all the challenges of starting a new life in a place where I know nobody and have no connections. Over the years, I got used to a new life, but one part was always missing.

You can't just take your luggage and say, "I'm out of here," when you move out of a place you had spent your whole childhood and youth and still have people you love living. You always leave behind one part of your soul; you know that you will never become one again, especially when the culture you grew up in is not individualistic but a community-driven culture.

In community-driven cultures, you feel the urge to help each other out. If someone else is in trouble, you rush to help them. When you need money, you first ask the closest people instead of going to a bank for a loan. When you want to do something on weekends, you don't do it alone. Alone activities are like sins. You do things with others. These behaviors are shaped by the tribal ancestors and organizational structures we had in history. Harmony precedes individualistic behaviors as it helped our ancestors to survive in harsh environments. Unlike individualistic cultures (many Western cultures), nobody promotes individualistic decisions. Everyone is urged to be part of a group and follow that group's decisions. And that's how I grew up in the middle of Anatolia.

When moving to Germany, one of the fundamental problems I faced was tied to this cultural difference; having nobody to support me and trying to do everything alone. When I tried building friendships with locals, they all stopped at some point. It was extremely difficult to have a colleague moving from a working relationship to a friendship. Feeling alone within a crowd and not belonging is the story of the lives of many who move to Western countries. However, recent events showed that we, actually, are not that alone.

Seeing all the support from the country I immigrated to feels great. All the efforts in Germany to help Turkey and Syria are just extraordinary: teams were sent immediately, minutes of silence in the parliament and schools, lowering flags to half-staff, commemoration ceremonies, all the support campaigns by NGOs and companies (e.g., we have a donation-matching campaign in SumUp), airlifts from Germany to Turkey full of donations, and many, many more. I'm simply proud and feel so much supported by the people of Germany. Thanks to all these efforts, I could participate in helping my country in one way.

Not only Germany but seeing other countries that I least expected (due to decades-long conflicts) to send help, such as Israel, Armenia, and Greece, makes me feel not alone. Also, many countries rushed to help, such as Japan, Mexico, Brazil, Austria, the UK, the US, and more. Albeit any support probably won't help with the long-term change we expect (learning how to live with earthquakes and building necessary infrastructure correctly), we at least don't feel alone and can bind up our wounds quicker. So, thank you.

Thank you to all my friends, colleagues, companies, organizations, governments, and people who shared our feelings with us, who gave us a hand, a hug, or a shoulder, and support.

You taught me one thing. As much as we often feel otherwise, we're not alone. Nobody is alone. There is still hope; there will always be hope.

Until next time,

Candost

P.S. If you want to donate some money, you can use the Ahbap organization—a trustworthy one.

Reply via email | Reply via Mastodon | Comment

Three Approaches to Decision-Making Styles

Wed, 15 Feb 2023 00:00:00 GMT

There are three categories or approaches to decision-making styles in the world that encapsulate all the decision-making models.

Ethical Reasoning (Good-Evil/True-False/Right-Wrong) It's conceptual reasoning. We have concepts in our minds that are formed over the years and impacted by people surrounding us, situations we've been in, and our beliefs. We make decisions based on our feelings about what we think is right or wrong. Ethical reasoning is mostly associated with religious thinking, but it's not limited to that. It's the ethical approach, and ethics can be independent of religion. People have opinions on what's right and wrong. It doesn't have to be religious thinking, but religion plays a good part.
Tribal thinking (Which group do I belong to, and how does that group think?) People decide based on which group they belong to. They choose a group in which the person feels comfortable. Then they follow the group's decisions even if the decision is wrong. They don't consider or think about themselves; they follow where the group goes. They want to follow the tribe, not the issues; they don't move from tribe to tribe just because the tribe made a wrong decision. People have an emotional residence in the group. Once they place themselves in the tribe, they follow. This behavior came in evolution: the more I belong to a group, the higher the chance I can survive. Individual cultures (such as Americans) might not have strong tribal thinking, but it's more visible in community cultures like Asian. Western cultures believe more in individualism. They can change their groups if the group's decision is not aligned with theirs. However, in tribal thinking, people change their minds rather than changing their group. While deciding which group to join, tribal thinkers often implicitly ask themselves, "Who do I want to be with as an operator in my life?" There is no right or wrong for individualistic vs. tribal thinking. None is better than the other; it depends on the context and the cultural background.
Thinking with mental models This thinking style adapts thinking and decision-making strategy to the situation at hand. It is a more pragmatic approach. Rao uses a world in science fiction and fantasy to define a mental model. There is a world and a story in that world in science fiction and fantasy literature. We learn the world while learning and following the story. The world is the mental model. Mental models allow us to make sense of stories efficiently.

Reply via email | Reply via Mastodon | Comment

How cultures are shaped in the world

Wed, 15 Feb 2023 00:00:00 GMT

It seems like the British had a devastating impact on Kenya.

"Modernization" shows its evil face in many places. When people are forced, preached, evangelized, and convinced that their culture is not good and that they have to change, they go over dramatic problems—many of these problems last years, if not centuries.

Kenya was a culture-rich country and still is, and Maathai was born into a family where she was the biggest girl of the second wife. The culture allowed men to take multiple wives. Back then, it's understandable that it was preferred because people needed a crowd to survive. They needed people to work in the fields. The man was responsible for the whole family, including all wives and children. The culture forced the man to take care of them. If the man didn't care about his family, he would be ostracized. So, the folk ensured that the patriarchy was beneficial to men and provided safety to women.

How Maathai perceives her childhood and culture is impressive. It's often impossible to see others through their lenses in life, but she explains everything well with empathy. With empathy and truthfulness, she lies the environment in front of our eyes as it is. She enables us to see clearly.

Related Note(s):
- 27: Developing Habits;
- 52: Personal Values;
Source(s): Unbowed by Wangari Maathai

Reply via email | Reply via Mastodon | Comment

Share pros and cons in announcements

Thu, 09 Feb 2023 00:00:00 GMT

Sometimes, leadership introduces something and doesn't explain what they consider to be the disadvantages of the change. They often talk about the pros of a new system without mentioning the cons clearly. This situation makes it very difficult to get the buy-in from people. When executive leadership and HR introduce new systems, they have to talk about disadvantages clearly so that people don't speculate on their importance. When it's not explained, people won't be able to weigh the costs properly as they don't either see the holistic picture or are not deep enough into the topic. Preventing people's speculations demands explaining both pros and cons together.

Related Note(s):
Source(s): Thanks for The Feedback by Douglas Stone & Sheila Heen
Resourced: Sometimes Saying Nothing Tells Everything;

Reply via email | Reply via Mastodon | Comment

Mektup #50: How to Build Habits That Last

Tue, 07 Feb 2023 00:00:00 GMT

Hey friend,

I wrote the following paragraph two years ago in the first Mektup.

Putting myself in front of many people is one of the hardest things I’ve ever done. Even though I’m a bit of an extrovert, it still frightens and excites me every time I start a live session, send a tweet, or publish a blog post. However, I want to keep going. This newsletter is my latest effort to share what I’ve learned, read, watched, and liked.

And I've kept going. This is the 50th issue, and I thought it would be good to talk about habits and how I kept my writing habit to bring Mektup to you every second week.

When Kahneman explained the two different systems our brains have in his ground-breaking research on how we think and make decisions, he was focused on breaking our automatic thinking to prevent mistakes and biases to make better decisions. Our brains' conscious side (system one) and automatic side (system two) impact our lives more than we expect. Think about learning how to ride a bike or swim. At first, we focus on getting it right; our actions are in system one, requiring focus and continuous attention. When we learn, though, these actions become automatic because they move to system two; we can perform these activities without thinking. That aligns with our bodies' physiological goal: preserve energy. The brain moves repeated activities to system two because system one is expensive—it demands constant attention and consumes a lot of energy. Then, why do we have such a hard time building habits if the brain is inclined to build automatic actions?

Because of the delayed feedback. If we're learning how to ride a bike, we fall when we make a mistake. That's immediate feedback: the pain in our knees or hands shows what we did wrong. If we cycle for hundred meters, we understand what we make right. However, while building a reading, writing, or exercising habit, there is no instant feedback. If we don't read or exercise, nothing hurts at that moment. Moreover, when we consider our bodies' goal of saving energy, we're already inclined to do nothing. To break this physiological need, we need to trick our brains by either getting rewards for the energy spent or reducing the energy we spend on habits.

The good thing about these tricks is that they don't need to be substantial. Our brain only needs something. That's why Seinfeld's "Don't Break The Chain" method works: putting a big red X on a calendar on the wall for every day completing the habit. Seinfeld moves the emphasis from performance and achievement to process. As long as he keeps putting marks, the chain continues. The longer the chain, the bigger the reward. As long as the process keeps going, the resistance to doing nothing shrinks.

I broke my body's resistance by following Seinfeld—I have been using a dot-on calendar for the last three years to mark my habits. Every day, I have two dots (one for writing, one for exercising) to put on the calendar on the wall. Although I might have skipped some exercise days, I have successfully kept my writing habit since 2020. My goal is to put a dot on my calendar every day, not writing 750 words a day for a year or writing three days per week. I sit down, grab the pen, write as long as I can, and put that dot sticker on my calendar. Albeit having a writing habit for years now, I struggled a lot at first. My most significant struggle was finding an answer to the question, "When?"

Whoever I talk to mentions that they have no energy in the evening to do anything. After hours of work, all of us want a nice dinner, relax and recover our drained energy for the next day. In busy schedules, creating time for habits is challenging. I first tried to start working at 7-8 am to leave work early, so I have more time for habits in the evening. But it didn't work. The only solution I could find was moving all my habits to morning.

Once I realized I was really productive in the morning, I decided to use this time for myself. These days, I do my writing and exercise in the morning. Once they are done, I'm ready for the remaining part of the day; I don't need to think about them anymore. This strategy helped me a lot to keep these habits consistent over time. You might not be a morning person to wake up early for habits. In this case, try attaching the habit to something you already do every day. For example, start by doing ten jumping jacks right after you close the working computer at home or directly go to the gym right after leaving the office. Attaching to existing habits work magically.

The last thing I tried was never missing a habit for two days in a row. If I can't write one day, it's not a big deal. But I will make sure to write the next day. If I break the habit chain, I start a new one. In the beginning, my chains were shorter: three days of writing and one day of break. Later, these days increased to five, six, and seven and ten and fifteen days, and became a month, and three months, and... You got it. The goal is transformed: it's not writing every day anymore; it's keeping the chain longer.

Once I learned that having shorter chains was completely normal in the habit-building process, I began to appreciate what I had achieved. The whole process boosted my motivation. Later I realized that when we change our behavior, we need time to adjust. At first, our well-being (happiness, energy levels, comfort, etc.) will plummet because of adapting to a change. Yet, after a while, it will start increasing faster and faster: it's a J-curve. That's why we need to give our habits a bit of time.

When you start building a new habit, think about experimenting. Can you experiment for a few days, weeks, or months and see how it goes? You can define the time according to your habit and lifestyle. But keep the J-curve in mind and stay until the end of an experiment. If the experiment doesn't work, you can always return to the previous state and try another experiment. Use the techniques I shared above if you're starting from scratch, and let me know how the experiments go.

That's it. I don't want to make this letter longer as it's already quite long. One more technique helped me a lot on my most unmotivated days. I will talk about that in another Mektup in the future.

Talk soon.

Don't forget to send this Mektup to one of your (work) friends.

Candost

P.S. If you're thinking about building a writing habit.

Reply via email | Reply via Mastodon | Comment

Trying the feedback

Mon, 06 Feb 2023 00:00:00 GMT

When we receive feedback, we might consider applying it fully or declining it. It often looks like a 0 or 1 situation; take it or leave it. Even when we try to find the middle ground, it comes down to picking up what's useful in feedback (only a small part) and applying it to our lives. If we're unsure about the feedback, we hesitate to take anything out of it. But it doesn't have to be that way. We don't have to change our lives till eternity with some feedback we got over lunch. However, we can experiment. We can try making a small change on one or two occasions and see how it changes our behavior and its impact on us. If the change doesn't feel right or doesn't improve anything, we can always roll back. Thinking about the changes we need to make often prevents any improvement because changes are scary as the results are unknown. By experimenting, we reduce the unknown and can make improvements.

Related Note(s):
Source(s): Thanks for The Feedback by Douglas Stone & Sheila Heen

Reply via email | Reply via Mastodon | Comment

Three Types of Feedback

Wed, 01 Feb 2023 00:00:00 GMT

We're at the end of the first month of the new year. I thought about sharing something about feedback that helped me a lot in my conversations, especially in one-on-ones with my team members.

There are three types of feedback: Appreciation, Evaluation, and Coaching (that I learned from the Thanks for the Feedback book).

Appreciation: It is the feedback we all love when it's authentic and given on time. Examples: Great job! Thank you for your dedication. I appreciate you taking responsibility. I appreciate the feedback you gave last week; I was able to improve thanks to it. Evaluation: The feedback is to evaluate skills, align expectations, and clarify consequences. The goal is to rate the person against standards and expectations. Examples: You exceeded our expectations last year. Our expectations for you were X, Y, and Z, but you could meet X and Y. We increased your compensation by A% because you achieved a lot during the last year. Coaching: The feedback is to give a direction. It's aimed at trying to help a person learn, grow, or change. The coaching is aimed at improvement. Examples: You should work on your debugging skills. To improve your communication, please read these two books. Here is a great article about mentoring that you wanted to learn.

We need all three of them. But we feel disappointed or become defensive when we expect one, but receive the other. Therefore, we should try separating them.

When you're talking with your team members, listen to them. As leaders, our job is to understand which feedback our team member needs and provide them with the correct type of feedback. We need to talk about the purpose of the feedback and discuss it to figure out the type of feedback. If we can, we should separate evaluation from coaching and appreciation.

In yearly performance reviews, we should separate evaluation from coaching and appreciation. First, we have to have the appreciation feedback. Second, we should have the evaluation feedback. And last but not least, we have to provide consistent coaching during the whole year. Separating evaluation from coaching and appreciation may sound unauthentic, but we can still give evaluation feedback with our perspective added on top and keep the feedback authentic.

Reply via email | Reply via Mastodon | Comment

Mektup #49: The Craft of Writing Effectively

Tue, 24 Jan 2023 00:00:00 GMT

With the extensive usage of tools like Slack, Confluence, and Google Docs, we—especially leaders—struggle to be articulate. In school, we were all taught to start writing by forming bullet lists, building our arguments, adding more background, and finishing our text by summarizing everything. Although this strategy worked until the end of education, it doesn’t work anymore, especially in the work context. People often don't read our messages well, or they skim texts loosely and hastily. People often miss the value of our messages—what's important to them.

We sometimes spend a long time crafting a message and become wordsmiths of the sentences and words to make our message more impactful. Once we send the message, we feel proud because an announcement message often records the conclusion of our diligent hard work. However, talking to the people after our announcement relieves that people were not hooked on our idea. We then spend hours and hours explaining our idea in meetings and conversations.

How can we shorten the time we put in after that announcement? More than hooking people to our idea, we need to be concise in text and make clear what’s valuable in our text to the reader.

As what we learned in education no longer works, we must relearn how to craft a message.

Recently, I spent some time watching this video by Larry McEnerney, Director of the University of Chicago's Writing Program about writing effectively. Although it’s aimed at academic writing, there are fantastic insights we can all benefit from and apply in our Slack messages, Google Docs, pull request reviews, presentations, and what have you.

Our text is not about us

It's about readers.

That is the biggest mindset switch McEnerney talks about. We're using our writing to think about our world while people are reading our stuff to learn what's valuable to them in our world. They read our stuff not because it's valuable to us but valuable to them.

That's why we must focus on what value we bring to the reader. We might have the most novel idea that nobody thought of. But if that idea doesn't bring any value to anyone, then nobody will care.

Writing is about changing the reader's ideas. What we think is unimportant if our thoughts don't change something in the reader's mind.

But how do we bring that value? How do we change the reader's mind?

Bringing out the problem

A value comes from an existence of a problem. We either surface a problem that the reader wasn't aware of or solve the problem that the reader already had.

And two characteristics define a problem: Instability and cost/benefit.

Instability in a situation causes the problem. For a problem to exist, there has to be an imbalance. We need to show readers that instability. As leaders, we often try to solve that instability by hiding them in our messages. However, to define a problem, we need to create that instability in our text and make it visible. Words such as but, however, although, and nonetheless create contradictions. These words help to point out what is challenging or conflicting in any situation. While defining a situation and working towards building the problem, these words help to point out the exact issue.

For example, look at how I used the word "however" in the above paragraph.

Once we make the instability visible, we need to explain what is the cost of that instability and what will be the benefit of getting rid of that instability. That's the main value to the reader. This cost and benefits component is what arouses interest and keeps the reader engaged. If the words don’t benefit the reader, nobody will care about the writing. They have no reason to keep reading.

While explaining cost/benefit, we also need to define who exactly will benefit from solving the contradiction we introduce or who will deal with the cost of that instability. We need to make the audience prominent. Readers have to understand who the text is written for. For example, at the beginning of the text, I narrowed down the audience of this text to leaders.

Now that we learned the components of effective writing, let's have a look at a few strategies to apply our learning at work.

How to apply it in daily work

When writing a Slack message in a team channel, think about whom your message impacts. If you're writing in your team's Slack channel, your audience is already defined. But still make the cost/benefit to these people clear and visible. If you're writing in a wider-audience channel, make clear who your message is for.
When writing a Pull Request description, Request for Comments Document (RFC), or Architecture Decision Record (ARD), don't write your ideas just from your perspective. Somebody will read your writing, so the text is for them.
If you're unsure about how to write for other people, just write whatever comes to your mind but ruthlessly edit what you wrote later on. Convert your narrative and change your angle from yourself to the reader.
Build a background of the problem. Use words that create a contradiction (but, although, however, nonetheless, etc.). If you need to convince people to change course, create that tension and instability.
If you don't know how to create that tension, have a look at a few well-written texts and search for words such as but, however, although, nonetheless, etc.
Make cost and/or benefit visible. Show what they will miss out on or what problems they will have to deal with in the future if they don't follow your ideas.

That's it.

Reply via email | Reply via Mastodon | Comment

DDIA: The Trouble with Distributed Systems

Fri, 20 Jan 2023 00:00:00 GMT

This article is part of my notes from Chapter 8 of Designing Data-Intensive Applications by Martin Kleppmann. You can read other chapter notes as well.

Chapter 1: Reliability, Scalability, and Maintainability in Distributed Applications
Chapter 2: Data Models and Query Languages
Chapter 3: Data Storage and Retrieval
Chapter 4: Encoding, Decoding, Schemas, and Data Evolution
Chapter 5: Data Replication
Chapter 6: Database Partitioning
Chapter 7: Transactions
Chapter 8: The Trouble with Distributed Systems
Chapter 9: Consistency and Consensus
Chapter 10: Batch Processing
Chapter 11: Stream Processing
Chapter 12: The Future of Data Systems

Welcome to the pessimistic chapter.

Faults and Partial Failures

So far, we have mentioned some failures and discussed how to prevent them. In distributed systems, there are way more things that can go wrong.

In a single computer, the system is deterministic; whatever happens, we can try the operation again and get the same result. Moreover, a single computer system has no partial failure; if it fails, it fails. Things can still go wrong in a single machine, and the computer usually prefers to crash the system instead of returning a wrong result. There might be some faults or bugs, but they often result from badly-written software.

On the other hand, distributed systems consist of multiple computers connected via a network. They are fundamentally different.

Note: We're not discussing supercomputers in this book, even though they are also distributed systems; we're interested in commodity computers connected via a network.

While building distributed systems, we must accept that partial and complete system failures will happen. We need to develop fault-tolerance mechanisms to recover from both kinds of failures or prevent them in the beginning. Therefore, fault handling must be part of distributed system design. We cannot assume everything is all right or be optimistic.

Unreliable Networks

When we talk about distributed systems, we mean shared-nothing computers communicating via a network. Nothing is shared means we must rely on the network, which can fail at any given time for various reasons. A package might never arrive; it can be damaged on the way even if it arrives; the other device might not accept it because of a fault; the package might queue up in the machine if that machine is overloaded. Let's say the package went, but the response takes the same way back. It might get lost due to a misconfigured switch or any other reason. It might also arrive late due to a network overload on the requesting machine. In any way, it's impossible to know why there is no response to a request. One of the best strategies to handle these situations is to use timeouts: give up waiting for it. When a timeout happens, we still don't know whether the other machine got our message.

Having network problems play a significant role in practice. As the failures can happen at every level (scaling from one network switch to entire data centers), there is no way to avoid them. The only option is either handling or tolerating them. While handling requires deliberate precautions, tolerating might mean just showing the user an error message and saying, "network problems are happening." We need to test our systems consistently to find out how we handle these problems and when to display an error message.

If everything is unreliable, how do we even find out any fault?

Detecting Faults

Many systems detect faults in one way or another. But until there is a successful response from the application, it's impossible to know what exactly failed.

In distributed systems, we can detect faults in the load balancer level to stop sending requests to a failed node or to detect a failed leader and assign a new one.

Moreover, everything can fail in the network, such as switches, routers, applications, machines, etc., and there is sometimes no way of detecting a fault; we only use timeouts to declare a node is down and take action. We can have retries, but eventually, we must announce a node is dead.

Timeouts and Unbounded Delays

If there is no other way than using timeouts, how can we use them effectively?

If we define timeouts as too short, we may accidentally declare a node dead while there is just a temporary slowdown. If we define the timeout as too long, we increase the waiting time for a dead node out of nothing and create a bad user experience.

We can use retry mechanisms when working with short timeout values. Yet that is also problematic: if a node is just slowed down temporarily and our operation is in the queue, we mistakenly can redirect the operation to another node; as a result, we execute the operation twice. Moreover, we can cause a cascading failure if the other node is already heavily loaded when we transfer a request to another node.

That may sound pessimistic, and it is. But it's the reality.

There is no guarantee for any delay to be a certain amount. Asynchronous networks have unbounded delays. They work with a premise to deliver packets as quickly as possible but without an upper limit in delays. Their main focus is reliability on the delivery, not on time.

Also, switches in the network redirect incoming packages to different links. When a network switch sends many incoming messages to the same link, a queue builds up and creates network congestion. Hence, it increases waiting time.

If we think more deeply about the protocols, there is also a delay that comes from TCP: when a package is not acknowledged (lost in the network), TCP retransmits lost packages after a certain timeout. This timeout value is also not consistent. Systems like TCP and Cassandra use dynamic timeouts calculated based on the previous network round-trips and response times.

As a result, it's almost impossible to define certain timeout values. We have to understand the network and systems we're using and how they work, so we can better estimate timeouts and adjust them according to our systems. To do that, we must learn the difference between synchronous and asynchronous networks.

Synchronous Versus Asynchronous Networks

When we think about phone calls, they are synchronous. They allocate a certain amount of bandwidth on the network (called a circuit) end-to-end between two callers. The system knows how many bits it needs to transfer when establishing a connection. Therefore, it can allocate bandwidth with certainty (~100 kbps per line is recommended). If we have a network capacity of 10000 connections, we can have 10000 concurrent calls without anyone waiting. We can also have one call and 9999 empty lines. Even data passes several routers from one end to another; the space is reserved when the call is established. There is no queuing, and end-to-end network latency is fixed. That's what we call bounded delay.

TCP connections are optimized for speed, so expectations differ. While establishing a connection, the packet sizes and bandwidth requirements are unknown (unlike in phone connections). Imagine we follow the same approach as phone calls and use a specific bandwidth size for all connections. Let's say we have 10000 connections capacity again. If one connection needs to load a gigabyte of data in that network and we have a 100kbps limit per connection in the hardware, it has to wait a long time, and the other 9999 slots will be empty and become wasted resources. We might directly allocate a 1gbps line to one data stream by using all remaining slots, but it's impossible to know how much bandwidth is needed initially. That's why queueing is used. We optimize for speed, and if a TCP connection requires massive bandwidth in the network, others queue up and wait for their allocation. All data centers and the internet is optimized for busty traffic. TCP optimizes the data transfer rate to the available network capacity.

As the network setup we use will build queues and have unbounded delays, we cannot guarantee any specific delays or reliability. That's why it's impossible to set correct timeouts. We have to experiment with it.

Experimenting and learning our challenges more in detail requires knowing how clocks work.

Unreliable Clocks

There are two types of clocks: monotonic and time-of-day clocks. These two serve different purposes and work differently.

Time-of-day clocks: The time is calculated based on an epoch (usually Gregorian calendar UTC Jan 1, 1970) and without counting the leap seconds. These clocks are usually synchronized using Network Time Protocol (NTP)—with the goal of making the same timestamp meaning the same thing on different machines. While synchronizing, jumps may occur; one clock may go fast and can be 10 nanoseconds in front. The clock can jump back when it is synched. That's why these clocks are not suitable for calculating the elapsed time (e.g., timeouts).

Monotonic clocks: Monotonic clocks always go up. Imagine a counter counting nanoseconds. It doesn't care about which day or time of the day; it just counts. The absolute value of the clock is meaningless; its goal is to tell us how much time elapsed between two points accurately. Each computer (or CPU) has its own monotonic clock. Albeit useful for calculating elapsed time because there won't be any jumps, they are useless when it comes to comparing two monotonic clock values. Monotonic clocks are normally not synced between machines (or CPUs). NTP can still be used to adjust the speed of a monotonic clock, but jumps cannot occur; NTP either slows down or fastens up the clock a certain amount.

Relying On Synchronized Clocks

Clocks have several pitfalls that make them unreliable. Quartz clocks have delays and skew. To solve this issue, we can also synchronize them with NTP. But NTP improves the situation rather than solving it because even synchronization makes a network round trip and is destined to delay. Hence, using time-of-day clocks requires designing the system against the clock faults. We must constantly monitor the clock offsets between all the machines and synchronize them before the offsets get bigger.

Most problems arise when timestamps are used for decision-making in the applications. Even when the clocks are synchronized, the nature of NTP and quartz clocks make it inaccurate to use the timestamp (there will always be an offset between two clocks), and we often don't know how much the offset is between clocks. Let's say two clients update the same value in two replicas, and we replicate these values to other nodes. How do we decide which client's operation is the first if we rely on the timestamp of the initial nodes?

It is challenging to separate writes that happen in quick succession or truly concurrent. Moreover, two machines can generate exactly the same timestamp, especially when the clock has only a millisecond resolution. If we use Last Write Wins (LWW) as a conflict resolution strategy, the database can mysteriously drop values by mistake because of clock skew. We can also use additional tiebreakers or version vectors to resolve these situations.

Another problem we mentioned is not knowing the confidence of a clock. Most machines only give the current time as the exact date and time. However, when asked about the current time, Google's True Time API provides two values to increase confidence: (clock-earliest and clock-latest). When we know the confidence interval, we can be more accurate in deciding which operation happened first in conflict resolution.

Lastly, we talked about Snapshot Isolation and Repeatable Read. In Snapshot Isolation, it's crucial to identify if a read operation happened after a write operation (as we offer the snapshot). When these operations occur in one machine, it's less of a problem. But in a distributed system, it's still a problem. Using Google's API for transaction ID generation to understand rolling IDs and deciding which transaction is first doesn't solve the problem.

Process Pauses

When we use clocks on the critical path of a system, we face another set of issues. For example, let's say we decided to keep the leader node for a specific time; after that time passes, we choose a new leader. One way to know if the leader still holds the position is by checking if the leader has enough time left in its position at the beginning of each request. Here, right at that moment, the system can pause the process for an unknown time for a variety of reasons.

These reasons include garbage collection (GC), allocating the memory for another virtual machine, a user closing down the laptop lid, an operations engineer sending a stop process signal by mistake, and many more. Weird things happen when these processes continue where they are left off. If the leader had been paused, the system could have declared another node as a leader. Suddenly having two leaders might create many problems.

In distributed systems, real-time requires having response time guarantees. Real-time capabilities (unlike real-time data streaming on the web) are often built for security-critical systems like opening airbag in a car (we don't want to be blocked by garbage collection in an accident) and demands extensive testing and robustness. That's why real-time is not economical and practical in most server-side data processing systems. Therefore, we will suffer the pauses and clock instabilities.

Yet a few things can be done to limit the garbage collector's impact. We can schedule garbage collector's work frequently. Small iterations of the GC process prevent long-running GC pauses. Another approach is considering GC pauses like an outage in a node and letting other nodes handle incoming requests while GC is working in the node. Some latency-sensitive financial trading systems use this approach.

Knowledge, Truth, and Lies

With all these problems we mentioned, it is almost impossible to make anything right because there are tons of things that can go wrong. We often don't know what is wrong (remember, we cannot distinguish problems that happen in the network). While being lost in the unknowns, the only thing we can do is to make assumptions and build distributed systems with some truths and knowledge and offer some guarantees.

The Truth Is Defined By The Majority

When we rely on one node to decide anything, we create a single point of failure. Imagine one node deciding by itself that it is the leader in the system while other nodes think someone else is. Or imagine a scenario where one node thinks they are alive and healthy while others cannot reach it due to a network problem, and they declare that node dead.

When considering these scenarios, a system cannot rely on one node's decision about certain topics. But the system can operate with a majority or—as it is called—a quorum. Individual nodes must obey the quorum's decisions instead of taking action alone.

For example, if we build a system that requires grabbing a lock on storage to write data, we have to build mechanisms to prevent the node that has the lock from misbehaving. When a node's garbage collector stops every process to clean up while the node has a lock lease from the lock service for writing data, the lease may expire. Meanwhile, another node can acquire a lease and write data to the same file. Once the garbage collector finishes, the node continues as if nothing happened and, assuming it still has the lease, writes to the storage, and corrupts the file. This was a real bug in HBase, and there is a way to prevent it.

We can add fencing tokens to the lock service. Every time a lock is leased, a fencing token (a monotonically increasing number) can be returned with it. The node can use the token to write to the storage. If the storage receives a write request with a lower-numbered token, it rejects it. While we require the storage to take an active role in the system, we cannot let clients accidentally abuse the system. We must consider building mechanisms to prevent clients from using systems incorrectly. We cannot assume they will always behave well.

Byzantine Faults

In this book, we ensure that nodes—at least—tell the truth within their best knowledge despite not answering, answering late, or answering with outdated values. They don't cheat the system. When one node doesn't tell the truth (e.g., sends a confirmation for a message it never received), Byzantine faults occur; the problem of reaching consensus in entrusting environment (Byzantine Generals Problem).

These problems mostly occur in aerospace systems where radiation corrupts hardware and sends unreliable messages or in systems where some nodes may try to cheat because of fraudulent activity. But overall, we most probably don't need to build Byzantine-tolerant systems because we mostly work with nodes in the same data center and a closed network. But there are certain things we can do to prevent lies in our system. For example, we can put input validation to prevent SQL injection and input character limiting to prevent denial of service due to large memory allocation.

System Model and Reality

There are tons of problems that can happen. While we cannot take cover for every problem or play Pollyanna and ensure everything will run perfectly, we create expectations and assumptions for systems so we know how they should behave. These assumptions and expectations are defined using models.

For example, we can use system models about timing, such as synchronous, partially synchronous, or asynchronous models, to build systems with specific ground rules. When we talk about faults, we can use crash-stop faults, crash-recovery, or Byzantine faults models to formalize our expectations. While these models reflect reality (or we want to create a reality with these), algorithms have other models to be defined as "working correctly"—algorithms have properties that say what it means to be correct. These are categorized as safety and liveness properties. If we think about an algorithm that generates unique fencing tokens, uniqueness is a safety property; the same applies to a monotonic sequence. And if we expect the node requesting the fencing token to receive a response eventually, we can say that the availability property is defined as the liveness property. In practice, we expect safety properties to always hold and liveness properties to have room for caveats.

Reply via email | Reply via Mastodon | Comment

Shift Left on Security

Sun, 15 Jan 2023 00:00:00 GMT

How would you explain the "Shift Left on Security" to a five years old kid?

That was a question that we had to answer in a group exercise at SumUp lately. Each group in an 80-people workshop took a few of the 24 capabilities that drive improvements in software delivery performance from the book Accelerate.

We found a simple explanation and I believe that answer can help many people understand how to include security in their software development processes.

Here we go.

Now, we want to make a sandwich. When we take a bite, we don't want to discover that one of the ingredients is rotten. If the ham is rotten, we want to learn about it before. If one of the cherry tomatoes is gone bad, we should know beforehand, not when we take the bite. Overall, what we want is to eat the freshest sandwich ever. How do we do that? Our sandwich is as fresh as its ingredients; therefore, we always want fresh ingredients. What can we do to get fresh ingredients to avoid last-minute surprises? We can test the ingredients before making a sandwich. Have a look at them, smell them, or even taste them. That's the first step. What else can we do? We can ensure that we buy the freshest products. How do we do that? Maybe in the supermarket, we can pick the products behind the shelf (supermarkets always put new products on the back). Perhaps we can even go to a farmer's market on Saturdays or take it further; we can go to the fields and pick up our product ourselves. Maybe we can also grow our own product. Once we move our focus from now to the whole process backward, we can actually get the freshest product in the beginning. And during the entire process, we still can ensure they didn't go bad by smelling the ingredients we bought or tasting them before making a sandwich.

We want to ensure that what we do is secure from the beginning and throughout the process. And that's what it means to shift left on security. However, I think one concept is not that clear to many people.

What the hell does shift left mean?

When we think about any work process, it usually goes from left to right, step by step.

When we think of security, it's often thought of near the end together with Quality Assurance. It's usually part of compliance testing and comes as an afterthought, and it quickly becomes a release blocker if any vulnerability is discovered. These vulnerabilities often demand significant time investment to fix because the implementation details or even sometimes software design are not built with that vulnerability in mind.

If we shift the security review or mindset to the left, we can discover the vulnerabilities earlier, and they often won't require substantial time investments because the software is still in the implementation phase. Yet, if we discover flaws in software design, we'll need to go back and redesign the system.

That's why shifting security to the left help us build secure systems right from the design.

When InfoSec experts are involved in software design, we can build safer systems from end to end. Involving security experts only in the beginning can also be a mistake because the team can fall into traps or make mistakes without recognizing their implementation or testing options downstream of the process. That's why InfoSec experts should be involved in every stage.

However, it's not feasible to involve security experts in every single project as that will require a lot of effort both in communication and decision-making. Instead, we can leverage the Enabling Team Topology from Team Topologies. InfoSec folks can join the team in the early stages to guide and improve their knowledge of information security. This way, both the team developing systems learn more about designing and developing secure applications, and InfoSec folks succeed at elevating the knowledge and systems in the company. As a result, the organization benefits from having fewer vulnerabilities.

Reply via email | Reply via Mastodon | Comment

Mektup #48: Lagom, Clutters in Life, and The Habit of The Rich

Tue, 10 Jan 2023 00:00:00 GMT

Hey friend,

Happy new year! I hope you will have a great year which you won't need any resolutions for 2024. I have had no resolutions for the last two years, and I love it. For me, New Year's Eve is a regular day, so it doesn't mark anything that I think of celebration. But it's not in a bad way. I just don't put too much value into any day. My goal is to try to live every day as valuable as possible and keep doing what I want to do. I know not everyone is like me. Many people have resolutions, and the date in calendars marks new beginnings. If you're one of them, I hope your resolutions will bring happiness and health to you.

As we're talking about happiness, I started reading a page or two from a book called Meditations by Marcus Aurelius, who is a former Roman Emperor (you might remember him from the movie Gladiator). The book is a collection of his personal notes; he didn't publish them as a book; he wrote notes to himself. There, he says, he learned from his mother about simplicity in his way of living, far removed from the habits of the rich.

If an emperor wants to live away from the habits of the rich, it might be wise to think about the habits of the rich in our lives, too, especially now while discussing new year's resolutions and creating habits.

Right before graduating from the university, I had a goal to buy myself a MacBook Pro with my salary. I thought I deserved that and would be happy to have it and bought it. In fact, I didn't need a MacBook Pro; I only needed a computer. That was a habit of the rich: assuming happiness comes from materials. After graduation, I also moved to Istanbul and had a different life than I expected. I started eating and going out all the time. While they all felt good, I had an increasing credit card debt and no savings. Later, I moved to Hamburg, closed all my debts, and canceled my credit cards. In Istanbul, I was trying to have the habits of the rich while not being rich. That was a recipe for disaster.

This kind of lifestyle is not uncommon. I see many people trying to have the habits of the rich without even thinking if they want these habits or not. Mainstream media and advertisements always encourage us to buy more things we think we need but don't.

Why do I tell you this? Because I want you to join me in thinking about what we seek in life and your new year's resolutions (if you have them). What are the habits of the rich in our lives—we think we need them, but in reality, we don't? I was planning to buy an AirPods Pro, but do I really need it? Do you need the newest iPhone just because everybody has it? Do you really need that tenth pair of shoes?

“It is not the man who has little, but he who desires more, that is poor.” —Seneca

Science says money and materials don't bring happiness directly, but at the same time, they enable us to create situations that can bring happiness. For example, we can hire cleaning help to open ourselves some time to do another activity that makes us happy. It can be as simple as walking in the woods with friends and family, going to the gym, or even reading our favorite book. To me, hiring cleaning help is not a habit of the rich; it's about creating wealth.

“Wealth consists not in having great possessions, but in having few wants.” —Epictetus

And that's what I want to seek. While focusing on wealth, I also don't want to advocate for the other edge; extreme minimalism—only living with a handful of items. I want to live in lagom.

Lagom is a notion in Swedish culture; the word means not too much, not too little—just enough. A balanced lifestyle is the main idea behind it. The famous Swedish interior design is a lagom. We can see that IKEA items are functional and uncluttered; they are simple yet last for years. Although we can still clutter our apartments with IKEA products, IKEA itself wants to reduce waste in every way it can.

Marcus Aurelius lived thousands of years ago, and Swedes have lagom for hundreds of years. When any idea survives the test of time, I try to listen to its wisdom. That's why I have been thinking about my lifestyle, habits of the rich, lagom, and simplicity. Instead of buying a ton of things I think I need, I want to be mindful and work on building a lifestyle around things that bring joy and happiness instead of materials. I invite you to join me in thinking about your life and what brings you joy. Feel free to send them over to me by replying to this email.

In the next Mektup, I will write you about building habits, my approach, and how I have been writing every day (the [ritual]/the-power-of-ritualization-rituals-vs-routines/) that brings me joy every day) for the last two years without breaking it.

Until next time,

Candost

P.S.: If you don't have a problem, does it make you happy?

Reply via email | Reply via Mastodon | Comment

One Decision That Removes Hundreds of Decisions

Mon, 02 Jan 2023 00:00:00 GMT

While we can improve our decision-making skills by learning methodologies and mental models and practicing mindfulness, one shortcut helps the most

Since the industrial revolution, our daily options are multiplied each year. We have tens of alternatives for a loaf of bread and hundreds of possibilities in choosing a drawer for our bedroom. Mass production and the evolution of the transport industry made everything available everywhere.

Moreover, in the digital age, we started following algorithms' suggestions which tell us what we should choose from millions of options. But these suggestions are not necessarily the best for us; they only represent the best players in the algorithmic game. Although Amazon offers deals to show what we need, Netflix recommends things we might like, Twitter nudges us to follow trends and people, and Goodreads suggests what we read, they only produce poor proposals that sound like good recommendations; the decision is still on us—we still have to decide between a certain number of options.

Unlike many people believe, we're not good at decision-making because we can't consider all aspects of every decision all the time. We create wrong assumptions and make fast decisions that only look good in hindsight.

That's why we don't like the last bestseller book we saw in the bookstore or why that cheesecake we ate after dinner with a recommendation from our friend breaks our sleep and makes us unhappy.

If we're really bad at decision-making even though algorithms help us to make better ones, what can we do?

While we can improve our decision-making skills by learning methodologies and mental models and practicing mindfulness, one shortcut helps the most: removing the decision itself. If there is no decision to make, we cannot make a bad decision.

For example, I decided not to read any book the same year it was published. Whenever I go to a bookstore and look for books to buy, I don't need to think about if I should buy that new bestseller book or not. I can safely ignore any new book that came out in the last year. That decision alone has already eliminated hundreds of decisions.

We can convert hundreds of future decisions into one higher-level decision and make only one decision. Instead of making one hasty decision, we slow down, take our time, and decide once and for all.

This concept is not mine. I learned it from Tim Ferriss, and Tim also learned it from other folks. They used this technique to lighten their decisions and allow themselves to focus their energy on more important areas in their lives. After reading and listening to what they have been saying, I initially found it difficult to generalize my decisions in my life. I felt like my decisions didn't have any importance overall, and I could make them every day.

Luckily, Tim gave some guidance that we can use. He used a few questions to help him think through all of his decisions and find his blanket policies:

In my life, where am I making decisions or saying “yes” out of guilt? Can I create a blanket policy that makes it easier for me to say “no”?

In what areas am I making a lot of decisions, or sending a lot of communication? Are they concentrated anywhere? Can I create a blanket policy that makes it easier for other people to make those decisions?

In what areas am I making a lot of decisions, or sending a lot of communication? Are they concentrated anywhere? Can I create a blanket policy that entirely removes the need to make those decisions?

I also used these questions along with mine:

In what areas am I making a lot of decisions, or trying to make a lot of decisions but usually make the worst one? Can I make one decision to not even think about these decisions anymore?

The additional question helps me discover the situations where I make many bad calls. For example, when someone offers me some sweets, I often accept them for two reasons: I don't want to turn a nice gesture down, and I love sweets. While accepting a piece of chocolate creates a social bond between the other person and me, it's not that great for my health. It doesn't mean that I won't eat sweets; I will eat them only whenever I want to. Just for this reason, starting in 2023, I won't accept anyone offering me some sweets.

With a similar approach, here are a few decisions I made:

I won't watch any TV series that algorithms offer me on any platform.
I limited my following count on Twitter to 100. (The same will apply to Mastodon)
If any blog, podcast, or newsletter has an RSS feed, I will only subscribe to the RSS feed.
I only read blog posts that I send to my Remarkable; I won't read any blog posts whenever I see any on social media. My blog post reading day is only on Sundays.
I won't buy books that have been published in the last year.
I won't accept any dessert or sweets offers from anyone.
Every Tuesday, I will go to the gym for strength training.

I know these decisions' impact on my life will not be visible tomorrow. My gain in the short term is saving some brain power, energy, and time to spend on more impactful decisions.

I'm still looking for higher-level decisions I can make. I'm constantly looking for ways to discover upstream decisions.

Where can you look upstream? What's your decision to remove hundreds of decisions?

Reply via email | Reply via Mastodon | Comment

Faucets and Bad Ideas

Mon, 02 Jan 2023 00:00:00 GMT

I was reading Julian's latest monthly newsletter issue—one of the few newsletters I follow. There, Julian talks about doing things consistently to become great at them by sharing what Ed Sheeran and Neil Gaiman do.

Ed Sheeran uses the pipe with one faucet analogy. If you're using the pipe for the first time, the first water that comes out is always dirty. You have to push out all the dirt to reach clean water. Even between clean water, you might see some dirt from time to time. It doesn't matter; you have to keep pushing it. How long the dirty water will keep coming depends on your proficiency. But eventually, you'll reach clean water.

That reminded me of what Adam Grant says in The Knowledge Project podcast's 22nd episode,

"You have to tolerate a lot of dead ends and false starts in order to have a shot at doing something truly worthwhile."

Reply via email | Reply via Mastodon | Comment

Mektup #47: Techniques and Tools for Energy Management

Tue, 27 Dec 2022 00:00:00 GMT

Hey friend,

Do you think that you have a lot of meetings? Do you feel overwhelmed by the distractions at work that don't let you do your job? Maybe you found some tricks to manage your time and move some meetings back and forth to create "focus time" for yourself. But how many times did it also get interrupted? Within all these, when was the last time did you think about your energy, not only your time?

In the last Mektup, I talked about the challenge of managing time and energy and promised to talk about how to manage energy and time together in more detail.

Before we start, I want you to take a deep breath, breathe in from the nose, and breathe out from the mouth.

Once more.

Are you done?

Good.

And that's the first thing I do when I feel my energy depletes. We're in front of a screen for hours and hours every day. While working or watching Netflix, we forget to breathe. This situation already has a name: email (or screen) apnea. The research shows that we either hold our breath or shallowly breathe in front of a screen, which in turn puts our body into panic mode, increasing our stress levels. Reducing our stress level (and increasing our energy) starts with taking a deep breath.

“Deep and regular breathing, also referred to as diaphragmatic breathing, helps to quiet the sympathetic nervous system and allows the parasympathetic nervous system — which governs our sense of hunger and satiety, the relaxation response, and many aspects of healthy organ function — to become more dominant." — Linda Stone

Breathing is also a fundamental piece of mindfulness meditation. Wherever we breathe out, our muscles relax, and we find a moment of peace. A few years ago, I didn't believe in all the meditation propaganda. My skepticism and imagining myself as a strong person ("I don't need this crap to relax.") pushed me away from this thousands-of-years-old practice. Aaah, my ignorance. 😅 Once I tried it for two weeks, the benefits surfaced. These days, I practice meditation for 10-15 minutes every morning (I use the Headspace app). It helps me notice my feelings, thoughts, cravings, and stress. I'm also less judgmental of myself.

Moreover, it helps me build empathy for others. When they recognize I understand them well, they also build empathy toward me. At work, this improved relationship and trust make it easier to say, "I don't feel well today; I need to have a walk or leave early." in our team.

This trust also helped me deactivate any notifications about work. As we're always connected to the digital world, notifications have started ruling our lives. Whenever we get a notification, we feel like we have to respond immediately because notifications have replaced social connections. In every message, our brain thinks that the person is in front of us and wants to reply. Imagine a person talking to you in real life, and you don't say a word for hours. How awkward it would be. Our brain urges us to respond immediately to satisfy social bonds. But we need to separate the digital world's social connections. There is no need to respond immediately because the conversation is not synchronous like face-to-face; it's asynchronous. That's why I removed Slack and all email applications from my phone, turned off most of my work notifications on my computer, and always set my Slack status to "away." (I also explained these to people I'm working with, so our expectations from each other are aligned.)

One caveat of having close-to-none notifications required me to manage my meetings more carefully and be punctual. I have at least twelve 1-on-1 meetings per week, and I join other regular and irregular events weekly. Managing calendars, moving appointments, and declining events to create focused work time actually takes a lot of energy. That's why I started using Reclaim.ai and created regular habits (that's the feature's name on Reclaim) on my calendar. The beauty of Reclaim is that if I receive a meeting invitation on my auto-scheduled "focus time," Reclaim moves my focus time to some other time within the week if it can. If it cannot move, it auto-declines the invitation with a nice message I wrote. The bot helps me defend my solo work and focus time without back-and-forth messages on Slack. Here is the example auto-decline message I use.

"Hi! I'm sorry, but I cannot commit to your meeting at this time, and this slot is one of the last open slots available for me to prepare for feedback and think about problems I have to solve. Can you find another time to meet? If not, please write me on Slack."

These days, I have auto-scheduled events for lunch (1 h/day), personal weekly retrospective (45 mins/every Friday), dedicated time to think and prepare for feedback (1,5 h/week), time for engineering work (1 h/week), and morning catch-up (15 min/day), and evening close-the-day (30 min/day). I also have a 7-minute "Decompression" time that Reclaim schedules automatically after every meeting.

Having these blockers and decompression time on my calendar also helped me to build better relationships. I can be fully present and commit to meetings I join because, after every meeting, I have time to clean up my mind, organize my notes, and prepare for the next meeting.

Before I end this Mektup, I want to mention briefly one but not least thing that helps maintain energy: exercise. I wasn't regularly exercising for years, and after having burnout a few years back showed me the importance of movement. All the research shows that exercising helps our mental and physical health together. That's why exercise at least 3-4 times per week. Walking is one of the best exercises we can do, and it's really easy. If you're not active, just take walks for 20-30 minutes. If you have no time, have your next one-one-one while walking. I did this even via Zoom. I asked one of my direct reports to temporarily install Zoom on the phone and put on headphones, and take a walk while I did the same. We were in different cities, but we talked while walking. It was one of the best conversations we had.

Well, that's it. If you try anything above, let me know how it goes!

Candost

P.S. You might also want to try deep walks.

P.P.S. I'm now on Mastodon @candost@hachyderm.io.

Reply via email | Reply via Mastodon | Comment

DDIA: Understanding How Database Transactions Work

Sun, 25 Dec 2022 00:00:00 GMT

This article is part of my notes from Chapter 7 of Designing Data-Intensive Applications by Martin Kleppmann. You can read other chapter notes as well.

Chapter 1: Reliability, Scalability, and Maintainability in Distributed Applications
Chapter 2: Data Models and Query Languages
Chapter 3: Data Storage and Retrieval
Chapter 4: Encoding, Decoding, Schemas, and Data Evolution
Chapter 5: Data Replication
Chapter 6: Database Partitioning
Chapter 7: Transactions
Chapter 8: The Trouble with Distributed Systems
Chapter 9: Consistency and Consensus
Chapter 10: Batch Processing
Chapter 11: Stream Processing
Chapter 12: The Future of Data Systems

Developing reliable systems is difficult as many things can go wrong. Transactions are one of the ways to simplify a certain set of issues. In the simplest form, we can define a transaction as a group of certain (read and/or write) operations together and think of this group as (conceptually) a single operation. A transaction is a mechanism that can succeed (commit) or fail (abort, rollback) as a whole; there is no halfway success or failure.

Transactions are a way to simplify the programming model, and they offer certain safety guarantees for specific errors and fault scenarios. Of course, they are not the solution to everything and have tradeoffs. In this chapter, we will learn these tradeoffs, how to avoid them, and different isolation levels for race conditions that can help increase fault tolerance.

ACID (Atomicity, Consistency, Isolation, Durability)

Atomicity: An atomic transaction can succeed as a whole or rolls back to the beginning like it never executed anything, undoing changes it had made halfway. If an error occurs in the middle of an atomic transaction, the transaction rolls back to what it had done until that point, so the application can safely retry the same transaction without any side effect.
Consistency: It doesn't belong to the ACID; it belongs to the application side. It means having consistent data (such as credits and debits must be balanced), but this ACID consistency is the application's responsibility, not the database's. An application can use isolation and atomicity features to keep data consistent, but a database cannot provide features to do the application's role.
Isolation: Isolation means transactions cannot step on each other's toes. The database ensures transactions are raining in isolation and have the entire database to them like they are running serially. The database can run transactions in parallel, but the result would be like if they run in series. In reality, full isolation is rarely used due to performance penalties. We'll talk about weaker isolation levels later in the chapter.
Durability: The database promises that the data will be kept after a transaction commits, even if there is hardware or any other fault. Usually, transactions are not committed until all durability mechanisms are completed. Durability usually includes write-ahead-log or similar mechanisms.

Single-Object and Multi-Object Operations

Single-Object Writes: Isolation and atomicity can be provided easily. Isolation is provided by using locks on the object, and atomicity is provided by using a log for crash recovery. There are also single-object operations like the INCREMENT function in a database that eliminates read-increase-write, but these are not transactions; they are marketed as ACID or lightweight transactions. Transactions are mostly understood as mechanisms for multi-object multiple operations grouped as one execution unit.

The need for multi-object transactions: As much as we can try, there are scenarios where we need to work with multi-object updating foreign keys in multiple tables, updating data in multiple documents because the data is denormalized, and updating secondary indexes. These things can still be implemented without transactions, but error handling becomes tricky without atomicity and isolation.

Handling errors and aborts: Transactions provide a key feature that is a fundamental piece in error handling: abort the transaction and retry mechanism. There won't be a half-finished transaction. As good as it sounds, there are times this doesn't work, Such as leaderless replication systems. They work with the "best effort" model. The system tries as much as it can but doesn't undo anything if one part fails. It's on the application developer to handle.

Also, there are scenarios where error handling is not perfect:

If a transaction succeeds, but the network fails, the user may think the transaction failed.
We may get an error due to overload. Retrying the transaction will only make it worse.
Retry is useless if the error is permanent. Try all you want; it's not going to change a thing.
When a transaction has side effects, these side effects can still happen when the transaction aborts.

Weak Isolation Levels

Concurrency bugs are difficult to find and reproduce. Databases tried implementing transaction isolation to hide these concurrency issues, but it had a cost on performance. The serializability, as if executing transactions one after another like they are not concurrent, is very costly, and databases are not willing to pay the price. That's why it's common to use weaker isolation levels instead. Of course, these isolation levels also come with costs and tradeoffs: they are harder to implement and can lead to subtle problems. That's why we need to understand them well and learn their tradeoffs to not rely on them incautiously.

Read Committed Isolation Level

Offers two guarantees: no dirty reads, no dirty writes.

No dirty reads: A transaction cannot see any other transaction's written data until that other transaction commits. It is useful to prevent any confusion users might have caused by a transaction updating some values but has yet to finish updating others. Another confusion might arise from aborting a transaction mid-way: the user might see any data (written in the first part of the transaction) that will eventually not be there.

No-dirty-writes: A dirty write happens when a transaction writes a value and another transaction overwrites this value while the first transaction is not yet committed, so the first value is lost. Read committed isolation levels prevent these situations usually by delaying the second write operation until the first transaction is committed or aborted.

Implementing read committed: Databases implement "no dirty writes" by using locks. When a transaction writes a value, it first acquires a lock on the row and holds it until it is committed or aborted. All other transactions that need to write to the same row must wait for a lock to be released. No-dirty-reads is implemented a bit differently. Instead of locks, databases keep both the old value and the updated value of the row. Until the writing transaction commits (or aborts), the database gives the old value to every read operation. Once the transaction commits, the database switches to the new value.

Snapshot Isolation and Repeatable Read

Transaction X reads data from A and B, and transaction Y writes data to A and B (A=2, B=2). After X reads A (A=1), Y updates A (A=2) and B (B=2); now, when X reads B, it will see a new value (B=2). But what it had read from A was an old value (A=1). If X rereads A and B, it will probably see updated values.

This temporary problem is called read skew. To prevent read skews, we can use snapshot isolation: a transaction can only see data that has been committed before the transaction started. The database takes a snapshot of the data version right when the transaction begins and uses that snapshot throughout the transaction instead of using up-to-date data all the time.

Implementing Snapshot Isolation

While read-committed isolation maintains locks to prevent race conditions, snapshot isolation uses only write locks: locks resources only when writing. The golden rule of snapshot isolation is that readers never block writers; writers never block readers. When a transaction reads data, the database takes a snapshot at the beginning and uses that snapshot throughout the entire transaction.

As each read transaction uses snapshots, the database has to maintain all of them. For that, it uses Multi-Version Concurrency Control (MVCC). When a transaction starts, it creates a new snapshot version.

If a row needs to be deleted, the database marks these rows with a deleted-by label and only deletes them (via garbage collection) when it can be sure that no other transaction uses the deleted row.

Any reading transaction can see edits (write/delete) from other transactions only if they are committed before the reading transaction has started.

Snapshot isolation is also known as "repeatable read," but this term is used differently across various databases, so there is no standard.

Preventing Lost Updates

We may lose an update when two concurrent transactions try to update the same data. The lost update usually occurs when a transaction updates data right before another transaction's update. Think about incrementing a value. If one transaction takes a long time and we use a read-modify-write operation to increment a value, two increment operations update concurrently, and we lose one increment. There are certain strategies to prevent lost updates from happening:

Atomic write operations: Databases can provide certain operations atomically (such as increasing a counter) instead of using a read-modify-write cycle. These atomic operations usually happen with the database taking an exclusive lock on the object.
Explicit locking: Transactions can take an explicit lock on the object to prevent any other transactions (including reads) from accessing the object. All other transactions must wait for the read-modify-write cycle of the first transaction to end.
Automatically detecting lost updates: The first two options force transactions to run sequentially. Another way is allowing them to run in parallel. When the transaction manager detects a lost update, it can force the transaction to retry its read-modify-write cycle.
Compare-and-set: In databases that don't provide transactions, we can see this method. When data needs to be modified, the database allows it only if the data is not changed since the operation last read the data. If changed, it restarts the read-modify-write cycle.
Conflict resolution and replication: Lost updates take another form in replicated databases. Especially in multi-leader and leaderless databases, it's difficult because they distribute data asynchronously. The main strategy used in these systems is to allow conflicts to happen and use application code or special data structures to resolve them. Atomic operations work well if they are commutative (regardless of order, they give the same result).

Last-Write-Wins (LWW) (LWW) method doesn't prevent lost updates, yet, it is the default in many databases.

Write Skews and Phantom

Write skews are similar to lost updates, but there is a subtle difference. While the Lost Updates happen during writing on the same object, write skews happen on different objects causing unwanted states and are more difficult to detect. When two transactions concurrently read some data and update other data according to what they read, write skews occur.

A good example is a doctor on-call system. Think about a hospital on-call system where one on-call doctor is required at any time. When there are two doctors on-call, and both want to go off-call simultaneously, what happens? If the software is built without write skews in mind, each doctor checks if another doctor is on-call and updates its data to go off-call.

Snapshot isolation and unsafe design make write skews possible. If we run these transactions sequentially, the second doctor won't be able to go off-call.

If a write operation in a transaction changes the result of a search query in another transaction (going off-call impacts the search of the query of how many doctors are currently on-call), it is called a phantom.

To solve phantoms, we can put a lock on rows that the search query returns, so another transaction won't be able to read these rows. But it doesn't solve situations when the transaction checks for the absence of rows (if there is no doctor on-call) and takes action accordingly. We can't put a lock on non-existing rows.

We can use an approach called materializing conflicts: creating rows for all possible scenarios in that a phantom occurs. One example is calendar events for meeting rooms. We can create 5-minute empty meeting slots for each room by default and lock them whenever someone searches them. However, this approach is error-prone, hard to figure out, and impacts the application data model. So, it should be the last resort.

Serializability

Serializable isolation level guarantees that the transactions result like they run one after another, serially, even though they run parallel. This way database prevents all race conditions.

Actual Serial Execution

Executing transactions one by one (serially) is not new, but it was abandoned for a while. It came back because RAMs became cheap enough and had more capacity that allowed putting all the data a transaction needs, so disk I/O operations (slow operation) are eliminated. The second reason for the comeback is that OLTP transactions are short, don't require a huge piece of data to be loaded to RAM (compared to OLAP), and are often a few reads and writes.

Stored Procedures: When we think about applications nowadays, they require multiple multistep transactions and run some logical operations in between. When there is a constant back and forth between a database and an application, the system spends a lot of time in network connections. Think about the doctor's on-call scenario we talked about before: if the application needs to have an if clause in between two operations (if the number of on-call doctors is greater than one, get an on-call doctor and set on-call to false for that doctor), we can move this if clause and two operations into a stored procedure. The system can run the procedure in one go without going back and forth between the application and the database. This way, systems with a single thread can execute much faster without blocking other transactions. That's why single-threaded serial transaction processing systems don't allow multi-statement transactions. Statements must be submitted in a stored procedure.

Of course, this approach has pros and cons, like everything else. The cons of a stored procedure are:

Each database vendor has their own language
The languages are often archaic. Compared to modern languages, they lack many basic language features. But some database vendors use modern programming languages these days.
The libraries and tools around them are limited, and monitoring is not really possible. So, the developer experience is not good. It's also hard to test and debug.
A database is much more performance sensitive than an application. One badly written stored procedure can slow down the whole system (because it is single-threaded).

With in-memory data and stored procedures, the throughput is quite fast on single-threaded transactions. Some vendors use stored procedures for replication: instead of replicating data, they run procedures in each replica (with one condition: it has to be deterministic—produce the same results regardless of where they run).

Partitioning: With a single thread, we can actually do more. If we can partition the data well, we can assign a separate CPU to each partition and run transactions on partitions in parallel. So, each partition works with single-threaded transactions, but the whole database runs transactions in parallel. Meanwhile, there will be transactions that need to run in multiple partitions. These operations require locks on data. Databases provide support for this operation, but often, databases limit the number of transactions that can run in parallel over multiple partitions. Ultimately, it will depend on the data structure and partitioning strategy. If we pick the right structure and partitioning, we can eliminate most of these costly operations.

Two-Phase Locking (2PL)

2PL is a more strict isolation level than no-dirty-writes. It uses locks but with a difference. The writer-locks block all other transactions. Contrary to writers not blocking readers in no dirty writes, 2PL blocks readers too.

The 2PL mechanism has two locks: shared mode and exclusive mode. There can be only one exclusive lock on the object. Any write operation must acquire an exclusive lock on the object first. If there is any other lock on the object (shared or exclusive), the write operation must wait for other locking transactions to complete. Once the write operation acquires an exclusive lock on an object, this time, all other transactions must wait. If any transaction already has a shared lock, it can upgrade its lock to exclusive. Upgrading has the same mechanism as acquiring a new lock.

As many locks are in place, deadlocks happen (transaction A waits for B to complete while B is waiting for A to complete). Databases automatically detect deadlocks and abort one of the transactions. The application must retry the aborted transaction.

The name two-phase lock comes from any transaction acquiring the lock (first phase) and releasing the lock (second phase).

The downside of 2PL is getting hurt in the performance because of locks. That's one of the reasons for 2PL has not been widely used since the 70s. Acquiring and releasing locks also significantly worsen transaction throughput and query response times. Moreover, database latency is not predictable. Who locks when and for how long depends on the data and access patterns; one transaction may block all others.

How do we handle Phantom skews (one transaction causing another transaction's search conditions to change) in 2PL? There is a concept called predicate lock. Instead of acquiring a blocking lock on the object, we acquire a predicate lock on all the possible results that can return from the search query. If any data that will be written later fits into that search query, it also gets the lock. If there is any exclusive lock on the data, the transaction must wait before acquiring a predicate lock. Predicate lock prevents any other transaction from writing to that data. The key idea is that predicate lock applies to objects that the database doesn't yet have.

Most databases use index-range locks instead of predicate locks. The mechanism is similar, with a subtle difference. Instead of locking all search results, the transaction expands the predicate and puts a lock on a range of indexes that approximate the predicate. For example, if the predicate looks for meeting rooms between 13:00-14:00, the index-range locks can be put on all rooms between 13:00-14:00. If the predicate looks for a meeting in a specific room, the index-range can put a lock on the meeting room for a few days. The index-range lock is a greater set of predicate locks since we're putting a shared lock in a range of indexes. If a shared lock is already on data, the predicate locks have to wait for the shared lock to release.

Serializable Snapshot Isolation (SSI)

2PL is more of a pessimistic locking mechanism: it uses locks in places where conflicts or race conditions may happen. It operates with the assumption that if something can go wrong, it will go wrong, so it's better to prevent it by using locks.

Serializable Snapshot Isolation (SSI) chooses the other way and uses an optimistic approach. It assumes that everything will be all right. Until something goes wrong, there is no need to take precautions. When it's obvious that something is wrong, then it is time to act. So, how do we implement that?

Similar to snapshot isolation, SSI uses snapshot isolation for reading transactions. However, when a transaction writes data according to the result of a read operation and commits, the system checks other committed transactions since the transaction started to see if anything has changed for that object(s). If it did, the system aborts the transaction because it's not safe to commit anymore.

Overall there are two cases to consider while detecting stale data:

Uncommitted write occurred before read (stale MVCC object version): Serializable Snapshot Isolation works with MVCC (Multi-version Concurrency Control) to track snapshots. We ignored uncommitted writes in previous isolation levels while executing a read transaction. Now, if a write operation is committed before a read transaction commits, the read transaction that uses the same data will be aborted. The database keeps track of ignored transactions when taking a snapshot. If any other transaction accesses or uses data used by one of the ignored transactions, it aborts all other transactions when the ignored transaction is committed.
Data is modified after it has been read: The system temporarily keeps the information about who read the data until any transaction and all concurrent ones are complete. With this information, a transaction informs other concurrent transactions that the data they had read is not accurate anymore. If one of the concurrent transactions commits, all the others must abort to prevent losing data. As there are a lot of aborts and retries, this implementation has a performance drawback. Aborts and retries happen more if the transactions are long. Therefore, SSI requires transactions to be short. On the other hand, as SSI doesn't block transactions, it's better performant than 2PL. Also, SSI is not dependent on a single CPU, like serial execution. It can leverage multi-CPUs and multi-machines. One overhead, though, is keeping track of extra information about transactions' read and write. This info can be granular or in detail. The database implementations decide its granularity. More granular is faster but error-prone; more detailed is slower but more precise, resulting in fewer transactions being aborted.

Reply via email | Reply via Mastodon | Comment

Team Topologies Book Review, Summary, and Notes

Thu, 22 Dec 2022 00:00:00 GMT

How Strongly I Recommend: 9/10

How likely I will gift it to somebody: 8/10

The Review

The book is short but very dense. It took me a while to finish it because I had to stop and think about the practical applications of concepts.

The four fundamental team topologies and interaction modes help us understand how we want to design our teams. For example, if I'm leading a platform team, I must take action to reduce synchronous communication (meetings, face-to-face, etc.) between my team and our consumer teams. Because these direct communication lines will result in bad documentation and developer experience of the platform we develop. If we rely on meetings to explain how to use the APIs, we will never set time aside to improve documentation.

The main ideas the book is driven from are Conway's Law and Inverse Conway Maneuver. These two helped me to grasp how system designs work and how we can achieve our target team structure and system design. Although systems, teams, and business should go hand in hand, it rarely happens. Often technical design cannot follow structural changes in the organization. We often do re-organizations to adapt to changing business environments. But it's difficult to change system design as quickly as organizational design. Having frameworks like team topologies help to find shared language and mindful action while redesigning the organization.

Why should you read it? (Why I recommend it)

I recommend this book because it taught me a framework I could use daily while collaborating with other teams. After reading the book, I have a better understanding of how to structure my team and how to collaborate with other teams. If your team collaborates with others on a more ad-hoc basis and without any structure, you should read this book.

The Summary & Chapter Notes

The Problem with Org Charts

The static nature of the organizational chart prevents organizations from clearly seeing their workstreams and communication lines. The problems grow as the organization becomes more org-chart-driven. As organizational charts rarely reflect which collaborations are needed to get things done, leaders often do reorganizations to meet changing business needs. These reorgs have significant consequences because they avert teams from getting to know each other and working efficiently.

When organizations rely on org charts to align with each other to drive multiple projects, teams' accountability doesn't reflect reality. In cross-team projects, it becomes unclear who is accountable for what. In the end, reorganizations only look good on paper, like org charts.

The Conway's Law

"The organizations design systems in a way that reflects and is constrained by their communication structures." — Melvin E. Conway

This law has held true since 1967.

Software development methodologies have evolved over the years. Earlier, the software architects were handing over architecture blueprints to the teams. That was because the software architect was not part of the team, and the responsibility was not separated among certain people.

After many stages, microservices architecture emerged and reversed Conway's law. Microservices architecture enabled organizations to design teams in a way that they plan their target architecture instead of designing the architecture reflecting team structures. This is called Inverse Conway Maneuver.

Conway's Law in Practice

For example, having a separate database administrator (DBA) from teams will create software design with one big database. If we want teams to own their portion of the database, we must embed this competency in the team. Once the database ownership belongs to the team, they separate their part of the big database into its own entity they can maintain. That's how Conway's law works in practice.

Organization design requires technical expertise: Anyone who makes decisions about organizational structure should at least understand the basics of software architecture design.

Everyone does not need to communicate: If we want to reduce the coupling between services, we need to make these teams difficult to communicate with each other. When communication is too easy and people (unnecessarily) over-communicate, it reflects on the system design. Although communication is often promoted as a good practice, we need to be mindful if we want this to reflect on our systems. Sometimes keeping communication at a minimum is better if we want the software systems highly separated.

Team-first Thinking

Defining a team API (similar to service APIs) is a good strategy for designing the team's external communication.

The team API includes the following:

Code
Documentation
Versioning
Principles & Practices
Work Information (Roadmap)
Communication

Everybody who needs to talk to the team should be aware of that and can use that API. Once the API is defined, the team can constrain the stakeholders to use these frameworks when communicating.

Static Team Topologies

There are two team anti-patterns:

Ad-hoc team design: Designing a team to solve a problem at a certain point and, after solving the problem, leaving a few people behind to take care of the maintenance.
Shuffling team members: "Temporary Task Forces" is actually an anti-pattern. When we mix the teams, it becomes challenging to maintain the systems because an engineer can behave differently in Team A than in B.

Instead of falling into these anti-patterns, we should consider the team's maturity on the technical and cultural front, internal and inter-team dependencies, organization size, and creating or breaking down silos.

We must adopt and use team topology (team structure) based on our context and consider the long-term instead of solving a problem for the moment.

The Four Fundamental Team Topologies

Each topology has different demands on the technical and cultural front. Specific topologies (e.g., end-to-end independent teams) require maturity in tech and mature culture to work. They demand consistent monitoring of dependencies to determine if a new dependence occurs. Therefore, we must understand our talent for each topology and team people up according to their knowledge, culture, and growth plans.

The book defines four fundamental team topologies that can be used in an organization.

Stream-Aligned Teams

Stream-aligned teams are working on a single stream of work. They are empowered to work end-to-end with their capabilities and don't need to hand their work to another team. They aim to deliver customer value quickly and iteratively and learn and adapt according to their learnings. The other teams help stream-aligned teams to offload some work (e.g., platform and enabling teams we mention below), but most teams should be stream-aligned in an organization.

That's why this team type has to have all capabilities within it. Amazon's two-pizza teams are an excellent example of the size of the team.

Stream-aligned teams should

Deliver steadily
Course correct based on feedback they receive from customers
Use an experimental approach to learn and adapt
Does not hand work off to others
Must have time and space to work on tech debt that accumulates from fast delivery and changing requirements
Have good collaboration between other stream-aligned teams (not to hand off part of work but to deliver steadily)
Team members must have autonomy, mastery, and purpose—they must be engaged in their work.

Enabling Teams

Enabling teams aim to take some pressure off of stream-aligned teams. They focus on filling knowledge gaps. As stream-aligned teams concentrate on delivery, they tend to have little-to-no time for research, reading, learning, and practicing new skills. Enabling teams join stream-aligned teams to fill these gaps. They do not execute on these gaps but rather guide the team and share knowledge on specific topics. As enabling team consists of experts in certain topics, they focus on a problem the stream-aligned team has no time to research. The enabling team temporarily joins the team and shares their knowledge via pairing and workshops and leaves. Enabling teams act like a "Technical Consulting Team." Their pure focus is on helping the stream-aligned team to deliver faster with fewer problems.

Complicated-Subsystem Teams

Complicated subsystem teams are formed to reduce the burden and load from stream-aligned teams. These teams focus on a specific and complicated subsystem used by stream-aligned systems and heavily require specialist knowledge. Complicated-subsystem team members have to be experts on their topics. For example, a real-time trade reconciliation algorithm or a face-recognition engine are complicated systems that stream-aligned teams don't need to learn end-to-end.

In organizations, there should be only a few teams like that, not more. These teams should collaborate closely with stream-aligned teams in the beginning and reduce interaction later on. Also, this team should correctly prioritize and deliver high-quality work according to the stream-aligned team's needs.

Platform Teams

Platform teams empower stream-aligned teams to deliver work with substantial autonomy. They extract a complicated part of the domain and convert it into a simple self-service platform where stream-aligned teams can consume without understanding every single detail of the sub-domain. Payment platforms like Stripe and Adyen are good examples; they hide the complexity of payments by providing a platform to their customers. Customers don't need to know the payments, billing, and tax details.

Ease of use is fundamental to any platform. That's why platform teams must treat their services as real products and make them reliable, usable, and fit for the purpose. Platforms should be developed the same regardless of serving external or internal users.

Product teams are expected to work and deliver a small number of services with high quality. Platform teams should strongly collaborate with stream-aligned teams and understand their needs. They should also work with small iterations, experimentation, and feedback. They should have a strong focus on usability and reliability. They should regularly assess if the services fit the purpose or not.

The platform team should understand the adaption of the platform will be slow.

The platform always needs to serve its consuming applications and services' needs, not the other way around. A good platform should offer consumers practical and straightforward APIs, templates, standards, and best practices. The platform should be as thin as possible and not dominate the discourse. It aims to reduce the cognitive load of consumer teams and simplify other developers' lives. It has to be consistent and must have well-chosen constraints and a good onboarding experience.

Organizations should treat the platform as a live production system with downtime planned/scheduled and use product and service management techniques.

Team-First Boundaries

How we shape our teams is important when talking about monolithic applications. There are multiple hidden monoliths that define the organizational structure (I wrote about hidden monoliths here). These monoliths are not only software but also physical offices, deployment pipelines, tech standardization, build and release strategies, and software development strategies such as monolithic databases or applications.

Team Interaction Modes

After defining the topology of the team, we cannot expect that it will stay as it is. Just saying a platform team doesn't make the team a platform team and remain as it is forever. Team interactions and working styles change along with business needs, market, technology, and personnel needs. The Team Topologies framework defines three team interaction modes between two teams to collaborate effectively and deliver results. These three are Collaboration, X-as-a-service, and Facilitation. To achieve the best results, we define (and redefine) these interaction modes between teams during their lifecycle. Clearly defining these interactions helps teams focus, deliver effectively, determine service boundaries well and stay sustainable.

Collaboration Team Interaction Mode

This interaction mode is suited for rapid discovery and innovation. Two teams can collaborate in two ways: each team works on its expertise area and works with the other team on a small set of things, or we merge two teams. Both styles demand good collaboration skills, alignment, and the ability to work with other teams.

Two teams must take responsibility for the work together and build trust. Because close collaboration blurs the responsibility lines, teams must work well together in a trust-based environment.

There will definitely be communication overhead that will cost the organization some efficiency. Therefore, instead of measuring efficiency, the organization should focus on what it gains from rapid discovery and innovation.

There is one restriction for this collaboration mode: one team should have only one other team to collaborate with, not more.

X-As-A-Service Team Interaction Mode

Once the discovery is completed by collaboration interaction, it makes sense for one team to own low-level details and provide APIs, components, a platform, or tools to other teams. The goal of separating is to reduce the cognitive load on delivery teams and make the ownership clear.

For this interaction mode to work, boundaries should be well-defined. The X-as-a-service team should have service management capabilities (product management, versioning, etc.) and work on user and developer experience to improve.

The organizational goal in creating an X-as-a-service mode is to reduce interactions between two teams. The delivery team should be able to move quickly by using the service without interacting with the service team. The service team must keep the service viable and not just build features because other teams' asked so but plan features deliberately for further uses and generalization.

Facilitating Team Interaction Mode

In facilitating team interaction mode, facilitating team does not build and run the software. The facilitating team coaches or guides stream-aligned teams on a topic they struggle with. Facilitating teams identifies impediments between teams and throughout the organization. As this team often guides others, team members are usually experts and work toward increasing other teams' effectiveness and discovering and removing common problems.

Expected Team Behaviors for Each Team Interaction Mode

The interaction modes define the expected team behaviors. For example, the collaboration mode demands mutual respect and high interaction while knowing some activities will take longer due to communication overhead. In X-as-a-service mode, the team behavior should shape around providing the best user experience (UX) and/or developer experience (DX), so focusing on experience becomes essential. In facilitating mode, the teams should be open to help and be helped. The team getting help should be open to hearing suggestions and accept the help because the facilitator team has probably seen similar issues before and know better solutions.

To reduce uncertainty and enhance flow, we can explicitly use team interaction modes. For example, we can use the collaboration mode between two teams to discover possible X-as-a-service integrations.

We can also temporarily change the team interaction mode to help a team grow and enhance empathy. When we do this, we have to do it deliberately and with full consent from people. Otherwise, the team who gets help can reject and ignore the other team's suggestions.

We can also use team interaction modes to determine the problems between teams and systems.

Using Team Topologies To Design the Organization To Design The Systems

Knowing team interaction modes and different team types allows us to design the organization and systems together. Learning about team interaction modes helps us use Inverse Conway Maneuver and shape teams as we create systems design.

During the initial organization design, there will be friction between teams and systems. We cannot expect software design to emerge just by designing the teams. That's where temporary roles like software architect can be influential. Architects are expected to be technical and have social, product, strategy, and people management skills to drive these organizational changes.

Evolve Team Structures with Organizational Sensing

When designing teams and organizations, we also must design the design rules. The business and its needs will change. Our teams need to adjust themselves to these changes. So, we need to think about when to use which collaboration mode and when not to have any communication between the teams. If our organization needs innovation, we can start by using collaboration mode. Later, if we decide to establish the invention as a product, we can move to X-as-a-service or two stream-aligned teams taking parts of the product. Defining these design rules are as crucial as designing teams.

Organizations should have senses to understand their performance and use these senses to learn about their environment and problems. Much like any living organism needs senses to respond to changes in a dynamic environment, organizations can use communication lines between teams, organizations, and users, and also between internal and external stakeholders to understand and adapt to changes. Organizations can also use operations teams (like IT Operations and DevOps) to provide feedback to other teams about problems in operations. To better align feedback, organizations need to have operations teams embedded in development teams instead of having maintenance teams which are usually filled with low-cost labor to lower the costs.

Software is less of a "product for" and more of an "ongoing conversation with" users. To make this ongoing conversation effective and successful, organizations need a "continuity of care" for their software.

Reply via email | Reply via Mastodon | Comment

Genghis Khan on Friendship

Mon, 19 Dec 2022 00:00:00 GMT

The interesting side of Genghis Khan is how he destroyed his family and tribe relationships. In his childhood, building relationships based on trust and choice was more important than having kinship. He killed his brother because his brother mistreated him. He took Temüjin's (Genghis Khan's birth name) prey for himself just because he was an elder and the leader of the family. This was the last drop for Temüjin to kill him after a lot of unfairness and rivalry between them. The importance of companionship was significant to him, and he trusted his friend (blood friend) and exchanged gifts, which was very rare at that time. That made me think about my kin and friends. Friendships are by choice; blood relations do not drive them. That's why they are often stronger. For me, my friendships were always more substantial than my blood relationship. That was my choice; it's not forced upon me. That form of love is always more robust, and we can also see the results in betrayals: it's often more psychologically devastating to have a friend betray you than a family member betrayal. We frequently forgive family members but rarely show forgiveness to friends.

Related Note(s):
Source(s): Genghis Khan and the Making of the Modern World by Jack Weatherford;

Reply via email | Reply via Mastodon | Comment

The Power of Ritualization: Rituals vs. Routines

Thu, 15 Dec 2022 00:00:00 GMT

For years, I've been planning my days hour by hour, trying to build habits that last for longer periods, not just for a few months. In a life without goals, habits are the fundamental stones, and opening some space for them is crucial to not falling into an aimless life.

One of the results of these habits (writing every day) is this blog. This blog is the product that came out from me sitting down and writing for at least thirty minutes every morning. It was difficult to start writing at first, but these days, I just grab my pen (or sometimes keyboard) and continue writing or editing my previous drafts. Once I got used to the habit, it became a routine.

Actually, many of my habits became routines; I planned them carefully and adjusted their times and cadence according to other events happening in my life. Doing something every single day may sound quite boring to many people and also can be challenging. When someone asks me how my life is going, I can mostly say, "It's the same since you last asked." Sometimes there might be some news; sometimes, nothing interesting happens. At least, nothing interesting for them, not for me. Life is actually not boring, even if I do the same things every day. Because I don't have routines, I have rituals.

I've been using Headspace for a few years on and off to learn meditation and to train my mind. In one of the meditations, the guide talked about rituals. That was an enlightening approach that helped me understand why I enjoyed doing a lot of activities every day while others found them loathing.

When we build a ritual around a routine, it ramps up the routine, much like the weekend hikes we used to do as a family in my childhood. Or, like cooking turkey in our family's new year's celebrations. They both had a set of activities consistently done in a certain order every time. When we went on weekend hikes, we always searched for wild fruits and always ended with a barbeque next to a small river. When we cooked turkey for the celebration, preparations started a few days ago, and we always had my uncles as guests in our apartment. We didn't only go for a hike or cook turkey alone; we consistently built activities that made these experiences delightful.

Ritualizing layers meanings around activities. It gives a sense of satisfaction to the most tedious and regular activities. Think about a family dinner on a religious day like Christmas or Ramadan. These dinners have certain rituals around them that have been done every year. They are not just dinners where everybody is present. They have been ritualized with multiple layers around them.

I've been adopting this ritualization idea in my life for a while. One of my daily rituals after waking up is grinding a coffee, setting up the coffee machine, meditating for ten minutes while the coffee is brewing, and drinking that coffee. Drinking a cup of coffee is a ceremony, not an activity to wake me up. Certain and consistent activities lead to taking the first sip—measuring the weight of beans, manually grinding coffee at hand instead of using a machine, adjusting the strongness of the brew depending on my day and mood, and then meditating in silence at 5:30 in the morning. The very last moment of this series of events is actually enjoying the coffee in complete silence. For me, reaching the first sip of coffee demands building up mindfulness. I have huge respect for the people who bring these coffees to my cup, and I feel like that's one of the things I can do to honor them.

Rafael Nadal, a world champion tennis player, is known for his ritualistic habits in the game. He arranges his water bottles carefully, never steps on the lines while walking in the court, and always jumps during the coin toss. He says that his activities are not superstitious. When he serves a ball, he adds something from himself. He individualizes every single move. By doing so, he focuses on the game and enjoys every moment—even the most boring parts, such as drinking water.

Sometimes, it isn't easy to individualize each activity and make them joyful and ceremonial. For example, I started reading books at university. Building the reading habit took me a lot of time. That's when I realized that I was reading physically low-quality books—the print material of the books was horrible, hence reading was not fun at all. Once I recognized this, I decided to find books with better print. These days, I always opt for hardcover prints instead of paperback if it's available. Reading from hardcover books makes reading more pleasant. If the book has a good cover design, that becomes a cherry on top.

A well-designed item nudges me to use it. When I pick up a well-designed book from the shelf, the excitement encourages me to fulfill the book's purpose: to be read. When it's a beautifully designed book, that purpose shows itself instead of me searching for it.

The visualization helps keep rituals consistent. If I want to keep going to the gym, I prefer having comfortable and nice-looking shoes. These shoes motivate me not to skip the gym day. Because I really want to wear my shoes; they just look great. The same applies to note-taking: I usually use fountain pens while note-taking. Suddenly, writing things down becomes a pleasure because writing with a beautiful fountain pen is more satisfying.

All routines can become rituals. It's all about perspective and how we approach building habits. The perception of routines has to change, and one way to do this is by ensuring we build some routines with people we love. Maybe regularly watching sports with friends, meeting up in the same café every month to catch up, or going to the same location every summer for a family trip. From one perspective, they are routines, but from another, they are rituals. They have certain ceremonies we do every time that makes these routines delightful.

We need to search for and find pleasure in every activity we do. Our jobs might be tiring or overwhelming. But when we find some things around them and ritualize some parts, they become easier. A beautiful physical calendar can change our daunting planning cycle. A beautiful coffee machine may boost our mood in the mornings when we're having a cup of coffee with one eye closed. Or going to the same hotel in summer can relieve stress from searching and planning and help us enjoy every moment of family time.

Routines can—and should—become rituals. And beautiful design helps build and keep them consistent. If we are going to do the same thing every day, then it should be a pleasure, not a burden.

Reply via email | Reply via Mastodon | Comment

Communicating Organizational Changes

Wed, 14 Dec 2022 00:00:00 GMT

If a leader makes an organizational change, they have to write down clearly what it is about. No leader has all the answers. So, they must show people they don't have all the answers. They have to be authentic, intentional, and emotional. While announcing an organizational change, they should add TL;DR (executive summaries are not only for executives) and FAQ to the document. What leaders have is the context, and they have to give people the context; why they had to make this decision and what the things others can't see (things that are only visible to leaders).

"People are not resistant to change; they are resistant to change they don't understand."

Related Note(s):
Source(s): The Weekly Hagakure #30;

Reply via email | Reply via Mastodon | Comment

The Last Person on Earth

Wed, 14 Dec 2022 00:00:00 GMT

Understanding our values is one thing; building personality around them is another. We do something every day. Sometimes, they differ, and sometimes, they are part of a routine. We're sometimes lost; we don't know where we're headed. In these situations, it's a good practice to ask ourselves, "If we were the last person on earth, would we still do what we do?" If what we do is aligned with our values, then the answer should be a big yes. If not, there will be questions in mind. The question is intentionally bold and provoking. When our job is tied to other people, the answer automatically becomes, "There is no purpose of my job if I'm the last person." Yet the idea is not about that; it's about you doing that work, not giving up, and still looking for opportunities to continue on that path. If it's playing basketball is your thing, would you play it even if there is no one around you? If you're writing, would you keep writing even if you know nobody will ever read anything you write? That's the notion of learning ourselves and how our actions are tied to our values.

Related Note(s):
Source(s): The War of Art by Steven Pressfield;

Reply via email | Reply via Mastodon | Comment

Mektup #46: Energy or Time—Which One to Manage?

Tue, 13 Dec 2022 00:00:00 GMT

Hey friend,

In previous Mektups, I talked about deep work and multitasking. These two are correlated, and I wanted to return to the theme from a different perspective: time management vs. energy management.

The idea of not multitasking is about maximizing the effectiveness and outcome. Meanwhile, having focus and deep work is about the quality of the outcome and personal satisfaction with the process and that outcome. Having a focus state and reaching desired results are not straightforward. When we want to grasp how many concurrent tasks, projects, and initiatives we are "focused on" at a time, the very first thing we do is look at our calendars. We search for unnecessary meetings to reduce distractions and scan project boards to see how many tasks we juggle simultaneously.

Especially in leading roles, calendars are cluttered with meetings, and we quickly fall into—what Paul Graham says in his famous essay—manager's schedule. Our most effective action then becomes moving meetings here and there to create an hour or two to focus on "the important" stuff. Regardless of the manager's or maker's schedule, we often try to optimize our time because that's what the system focuses on: eight hours per day should produce the maximum outcome. When we follow the system without thinking and reflecting, we usually become miserable.

How often do you feel you're "done" after work in a week and don't want to do anything besides mindlessly watching a movie or going to sleep? When was the last time you had some brain power after work to grab a non-fiction book or read the article that you saved on your reading list a week or two ago?

In many conversations I had, it's apparent that many people have no energy left in the evenings. Also, their energy often depletes after 4-5 hours of shallow work (4-5 hours of deep work is the max we can do in a day). And that's something we need to change—you and me. I include myself because I sometimes feel the same.

A few months ago, I felt lost while trying to start a new initiative at work. I was moving a few meetings to create two hours of uninterrupted time so I can work on it. After a few failed attempts, I came across Cate's article about energy management (you can see my comment under that post). Then, I realized I had time but no energy to run the initiative at all. I stopped chasing it even though I knew the initiative's outcome would bring positive results for the company and me. Yet, it could have drained my whole energy and motivation.

These days, I'm focused on managing and maintaining my energy together with my time. Before I take any extra responsibility, begin a new initiative, start a new project, or say yes to a "quick question," I ask myself, "Is this something I can spare some energy for even if I have time?" I follow up the "Yes" answer with, "Do I want to spend my energy on this thing? Is it going to deplete my energy or energize me?" Once I know the answers, it's clearer whether I should take that extra responsibility.

Learning about energy management was life-changing for me. Before, it wasn't easy to differentiate between two pieces of work I wanted to do and decide which one to pick up. It was challenging to say no. These days, I can say no more easily, even if I have always wanted to do that work.

The questions I ask myself are not the only things I do to maintain my energy during the day. I aim to say less, "I'm just done; I want to sleep," at 5 pm. To do that, I started using techniques and tools like Headspace and Reclaim.ai. I'm not going to dive into details in this Mektup; that will be the topic for the next one.

Meanwhile, think about how you maintain your energy. Observe yourself during the day to figure out what sucks your energy or gives you more. Be aware of how many days you say, "I'm done for today; my brain is not working anymore." In the next Mektup, I want to share a few more techniques to help you.

Until next time,

Candost

P.S. Did you fall into the productivity scam?

P.P.S. I didn't publish anything in the last two weeks because I was sick.

Reply via email | Reply via Mastodon | Comment

Mektup #45: How to Explain Things Clearly

Tue, 29 Nov 2022 00:00:00 GMT

Hey friend,

As you may remember that I started a new job in November. So far, it's going well. The team is full of great people, and I had a fantastic start in onboarding by having an offsite and two days of leadership training. While many things go well, there are challenging parts that I have to overcome quickly somehow.

One of them is learning a new domain and processes. In this phase, it's crucial for me to have people who can explain things in a way that I can understand.

As I am the new clueless manager on the team, I have yet no context of many things. Therefore, I rely on people explaining stuff in enough detail so things make sense and I can make an informed decision. There is particular stuff I can start doing, but as I'm missing context, learning the background of anything takes time and delays taking action.

Finding people who can explain things to me is difficult because these people are rare. I, once more, was faced with the reality that not everyone can explain things well to a person who has less knowledge or context. Not everyone can measure my knowledge level, even though their audience is just one person. Some people think that I'm already in context. Some assume that I am clueless while I have already learned a bit.

Many people—not just engineers—struggle to explain their knowledge, not because they don't know the topic but because they don't take the time to uncover their audience.

When I started my blog, podcast, and writing every day, one of the pieces of advice I received was to answer a simple question before starting, "Who are you creating this for?" This became a big question in my head in each podcast episode I recorded, and in each article and Mektup I published. Repeating the question every single time got me into a habit.

It's not easy to learn the audience, though. But with a few techniques, it becomes easier.

Have you ever been in a talk where a speaker asked you to raise your hand if you're familiar with a particular topic? Well, that's one of the techniques to learn the audience. After the speaker asks this question, if the majority knows about that specific topic, the speaker often quickly moves forward; if not, they explain deeply. This technique is adaptable to daily life as well. Maybe not asking to raise a hand in a two-people conversation but simply asking, "Are you familiar with X?" is more than enough.

That question helps us to continue the discussion effectively and creates engagement. As a result, the talk moves from monologue to conversation. The human attention span decreases yearly, so keeping the other side engaged is crucial.

Another strategy that helps to explain knowledge is thinking about how to explain the topic to a five-year-old kid. For example, how would you explain Continuous Delivery or Continuous Integration to a five-year-old kid who doesn't even know reading? We recently had leadership training at SumUp, and in one session, the presenters asked the audience to work in groups and explain one given technical topic to a five-year-old kid.

That was a great challenge and a brain gymnastic. So, my friend, next time you have to explain a technical topic to a non-technical audience, think about that. Find analogies. Even if your audience knows some technical knowledge and understands you to a degree, it's still valuable to use analogies to help them get on the same level as you.

These two simple strategies will help you get buy-in for working on the technical debt that's been building up for a while, explain why a feature was delayed, or successfully pitch an idea. These strategies enable your audience to feel included. Once they are part of it, they don't feel bored; they get on the same page as you more quickly.

Furthermore, these strategies make you a collaborative and well-communicator person. Your career growth fastens, and your relationships get better. So, next time, ask yourself, "Whom are you explaining this topic?" and see the magic.

Until next time,

Candost

P.S. Let me ask you. Reply to this email with one sentence without your name and introduce yourself! Who are you?

P.P.S. Annual Performance Reviews are approaching for some folks!

Reply via email | Reply via Mastodon | Comment

How Zettelkasten Method Works

Mon, 28 Nov 2022 00:00:00 GMT

Make a fleeting note. Whatever comes to your mind, write it down. No structure or full sentences are needed. It's for you to remember.

Make literature notes: Write what you've learned and don't want to forget. Use your own words. Keep it short—no structure or full sentences are needed here as well. Keep bibliographic details together with the note.

Ideally, once a day, go through fleeting and literature notes and make them permanent by writing them down as you are writing for someone else with full sentences.

And put the note behind the related note or the latest one if there is no related one exists. Scan your slip box and add links to existing notes where you think the new note is somehow related. Make sure you will find the new note either via a link from an index note or via an entry point note about a discussion or topic that is linked to the index.

Develop topics, questions, and research bottom up by using these notes. Check what is missing, and fill them up by doing more research and reading. You don't need any brainstorming on the topic. Find the chain in the notes.

Look at all the notes and find connections. Copy them to “desktop” to work on them. Don't directly work on them since this will change the previous notes.

Create a draft. Don't copy things from previous notes. Translate them into something that is related to your argument.

Edit and proofread the document and share. Go to the next topic.

Related Posts:
- How to Stop Endless Discussions;
- Why is Writing Important?;

Reply via email | Reply via Mastodon | Comment

Concluding My Struggle with Note-Taking Systems and Apps, Finally!

Sun, 27 Nov 2022 00:00:00 GMT

I've been researching a better note-taking system, trying apps, and moving hundreds of notes from one place to another for years. Today, I can finally say I have reached the end, and I'm finishing my research and experiments with apps. I share what I learned in this post and explain how things have changed.

I have been thinking about my notes and how to write them, edit them, and store them. There are countless note-taking applications and various techniques, and I tried many of them. Yet I realized it's not the differences or the method that matters for making notes valuable; it's the mindset I have while taking notes.

I used to copy quotes as notes. They didn't consist of any word that is mine; they mainly comprised words of others—the authors. I kept their words, memories, experiences, and ideas. In this collectivist mindset, you know what you have is not yours; someone else created it. And it will never truly be yours, even if you own them.

As I wrote down these notes, I also stored them within specific categories, such as habit building, software architecture design, personal values, et cetera. There were hundreds of notes and tens of categories. I never went back and read them. Even when I did, they were still not mine; therefore, I couldn't remember them. That triggered me to look for ways to improve my whole note-taking system.

For a while, I started trying apps. I tried Evernote, GoodNotes, Ulysses, Bear, Apple Notes, Notion, Scrintal, Dropbox Paper, pen and paper, Anki, Craft, and Obsidian in search of a better system. None of them worked. But I was wrong expecting another piece of technology to solve a problem when my fundamentals were wrong. If I was using them the same way, how could I expect them to solve the problem? All these applications claim that they solve the problem of note-taking. And they actually do if you have the right mindset and learn how to use them.

Apparently, I neither had the right mindset nor learned how to use these apps for years. So, what did I change?

I transformed myself, my perspective, my approach, and my expectations. Let's dive into each separately.

Changing Myself

First, myself. As cliché as it sounds, I'm not the same person anymore. I grew and evolved, and my old methods didn't suit me anymore.

Before all these changes started, I thought I was smarter and more knowledgeable, or at least I wanted to be. The more I read and learned, the more everything revealed how foolish and ignorant I am. I realized I would feel even more stupid every other day if I kept reading.

As I realized I was not smart, I had to keep better notes and write better. I couldn't leave it to chance to learn something and forget about it. As I'm a flawed human, I had to look at my note-taking with the mindset of a person who forgets. As I acknowledged that I would forget what I learned today, I was better off writing things down. Changing this perspective was not enough, though. Since I was already taking notes, something else should have been wrong.

Yes, I faced the harsh reality: it was my perspective on my system.

Changing Perspective on System

The perspective is the biggest flaw we have. Yet, the slightest change can lead to magnificent results. Near the end of my search, I changed my perspective on my note-taking system without changing the system.

I changed the collectivist perspective to a scientist's perspective. Scientists search the literature to learn from previous studies and collect a lot of data to build on it. While doing so, they write down their observations on the previous research. They use their own words (they have to prevent plagiarism). Otherwise, they never learn and cannot add anything to the literature. So, I started using my own words while taking a note.

I suddenly realized how much I was not learning from what I was reading. The sentences that I was trying to build threw me off the rack. I should have fully understood what I was reading to be able to write it down in my own words. As soon as I put the pen on the paper, writing tested my knowledge. I never had this challenge. By using my own words, I began to learn better. Along with better learning, I evolved my approach, and at one point, I had to change my note-saving system.

Changing Note-Saving System

The system I was using pushed me to use the folders and categories. I also used tags to cross-reference between notes, but they were also categories. I used tags to place a note under two categories if a note belonged to more than one category. Later in my research, I learned about Zettelkasten.

I started trying the system. At first, I couldn't really adapt to it because I was still saving quotes. My mind looked for categories and patterns to group notes. In Zettelkasten, there is also tagging, but it wasn't aligned with what I did before. Of course, I mistakenly used tags as before, and it didn't work out. I had to unlearn—which is one of the most difficult things we should do every day. Then I read How to Take Smart Notes twice. I learned the beauty and simplicity of the system and where I was wrong. The tags I used had the librarian mindset, but I needed the archivist mindset.

The librarian mindset looks for categories. Every book or magazine belongs to one category, and librarians place them with the goal of easily finding them by their name, genre, and author. Their purpose is simple: the shortest path to find a book.

On the other hand, archivist doesn't look for categories. An Archivist thinks about the question that leads to this information. They think about how that piece of information should surface in the future. They ask, "How should the information be relieved in the future?"

This tiny difference changed my mindset and my whole tagging and note-linking system. For example, instead of using the #productivity and #time-management tags for a note about improving outcomes with better time management; I now have #outcomes-not-output and #why-should-I-plan-my-day.

And every note has a maximum of three tags, not more. Each is written future-thinking and answers, "How do I want to find this note in the future?" That's the question. It's okay if I don't read this note in two years and don't have to remember where I put it. The goal is not the shortest path to note; it is trusting the system to reveal the note at the best possible moment.

The tags are a support system in Zettelkasten. The core idea of Zettelkasten is linking notes to relevant ones to connect them—increase their chances of being found out. As all notes are linear (no folders, just putting every note behind each other), we connect notes by linking each other. That provides visibility to a node. Eventually, it will be reached and read. No note will stay asleep forever.

That brings me to my last change.

Changing Expectations

My earlier expectations were shallow and almost non-existent. I took notes to remember things; I expected to become smarter, learn more, and eventually have a better life. These naive thoughts—of course—did not become a reality, and all my expectations were unmet. While altering the whole system, I deleted my previously taken notes to reset my expectations.

Instead of trying to become smarter and memorize stuff, I assume I will forget. Hence, I write things down. As I will forget with or without note-taking, I moved the responsibility of remembering things to my system. No expectation to remember things is a big relief to my mind.

Another expectation I had was to produce more articles or essays to publish on this blog. That is gone too. I will keep writing, but I do not crave to publish more. I expect to write daily and publish only when I'm ready and when it's time to publish Mektup.

One expectation I will keep is to learn more, but this time differently. As I write notes in my own words instead of taking quotes, each one challenges my learning. In every written word, I face a huge learning curve. Every note teaches me something better. That's why I keep my learning expectation.

Finalizing the Challenge

My new note-taking perspective, approach, and expectations will eventually change me. I'm embracing this change and even hugging it. At least, it produces less stress. Accepting that I will forget itself is a relief. Knowing that I will eventually find the note I write is just relaxing. And last but not least, writing notes in my own words will also improve my writing and show me invaluable thoughts and wisdom.

The best part of all these changes and systems is that I didn't invent them. This system is what made Niklas Luhmann and many others succeed in their fields. They already have figured out that it works; I only need to uncover and adapt it to me.

Maybe in time, I will adjust the system more to myself and change how I use it. That's not an issue. I'm not strictly following Zettelkasten as it is. I listen to my heart and reflect on how the system is progressing once in a while. In every reflection, I will have a chance to tweak the system and make minor adjustments.

With this, I'm ending my note-taking tool and system search. I have all my notes on Obsidian for a while now, and all of them will stay there. I will stay with this approach as long as it goes.

Reply via email | Reply via Mastodon | Comment

Why is it so hard to be kind?

Wed, 23 Nov 2022 00:00:00 GMT

Why is it so challenging to be kind? I ask this question myself because I'm aware of my rare unkindness to the people I don't know. I rarely stop being kind, especially when the other side is unkind.

But isn't responding with kindness the best reaction to a rude person? Isn't it what keeps our personality intact? Isn't it what makes us untouchable?

I observed others when they were in a conflict, and kindness often made one side partly superior—not as arrogant but as better or outstanding. Also, kind people don't chase this superior feeling; they are usually humble. Yet, they fall into a trap and act rudely in certain situations.

Then, I asked myself, why are we discourteous even though we're generally compassionate and caring?

Kindness is so challenging because of our daily stress routine. We're often rushing somewhere; we're late. We're nervous. We're frustrated. Something happened. We have a big chunk of emotions we can't even express. You name it. Within all the daily emotional rollercoasters we have, the last drop overflows the glass, and we abandon kindness. Just for a bit. Temporarily, like five seconds. The five seconds we will regret.

For instance, I cannot stand cunning people because they make me feel stupid. Recently a devious person cut the line in the supermarket, and something inside me fired up, and I acted. My reaction was also unkind. If this person had asked me, I could have voluntarily given up my position in the queue, yet they didn't. They chose the unkind way, and so did I.

Once we abandon kindness just for a bit, it's already too late. There is no turning back. It's like breaking a vase. We can glue all the pieces together, but it will be a broken vase forever.

Later, I regretted my discourteous action because the situation created an inner conflict. This conflict is the main reason I'm asking the above question myself. Inside me, I broke a small vase that can't be entirely repaired.

When we respond to rudeness with kindness, the unpleasant situation suddenly sees a bright light. A tiny light of hope bears inside us and tells us everything will be all right. A light like the one coming after a scary storm in the ocean. A light that arises hope for humanity and peace and brings beauty and color.

All these feelings and consequences are there, and it's good that I can see them. But still, the question I asked remains unanswered. Perhaps I need to change the question and approach from another perspective: Waymond's.

How to be kind to strangers, especially when they are not kind to us?

Not being kind has a rolling effect; the more unkind we are, the more stress and anger we accumulate. Lately, I have been building up stress and tension, and being kind has become more challenging. I moved to a new city and got a new job. Everything is new, and it is stressful to improve on every front while trying to adapt to them. To prevent kindness from falling over, I changed a few things.

While training my body in the gym, I'm training my mind more heavily these days with meditation. The core of mindfulness meditation is noticing. Maybe, we can recognize how we are being treated and notice feelings accumulating inside us. We can notice and acknowledge our harmful emotions instead of preventing them from suddenly unleashing as unkindness. And maybe, maybe, we can let them go. It is not easy, especially in the middle of heated-up arguments, but worth a try. Noticing requires consistent practice, but even noticing once helps to advance.

I'm also trying to improve my relationships with the community and help others. These nice things help me relieve stress and build kindness. I started spending some time in non-profit organizations and helping those less fortunate than me in this harsh life. I'm not doing these to show kindness. I'm fighting back unkindness. I'm trying to relearn it.

We evolve every day; we cannot stop. It's an endless journey. The only thing we, you and I, can do to impact this change is to choose a direction. We can make a conscious decision in which way we want to evolve.

And that way has to be kindness.

Reply via email | Reply via Mastodon | Comment

Barriers to Learning from Contact with Reality

Wed, 16 Nov 2022 00:00:00 GMT

Three personal barriers to growing as a person are perspective, ego, and accountability. Our perspective is limited. Think about the relative velocity. A person in a moving car throws a ball into the air and only sees the ball's vertical move. A person observing from outside sees the ball's vertical and horizontal movement. We're often limited to our perspective and need different ones to understand reality. It also allows us to reduce the ego effect. Our egos prevent us from opening ourselves to being wrong. We don't want to be seen as stupid or wrong. Yet, when we accept that we can't know everything and rightfully be wrong, we leap forward and can grow and learn other perspectives and new information to make better decisions. Lastly, the distance from the results of our decisions should be as short as possible. When we hit our small toe to the corner of the bed, that's the most immediate feedback we get. The distance between the result and our action is tiny. In decisions, we must keep the distance short of increasing accountability because we learn from the results. If the distance is big, we can't tie our actions to them and remember clearly what we did. As a consequence, we ignore the result and don't learn.

Related Note(s):
Source(s): The Great Mental Models Vol. 1 by Farnam Street

Reply via email | Reply via Mastodon | Comment

Mektup #44: Returning to Office and Remote Work

Tue, 15 Nov 2022 00:00:00 GMT

Dear friend,

I hope you're doing well and getting used to knowing the end of the year is coming. The cold is what winter brings in Berlin, and I'm ready to take out my snowboard, head to some mountains, and get lost in fresh white powder.

As much as taking a trip became more accessible thanks to remote work, I have not had any work-ation. This year, I might break this pattern and enjoy some winter trips. That brings me to the topic I wanted to write you about today.

I've been working remotely for almost five years now. As you may remember, I started a new job at the beginning of November, and since then, I've been going to the office every day! Although the office is not a requirement, I voluntarily opted-in to work at the office during my onboarding. Besides the time I spend commuting (oh, I hate commuting, in case I didn't tell you before. I can't read a thing on the subway, and I don't want to put headphones on for an extra hour every day. Anyway. I will live with it for a while), it's going surprisingly well.

The office work reminded me of a few things I had long forgotten. I remembered how much easier to get to know people when we spend face-to-face time. We're social animals, and it's the social part of our animal life. And I know that we can also socialize in a remote setup where we have regular socializing calls and events. Considering the best-case scenarios of both options, I think in-person socializing is far better than online socializing. It's more natural.

I know it's not for everyone. That's why we have to find a balance. Also, we should distinguish remote work from lockdown work-from-home. I'm a big fan of remote work and will continue working remotely after my onboarding, but I also want to encourage everyone (ahem, you) to meet with your colleagues and let them become your work friends.

You may say that you don't need to become friends with your colleagues and it is better to separate your personal and work life. That's understandable and, of course, a valid reason. What I'm saying is to convince your company to get all of you together once in a while. It will have a tremendous impact on your work.

Additionally, as I'm going to the office every day, I also remembered the case of hybrid meetings. I still don't like them. Luckily, we don't have most of our meetings hybrid, and everybody joins from their computer, even if half of the team is in the office.

Lastly, I love the inclusive environment remote work creates and will continue writing about some other practices I've seen work well and don't work at all. These days, I'm in onboarding mode, and my mind is full of new information I must digest. So it will take a bit of time to write them down. Yet, as I tend to forget things, I noted my thoughts and will share them soon.

We're in mid-November, and I'm heading to the office again today in cold Berlin. Let me know your experience and thoughts about social life and remote work vs. office work by replying to this email.

Until next time, Candost

*P.S. Here is the photo of me writing you the first personalized Mektup after changing its direction.*

*P.P.S. Deep Work and Focus Time are crucial for you.*

Reply via email | Reply via Mastodon | Comment

DDIA: How to Partition a Database

Sun, 13 Nov 2022 00:00:00 GMT

This article is part of my notes from Chapter 6 on Designing Data-Intensive Applications by Martin Kleppmann. You can read other chapter notes as well.

Chapter 1: Reliability, Scalability, and Maintainability in Distributed Applications
Chapter 2: Data Models and Query Languages
Chapter 3: Data Storage and Retrieval
Chapter 4: Encoding, Decoding, Schemas, and Data Evolution
Chapter 5: Data Replication
Chapter 6: Database Partitioning
Chapter 7: Transactions
Chapter 8: The Trouble with Distributed Systems
Chapter 9: Consistency and Consensus
Chapter 10: Batch Processing
Chapter 11: Stream Processing
Chapter 12: The Future of Data Systems

We talked about data replication in the last chapter. Database partitioning and replication techniques are often combined. While the replication is for fault tolerance, the goal of partitioning is scaling systems. Partition means part of nodes that can be replicated to other nodes. Each node can contain multiple partitions, and each partition can be either a leader or a follower if replicated.

Although replication and partitioning are related, strategies and how they impact each other are not necessarily entangled. So, there is no need to discuss them together.

We'll talk about partitioning key-value data (as it is the primary index), partitioning secondary indexes, rebalancing, and rerouting.

Partitioning of Key-Value Data

:::note 💡 Partitioning aims to spread the data and load across multiple nodes evenly. :::

In theory, if we partition one node into fifteen nodes, the system should be able to handle fifteen times the load it handles with one node. In practice, it doesn't work like that. Depending on how we partition, some partitions take more load than others and become bottlenecks.

Skewed System: When the partitioning is not fair, the load is not evenly distributed, and one or a few nodes have more data and queries, we call the system skewed.

Hot Spot: The partition gets a high load in a skewed system.

Let's assume we have a simple data store with a primary key only. We can partition it in two ways.

Key-Range Partitioning

We define boundaries for partitions with ranges in the key, similar to encyclopedias. The keys are sorted, and each is assigned to a partition. The advantage is that range queries are efficient, as we don't need to query all partitions to get a range of keys. The downside is that specific access points lead to hot spots, and the database becomes skewed. In order to manage the load, the ranges have to be adapted to the data, and the keys should be selected well. And it's often difficult to know beforehand which keys will become hot spots.

Hash-Key partitioning

To eliminate hot spots in key-range partitioning, we can use hash functions for keys. Even when two keys are very similar, their hashes can be different. For this to work, we need a good hash function that gives the same results independent of where it has been run. After having hashes, we can assign each partition range of hashes. The upside of hash-key partitioning is distributing keys evenly; the downside is losing range-based query efficiency (we need to query all partitions for range queries).

We can also combine both strategies and use a compound primary key where the first part is hashed to determine the partition, and the second part of the key can be ranged (for example, choosing [user_id, timestamp] as the key). Compound primary keys enable us to perform range queries on the second part.

Using the hash key doesn't solve all skew problems. In extreme cases, they still happen (e.g., having millions of followers on social media creates hot spots). There is no automatic way to handle these situations, so application developers must come up with solutions according to their use cases.

Partitioning and Secondary Indexes

When we involve secondary indexes (as they are widely common in relational databases and the main feature of ElasticSearch), we need to find ways to use them in partitioned databases to avoid skew effectively.

"The problem with secondary indexes is that they don't map neatly to partitions."

There are two ways to partition secondary indexes.

By document: We put secondary indexes in the same partitions as the primary index. So, each partition maintains its own secondary indexes—covering only the documents in that partition. For example, if we sell guitars and secondary indexes are color and brand, searching red Fender guitars requires searching in all partitions. This method is also known as the local index. The disadvantage is when you want to search by secondary index, you have to query all partitions (also known as scatter/gather). The benefit is write operations are very fast and happen within the same partition.
By term: Also known as a global index. In this strategy, we store indexes in partitions by their term. So all indexes of the same term are in the same partition, which covers data from all partitions. For example, searching red Fender guitars will only go to one or two partitions where the term color:red and brand:Fender are stored, as these terms will consist of a list of primary indexes of certain items. The benefit is having very fast read operations on the secondary indexes because they are often stored in the same partition as the data. But the difficulty comes with the write operations and maintaining these indexes. These secondary indexes need their own partitioning strategy, and key range or hash-value can be used to define these partitions. As secondary indexes are partitioned separately, maintaining them takes some effort too. To prevent heavy write operations from blocking the client, writing to secondary indexes are often asynchronous.

Rebalancing Partitions

Moving load from one node to another is called rebalancing. The golden rule of rebalancing is data shouldn't be moved more than necessary. During rebalancing, the database should continue accepting read/write requests.

There are a few strategies to rebalance skewed databases.

Rebalancing Strategies

hash mod N: We define which data will go to which partition by using mod function. Don't use it at all because, with this strategy, we move data too much; every time a new node is added, most of the data is reshuffled and moved to new partitions.
Using a fixed number of partitions: We assign multiple partitions to a node and use a fixed number of total partitions across all nodes. The difficulty lies in picking the right number for partitions, as it won't change later on, and data varies in time. Whenever a new node is added, it can take over partitions from each node. So, only the partitions' assignments change instead of individual data.
Dynamic partitioning: When a certain partition grows, we split it into two partitions and assign the new partition to a new node. Still, each node can handle multiple partitions, but their number is dynamic according to the data changes (we add or delete partitions). The nuisance is we don't know how many partitions we should start with; we can begin with one or multiple if we know how to split by the key (pre-splitting).
Partitioning proportionally to nodes: We use a fixed number of partitions per node. When a new node is added, the new node chooses random partitions to split and takes ownership of half of the partition. Randomly choosing partitions requires using hash-based partitioning. Randomization can introduce unfair splits, but there are algorithms to prevent that.

Rebalancing can be done automatically or manually, but having a human in the loop is better. When it is automatic, it can mess up with automatic failure detection. A huge amount of data moves from one node to another; meanwhile, one node can be overloaded. During overload, the other nodes can think that this node is dead. The automatic rebalancing mechanisms try to move load from it and cause more overload on the node, the other nodes, and the network, causing a cascading failure. So keep human interaction to prevent unwanted issues.

Request Routing

With all data rebalancing, nodes, and partitions changing, we need to take care of how the client will access the nodes. The clients should know the IP and port number to send a request. There are three ways to give this knowledge to a client.

Nodes can contact other nodes. When a node receives a request, and it doesn't have the data, it forwards to the appropriate node, gets data back, and forwards to the client.
Add a routing tier. The routing determines the node to request data.
Allow clients to know which node and partition to contact.

In all three options, the problem lies in learning when there is a change in the assignment of partitions to nodes. Everyone must agree on which partition to reach for specific data. We can use an external service (e.g., Zookeeper) that receives information about node changes and informs either the routing tier or clients about them.

Reply via email | Reply via Mastodon | Comment

Joining SumUp

Tue, 01 Nov 2022 00:00:00 GMT

Back in 2015, I didn't know anything about Jimdo when I moved to Germany. I started hearing it in meetups where Jimdo was a host. Later, I joined Jimdo in July 2016 as an iOS Engineer. For more than six years, I was lucky enough to work with fantastic individuals, and we worked towards creating excellent applications that fulfilled users' needs.

Jimdo was the third company I worked with. I'm so grateful and find myself lucky enough to work with such an amazing community for years on a great mission, which gave me a feeling of belonging. It will always stay in my heart like my first company Monitise (currently Commencis). I'll follow Jimdo's progress as a user from now on.

After 6+ years of journey in Jimdo, I was ready to start another challenge. I started answering recruiters who reached out to me and had a few interviews here and there. Yet, in any company, I couldn't find the energy I was looking for. Later, I saw that SumUp was looking for an Engineering Manager.

And it was the only job I applied for instead of recruiters reaching out to me. And the one I am happy to start my journey today.

Why SumUp?

Several considerations guided me to join this fantastic team.

Mission: Empower small merchants all over the world One of my biggest motivations for any job is how it contributes to the world. As I love to help people, SumUp's mission is dear to my heart and very close to the one that kept me in Jimdo for years. Small merchants face huge and unseen challenges. Just to give an example, everybody is curious about the challenges of Google, but I've rarely seen anybody's interest in the challenges of Ecosia. Think about tiny shops around the corner. When was the last time did you hear any politicians talking about their challenges? If we have a look at Jimdo-Ifo-Index (yes, Jimdo 😍), we can see the real situation of small businesses.
Compensation: Let's address the elephant in the room. If there is no compensation increase and my current role is not detrimental to me (which it wasn't), why would I change my company? I'm not going to disclose the details for now, but my compensation is at a level that makes me feel valued.
Culture: The culture defines a company's success. When nobody cares about it, it easily becomes chaos. During my interviews (and after interviews), I repeatedly saw and experienced cultural norms. It's still difficult to judge any organizational culture before experiencing inside, yet, so far, it was the one I wanted to be in.
Team: As I currently work as an Engineering Manager, I looked at the team and met with members—my direct reports, manager, and peers—as much as I could. They look and sound like fantastic and smart people who will elevate me. From another perspective, it's a team that I can contribute to and help people to do whatever they are doing the best.
Values: In many interviews, I've never seen a company that integrated its values into its hiring process as much as SumUp did. The values are public, and the hiring process—and everything they do—is tied to their values.
Economic Situation: As the recession is coming in Germany, the economic situation of a company was one of the major factors I considered. SumUp raised $624m with an $8.5b evaluation in June. On top, SumUp has a founder mentality, so they don't spend money recklessly.

Having said all this, we often have a bias toward not seeing the challenges and problems of an organization from the outside. Interviews are often not well-designed to showcase these problems to candidates. Each organization has its own difficulties and set of problems. While joining any organization, it's crucial to analyze and discover what they are and decide if the issues are the ones you want to work on.

Even good organizations often unintentionally hide the problems because sometimes they can't talk about them (business-sensitive) or want to convince the candidate to join the team.

SumUp didn't hide the challenges they have in the teams and has never been on a secret side of things. So, when I decided to join, I chose the problems I wanted to—and could—solve.

I had multiple offers, but SumUp was fast during interviews, addressed my concerns, took the time to talk to me each time I had questions, and explained their challenges. Considering everything together, I decided to join SumUp.

Today (01/11/2022) is my first day at SumUp. I'm excited to join this fantastic team. I hope to share more of my learnings and what I'm working on with all of you later on.

Reply via email | Reply via Mastodon | Comment

Mektup #43: Mektup is changing—Failures and Reflections

Tue, 01 Nov 2022 00:00:00 GMT

Hey friend,

Today, I want to reflect on the past ~2 years of Mektup and share some news with you. It's a bit longer than usual, but keep reading till the end.

TL;DR: Over time, I changed, and so did the Mektup. Now, Mektup will adapt to me and become more personal.

The very first Mektup hit your inbox on January 28, 2021, exactly at 10:03 CET. The newsletter Mektup did not begin as a new year's resolution. My new year's resolution was to learn to write. Mektup was an experiment and a venue for me to learn how to write and think better. The first Mektups included more links, some graphics, and fewer thoughts. They were "Here is what I've done" newsletters.

In the fourth issue, I removed section graphics, and in the fifth one, I started writing about a specific topic in each issue. Although the name Mektup (which means "letter" in Turkish) was born from a concept Anne Lamott mentions in her book Bird by Bird, I started writing fewer letters and more articles in each issue—hence, losing the goal of the newsletter.

The goal was to send casual letters to my friends about things I found interesting, things I learned, or things I was thinking about. I realized I was going off the track, and there was one reason.

There is a concept of "finding your niche" in the content creator world. I found myself searching for my niche in every Mektup I wrote. The content creator community hooked me and pulled me away from my way.

I sought to be more specific with the topics, my audience, and my writing. I focused on software engineers who are on the edge of becoming a leader. I looked for topics they needed to know and learn and tried to put one Mektup after another for them. You're one of these people, and I know how much stress you have in this leadership transitioning period. That's why I focused on helping you. With that focus, my list of possible topics to write about grew and became a giant that I could not complete in five years.

But (yes, there is a but), as my idea list grew, I forgot one crucial thing. While writing each Mektup focused on you, I forgot to focus on how I want to grow. While doubling down on helping you, I forgot to help myself.

Mektup evolved and changed me together with itself, without me realizing this change. When I started, I was transitioning from a software engineer role to engineering management. And I was thinking of becoming a content creator on the side. That's why I created a newsletter, and a podcast, gave talks and mentored people.

One thing I learned during my four months of sick leave for burnout (which was before all these efforts) was to know your limits and accept when you fail with your whole heart, as failure was yours from the beginning. So, this letter is an acceptance of my failure. Failure to find me, my goal, my voice, and my limits.

In every letter I wrote, it was not 100% me. I'm sorry. There were many pieces from me, but I tried to hold some of my thoughts for not going outside of the premise of the newsletter. Although it might be a good thing to write about a specific topic—a niche—it's not that great for me. I am a human, and I have more complex thoughts and life. Last two years, I put a blanket over my thoughts and hid them in my cabinet, where I stored all my other ideas.

Yet, some slipped through, such as Mektup #32 and Mektup #35. Looking at these now, I see them as signs. Guideposts. Lighthouses. I like these letters more. I want more of them.

So, "what's next?" you may ask.

Well, first things first: I don't want to be a content creator anymore. I'm done with that stage of my life. I am a failed content creator, and I acknowledge it. Just writing this down is a relief in itself. Finding it took me about two years, but I'm glad I had the journey.

Mektup will resume in the same cadence every two weeks on Tuesdays, though the content will change. It will include anything from my professional and personal life. It will articulate my thoughts, share my learnings in my professional life, and carry my personal journey with it.

So, you will read more about me from me. The topics will include—but won't be limited to—software engineering, leadership, productivity, software and hardware, consumer behaviors, writing, reading, podcasting, snowboarding, kayaking, hiking, coffee, books, sleep, physical and mental health, music, Berlin/Germany life, learning a new language, philosophy, psychology, and some other topics I find interesting.

I know there are a ton of different topics above, but I have many interests, and that makes me a human. Denying it would not be wise.

After the first issue of Mektup, I shared 110 blog posts and 21 podcast episodes. I learned to write and wrote to learn. I learned to talk in public and talked in public to learn. I will continue writing and podcasting and share them at the end of every Mektup.

I understand it may not be something for you. If it is not, the unsubscribe link is at the bottom of the email. I encourage you to click that link. I would be happy you're not following me because it's a conscious choice. Your time and your attention is the most important thing.

If you want to keep following my journey, I would be thrilled to know that you're following me with a conscious decision.

From now on, my goal will be to be myself and embrace my personality. And I hope it will be the same for you, my friend.

Talk to you soon in another Mektup,

Candost

*P.S. My all-time favorite author, Ursula K. Le Guin, on answering questions.*

*P.P.S. There are more changes in my life. I started a new job today!*

Reply via email | Reply via Mastodon | Comment

Behaviors run on Auto-pilot

Mon, 31 Oct 2022 00:00:00 GMT

As we evolved, we developed autopilot behaviors to eliminate suffering and details in our lives. We cannot care about every problem, so we—humans—have built systems in our brains to take shortcuts. These systems turned into issues and biases (also Kahneman talks about Heuristics). If we're not mindful of these autopilot behaviors, many of our day-to-day decisions will be false and even can lead to horrible situations. Once we understand how we behave in some instances, we can design our lives and make decisions to improve them. When Tim Ferriss wrote about a decision that removes hundreds of decisions, the idea was the same—using our brain's auto-pilot mechanism to develop helpful habits.

The same situation also happens when we switch careers. We need to break some of our habits and develop new ones, such as giving input when we shouldn't.

Related Note(s):
Source(s): How to Slow Down Time and Live Longer;
Resourced: One Decision That Removes Hundreds of Decisions;

Reply via email | Reply via Mastodon | Comment

Tell the other side what's been left out

Mon, 31 Oct 2022 00:00:00 GMT

While receiving a code review, we need to express ourselves and coach the other person. There is a reason for any decision we make. Sometimes, people don't see these reasons. Instead of insisting on being right, we need to tell the people what's been left out in the feedback/review we receive. If the decisions are not explicit (such as with ADRs), it's not easy to see implicit decisions even if the code is well written.

Related Note(s):
- 21: Efficient Code Review Process (The changes I wanted to do in one of my teams);
- Maximizing Personal Growth by Understanding Feedback You Get;
Source(s): Thanks for The Feedback by Douglas Stone & Sheila Heen

Reply via email | Reply via Mastodon | Comment

Be part of the conversation and also the manager while receiving feedback

Mon, 31 Oct 2022 00:00:00 GMT

Great communicators are both the managers and a part of the feedback conversations, especially when they receive feedback. They take steps back, unstuck the conversation, and give it a pause or a direction for the conversation. These people are better suited for facilitating the discussions and are likely to advance in their careers. They have the humility to admit how they contributed to the now-stuck conversation and can drive the conversation to a result.

Related Note(s):
Source(s): Thanks for The Feedback by Douglas Stone & Sheila Heen

Reply via email | Reply via Mastodon | Comment

Making decisions based on three groups

Sun, 30 Oct 2022 00:00:00 GMT

When an engineer gains more autonomy, their decisions have a greater impact and become more important. It's crucial to develop decision-making skills to make the best decision in various situations. Humans mostly belong to one of three different groups when making decisions: ethical reasoning (evil/good), following the tribe they belong to, and using mental models. Many software engineers stick to their tribes (often following what's hype at that moment) and destroy the growth advantage they have. Some engineers make decisions for ethical reasons. When engineers grow, they have to be aware of why they make a decision and understand their decisions' flaws and blind spots.

Related Note(s):

Reply via email | Reply via Mastodon | Comment

Passionate people drive work better

Sat, 29 Oct 2022 00:00:00 GMT

Although passion is not required, when we find passionate people, it's so much more rewarding to work with them. When people are motivated by what they do, they produce better work, are engaged, and collaborate better with others. They also influence and elevate others around them. As a result, the team is motivated and works toward achieving the goal faster and better.

Related Note(s):

Reply via email | Reply via Mastodon | Comment

Don't leave your best performers alone

Sat, 29 Oct 2022 00:00:00 GMT

When people perform well in their jobs, they earn autonomy. These people usually level up in their jobs. Some leaders neglect to take a look at these people's careers just because they are performing and don't want to break them, and they trust these employees. The manager starts to become absentee. Even though these people perform well in their jobs, they need more partners. Absentee managers are on the opposite side of micromanaging. We need balanced managers who can be partners with the best-performing employees, listen to their problems and have dedicated time with them, and even do the work together with them (even if it requires them to get their hands dirty). Otherwise, the best performers will feel lost, unguided, and uninformed.

Related Note(s):
Source(s): Radical Candor by Kim Scott

Reply via email | Reply via Mastodon | Comment

The More accidental complexity the less quality

Thu, 27 Oct 2022 00:00:00 GMT

When accidental complexity builds up, the quality of the systems reduces. I've also seen that engineers have a hard time clearly stating the problems.

Reply via email | Reply via Mastodon | Comment

Fault Tolerance & Resiliency

Tue, 25 Oct 2022 00:00:00 GMT

The systems that can tolerate the faults are called fault-tolerant or resilient. Fully reliable systems are like a dream we can never reach. There will always be a possibility of failure. An earthquake can happen, and the earth might explode. So, full reliability is not possible and not feasible. Therefore, our goal is to have resilient systems, not fully reliable systems.

Source(s): Designing Data-Intensive Applications by Martin Kleppmann

Reply via email | Reply via Mastodon | Comment

Mektup #42: How to Answer Hiring Manager Interview Questions

Tue, 18 Oct 2022 00:00:00 GMT

Hey friend,

In my previous letters, I wrote you about the growth path in an existing company, covering promotions, promotion expectations, and career frameworks for how to get there. One of the parts of our career journey I didn't touch yet is the interviews for a new job. In this letter, I wanted to talk about the STAR method you can use for your next hiring manager interview.

Before I get to the method, there is one aspect I need to write about first: what these hiring managers are looking for. What's their goal?

Hiring managers are often the managers of the team you'll join. As I have been a hiring manager for a while, I can list down the most common three criteria a hiring manager evaluates you. The below three are not the only ones; there are more they look for specific to the role you are applying for.

The first and the most obvious is, how do you fit into the current team structure, and can the team work with you? They direct questions according to the team they hire. They ask questions about conflicts, how you work with feedback, mistakes you've made, your learnings from them, and your collaboration approach.

Second, they look for your experience to understand the level you're in. Your leveling decision is not made only on the technical interviews. The technical part is ~40-45% of the job. It's fundamental, but there is the other half of the job you are expected to do. You might be very knowledgeable on the technical side because you worked and studied hard. How you leverage that technical side and your approach to work defines your level. They ask additional questions about mentoring, projects in which you had the lead role, initiatives you took, processes you built, and so on.

Last, can they support you while you're working together? Hiring managers don't only consider what they expect from you; they also think about how to support you. Because if they can't, you'll probably leave the company quickly and they have to start searching again. Their goal is to identify which skills you lack and need some support. Think about the last time you had an awful interview but passed it. That shows that the hiring manager was willing to and had time to support you.

According to your answers and how you give those answers, the hiring manager creates a risk and support portfolio. Their decision will be based on the amount of risk in hiring you. The risk portfolio is based on how likely you will be a strong team member, how long you will stay, and how much you will contribute to the business. The support portfolio is based on which areas you lack skills.

If you focus on drawing a clear risk and support portfolio, the result will be good for both sides. Sooo, how do you bring clarity to them?

That's where the STAR method comes in.

Let's have an example.

Think about the question: "Could you tell me about a mentoring you did before?" You can structure your answer with the STAR method to bring clarity.

Define the situation first. Then explain what your task was and what exactly you did—your actions. Last but not least, how your actions resulted.

Without the STAR method, I often hear answers like this:

When I mentor, I begin by understanding the person's level and what they need. I ask them questions. Once I know, we devise a plan together and meet weekly to stay on track and help the mentee with their struggles. Also, they reach out to me when they have problems they cannot solve.

There is a lot of ambiguity. Although the explanation gives some idea about how the person approaches mentoring, it says nothing about their prior experience. It sounds hypothetical. The hiring manager needs to ask a few more questions to uncover the hidden story.

Let's try answering by using the STAR method.

Situation: When I mentored a junior engineer in my ex-company, they needed to develop debugging skills. The engineer struggled to find cues for bugs and didn't know how to use tools correctly.

Task: My goal was to guide them when they struggled and purposely improve the challenges they worked on to step up in debugging.

Actions: To achieve this, I asked a few questions and watched them while debugging to understand how much they knew the tools and where they got stuck the most. After figuring it out, we created a step-by-step plan and a weekly one-one-one appointment. In each one-one-one meeting, we looked at where they faced problems, solved them together, and looked at the following week's task. During these meetings, I also give some recommendations.

Result: In three months, the mentee found out most issues without anyone's help and started helping others who struggled to debug our distributed systems. My mentee later gave a talk on a meetup about the debugging best practices of distributed systems and hosted a workshop in our company about improving the debug-ability of our services.

The ambiguity is gone. When you answer like this, it also sounds like you know what you're talking about. That's the beauty of using methods, frameworks, and mental models. They put your experience in a shape that is visible to others. The STAR method is no different. When you use it in behavioral interviews, it brings clarity and visibility.

On top, when you make your approach visible, the hiring manager has a better idea of which level you're in and can also understand where they can support you. Thus, it reduces the risk of hiring you—the decision point for a hiring manager. ;)

Although the method is helpful, it won't apply to every situation. If you have no experience in mentoring, simply saying, "I have no experience in mentoring, but I would approach it this way." is better than trying to create an imaginary case.

Until next time, keep your authenticity alive and prepare for interviews!

Candost

P.S. Do reverse interviews.

What I Published Over The Last Two Weeks

Goals and Existence

I wrote an essay about the goal of life, my life. Or the absence of it. I pursue two questions: How do we know we're on the right track? How can we ensure that we're progressing in the right direction?

Hidden Monoliths Affect The Software Design

This article is about hidden monoliths that I learned while reading Team Topologies. They are everywhere and affect the software system design. When the organization is aware of its software's environment, it can thrive. If not, it faces various challenges.

Encoding, Decoding, Schemas and Data Evolution

I continued reading the book Designing Data-Intensive Applications. Last week, I published my notes from the fourth chapter (read chapters 1, 2, and 3 here).

Reply via email | Reply via Mastodon | Comment

Decision-Making Strategies

Tue, 18 Oct 2022 00:00:00 GMT

Justifying the decisions is a complicated process. When we make any decision, there has to be a case we should justify. Charity put it greatly that if our internal decisions leak, we should be able to justify it well. If we can't, or we're ashamed of our decision, then the decision is wrong. Hence, asking ourselves a few simple questions while making decisions is a solid strategy to prevent unwanted results. We can simply ask ourselves, “Would I be able to justify the decision if it's leaked? Would I be ashamed of it? Am I comfortable with people knowing this decision?” Then we know which decision is wrong.

Related Note(s):
Source(s): Figuring out the wrong decision;

Reply via email | Reply via Mastodon | Comment

Goals and Existence

Mon, 17 Oct 2022 00:00:00 GMT

Many thoughts arrive at a point where we ponder what we want in life and how much it's unknown to us. Doesn't matter what we do, try, or think; it's almost impossible to find our wishes for the end of our life. Where do we want to be in the future while taking our last breaths?

Answering a question like that is almost impossible. We have no idea what we will see, live through, remember, and forget. The question is about one thing; it reduces all the factors and experiences into one parameter: a goal, The Goal.

And I have problems with that goal.

Having a life goal doesn't make that goal happen magically.

If we have a goal like "I want to be wealthy," then we may never reach that point and live a miserable life trying to reach it. Whatever we do today won't make us feel we achieved anything because our action does not result in today. The wealth will never be today, even if we are a billionaire.

If we have a goal like "Travel thirty countries," then once we're done, we're done. Yet, life goes on. When we reach a point, we get our reward, and it's done.

On the other hand, without any goals, we can focus on what to do every day—choosing our daily habits and routine. We define our daily lives and shape our paths while keeping the options open. In this carpe diem life, how do we define a long-term plan? Furthermore, how can we define our daily habits that result in the life we want in the end?

We rarely know what we want today. How can anyone know what they want in the long term? I only know what I like now, not tomorrow, and definitely not in a week.

Do you see the fundamental problem?

Let's say I have a goal; how will I know it will be what I want after three months? Meanwhile, if I have a daily habit, how can I ensure that it will result in something that I will want in three months? What if I waste my time on all these habits?

I may sound negative, but I'm not. I'm questioning.

A while ago, I abandoned all my goals. Having goals did not do better for me. At that time, I asked myself what would be my high-level goals so that I at least stay on track. Now, I'm questioning the existence of a track.

How would any track be possible and keep me on the way I want to go? At the same time, if I have no goal at all in my life, how can I prevent wasting my time on useless habits and routines? Do I have to have useful habits? Maybe healthy ones are a must. But I'm unsure about its usefulness. What is the definition of useful?

Do you follow what I'm saying? How can we define the usefulness of anything?

Is reading a book useful? What about a bad book that ends up as a waste of time for us?

Is playing an instrument useful? What about we stop playing after three months?

What about spending hours on social media like Instagram? How about we follow all useful and informative accounts on Instagram?

Do you see the problem? Who decides the usefulness of a thing?

If I watch YouTube for hours but only informative videos, did I do something useful or waste my time?

The same dilemma exists in goals. If we have worthwhile goals (specific or high-level ones), we will be unhappy right after we reach one and look to the next. If we have no goal at all, how can we decide which habits and routines we will build so that we will reach a point that will pay out as useful in the future?

You might say, "Candost, even if you stop the habit after six months, you still learn something." Yes, that's true.

But what if I keep doing it for twenty years—start and stop habits? What would you say then? You will see Candost, the master of none, reached nowhere and struggled to find the path of their life.

Do you recognize the problem? What is the way out of this? What am I missing?

I can't claim that I have (or will have) answers. I only have my questions. I don't think anyone has any answers.

Sometimes, I think, people—like you and me—avoid these questions. I went on a small quest to seek some answers.

On a warm sunny evening in the west of Turkey, I asked my father, "Did you have any time in your life in which you questioned your purpose or aim of your life?" He gave me an answer that was—and still is—mind-boggling. It was so simple, yet, shocking.

He put down the glass of rakı that he just took a big sip, reached to the glass of cold water to soften the rakı's strong taste, and looked at the garden next to where his chair stood. He said, "No, never, and ever. I had my wife and kids. I was, and still am, the happiest man in the world." He is retired, lives in a summer house, and turned 60 this year. He knew what he was talking about.

But my mind was confused after hearing about my father's aimless life. His goal was to raise his children as well-educated people who are good to society. I can't say if he reached his goal but this goal stroke me with another perspective.

What if all I'm feeling is the mechanism of human survival and reproduction? What if our instincts, which are evolved over thousands of years, say that our goal is reproduction, and if you have no kids, you will wander? What if the questions are not a cause but the result of our thousands of years old instincts?

I kept observing other people and asking them about their goals. The results are not surprising: many people who don't have kids have similar questions in their minds, while folks with kids have almost none of them (maybe due to lack of time or another reason that I can't see). Parents' life goals are often gathered around their children. If you want to test yourself, look around, ask any parent about their goals, and they will say something related to their children.

I can't stop thinking: if we don't have kids, is this our punishment?

I know I'm talking about different things, and you may wonder where I will go with all these thought lines. Where will all the questions land and be answered? Nowhere. That's not the goal.

Questions don't always need answers. Sometimes, they have to stay unanswered. Learning which question should be left out without an answer is another skill for me to learn.

“To learn which questions are unanswerable, and not to answer them: this skill is most needful in times of stress and darkness.” — Ursula K. Le Guin

Goals are a recurring theme I'm pondering and writing about. Complement this post with Growth with Systematic Bliss, A Life without Problems—The Happiness and What Hades Taught Me.

Reply via email | Reply via Mastodon | Comment

Energy Management at Work

Fri, 14 Oct 2022 00:00:00 GMT

Avoid snack work

Snack work: Doing side tasks like founding a book club (while you're under the stress of a high workload in your team) when it doesn't make sense.

Your energy levels are insufficient, and you cannot run the club sustainably. This type of work—snack work—requires low effort. That's why it's so attractive. But it also has a low impact. If you only eat snacks, it won't fulfill you. Snacks are just short-term solutions. Sometimes you have to have them, but you have to be careful. You don't want to find a book club, moderate other teams' retrospectives, and do your main work at the same time for long periods. You need to focus and manage your energy. You also have to reevaluate snack work all the time. If you receive a promotion, your snack work definition will also change.

Related Note(s):
Source(s):
- Reminiscing by Will Larson;
- The Best Startups Resist Snacks (& I’m Not Talking About Food);

Reply via email | Reply via Mastodon | Comment

Hidden Monoliths Affect the Software Design

Wed, 12 Oct 2022 00:00:00 GMT

One of the things I learned and enlightened while reading Team Topologies is there are hidden monoliths everywhere.

Many organizations try to develop fully distributed systems using microservices and have significant problems because they work either in the same office or time zone while using synchronous communication.

Conway's law says organizations will develop systems reflecting their communication structures.

If an organization uses a monolithic office or highly depends on sync communication like video calls, it's difficult for teams to design clear boundaries between systems.

If we extend Conway's law, we can say that whatever monolithic we have will impact our system design.

Be it a monolithic CI/CD, monolithic tech stack (org tech standards), monolithic time zone, monolithic way of communication (using video calls all the time), etc.

Also, I'm sure some organizations are aware of these. An organization can be in the same office but mindfully separate teams to prevent unnecessary communication.

These organizations make a conscious choice and deliberately take care of their systems by focusing on hidden structures that affect teams and infrastructure.

On the other hand, some organizations don't even have an office, work asynchronously, and yet, develop monolithic software (e.g., the old WordPress system).

If the organizations are aware of their hidden monoliths and work deliberately to alter disadvantages or extend advantages, they can create the software effectively.

Many problems occur when organizations don't even sense that their hidden structures affect their software design. They create a goal themselves (e.g., use microservices, use monolith, use domain-driven design, etc.) and follow their decision without the holistic picture.

The solution: we need to look around the (virtual) office, systems, and pipelines and analyze how they impact the software and team design. If we are destined to obey Conway's Law, how we design the environment in which our software will be developed and maintained will define our system design.

Reply via email | Reply via Mastodon | Comment

What to delegate?

Wed, 12 Oct 2022 00:00:00 GMT

Things to delegate:

Work that drains your energy.
Wherever the work is running, and not so relevant for you anymore.
Whenever the work is running and more operational work (in case you want to do more strategic work).

Related Note(s):
- 3c: Giving Ownership to People;

Reply via email | Reply via Mastodon | Comment

Who to delegate the work?

Wed, 12 Oct 2022 00:00:00 GMT

When deciding the person you're going to delegate the work, look for specific criteria and ask yourself a few questions:

How much time would you spend when you delegate?
How much time does this person require from you?
How bad can their decisions be, and how can they impact you and the business?
What are the results you expect after delegation?

Related Note(s):
- 3c3: Giving ownership to people by delegation;
Source(s): My mentor, in one of our one-one-one sessions, I asked him how I could decide to whom I would delegate the work.

Reply via email | Reply via Mastodon | Comment

The Teams that enable other teams

Tue, 11 Oct 2022 00:00:00 GMT

The most difficult part of facilitating interaction mode is to create an enabling team that consists of experts. Because experts rarely want to work as an enabler. However, I think staff engineers are the perfect solution for being in the enabling team. I actually think that they are a one-person enabling team. Some of them still build software but especially solver and architect archetypes are kind of in an enabling mode.

Source(s): Team Topologies by Matthew Skelton and Manuel Pais;

Reply via email | Reply via Mastodon | Comment

Facilitating Teams in Organizations

Tue, 11 Oct 2022 00:00:00 GMT

Having facilitating team interaction mode should be across the organization. I think Quality Engineering can work in this mode for some organizations for a certain period. They can coach other teams to increase the quality of the software. The same approach can be taken for DevOps to guide teams to improve their CI/CD pipelines at the beginning of the DevOps journey. This way, the organization gains the strength to build its tools.

Source(s): Team Topologies by Matthew Skelton and Manuel Pais;

Reply via email | Reply via Mastodon | Comment

Setting the environment for team interactions to work

Tue, 11 Oct 2022 00:00:00 GMT

For team interaction modes to work, managers have to work on creating the environment and consistently (and sometimes with big-bang changes, sometimes with deliberate actions) work on setting the expectations for the team. The managers should bring clarity and support people in their expected path. For example, if one team should work in facilitating interaction mode, the manager should work with individuals to improve their mentoring, coaching, and facilitation skills. Each interaction mode requires different skill sets, and the manager's job is to identify which skills are needed and support the individual growth.

Related Note(s):

Reply via email | Reply via Mastodon | Comment

Inverse Conway Maneuver gets help from team interaction modes and team types to succeed

Tue, 11 Oct 2022 00:00:00 GMT

Inverse Conway Maneuver doesn't work alone. Knowing team interaction modes and team types helps us use the Inverse Conway Maneuver to our advantage. As I'm not fully convinced that the Inverse Conway Maneuver will work, I cannot see how it can be implemented. Inverse Conway Maneuver can only work on high levels, and technical people often don't even have a seat on the table while designing teams. This situation can result in bad organization and, therefore, system design. When skilled and experienced software engineers are on the table, I can see this strategy working.

Related Note(s):
Source(s): Team Topologies by Matthew Skelton and Manuel Pais;

Reply via email | Reply via Mastodon | Comment

Team Design Rules

Tue, 11 Oct 2022 00:00:00 GMT

Designing Teams shouldn't be with instincts. Leaders should design frameworks to move their teams and define how they work, evolve, and succeed. While planning the organizational changes, leaders should also create team design rules to set the course of teams. The rules should answer questions like:

If two teams need to collaborate, how long should it be? What should be the next step after collaboration? What would be the expectations?

Related Note(s):
- 30a: Change is Inevitable;
Source(s): Team Topologies by Matthew Skelton and Manuel Pais;

Reply via email | Reply via Mastodon | Comment

Monoliths are everywhere

Mon, 10 Oct 2022 00:00:00 GMT

I used to think of system design as being formed by technical and communicational patterns. However, everything around software teams and technical infrastructure affects the system design: offices, team distribution, CI/CD, organizational technology standards, and best practices. Even when we want to build microservices while everyone is in the same office, we will produce different designs than when everyone is distributed across multiple offices or works remotely.

Related Note(s):
Source(s): Team Topologies by Matthew Skelton and Manuel Pais;

Reply via email | Reply via Mastodon | Comment

Team Interaction Modes

Mon, 10 Oct 2022 00:00:00 GMT

When organizations are poorly managed, usually, there is chaos between teams: either more interaction than necessary or no interaction at all where it needs to be. Clearly defining the expected interaction mode will provide clarity, and engineers will understand what is expected from the other team. In return, the organization will benefit by reducing cognitive load and unnecessary conversations in places where there is no need and increasing innovation by using close collaboration between teams where it needs to be.

Related Note(s):
Source(s): Team Topologies by Matthew Skelton and Manuel Pais;

Reply via email | Reply via Mastodon | Comment

Two teams shouldn't collaborate all the time

Mon, 10 Oct 2022 00:00:00 GMT

Sometimes, it looks like long-term collaboration is necessary between two teams that are both stream-aligned. But it doesn't fit into the collaboration team interaction mode framework (e.g., consumer and provider teams were meeting every week). Any friction between these teams should be avoided (if the goal is not discovery or innovation) because its cost will be high. I think organizations shouldn't have many teams in collaboration mode, although it is highly attractive to imagine collaborating teams closely.

Related Note(s):

Reply via email | Reply via Mastodon | Comment

Collaboration harms organizations

Mon, 10 Oct 2022 00:00:00 GMT

Organizations mistake collaboration as a good strategy and don't see its side effects. The effect of two teams collaborating on systems is sometimes invisible. Collaboration between two teams can enforce "great teamwork," and leaders can praise this style. Yet, when collaboration is not on purpose, it's more harmful to the company. It creates communication overhead, blurs the responsibility lines, and decreases transparency and clarity around ownership and responsibility.

Source(s): Team Topologies by Matthew Skelton and Manuel Pais;

Reply via email | Reply via Mastodon | Comment

How I think about X-As-A-Service Teams

Mon, 10 Oct 2022 00:00:00 GMT

Creating an X-as-a-service team communication mode has advantages and disadvantages. The biggest con I see is the operational cost of setting the team up. The forming stage requires deliberate actions and doing them consistently in a changing business environment. When the business doesn't think of the platform as a product (which often happens), the results are heartbreaking. The initial stage of the X-as-a-service team should be well-managed and supported by the organization.

Related Note(s):
- 3c: Giving Ownership to People;
- 19a: Knowns and Unknowns;
Source(s): Team Topologies by Matthew Skelton and Manuel Pais;

Reply via email | Reply via Mastodon | Comment

Separate Concerns to Relax the cognitive load by using complicated subsystem teams

Sun, 09 Oct 2022 00:00:00 GMT

Using Complicated Subsystem Teams separates the complicated part to reduce the cognitive load on stream-aligned teams. Separation of concerns and decoupling are fundamental techniques in software engineering. The key part and difficulty is the sustainability of a complicated subsystem team. When this team is formed by experts, it's difficult to refill if someone resigns.

Related Note(s):
Source(s): Team Topologies by Matthew Skelton and Manuel Pais;

Reply via email | Reply via Mastodon | Comment

Platform Teams

Sun, 09 Oct 2022 00:00:00 GMT

Getting the platform right is difficult because of the product pressure. Once the platform team works efficiently, it's fantastic to have because the team takes a lot of organizational burdens away from stream-aligned teams along with the cognitive load. Documentation is crucial to reduce the synchronous communication lines to prevent distractions. The platform's mission should be to increase the focus of its users and let them thrive. It will take time and a lot of effort, but the result is great.

Related Note(s):
Source(s): Team Topologies by Matthew Skelton and Manuel Pais

Reply via email | Reply via Mastodon | Comment

How to Use Platform teams In The Organization

Sun, 09 Oct 2022 00:00:00 GMT

Platform teams have a lot of organizational work besides designing and coding the platform. Without organizational work, they cannot function well. Organizations have to ensure that platforms' APIs are well-designed and documented. Their consumers should start using the platform without the platform team's input and continue doing so. The only interaction between the platform and its consumers should be around understanding what consumer teams need so that platform's roadmap will be shaped efficiently. For platform teams to succeed on all fronts, organizations should keep them as fundamental.

Related Note(s):

Reply via email | Reply via Mastodon | Comment

DDIA: Encoding, Decoding, Schemas, and Data Evolution in Databases

Fri, 07 Oct 2022 00:00:00 GMT

This article is part of my notes from Chapter 4 on Designing Data-Intensive Applications by Martin Kleppmann. You can read other chapter notes as well.

Chapter 1: Reliability, Scalability, and Maintainability in Distributed Applications
Chapter 2: Data Models and Query Languages
Chapter 3: Data Storage and Retrieval
Chapter 4: Encoding, Decoding, Schemas, and Data Evolution
Chapter 5: Data Replication
Chapter 6: Database Partitioning
Chapter 7: Transactions
Chapter 8: The Trouble with Distributed Systems
Chapter 9: Consistency and Consensus
Chapter 10: Batch Processing
Chapter 11: Stream Processing
Chapter 12: The Future of Data Systems

The previous chapter talked about data storage and different ways to store data. This chapter talks about schemas, encoding, and decoding.

When we look at relational databases, they have one schema defined at any point in time. Non-relational databases, on the other hand, have no schema defined; the data model can be different for each document for the same data in the application.

In both data storage models, the data never stays the same. The requirements and systems evolve, and data schema changes. When these changes happen, two concerns pop up: backward and forward compatibility.

Backward compatibility: new code can read the old data schema Forward compatibility: the old code can read the new data schema.

Some applications might need to support both at any time because they might use rolling upgrades or the clients have optional upgrades. These strategies force systems to be compatible both forward and backward.

Encoding Data

There are at least two data representations:

In memory data: Objects, structs, arrays, lists, etc. Optimized for efficient access and manipulation by CPU.
Self-contained bytes to transfer in-memory data to a file or over a network. As in-memory data uses pointers and they are useless while saving or sending data, we use encoding to convert data to bytes. Translation from in-memory to a byte sequence is called encoding (serialization), and the other way around is called decoding (deserialization).

Do not use language-specific (e.g., java.io.Serializable) formats to encode the data because they are inefficient, bad with versioning, tie you into a particular language, and create security problems like remote arbitrary code execution.

JSON, XML, and Their Binary Variants

The most common encoding formats are JSON and XML. Both are common and widely loved and hated. Each has its own pros and cons.

Encoding numbers is problematic in all encoding formats. JSON supports it but not for big numbers. It also does not have precision in floating-point numbers.

JSON and XML don't support sending binary data. People use base64 encoding and pass data as a string, which increases the data size by 33%.

Schema support is optional for both XML and JSON.

{
  "id": "unique-id",
  "key": "value",
  "foo": "bar",
  "number": 123
}

In binary variants of JSON and XML, we can get rid of empty spaces to reduce size. But the data still include field names because these binary variants don't prescribe a schema and use field names to match data with keys.

As long as people agree on the encoding format, it doesn't matter that much which one they choose. The difficulty is agreeing on anything in organizations.

Thrift and Protocol Buffers

Both Thrift and Protocol Buffers require schemas for encoding data. The encoded data doesn't include field names compared to JSON and XML. The exact encoding differs in Thrift and ProtoBuf.

Both use field tags and encode data using data types and lengths. Each encoding protocol differs in ways of encoding (using variable-length vs. fixed length for data, different bytes vs. merging field type and tag number into a single byte, etc.). The schemas include required or optional marks for data fields, but they are not encoded, only used as a routine check.

The same example in Thrift:

struct Request {
  1: required string id
  2: optional string key
  3: optional string foo
  4: optional i32 number
}

In ProtoBuf (similar to Thrift but indexes are at the end):

message Request {
  required string id = 1;
  optional string key = 2;
  optional int32 foo = 3;
  optional int32 number = 3;
}

Both have code-generation tools that generate classes for many programming languages from a schema definition.

Schema Evolution and Field Tags

Schemas eventually change. Using field tags correctly enables us to support forward and backward compatibility. For example, when removing a field, we cannot use the same field tag again to support forward compatibility. The same way goes for required fields. All new fields that come after the initial deployment must support backward compatibility. When we set ourselves some ground rules, we can easily support compatibility in both directions.

Thrift with introducing and removing new fields (same example):

struct Request {
  1: required string id
  2: optional string key
  // 3: optional string foo (removed because of a change in requirements)
  4: optional i32 number
  5: optional i32 new_number
}

Avro

Avro separates writer's and reader's schemas to offer flexibility, forward and backward compatibility, documentation, and code generation.

In the encoded data, Avro doesn't keep any field tags or names; thus, it reduces the size of the message. Avro uses the order of the data to match encoded data to decode schema (reader's schema).

While decoding, if the schemas are different, it compares the reader's and writer's schemas to match fields by looking at field names and types. When it cannot match, it uses default values. Reader's and writer's schemas don't have to match exactly; they have to be compatible.

After the data is decoded, the reader has access—and uses—the writer's schema. There are various ways we can provide the writer's schema to the reader. We can

Store all schemas by version in the database and return them at the beginning.
Include the schema version in the initial request header.
Include the version number at the beginning of each record so that the reader first looks up the schema by the version and decodes the rest of the data after.
Set the scheme version at the beginning of a connection and use that schema for the lifetime of the connection.

The Merits of Schemas

The schema-based encoding made the adaption of Thrift, ProtoBuf, and Avro faster. These days, there are a lot of tooling and features around them.

Binary encoding-based schemas are more compact than JSON and XML.

Overall, schemas provide up-to-date documentation. They allow us to check backward and forward compatibility before deploying any change and to generate client codes to type check in compile time.

Modes Of Dataflow

We talked about the process of dataflow—encoding, decoding—and how to offer mechanisms for dataflow. Now, it's time to talk about how we move data from one place to another and where we use encoding and decoding.

Dataflow Through Databases

Both backward and forward compatibility is required for databases. Because we often access the data we wrote by using the previous schema. We often read newer data with old code (e.g., during a rolling upgrade).

Migrating data is one strategy, but it is expensive, and we want to avoid it as much as possible. "Data outlives code" means we write data that might not be rewritten for years while writing new data every second. Also, we might take snapshots of data for backup and encode it with that latest schema, even though the database might include data written with different schemas.

Dataflow Through Services: REST and RPC

Using HTTP as an underlying protocol makes a service web service—even though it's not limited to the web. There are two approaches to web services: REST and SOAP.

REST (Representational State Transfer): It's not a protocol but a design philosophy. REST uses HTTP features, URLs, and simple data formats. There is no consensus on API versioning in RESTful APIs.

SOAP (Simple Object Access Protocol): XML-based protocol for making network API requests. It aims to be independent of HTTP. A SOAP web service uses Web Services Description Language (WSDL) to define the API. WDSL enables code generation.

SOAP users heavily rely on tooling, code generation, and IDEs, as the WDSL is not human-readable.

The Remote Procedure Call (RPC) model makes a network request look like a local function call. This approach is fundamentally flawed for various reasons:

Network requests are unpredictable (request or response may be lost),
Network request has a state that function call doesn't, which is returning without data (timeout),
We never know if a network request went through or not, so we need to build idempotency to handle network request failure cases,
Network request's time varies when compared to local call, which always executes at the same time wherever it is called,
You need encoding and decoding in network requests and responses.

The new generations of RPC frameworks are more explicit about these facts.

The common usage of RPC is for internal communication processes within an organization. REST is predominant for public APIs (also good for experimentation and debugging).

RPC servers and clients need to be deployed independently (update servers first, clients second; backward compatibility on requests, forward compatibility on responses).

Using RPC across organizational boundaries makes service compatibility harder. Compatibility must be maintained for a long time because the services often don't have any control over their clients and cannot force an upgrade.

Message-Passing Dataflow

In message-passing dataflow, the message is delivered in low latency and is not sent via a direct network connection but goes over a message broker that stores the messages temporarily. Asynchronous message-passing systems are somewhere between RPC and databases.

Message broker has certain advantages:

It improves system reliability because it acts as a buffer in downtime.
It automatically redelivers messages to crashed processes.
The sender doesn't need to know the service IP.
One message can be sent to multiple recipients.
Decouples the sender from the recipient.

The sender doesn't wait for the message to be delivered; the communication is one way.

Message Brokers

One process sends a message to a queue or topic, and the broker ensures the delivery of that message to one or more consumers. There can be any number of message producers and consumers on the same topic.

Message brokers don't enforce a data schema. Keeping encoding and decoding forward and backward compatible gives the flexibility to change publishers and consumers easily.

Reply via email | Reply via Mastodon | Comment

DDIA: What is Replication in Distributed Systems

Thu, 06 Oct 2022 09:53:52 GMT

This article is part of my notes from Chapter 5 on Designing Data-Intensive Applications by Martin Kleppmann. You can read other chapter notes as well.

Chapter 1: Reliability, Scalability, and Maintainability in Distributed Applications
Chapter 2: Data Models and Query Languages
Chapter 3: Data Storage and Retrieval
Chapter 4: Encoding, Decoding, Schemas, and Data Evolution
Chapter 5: Data Replication
Chapter 6: Database Partitioning
Chapter 7: Transactions
Chapter 8: The Trouble with Distributed Systems
Chapter 9: Consistency and Consensus
Chapter 10: Batch Processing
Chapter 11: Stream Processing
Chapter 12: The Future of Data Systems

Replication is keeping the copies of data between multiple machines that are connected via a network.

We replicate data to either serve users from the closest data center to reduce latency, allow the system to continue working if one part fails (to increase availability and fault tolerance), or scale the machines to serve more read requests to increase read throughput.

:::note 🧶 All the difficulties in replication are related to handling changes in replicated data. :::

In this chapter, we'll see leaders, followers, multiple-leader and leaderless systems, synchronous and asynchronous replications, problems in all these strategies, how to solve them, and the pros and cons of each system. We'll start with understanding the leader and follower, synchronous and asynchronous replication, and dive into three different strategies to replicate data using the leader-follower structure.

Leaders and Followers

A replica means a node that holds a copy of the database.

When there are multiple replicas, how do we ensure the data client writes copied to all replicas?

We assign one replica as a leader and distribute data from the leader to others—followers. In this setup, whenever a client wants to insert, update, or delete data, it goes to the leader, and the leader's job is to pass down that operation to follower replicas. Although the client is limited to talking to the leader for the write operations, it can read data either from the leader or any follower.

How does the leader effectively send the data changes to its followers?

Synchronous vs. Asynchronous Replication

A leader can send data changes to a follower either synchronously or asynchronously. There are pros and cons for each implementation. Database systems can also combine both approaches (a leader synchronously replicating to one follower while using asynchronous replication with others).

In fully synchronous replication, the write operation awaits the data replication to a follower to succeed. If any problem occurs during replication, the write operation returns a failure. In sync replication, the data will be available and durable in at least two nodes—leader and follower. If the leader fails, we can assign the synced follower as a new leader without the risk of losing data. However, if a follower slows down for any reason (like network latency), the leader will have to block all incoming write requests and can become unresponsive until the follower is back up again.

In fully asynchronous replication, there is no problem with waiting for followers in write operations and no blocking the clients. Writing to the leader returns a response without waiting for replication. But if the leader fails in the middle of a replication operation, we lose the data that's not replicated to followers. The data is not durable in the advantage of write availability.

When we consider the pros and cons of both replication strategies, we often combine async and sync (often called semi-synchronous): the leader synchronously replicates to one or two nodes and uses asynchronous replication with the rest of the followers.

Handling Node Outages

Follower Failure: Each follower keeps a log of data changes it applied before. When any follower fails and restarts, it can request new data changes from the leader by looking at its last logged data.

Leader failure: The leader's failure and assigning a new leader is called a failover. Failovers can be done manually or automatically. The automatic process looks like this:

Determine that the leader has failed.
Choose a new leader.
Reconfigure the system to use the new leader.

Albeit looking simple, the whole automatic process is fraught with possible problems:

What happens when the new leader doesn't receive all updates from the old leader (if async replication is used)?
- When the old leader rejoins, there may be conflicts. In that situation, we may discard the old leader's data fully, but it harms data durability.
Discarding data has more problems if that data is used in other systems and coordination (side effects).
What happens when two leaders are configured to be a leader (in certain fault scenarios, it's possible)? If both leaders accept writes and have no process of handling conflicts, it's dangerous. We may shut down one of them, but we have to be careful in designing that mechanism.
How can we define the right timeout to declare the leader has failed?

Now we know the sync and async replication and handling node outages. How can we add a new node to increase read throughput and fault tolerance?

How to Set Up A New Follower

Take a snapshot of the leader without blocking the writes.
Copy the snapshot to a new follower.
Request data changes from the leader since the snapshot is taken.
Process the data changes on the new follower. Then, the follower caught up.

Once we set up a new follower, it's time for it to receive data updates from the leader. That's done via replication logs.

Implementation of Replication Logs

Each time data is changed, the system replicates data by sending logs from leader to followers in one of the following ways:

Statement-based replication: Replicating every write statement (INSERT, UPDATE, DELETE, etc.) to followers. This method is problematic when there are nondeterministic functions in the statements (e.g., RAND() or NOW()), when statements use an auto-incrementing column (the order of statements has to be precise in this case), or statements have side effects (unless the side effects are deterministic).
Write-ahead log (WAL) shipping: We talked about WAL before with SSTables, LSM-trees, and B-Trees. The WAL is append-only, and the leader can send logs to follower replicas; then, the follower builds the exact same data structures as the leader has. WAL shipping is used by PostgreSQL and Oracle. The disadvantage is that it couples data to the storage engine as WAL operates at the byte level. Thus, upgrading storage engines to new versions can be problematic.
Logical (row-based) log replication: Similar to write-ahead logs, but to decouple storage engine logs and replication, a logical log is used. For a relational database, logical log records actions per row. These logs include all columns if a new row is inserted. If a row is deleted, they include enough information to identify the row. If the data is updated, logs include all (or only updated) columns of the row. The decoupling allows us to upgrade the storage engine when needed without much hassle.
Trigger-based replication: Predefined database replication methods are not enough when we want to customize replication to our use case. Databases offer write triggers for application developers to allow them to do something when a write occurs. App developers can register their codes that are automatically executed when any write action happens. Databases implement this method by logging the change to another table that can be read by an external process to replicate the data. Trigger-based replication is more error-prone and has greater overheads.

Now we know how the replication logs work, we need to understand the problems we face when there is a lag between leader and followers during the replication process and how to approach these problems.

Problems with Replication Lag

Using synchronous replication for all followers is not a great solution, as any small problem in replication (like a network lag) can block all write operations. On the other hand, asynchronous replication also has a tradeoff: in ideal scenarios, replication takes a fraction of a second, but when there is a network lag or any other issue, the replication takes much longer and creates replication lag.

When a client reads data both from the leader and a lagged follower at the same time, it will see differences in data. If a client waits for a follower to catch up and reads it, it will see updated data. That's why these systems (systems with replication lag) are called eventually consistent. The word "eventually" is intentionally vague because it's not certain how long the lag can be.

There are ways to overcome lag problems and/or shorten them.

Read-After-Write Consistency

If a client writes some data and immediately reads it, how can we ensure that it reads the latest version of the data? As write operations go to the leader and read goes to the follower, the replication lag may create inconsistency during these situations.

To solve the problem, the client can read from the leader right after updating the data. This strategy is known as read-after-write consistency (or read-your-writes).

There are a few ways to implement read-after-write consistency:

When the user wants to read something they may have modified, read it from the leader. For example, in social networks, a user can always read their own profile from the leader replica because only the user updates their profile, no one else. The user can read other profiles from the followers.
If most things in the app are editable by the user, use other criteria for the decision: for example, the last update time. If a user updated data in the last two seconds, use the leader replica while reading it.
Another strategy is saving the last timestamp user wrote something. During the next read operation, the system can then check the timestamp and read from the leader to reflect updates at least until that timestamp. There are more complications if a user accesses the data from multiple devices, but we won't get into it now.

Monotonic Reads

Replication lags sometimes cause moving backward in time: a user writes data and reads it from one replica with a lesser replication lag, then refreshes the screen and reads old data from a follower with a greater replication lag. The user sees new data and old data in sequence. Monotonic reads mean that the user won't see the old data after they have seen the new data. It's a lesser guarantee than strong consistency but stronger than eventual consistency. One way to implement this is to ensure the user always reads from the same replica.

Consistent Prefix Reads

Sometimes, data has causality, and the order of the write operations is crucial (like messages in a chat app); when different replicas are used in conversation, anomalies like broken message sequences can occur. Preventing these anomalies requires consistent prefix reads. This problem happens more in sharded databases. One solution is writing the causally related data to the same shard, but there are also some algorithms we can use. We'll talk about sharding (or partitioning) in the next chapter.

Solving Replication Lag

Replication lag is complex to handle in the application. In the application code, don't pretend the replication is synchronous when it's actually asynchronous.

Transactions are there to prevent complexity in the application. Their role is to provide stronger consistencies. The book dives into it in later chapters.

Multi-Leader Replication

In this model, we have more than one leader who accepts writes, and each leader also acts as a follower to the other leaders.

Avoid multi-leader replication if you can. The benefits rarely outweigh the drawbacks it has.

There are only certain situations where multi-leader configuration is reasonable:

Multi-datacenter operation: If the data needs to stay geographically close to users or the system needs to reduce the risk of an entire data center failure, choosing the closest data center as a leader and replicating writes to other data centers asynchronously makes sense (while having a single leader replica in each data center). This strategy increases the perceived performance and better tolerates data center outages and network problems(e.g., interruptions don't prevent writes). The downsides are conflicts and strategies to resolve them. Also, configuration pitfalls occur if there are auto-incrementing keys, triggers, etc.
Offline working clients: In theory, if a client works offline, each client becomes a leader because they keep data on their local system. Conflict resolution becomes a real problem because data synchronization can happen after hours, days, or even weeks. Mobile calendar apps are good examples.
Collaborative Editing: Think of apps like Miro or Google Docs. In this system, a user's change is applied to their local replica and asynchronously replicated to others. If the system doesn't maintain a lock on the database, it becomes multi-leader, and conflict resolution becomes a challenge. One strategy to keep conflicts minimum is having the unit of change tiny. For example, Google Docs uses a keystroke as a unit of change.

Handling Write Conflicts

Write conflicts are one of the big problems of multi-leader configuration. There are several ways to handle them:

Use synchronous conflict detection: Waiting for the data to be replicated to all replicas before telling the user the write operation is successful. This strategy causes losing the main advantage of multi-leader configuration: asynchronously and separately accepting writes in each replica.
Avoid conflicts: Designing the system to avoid conflicts in the beginning. For example, using only one data center for the same user whenever they write data avoid conflicts. Still, there should be mechanisms to handle when the user moves geographically and becomes closer to another data center.
Converge toward a consistent state: Here, the goal is to have the same data in each replication. To ensure that, between conflicting operations, we can choose one write operation as the final one. There are various strategies, such as giving each write operation a unique ID and choosing the last one, including assigning each replica ID and choosing the higher ID in conflicts, merging values together (e.g., concatenating), or recording conflict in a special data structure and handling it in the application later in time (e.g., via prompting the user).
Create custom resolution logic: Multi-leader replication tools allow us to write application code that runs in conflicts. We can use them to build our own logic.

Multi-Leader Replication Topologies

When there are more than two leaders, we have different replication strategies to use. Circular(one replica sends data to another in a circle), star (one replica sends data to all replicas), or all-to-all (all replicas send data to all other replicas) topologies are different ways to send data to other leaders.

The main problem of circular and star topologies is having a single point of failure.

All-to-all is the most used topology, and its challenge is causality. For example, when a client creates and immediately updates a value, these two write operations have to be received in sequence by other leaders. As the connection between leaders may vary, some leaders can fall behind and receive the update operation first. Yet, they cannot update a value that doesn't exist. Version Vectors technique can be used, but these conflict detection mechanisms are often poorly implemented in database systems.

Leaderless-Replication

The replication approaches we learned all had leaders. The leaderless systems have one difference: every node can accept writes. These systems are also called Dynamo-style databases. Also, in some of these systems, there can be a coordinator that is different than a leader.

The idea is simple (each node can accept write operation), but the problems are not. That's why instead of how implementing these systems, we will spend time understanding their challenges.

Writing to the Database When a Node Is Down

If one node is not available, what happens when we receive new writes from a client?

Clients read from multiple replicas at the same time to solve this problem. Also, version numbers are used for data so that clients can decide which data is the latest one by looking at its version number.

Another challenge is, what happens when this node comes back and has stale data?

There are two mechanisms to repair stale data.

One is read repair: whenever the client reads stale data from a node that is behind and up-to-date data from the other nodes, the client sends updated data to the node that was behind.

The other mechanism is the anti-entropy process: the system regularly checks the differences between nodes and updates stale data. The anti-entropy process doesn't care about the order of data; it just syncs nodes.

The read repair works well for values that are often read. The anti-entropy process is good for values that are rarely read. Both mechanisms improve durability.

How do we count a read or write operation as successful?

When there are n nodes, we focus on getting a successful response from a certain number of them. All requests are still sent to all nodes, but we await only a few of them to return success. In general, we want to ensure we get up-to-date data from at least one node in every read and update data in most nodes in every write.

We can formalize this.

If every write must be confirmed by w nodes to be considered successful, and we must query r nodes to get up-to-date data in an n node system, generally speaking, w + r > n should give us up-to-date reads.

For example, if we choose n as 5, we need to choose w and r as 3, so every time, we will wait for 3 nodes to succeed while writing or reading data. Even if writing to the remaining two nodes fails, we will have one node with up-to-date data. While reading, we'll have at least one node where we get updated data. So, one node will always overlap.

Reads and writes obey these rules are called quorum reads and quorum writes. A common choice is selecting n as an odd number and setting the w and r as w=r=(n+1)/2 (rounded up). Keep in mind that writes and reads are still sent to n replicas, but we only count r and w for how many nodes we wait for.

What are the limitations of Quorum Consistency?

If Sloppy Quorum (details below) is used, there is no longer guaranteed overlap between r nodes and w nodes.
When two concurrent writes happen, there are no guarantees which one will be the first (conflict resolution is required).
If a read is concurrent with a write, there is no guarantee for the read to return after the write (or up-to-date value).
If a write succeeds in fewer replicas than expected w, there is no rollback mechanism for updated nodes.
If a node with up-to-date data fails and a replica with a stale value is used for recovery, the w quorum condition can be broken.

Sloppy Quorums and Hinted Handoff

Sometimes, due to networks or any other issues, clients cannot reach the nodes to write data and cannot satisfy w + r > n to reach a quorum. A client can still reach a few nodes but not "home nodes" of data. In this case, database designers have a tradeoff: either return an error or write to available nodes that are not among n nodes that need to be written to. The latter case is called a sloppy quorum. Once the nodes come back, any writes in these temporary nodes are sent to the "home nodes," and this operation is called hinted handoff.

Detecting Concurrent Writes

There is no good database-level solution to solve conflicts that arise from concurrent writes. Application developers have to know and handle the conflicts in the application code. There are mechanisms that help them.

First, we need to understand what concurrent means, then we can define ground rules to solve conflicts.

If clients A and B write to a key simultaneously, we cannot tell which is first because there is no first—they are simultaneous. We can keep some identifiers like timestamps to define which write operation is the last one and use that one while discarding the rest. This strategy is called Last-Write-Wins (LWW). But it is problematic because of the challenges of clock synchronization between nodes (more details are in later chapters), and we lose data if we discard the rest of the data that is not the last.

We actually define concurrency differently: when two nodes are not aware of each other's write operation, they are concurrent. It's not directly related to timing and clocks. While replicating data, nodes eventually catch up (eventual consistency). While catching up, there can be some write operations to nodes that are behind. We count these write operations as concurrent even though they happened later in time, just because the node is not aware of another node's data.

We can use version numbers to solve conflicts. Each request to write data gets a new version number from the server, and clients send these version numbers back in each write request. So, the server can decide if the client has outdated data by looking at its version. Meanwhile, the server keeps older versions to perform merge operations. Also, applications can merge data: when it receives updated data, they can merge it with a new value they have and send it to the server together along with the version number they received from the server.

A client has to read a key before write. When a client reads a key, the server returns all values that are not overwritten with their latest version numbers. When the client merges values it received from the server and the value it owns, it sends back, and then, the server overwrites the values.

When a client wants to remove data, the system doesn't remove it but puts a delete marker that is often known as a tombstone. This way, no data is lost, but clients have to do some work.

This whole strategy is efficient for a single replica, but what about leaderless replicas?

We need to keep another version number for a replica as well and use it with the version number within the replica. The algorithm is the same as above, but this time each replica increments its own version number when a new write comes in and keeps track of the other replicas. A collection of version numbers from all replicas is called the version vector.

Reply via email | Reply via Mastodon | Comment

Mektup #41: One Thing At A Time: Multitasking for Software Engineers

Tue, 04 Oct 2022 00:00:00 GMT

Hey friend,

As a manager, I coach engineers at various seniority levels. Some of them have much more experience in the industry than me, some have a similar experience, and some are less experienced. Regardless of the experience levels, I often see similarities between each one of them. Today, I write you about one similarity I often observe: trying to multitask.

There is tons of research about multitasking (191k results on Google Scholar), and there is a common finding: people cannot perform two attention-demanding activities simultaneously. People like software engineers need focus, and context-switching harms their train of thought.

Every task comes with a cognitive load that must be absorbed and kept while on the task. The cognitive load is what makes software engineering difficult and context-switching problematic.

In management roles, the cognitive load is a bit lighter. Managers don't have to know every detail of the task, its technicalities, and its solution like software engineers. For managers, other factors like challenges, risks, clarity of requirements, and timeline are more important.

Juggling multiple things at a time is common between engineering managers and staff engineers. It's due to a lack of company focus, not having enough people, or high expectations for productivity. Most of these issues are not in our hands, but there is one thing we can do. Within the endless backlog of tasks, features, and meetings, we have to stay focused.

The common advice I give junior engineers is to take one task with you, which is split thoughtfully and doesn't entangle with any other tasks. Then create a small pull request (or merge request) that does one thing from end to end. Most juniors I've seen struggle to stick to the scope of the task and get it to the finish line.

When I became a manager, I forgot this advice myself and jumped into a lot of things and tried to do them simultaneously. Because similar to the junior engineers, I didn't know what I was supposed to do because I had no experience in management. There were tons of new things that I had to comprehend and figure out solutions for.

The same applies to staff engineers (at least for Architect and Right-Hand archetypes). Once senior engineers get a promotion, they must figure out many new things and how to become successful at their new job, which is often different from what they did until that time.

I was trying to achieve something between multiple tasks, projects, and people's problems and wishes, and my coaches recommended various strategies. They ranged from complicated Getting Things Done methodology to calendar management techniques, from delegation to learning how to say no. What they had in common was (and I wish I had seen it clearly at that time) to do one thing at a time. The exact same advice I give to engineers.

So, that is my recommendation for your whole life, independent from you being an engineer or manager. Stick to it, and you will achieve a lot.

Doing one thing at a time helps you focus on one just thing, do it well and finish it on time. It makes you reliable, trustworthy, and a problem-solver. When you do one thing well, you will also be surprised that you will have time for other things that need your partial attention.

When you're focused, nobody can pull you into side tracks. When they try, you kindly decline because focus demands saying no. Especially in leadership roles, you have to say no, decline meetings, and stay on track. I'll write in the future about these strategies, but for now, have a look at how many things you're trying to achieve. Are you multitasking? If you're, choose one topic and keep working on it until it's done.

Meanwhile, I don't recommend reducing all your projects, initiatives, or tasks to one and abandoning the rest. You'll have to learn how to run multiple things in parallel to have a greater impact. The point is to have only one of them in your focus and reduce context switching during the day and—if possible—during the week.

Choose your focus and keep pace with others slowly.

Give it a try, and let me know how it goes.

*P.S. If you don't know what to focus on next.*

What I Published Over The Last Two Weeks

Questioning vs. Asking

I wrote a short essay about the subtle difference between questioning and asking a question.

Data Storage and Retrieval

As you know from the last Mektup, I started reading the book Designing Data-Driven Applications. Last week, I published my notes from the third chapter (read chapters 1 and 2 here).

At the fundamental of any database, it stores data when we give it and retrieves data when we ask for it. We won't build a new database engine, but we roughly need to know how these operations work with hash indexes, LSM trees, SSTables, and B-Trees.

Reply via email | Reply via Mastodon | Comment

Questioning vs. Asking

Fri, 30 Sep 2022 00:00:00 GMT

These two words—questioning and asking—have different meanings, although both often refer to the same meaning.

When we question a person or a piece of work, we meet with resistance. Questioning judges, investigates or interrogates. It looks for gaps, expects a valid reason why there are gaps, and tells that there might be consequences.

In facing with resistance, we simply say, "I'm just asking!" trying to release some tension.

We don't say, "I'm just questioning!"

That's the nuance.

When asking (non-rhetorical questions), we have curiosity, we seek information purely to fill our knowledge gap. We ask because we want to learn.

That's why the advice for young professionals (e.g., junior software engineers) is "ask questions," not "question things." Although we want them to question the status quo, we expect them to ask first.

We may argue about both being the same if the intention is correct. I don't think so. Because the intention is invisible.

We don't see anyone's intention when they question us or ask us questions. When someone messages me, I read the message. I pay attention to the words they choose.

If we're in a conversation, the other side may make their intention somehow visible. Because we hear their voice. We observe their behavior and body language.

As long as they don't reflect their intentions in their tone, body language, behavior, or words, we hear them as either condescending or uninterested in learning how things are done.

If we say, "I'm just asking!" one more time, we know where we stand.

Now, I ask, are you questioning or asking a question?

If you're going to ask, ask. Don't question.

If you're going to question, first ask, then question.

Reply via email | Reply via Mastodon | Comment

DDIA: Data Storage and Retrieval

Fri, 23 Sep 2022 00:00:00 GMT

This article is part of my notes from Chapter 3 on Designing Data-Intensive Applications by Martin Kleppmann. You can read other chapter notes as well.

Chapter 1: Reliability, Scalability, and Maintainability in Distributed Applications
Chapter 2: Data Models and Query Languages
Chapter 3: Data Storage and Retrieval
Chapter 4: Encoding, Decoding, Schemas, and Data Evolution
Chapter 5: Data Replication
Chapter 6: Database Partitioning
Chapter 7: Transactions
Chapter 8: The Trouble with Distributed Systems
Chapter 9: Consistency and Consensus
Chapter 10: Batch Processing
Chapter 11: Stream Processing
Chapter 12: The Future of Data Systems

If we think about the fundamental of any database, we can think that it stores data when we give it, and retrieves data when we ask for it. Sure, we're probably not going to build a database engine, but we should know roughly how they fundamentally work so we can make an informed decision while choosing a database engine for our application.

To understand these fundamentals, we start looking at data structures that power our databases, such as hash indexes, LSM trees, SSTables, and B-Trees.

Data Structures That Power Our Database

Let's think of the simplest database that stores key-value pairs. We can have one function for retrieving an entry by searching the key and one function for saving the pair into a file. When there are a few key-value pairs, everything sounds good because when we search, we can go one by one and look for the key. Also, writing a new pair to the end of the file is not a problem at all.

However, the problem starts when our number of key-value pairs increases. Imagine going through all the keys in millions of key-value pairs one by one while searching for a key. That definitely is costly when we want to retrieve data, while it doesn't cost that much when we want to save it (if we keep writing data at the end of the file).

To solve this problem, we need a different data structure: index. While storing data, we keep some metadata on the side (index) that acts as a signpost that helps to find data. Adding and removing indexes don't affect the content of the database; it affects the query performance. Maintaining additional structure, of course, has an overhead.

Keeping indexes has a drawback on write performance because every write requires an additional operation to update the index. That's why databases don't index everything by default and require us to choose indexes manually.

There are multiple ways of indexing.

Hash Indexes

The most common kind of data we can index is key-value data. In the simplest indexing strategy, we can keep a hash map where every key is mapped to a byte offset. When we seek a key in the hash map, it gives the byte offset that tells the location of the data in the disk. Then, we can go to data in one disk I/O.

As we keep the hash map in the memory (RAM), we don't seek disk I/O for searching the data; finding the data will be fast. We only have one disk seek for any data we need. When we add new data, we add its location to the hash map.

But so far, whenever we add new data, we append its byte offset in the log file. As the hash map is on memory, our space is limited.

How do we avoid running out of space? One solution is to break the log into segments and close segments when it reaches a certain size and make writes to a new segment file. We can then perform compaction on these files.

We can also merge segment files during compaction. These operations can be done in a background thread, and we can still serve read requests from old segments until we're done. Meanwhile, write requests can go to a new segment file. As we have multiple segments, reading will start from the most recent segment file and go back until we find the key. As much as this looks simple, in reality, there are various challenges: file format, deleting records, crash recovery, partially written records, and concurrency control.

Having an append-only log turns out to be good compared to updating files in place for a few reasons:

Sequential write operations (append and segment) are faster than random writes.
Concurrency and data recovery after crashes are simpler if segment files are append-only and immutable.
Merging old segment files prevents fragmented data files.

Yet, there are limitations: hash table must fit into memory. If we have a very large number of keys, it doesn't work. Keeping a hash table on disk instead of memory doesn't solve the problem either because of the performance drawback of random access I/O on disk. The other limitation is inefficient range queries; we can't query keys in certain ranges.

That's where SSTables and LSM Trees jump in.

SSTables and LSM-Trees

In the hash index table, we recorded key-value pairs. Whenever there was new data, we appended it to the end of the file. Now, we make a small change and make the keys in the file always sorted instead of appending to the end. We call this format a Sorted String Table (SSTable), which has several advantages over hash index logs:

Merging segments is simpler—even with multiple key appearances—since the keys are sorted.
No need to keep an index of all keys in memory to find a key. If we know some of the offsets of other keys that are closer to the key we're searching for, we can narrow down our search to that range. We can then go to that range and scan our key there. We still need an in-memory index of certain keys, but it can be sparse. It's quicker to scan only a short offset range.
In SSTables, read requests scan over several key-value pairs in the requested range. Since we already do this, we can group these key-value pairs and compress them before writing to the disk.

How do we construct and maintain SSTables?

Maintaining a sorted order key value in memory is easier than on disk. We know some tree structures work well (AVL, red-black) where insertion is in any order, and reading is sorted.

In new writes, write to the in-memory balanced tree (memtable).
If the memtable is bigger than a threshold, write it to the disk as SSTable. SSTable becomes the most recent segment. During SSTable write, a new memtable is used for write operations.
While reading, start from memtable, then to recent disk segments.
Frequently run a merging and compaction process to maintain order.

This scheme suffers from one problem: if the database crashes, values in the memtable are lost. We can prevent it by keeping a separate log on the disk that we immediately append every new write (we can discard this log when the memtable is written out to SSTable). Storage engines that are based on this algorithm are often called as Log-Structured Merge (LSM) storage engines, and the indexing structure is called LSM-Tree. To increase the performance, storage engines use bloom filters to identify if a key exists or not. Engines also use size-tiered or leveled compaction to determine the timing and order of how SSTables are compacted and merged.

The LSM-tree idea (keeping a cascade of SSTables that are merged in the background) is powerful. Even when the dataset is bigger than available memory, it works well, supports range queries, and has high write-throughput.

B-Trees

The most widely used indexing structure is not log-structured indexes; it's the B-Tree.

B-Trees keep key values sorted by key. B-Tree breaks down data into fixed-size pages instead of variable-size segments.

Each page has a reference to be identified, and parent pages can refer to children with these references. The number of references to child pages in one page of the B-tree is called the branching factor. The B-tree always stays balanced. Elements of parent pages are ranges and references to child pages. This makes range queries easy to execute as well. Between two ranges in a parent, there is a reference to the child page that indicates keys between these ranges are inside the child.

Updating any value for an existing key is also easy. Search for the leaf page containing the key, and change the value. When we want to add a new key, find the page whose range encompasses the new key and add it there. If the new key causes overflow, split the page into two from the middle and update the parent to reflect new ranges. This algorithm keeps the tree always balanced. As a result, a B-tree with n number of keys always has a depth of O(logn).

When adding a new key, the overflow requires pages to be rewritten. The database can crash mid-way through this operation. A child page might become an orphan, or splitting pages might not be finished. How can we recover from there? To make B-Trees reliable, it's common to keep a write-ahead-log (WAL) as an append-only file. Before doing any operation on the tree, it has to be written to WAL.

Latches (lightweight locks) are also used to coordinate concurrent threads accessing and editing the tree so that threads don't see the tree in an inconsistent state.

Comparing B-Trees and LSM-Trees

Advantages of LSM-Trees	Disadvantages of LSM-Trees
A B-tree index writes data twice. Once to WAL and second to the tree.	Compaction can interfere with read & _write_s.
Log structured indexes write the data several times due to compaction and merge (write amplification)	The bigger the DB, the more disk bandwidth is required for compaction.
On average, LSM trees are better in write throughput than B-trees.	Need explicit monitoring of compaction and incoming writes. Sometimes compaction cannot keep up, and the database slows down.
LSM trees can be compressed better.	Log-structured storage engine has multiple copies of keys in different segments. In many databases, transaction isolation is done with locks on range keys.

There are other indexing structures that commonly use secondary indexes. These indexing structures store values within the index, use multi-column indexes, full-text search, and fuzzy indexes, and keep everything in memory.

Online Analytic Process (OLAP)

What we have talked about earlier doesn't work well for analytic and business intelligence queries which process larger amounts of data, and often they have been executed either one-off or once a day. While Online Transaction Processing systems (OLTP) reads a small number of records in each query, OLAP systems read in bulk and aggregate data. OLAP mainly uses bulk import or event streaming to write, while OLTP has low-latency writes in random access order.

The data itself is also very different; in OLTP, the data presents the current point in time, while in OLAP, the data is historical (events that happened at a certain point in time).

These differences demanded different approaches to data storage and data retrieval. OLAP systems use column-based storage instead of row-based (SQL-like) or document-based (NoSQL-like), or graph-based storage. Therefore their read patterns are also different.

In OLTP systems, the disk-seek time is often the bottleneck because the number of queries is high (even though the data they require is small). In OLAP systems, disk bandwidth is often the bottleneck because even though there are fewer queries that process data, they often are demanding, requiring a big chunk of data to be scanned quickly.

In OLTP, there are two schools of thought: log-structured school (only append to file and delete obsolete files) and update-in-place school (treats the disk as a fixed-size, e.g., B-trees). These indexing strategies don't work for OLAP systems. In OLAP systems, it's important to encode data in a compact way and minimize the amount of data that the query needs to read from the disk.

Reply via email | Reply via Mastodon | Comment

Mektup #40: Pros and Cons of Changing Tech Stacks

Wed, 21 Sep 2022 00:00:00 GMT

Lately, I had a conversation with an iOS developer who wants to change to the gaming industry and asked me how I switched my tech stack from iOS to the backend and my experience. Today, I will talk about the tech stack change, its effects on your career, advantages, and disadvantages you will get.

In short,

Advantages	Disadvantages
Gaining technical breadth	Losing technical depth
New and transferred skills	Low-skill evaluation
Higher compensation in long-term	Lower compensation in short-term
Fresh perspective	Short-term stress
Always having a backdoor

On top of these, there is a key difference between switching and sticking to a tech stack that is neither an advantage nor a disadvantage:

If you stay in one tech stack, your career progress toward more of a tech lead; if you switch, you progress towards more of an architect or manager.

How these pros/cons play out will differ for specific tech stacks and companies. But these are the most common ones that encompass various tech stack changes.

Let's dive into the advantages and disadvantages.

Technical Breadth vs. Technical Depth

I wrote about the difference in a previous Mektup, and I'm not going to go into details here. When switching tech stack, technical depth (expertise in one area) loses its strength. The moment you stop working in one tech stack, the knowledge gap starts to build. On the other hand, when you switch to another stack, you can still follow trends and novel features in your previous tech stack. Switching tech stack helps to build technical breadth (broad area of knowledge). While gaining new skills, you can stay up-to-date with your previous ones.

New and transferred skills

When you switch tech stacks, it's not like you lose all your knowledge in one day. You may stop using specific knowledge daily but transfer most of what you have learned. The fundamentals of software engineering and business are transferrable. Although how you work in a team might differ, soft skills and work processes are also often similar—or at least adaptable.

Career progression

When you change your tech stack, you broaden your horizon. Working on one stack keeps you on track for tech lead-like roles where your expertise in one topic is needed the most and the enormous impact you can have.

When you have worked on multiple stacks, you progress towards architect-like roles where your technical breadth is more appreciated and expected. I wrote on a previous Mektup and talked on my podcast about expectations from software architects; check them out for more details.

When we think about managerial roles, it's up to the company's expectations. There are companies where managers are experts in one topic, and also there are companies where managers are expected to have more technical breadth than depth. So, both tracks can end up in management roles.

Impact on Compensation

Let's address the elephant in the room—money. The company in which you're changing the stack will play a critical role here. If you're joining a big company like Amazon, your leveling will be lower than your expertise if you're changing tech stack by joining Amazon. I had a friend who got lower level because they joined a team that was not working in their expertise area.

On the other hand, if you're staying in the same company, you may negotiate. I had a friend who did the change and did not have an impact on the compensation. The possible scenario is you won't get any raise for another year, and if you're up for promotion, changing the tech stack will probably delay it.

Long- vs. Short-term Impact

When switching tech stack, you're making a move for your long-term career. It gives you new perspectives that will broaden your horizon in the long run. Yet, in the short term, it causes stress. In the short term, you must put extra effort into catching up and becoming proficient in the new tech stack. Simply put, you will become a newbie again. Some folks don't like this feeling, but I love it. Feeling stupid and learning something I didn't know amazes me and drives me to put in extra effort in the short term.

Can you go back? And if you go back, how will it be perceived?

In my first attempt to switch to a new tech stack, I worked on the backend after working on iOS. Six months later, I returned to iOS by changing companies. Although I didn't enjoy my initial backend experience, it gave me a new perspective and made me a better developer. I improved not only my technical skills but also my communication and empathy skills toward backend engineers. Working with backend folks became much easier, and everyone was happier.

So, returning is the option you will always have, and people will perceive you as a better engineer when you return. In case you have a chance to work on a different tech stack, I highly recommend giving it a try.

We had a live stream about generalist engineering where we talked about switching tech stacks often in detail. You can watch the recording here or listen to it in any podcast app here.

— Candost

P.S. Switching tech stack positively impacts your software architecture design skills.

Reply via email | Reply via Mastodon | Comment

The Real Difficulty of Engineering Leadership is Not What They Say

Mon, 12 Sep 2022 00:00:00 GMT

For a while, I've been thinking about what makes leadership difficult and why it challenges me—and others—that much. Before becoming a manager, I had a few discussions with some leaders to figure out the difficulties. I asked them what was their biggest challenge after they became a manager. The answers varied: context switching, stakeholder management, lack of focus time, prioritization, leading people to get things done, and a few others. Although I faced these common leadership challenges after becoming a manager, I realized that all of them had one greater difficulty behind: learning to let go.

Before becoming a leader, our life was focused on telling what should be done, giving input on a problem to solve, getting our ideas in public, and applying what we've learned. We got many—small or big—rewards for expressing our thoughts and executing ideas. Until the promotion to management, we were expected to give input on projects, and even we may have received a promotion for our execution work and thus became a manager.

The moment after the promotion, the tables turn. Many managers don't realize this moment or can't quite figure out what to change. The difficulty after the promotion is to alter our behavior which is shaped as a result of what we have been rewarded for years. In most situations, we have to listen, not give input. We have to ask questions, not give answers. Even when we know the solution, we must let others figure it out on their own and reward them when they do. That's what I've been struggling with for a while.

I am known for getting things done. For years, when I had a task, I pursued it to the end. Anyone working with me gave the same feedback: give me the job and forget about it; it will be done. Now, as a leader, it doesn't work as it used to. I can't bring the job to an end, even if I know how to do it. Not only do I have to guide, coach, mentor, or influence people to get things done, I must stay silent, listen, and ask questions instead of giving input when team members are trying to figure out a solution. As an engineer, I've been providing solutions for years, and I developed the behavioral patterns to share what I think is correct, execute work, and get instant rewards. As a leader, staying silent so others can create these behavioral patterns is utterly backbreaking. And this challenge doesn't stop with remaining silent.

Let's take delegating tasks as an example: the formal version of letting others do the job. Until leadership or senior roles, I have got a task that was mine until the end. I implemented, tested, published, followed up, and did more similar things. In a leadership position, it's about creating an initiative, starting the execution, pulling myself back, and giving it to someone so they can grow. In general, this behavior gives the leader time to work on more impactful and strategic work. It sounds simple and effective in theory, but doing it is challenging. Because often, the initiatives we—leaders—kick off easily become our baby, and handing it over to someone else turns out to be not easy. Yet, we somehow have to let it go. We must learn to let it go.

We are rewarded for years because we were great at what we did. Now, accepting the new role and letting others become the best at what we have done for years is challenging. Yet, it is the only way. Effective leadership *requires asking questions and not giving answers—especially when there is no question*. It demands staying silent—even when we know how to solve a problem—and guiding others to find the right solution without telling them the solution. I'm not saying that we should always stay silent; leaders need or have to know when to stay silent.

One part of letting things go doesn't require staying silent—contrary, it demands to be vocal. When I was a senior engineer, I gave inputs on the projects and explained how complex or easy to implement they were. I asked questions to figure out the priority of a feature or task. Although I was involved in prioritization discussions—and again gave my input—my focus was still on the execution. The prioritization decision was always on the "leadership role" or function of the project or team. After I became a manager, I learned that prioritization skill doesn't develop easily. I tried to implement the same good old friend letting things go strategy—staying silent and asking questions—and failed miserably.

I learned that prioritization demands letting projects/features/tasks go, not giving input. It involves consistently saying no and encouraging to give input as a manager. We can't solve every problem, implement every feature, plan every project, or tackle every organizational challenge. That's why we have to say no to good things to be able to say yes to great things. When we do, we have to explain why we say no and give constructive input about how and when the thing can be done. Simply saying no doesn't work; I tried. Our input as a manager is crucial and has to be clear while we're letting some work go.

The difference between Maker's vs. Manager's Schedule was the actual definition of why I lack focus time. I read that post before I become a manager. So, I knew what I was getting in. During my first few months as a manager, I indeed struggled to find focus time, and I'm still not in a place where I was as a software engineer and will never be. However, when I experimented with delegating work and started lettings things go or saying "No" to various things, my focus time increased. Eventually, letting things go and leading others to do the work improved my focus.

Letting things go is the underlying reason for many other challenges leaders face: lack of focus time, micromanagement, not getting things done, failure to grow others, wrong prioritization, and more. I had managers who always gave input and got their way implemented. I also had managers who stayed silent in the wrong place and failed to say no consistently. Now, I realize they just kept what they have learned over the years as engineers and did not change their behavioral patterns after getting a promotion. They were not bad managers, but also not great ones. They were not effective and couldn't unleash their potential. Now, I'm on the same train, trying to unleash my potential. It's a difficult journey, but worth a try.^[Recently, I was listening to Marshall Goldsmith on The Knowledge Project podcast, where he talked about the essentials of leadership. He mentioned a simple strategy to overcome leadership challenges, and that's what I will try for a while. Wherever I want to say something, I will take a breath and ask myself: does it worth saying what I'm going to say? If the answer is a no, I will stay silent or only ask questions. If it's a yes, then I'll give my input.] Will I succeed? I'm not seeking an answer to this question anymore. I had let it go. Time and people will tell, not me.

Reply via email | Reply via Mastodon | Comment

Mektup #39: How I got a promotion offer from another company

Tue, 06 Sep 2022 00:00:00 GMT

I was thrilled when I received an email from a company—let's call them Acme Inc.—to lead a team of six engineers, including mobile app developers, reverse engineers, and a QA specialist. Although I'm happy that I took the counteroffer my company gave me at that time, I want to finish the story I started in the last Mektup.

During the interviews, I had a technical challenge and leadership, team, and hiring manager interviews—pretty much the common interviews for that level. After I got the offer, I had a reverse interview to ask my questions about the team, challenges, company, and manager.

But everything started a long time before the interviews. I self-studied leadership, read many books and articles, and took responsibilities that taught me how to influence others without authority—a skill every engineer has to learn at the beginning of their careers but most overlook it.

:::note 💫 Study leadership to learn how to act in certain situations and how to influence others without authority. :::

By the time I started interviewing for leading roles, I had been in the industry for 6-7 years and mainly worked as an iOS engineer and partially as a backend engineer. Although my focus was on coding most of the time, the last 1-2 years went with leading projects, dividing the project into sed chunks and tasks so that people could just grab the next task and go focus on it.

That was the first step towards leadership and what companies look for from leaders: manage a project. I know, I know we have a project manager, and it's their job. Yet, you shouldn't leave them alone and give them a hand or two.

:::note 💫 Manage a project to learn the dynamics of task prioritization, stakeholder communication, and staff planning. You'll also understand the customer perspective fully. :::

After getting used to projects (with successful and failed ones) and how to manage them, I began to have a holistic picture of the work. I learned prioritization, trade-offs, and influencing others without being a manager (someone with authority).

At that point, I realized that I like helping others do their jobs in the best way possible, prioritizing work according to business needs, the number of work people has, and the sustainability of the project. Once I realized which path lies in front of me—engineering management or, more broadly, people management—I went all in. I talked with my manager, and we worked towards growing my career in that direction by finding opportunities and creating initiatives to sharpen my leadership skills and learn new ones. The RFC process that I worked on was the first cross-team initiative to solve the feedback problem.

:::note 💫 Talk with your manager and work with them to grow your career in the direction you want. Even though you might not get a promotion, they will help you to learn a lot of stuff that you will need later. :::

I started having one-on-ones with my peers and tried solving some of their problems.

Later on, I changed teams because my team was dissolved 🤷. It was a setback.

In my new team, I talked with my new manager and started taking over organizational tasks and career development work for other team members. I held workshops for building the team culture (where there were a ton of problems in the team).

:::note 💫 Ask your manager to delegate some of their work to you. Learning on the job is always better than studying and not practicing it. :::

Meanwhile, I was a backend engineer coding in a project. All the extra responsibilities I took were aligned with my career goals, team's, and business's needs. Also, nobody wanted to tackle the problems I wanted to solve. Every other engineer was focused on technical problems, which were a lot. Later, my efforts helped the team to become a high-performing team.

:::note 💫 There are always boring problems that nobody wants to tackle. These problems are often a real gem. If you can solve them, the reward is always bigger. :::

All of these initiatives and study on the side helped me solve complex team and staff problems and the career growth challenges of others. In the interviews for engineering manager (EM), I already have some experience that I could talk about.

Of course, it was apparent that I didn't have much manager experience because my manager was accountable for all the things I did. Although I had a lot of freedom, being the accountable and responsible person for a piece of work is different than just doing the work from start to end. It's not the authority that has the weight but the lack of official responsibilities (e.g., having performance review feedback of engineers).

As it is apparent that I never had a direct reporting person at that point, I was still knowledgeable to answer many questions using the STAR method during interviews: I talked with my real-life experience.

Acme Inc. was okay with hiring junior EMs because they had the time and resources to train the managers. There are a lot of companies that are okay with hiring junior EMs. Your job is finding them (and theirs is finding you) and applying to open positions.

Still, it's easier to get a promotion in your current company. But if they are unwilling to give it to you or have no positions, don't lose that much time and look for something else.

It is easier to get a promotion in your current company because usually, instead of hiring a junior EM, they can promote someone internally. Companies only hire externally when there is no one in the company who wants to become an EM or when that person has no experience at all.

:::note 💫 Ask yourself, "Why should they hire you instead of promoting someone from inside of the company?" and find good answers. :::

Lately, finding good EMs has become challenging. Before, management was the only way to get a promotion. These days I see more and more folks choosing the Individual Contributor (IC) track over management because of the availability of the IC track career. As great as having an IC track, the management track has become lonelier, and the competition for EM roles is decreasing. That's why I see a bigger trend coming up for hiring junior EMs and training them. Also, many good EMs are switching to the IC track.

As finding new EMs has become challenging, applying for these positions might be worth your time. You never know what kind of leader they are looking for before applying. Even if they require some years of experience in the requirements, still go for it. I've never seen a person checking every item in the requirements list. Companies make sacrifices, and hiring someone will always have trade-offs and risks. It's up to the company to decide which trade-off they want to tackle.

In the worst-case scenario, you will improve your interviewing skills.

Reply via email | Reply via Mastodon | Comment

DDIA: Data Models and Query Languages

Sun, 04 Sep 2022 00:00:00 GMT

This article is part of my notes from Chapter 2 on Designing Data-Intensive Applications by Martin Kleppmann. You can read other chapter notes as well.

Chapter 1: Reliability, Scalability, and Maintainability in Distributed Applications
Chapter 2: Data Models and Query Languages
Chapter 3: Data Storage and Retrieval
Chapter 4: Encoding, Decoding, Schemas, and Data Evolution
Chapter 5: Data Replication
Chapter 6: Database Partitioning
Chapter 7: Transactions
Chapter 8: The Trouble with Distributed Systems
Chapter 9: Consistency and Consensus
Chapter 10: Batch Processing
Chapter 11: Stream Processing
Chapter 12: The Future of Data Systems

Data modeling might be one of the most difficult processes of software engineering. On top of that, data presentations differ for application developers from hardware engineers. Within these difficulties, we must learn how data modeling approaches work to choose the best one for our problem.

What is a Data Model?

Data modeling is creating a simplified data representation of our application's data from the real-world or other services we use and defining how this data flows through the application by using a database management system.

There are two schools for data modeling. Both of them have advantages and disadvantages. As it's the same for everything in software engineering, the modeling approach of choice will depend on our use case.

Relational Data Model vs. Document Data Model

Structured Query Language (SQL) is the best-known data query language based on the relational model that was proposed in 1970 by Edgar Codd. It has been here for decades, and no other data models have overthrown its dominance. NoSQL is the latest attempt to do that and was born because of the need for scalability with very large datasets, people looking for open-source and free software instead of commercial databases, businesses' need for specialized query operations, and the need for more dynamic and expressive data models.

Yet, it looks like SQL is not going away and will stay together with non-relational databases.

The Root Problem of Data Modeling: The Object-Relation Mismatch

A lot of applications are written with object-oriented programming. When these applications want to store data in a relational database, they require a translation layer because data models between the application (object or class definitions) and the database (tables defined by schemas) don't match. This mismatch is called impedance mismatch (borrowed from electrical engineering).

When we consider a social profile as an example (LinkedIn), we can store profile data in relational databases. Although we will have one field for a person's name and/or surname, one person may have multiple jobs and educations that we have to store somehow. Earlier versions of SQL used foreign keys to connect separate tables (education table, profile table, job positions table, etc.). We may use the same approach or use newer versions that allow storing multiple entries in one row using structured data types (XML, JSON) while keeping the querying option.

We can also encode the data in JSON/XML and store it in a text column and let the application handle its data structure and content. For applications like LinkedIn, JSON representation is better. It has a better locality than the multi-table schema and makes the one-to-many structure (one person → multiple jobs, education, etc.) explicit.

Locality: all data is in one place and accessible via a single query.

Even though JSON is good for one-to-many, there are many-to-many relationships that we have to consider.

Many-to-One and Many-to-Many Relationships

Applications are evolving and changing day by day. The initial data model of applications often does not fit into the future requirement. For example, think about Facebook and city and institution names. Initially, we might save the city as a string in the profile database. But how can we update the city name in every profile it's used? City names can change due to a political change, or Facebook might give every city a page. In these cases, updating the city string to ID will be the solution.

We can remove duplications and replace them with IDs that refer to other rows in other tables. This operation is called normalization.

When IDs are used, the relational databases can run join operations easily to collect data across multiple databases.

On the other hand, document databases often don't support join operations. This operation is moved to the application. The application has to emulate join operations by making multiple queries to the database.

When considering different types of relationships, relational and document-based databases have pros and cons.

Relational Databases vs. Document Databases: Pros and Cons

Relational Databases	Document Databases
Join operations and references support many-to-one and many-to-many relationships nicely. However, if the application doesn't have these relationships a lot, it might not need a relational database.	It's not possible to refer directly to the nested items. Yet, if there is no deep nesting, document databases are usually fine. The poor support for `join`s may or may not be a problem. It depends on our application. If there are a lot of many-to-one or many-to-many relationships, the document model is not that great because these cases need to be handled by the application.
Shema-on-write: Enforcing schema on write operations is similar to static type checking (compile-time) in programming languages. Ensures data schema is the same, and nobody can put broken data into the database. When we want to change data format, we have to perform a migration. (e.g., initially having one field for name and surname and separating it later). These schema changes (migrations) might be slow depending on which database is used (MySQL, PostgreSQL, etc.). Some databases might even require downtime.	Schema-on-read: Seeking schema on read is similar to dynamic type checking (run-time). This operation moves schema constraint to application. When we want to change the data format, we have to support old documents in the application code and start using the new format in the new documents.
Advantageous when data is homogeneous because it enforces a mechanism and documents it (with explicit schemas).	If the data is heterogeneous, it's advantageous. No explicit schema makes it adaptable.
Storage locality is supported in some databases (e.g., Spanner, Oracle, Big table) but in different strategies to group related data together.	Provides data locality, which can be powerful or harmful. If the document is big, the performance gets worse. When we need a small section of a document, we have to read the whole document. Rule of thumb: keep documents fairly small & avoid writes that increase the document size.

Overall relational databases have document features that allow storing and performing join operations on XML and JSON. Also, document databases (e.g., RethinkDB, MongoDB) have relational-like joins that are similar to relational databases. Although these join operations are slow—as they require a network round trip—both relational and non-relational approaches are becoming more similar and adapting good sides from each other. These feature intersections are good for the future of databases.

Query Languages: Imperative vs. Declarative

Most programming languages are imperative: we define how the algorithm will work step by step. We tell the computer line by line what it should do.

On the other side, SQL is a declarative language: we define what we want in the end, the criteria that the result should fit into, and how we want the data to be transformed. We don't get into defining the algorithm or steps that the database engine needs to execute in order. Our focus is on the end result.

Declarative languages—such as SQL—hide the implementation details. When we write an SQL query, it's up to the query optimizer to decide which operations the query needs and the algorithm it will use during execution. As we don't care how the data is retrieved from the storage, the query optimizer can decide the order of operations as well.

This abstraction (asking for the end result) allows the database to do behind the scene improvements. If memory optimization is needed, the database can move data from one place to another without breaking any query written before. As we define the order of data we want in the query, we don't know how the data is stored. If we were using an imperative style, the database couldn't do that because we would need to write the query according to how the data is stored.

Lastly, declarative languages have the advantage of running tasks in parallel. They have a better chance for parallelization because we only define the resulting pattern, not the algorithm, to determine the results. The query optimizer can run tasks in parallel if it needs. In imperative languages, parallelization is more problematic because we define the order of operations one by one.

"The fact that SQL is more limited in functionality gives the database much more room for automatic optimizations."

MapReduce Querying

MapReduce is used in document-based databases. It is a lower-level programming model than SQL. MapReduce supports using Javascript in the middle of a query, which is great but writing carefully designed Javascript functions is not that easy. There are also limitations (like in MongoDB, map and reduce functions have to be pure functions). That's why MongoDB added an "aggregation pipeline" to support a declarative approach.

Graph-Like Data Models and Graph Query Languages

Relational databases support many-to-many relations already, but when it's too much, it becomes challenging to manage, connect, and query data. When many-to-many relationships are common in the application, graph-like data models are better solutions.

A graph has two object types: vertices (also called nodes, entities) and edges (also called relationships, arcs).

There are two graph models to structure and query data: the property graph model and the triple-store graph model.

Property Graphs

Each vertex has a unique ID, set of outgoing edges, set of incoming edges, and collection of properties (key-value pairs).

Each edge has a unique ID, the vertex the edge starts (tail), the vertex the edge ends (head), a label to describe the relationship between two vertices, and a collection of properties (key-value pairs).

There is no schema restriction in this model. We can have any vertex connecting to others for anything. We can also traverse the graph because we know any vertex's incoming and outgoing edges. Additionally, labels give the flexibility to define the relationship between two vertices.

This model gives us flexibility and evolvability. When we need to extend our features in the application, we keep adding new data to the existing graph. However, the graph data store easily becomes a mess. We need to be careful with a single graph data store.

Triple-Stores

In Triple-Stores, the data is stored in three-part statements: (subject,predicate,object). This model is mainly equivalent to the property-graph model. The subject is equivalent to the vertex. The object is one of two things: a value in a primitive data type or another vertex. When it's another vertex, the predicate is on the edge of the graph, the subject is the tail, and the object is the head.

Examples: (alice,age,23), (alice,marriedTo,bob)

The Foundation: Datalog

The data model is similar to triple-stores but generalized a bit.

(subject,predicate,object) becomes predicate(subject, object)

We can also define rules to tell the database new predicates on top of the data's predicates. It's similar to functions. These aren't triples in the database. They are derived from data or other rules. Rules can call others or themselves recursively.

Datalog is a subset of Prolog and uses a bottom-up approach instead of a top-down approach Prolog takes.

Summary

Choosing a database query language and data model is difficult. Data modeling processes are important in database management systems to support the application we're developing. Representing physical data models or logical data models in conceptual data models will always be difficult. Once we understand the basics, we can make an informed decision about our data architecture and database design.

Document databases are good for one-to-many data modeling. Relational databases are good for one-to-many, many-to-many, and many-to-one relationships. When many-to-many relationships are extensive in the database, graph-based models are better for storing and representing data.

Relational databases are also suitable for homogenous data, while document-based databases are better for heterogeneous data due to the lack of a fixed schema.

When it comes to languages, a declarative language is designed as an abstraction layer for the details and has a huge advantage for behind-the-scenes optimizations. On the other hand, imperative languages are better for programming languages and services. When it comes to query operations, declarative languages (such as SQL) are the way to go.

Reply via email | Reply via Mastodon | Comment

Speaking, Writing, and High-Quality Ideas

Fri, 26 Aug 2022 00:00:00 GMT

In a lecture, Patrick Winston said,

“Your success in life will be determined largely by your ability to speak, your ability to write, and the quality of your ideas. In that order.”

I pondered on that sentence for days. The longer I thought about it, the more I recognized Patrick right.

I thought about the leaders I follow, the leaders in the organizations I worked in, and the leaders who lived long before I was born. Many are great speakers but cannot write two paragraphs that connect two thoughts. Some of them are fantastic writers but full of crappy ideas. However, all the highly successful ones dedicated a significant amount of time to improving themselves in these three abilities. They are fantastic thinkers because of their excellent writing skills. They are great at persuading because they can speak well with ideas that are well thought out.

Whoever speaks well will have the advantage of convincing others to follow them.

Whoever writes well will create a margin in their thinking.

Whoever has the best ideas will have a chance to impact the world. However, they won’t be able to move a needle if they cannot write or speak about it.

Think about a leader who speaks well. If they are extraordinary speakers, we might be surprised to see how much they climb up the success ladder. But does it make these people great intellectuals? They often fall suddenly, and the results are usually miserable. If they don’t pursue the writing path, their success collapses because their ideas begin to rot.

Whoever succeeds in these three fronts succeeds in life. Growing in only one is already difficult, yet how can one become the best?

I leave here Patrick Winston’s lecture. I highly recommend watching it.

Reply via email | Reply via Mastodon | Comment

The CAP Theorem

Fri, 26 Aug 2022 00:00:00 GMT

“Strong Consistency, Availability, and Partition tolerance: pick two out of three” — The CAP Theorem

PACELC theorem: “In case of network partitioning in a distributed system, one has to choose between Availability and Consistency, but else, even when the system is running normally in the absence of partitions, one has to choose between latency and consistency.”

Related Note(s):
- 43: The Role and Responsibility of Software Architect;
- 45: Software Architecture Patterns and Models;
Source(s):
- Understanding Distributed Systems;
- Software World #24: Understanding Distributed Systems with Roberto Vitillo;

Reply via email | Reply via Mastodon | Comment

Elasticity in Software Systems

Fri, 26 Aug 2022 00:00:00 GMT

Elasticity is a service’s ability to handle bursts of traffic. It’s often confused with scalability. Scalability is the ability to handle a large number of concurrent requests.

Although these two are different, elastic systems also need scalability.

For example, ticketing or bidding systems usually need elastic scaling as they will have bursts of traffic in a short amount of time. They need to scale up and down with a different load of requests coming in. However, a growing no-discount e-commerce website will scale differently as it probably won’t need any elasticity and can scale up with the overall increasing number of users.

We might need to uncover the real need for the software. Sometimes, these Architecture Characteristics might come with requirements, but some of them can be hidden in the problem domain.

Serverless architecture is one of the most elastic systems. You pay-per-use, and it scales up and down all the time by adding more resources when you trigger a serverless function.

Source(s): Fundamentals of Software Architecture by Mark Richards & Neal Ford;

Reply via email | Reply via Mastodon | Comment

Key-Value Partitioning (Key or Hash)

Fri, 26 Aug 2022 00:00:00 GMT

In hash partitioning, we use hash functions for ranges to distribute data evenly between partitions. The range-based partitions still have the disadvantage of loading one partition with more data. With hash functions, we solve this problem. Putting the identifier into a hash function produces a unique hash. We can then use this hash to write data to a related partition.

Reply via email | Reply via Mastodon | Comment

Diseconomy of Scale

Fri, 26 Aug 2022 00:00:00 GMT

The size of the project matters a lot in the diseconomy of scale. In Software Estimation, Steve McConnell talks about estimating projects on different scales and considering important factors. Typically, we talk about economies of scale by saying, “If we build five more factories, the cost per unit we produce will be lower.” However, in software engineering, it’s quite the contrary. When we build larger systems, we significantly increase the costs. That’s why it’s called diseconomy of scale: different factors, such as the cost of communication, increase exponentially.

Related Note(s):
- 2e: Elements of a Story;
- 49: Accidental Complexity;
- 19c: How to move faster in organizations;
- 36: Open Feedback Culture;
- As we can’t comprehend the growing scope, it becomes difficult to plan projects at scale.
- The reason why cities are richer is due to economies of scale.
Source(s): Software Estimation Book by Steve McConnell

Reply via email | Reply via Mastodon | Comment

Scalability in Software Systems

Fri, 26 Aug 2022 00:00:00 GMT

Defining the system load and performance is important to understand scalability. Scalability is the system's ability (performance) to cope with increased load. The load doesn't say anything when it's used alone. The load can be anything, depending on the system's architecture. For Twitter, as an example, it can be the number of tweets posted in a second or the number of tweets read in a second.

Scalability: Ability for the system to perform and operate as the number of users or requests increases. — Fundamentals of Software Architecture

Scalability is not a label that we can define a service as scalable. Scalability means thinking about the strategies to deal with the growing load.

When we try to understand how scalable the system is, we usually ask questions like, “How does the system perform when it gets 10x more load than now?” and “How can we add more resources to cope with the increasing load?”

Before we look at the strategies to handle the increasing load, we have to understand how we measure the scalability and what load and performance mean.

The capacity of a system is often measured by throughput and response time. Throughput means the number of operations processed per second; response time means the time between request and response.

Defining the load depends on the system. As Martin Kleppmann explains in Designing Data-Intensive Applications,

The load can be described with a few numbers, which we call load parameters. The best choice of parameters depends on the architecture of your system: it may be the requests per second to a web server, the ratio of reads to writes in a database, the number of simultaneously active users in a chat room, the hit rate on a cache, or something else.

Once we know the load, we can understand the capacity of the systems.

Understanding Distributed Systems;

Don’t confuse it with Elasticity which is mentioned in the Fundamentals of Software Architecture by Mark Richards & Neal Ford

There are different types of scaling. It’s crucial to understand Horizontal vs Vertical Scaling.

Load Balancer is required in Horizontal Scaling.

Scalability in Cracking the Coding Interview gives a good overview of concepts related to Scalability and System Design.

It’s all trade-offs.

How does it work in Microservices architecture? Read the Building Microservices book on page 216.

Related Note(s):
- 48: System Design Index;
- 55: Database Partitioning (Sharding);
Source(s): Designing Data-Intensive Applications by Martin Kleppmann

Reply via email | Reply via Mastodon | Comment

Defining System Load

Fri, 26 Aug 2022 00:00:00 GMT

To talk about increasing load and scalability, we first need to define the system's current load. There is no one way of doing it as it depends on the project and its architecture, but we use load parameters. These parameters will be different for every application.

When we think about Twitter, the load parameter is not how many tweets are posted per second alone because it's not a high number that requires scaling the whole system. If there are 12000 tweets (write operation) per second, it's easy to handle. The load parameter for Twitter is the fan-out effect of posting tweets. Each Twitter user follows many people, and each user is followed by many. How to build this system with 12000+ incoming tweets every second is the scalability problem of Twitter.

Source(s): Designing Data-Intensive Applications by Martin Kleppmann

Reply via email | Reply via Mastodon | Comment

Defining System Performance

Fri, 26 Aug 2022 00:00:00 GMT

Besides load, we have to understand the performance of the system before trying to scale the application. We use performance metrics. These metrics vary in different systems. In batch processing systems, it is throughput (the # of records the system can process per second); in online systems, it's the response time (the time between request and response, not latency).

When we take the response time, measuring it is simple: put a timer between the time the request is made and the response is received. Yet, talking about response time demands something else. We cannot only look at one single response time. Because each time we make a request, the response might arrive at different times for various reasons: network delay, database crash, garbage collection pause, package lost in the network, waiting for another system's response, etc. That's why we cannot take one request-response pair and define the performance. We need to gather a lot of pairs in a certain timeframe and analyze the response time from there by using percentiles.

When we talk about average performance, we usually talk about the arithmetic mean. The average is rarely useful because it doesn't say anything about how many users are experiencing delays. That's why we use percentiles.

Understanding percentiles is crucial because they are the required elements of Service Level Agreements (SLAs)—the contracts that define the expected performance and availability of a service—and Service Level Objectives (SLOs) and Service Level Indicators (SLIs).

To calculate average performance (the arithmetic mean), we get all our response times in a certain period. Let's say we have 100 requests in a second. We order response times from fastest to slowest. When we draw a line in the 50th response time in the ordered list, that is our median response time. If the 50th item is 100ms, it means 50% of our response times are faster than 100ms, and 50% of them are slower than 100ms. The arithmetic mean is called the 50th percentile—p50. Be careful: percentiles are not percentages. Percentile represents a single entry in the ordered list.

Let's take the 99th item in our previous list as another example. If it is 200ms, then we can say that the 99th percentile (often referred to as p99) will be 200ms. That means 99% of the response times will be faster than 200ms. Amazon uses the 99.9th percentile (p999) in its internal systems. That means 1 out of 1000 response times will be above a certain threshold that they defined.

Now that we understand how we can describe performance and load, we can define SLAs in our systems and track them properly. But still, how can we approach handling the increasing load and prevent breaking our SLAs?

Source(s): Designing Data-Intensive Applications by Martin Kleppmann

Reply via email | Reply via Mastodon | Comment

Approaches for Coping with Increased Load in Software Systems

Fri, 26 Aug 2022 00:00:00 GMT

There are two methods of scaling (a dichotomy): scaling up (vertical scaling) and sealing out (horizontal scaling). Although neither is a silver bullet, implementing either one or a combination of two is often the right action. Choosing which way to go depends on the application and operation overall.

Some services are elastic; they can add or remove resources depending on the need. Some of them need manual scaling, which leads to a simpler system and fewer operational surprises.

What kind of scaling to use will always depend on the system. The system that scales well will be built around assumptions of defined load parameters (predicted common and rare operations).

In start-ups and non-proven products, it's more important to iterate on the product instead of building the system for a hypothetical future load.

Related Note(s):
- 48d: Elasticity in Software Systems;
Source(s): Designing Data-Intensive Applications by Martin Kleppmann

Reply via email | Reply via Mastodon | Comment

Pros and Cons of Vertical Scaling (Scaling Up)

Fri, 26 Aug 2022 00:00:00 GMT

Increasing the size of the instances and, for example, increasing the server's memory to handle load changes.

Advantages

Doesn’t need I/O operations. Processing is within a machine.
Data Consistency.
Easy implementation.
Fast development.

Disadvantages

Hardware limitations (cannot scale infinitely).
Single point of failure.

Reply via email | Reply via Mastodon | Comment

Functional Decomposition in Software Systems

Fri, 26 Aug 2022 00:00:00 GMT

Functional decomposition is separating parts of your application into their own sections and allowing teams to develop these sections independently. Splitting the application by business capabilities and defining boundaries that enable teams to work independently is at the core of functional decomposition.

If you’re developing backend applications, one way to do functional decomposition is by splitting your monolith into microservices.

If you’re developing mobile applications, one way is by splitting your application into several frameworks and enabling teams to work within these frameworks.

The advantages of this approach are reducing communication overhead, easier maintenance of the small codebase, easy scaling, ease of deployment, replaceability, and resiliency. Communication between 4 people is way easier than communication between 20 people. As these small teams handle smaller codebases, they can deploy and scale easily. Whenever something goes wrong, it’s easy to replace the whole service.

Of course, it comes with disadvantages. Although small teams are independent in making decisions and moving fast, it becomes difficult to create developer tools and automate workflows when everyone chooses their tech stack and architecture. When the organization scales, automation, and developer tools become essential. With some technological governance, these issues can be minimized. For example, Netflix strictly uses Java, Python, and Javascript and developed tools for their teams to work effectively.

Other disadvantages are the difficulty of debugging and testing. As the number of independent modules grows, testing the integration of these modules becomes tricky. Testing the whole user journey becomes a challenge. It’s the same for debugging. Finding the root cause of a bug demands excellent monitoring and observability practices.

The last one I’ve experienced is the maintenance overhead. Teams create tiny modules, and each module requires maintenance. I would argue about starting a service to do only one thing. The overhead it creates is often more significant than the benefit it brings. One maintenance overhead is once you have an API definition, you have to maintain it for your clients. There are solutions, like API gateway, to solve the problem, but it will always be another thing to develop, deploy, and maintain. Also, the API gateway is coupled with multiple services and needs to be updated whenever there is an update in the services it is connected to.

The challenges of decomposing mobile apps and backend services are very different. Decomposing mobile apps often creates problems in dependency and release management. Decomposing backend applications create more points of failure and reduce resiliency. Although there are practices to reduce these risks, such as dependency inversion for mobile and chaos engineering for the backend, some challenges will always be unique to the tech stack and require knowledge in the area.

If you want to expand your knowledge in splitting monolith to microservices, I recommend reading Monolith to Microservices or Building Microservices, both by Sam Newman.

If you want to expand your knowledge in scaling mobile apps, I recommend reading Building Mobile Apps at Scale by Gergely Orosz. Although the book is not a technical deep dive, it gives great insights into the challenges you will face.

Reply via email | Reply via Mastodon | Comment

Database Normalization

Fri, 26 Aug 2022 00:00:00 GMT

Database denormalization means adding redundant information into a database to speed up reads. For example, duplicating data across tables is a denormalization process. We duplicate data to reduce Join operations across tables.

When the databases grow, join operations become slower. To avoid this, we either use denormalization or NoSQL. NoSQL is designed differently and has no join operation.

Reply via email | Reply via Mastodon | Comment

DDIA: Reliability, Scalability, and Maintainability in Distributed Applications

Fri, 26 Aug 2022 00:00:00 GMT

This article is part of my notes from Chapter 1 of Designing Data-Intensive Applications by Martin Kleppmann. You can read other chapter notes as well.

Chapter 1: Reliability, Scalability, and Maintainability in Distributed Applications
Chapter 2: Data Models and Query Languages
Chapter 3: Data Storage and Retrieval
Chapter 4: Encoding, Decoding, Schemas, and Data Evolution
Chapter 5: Data Replication
Chapter 6: Database Partitioning
Chapter 7: Transactions
Chapter 8: The Trouble with Distributed Systems
Chapter 9: Consistency and Consensus
Chapter 10: Batch Processing
Chapter 11: Stream Processing
Chapter 12: The Future of Data Systems

Most systems these days are data-intensive and require features such as databases, caches, search indexes, stream processing, batch processing, etc. As much as we don't get to—and don't want to—develop these features from scratch (it's rare to develop a new database engine from scratch), we use them to build systems. Understanding how they work is fundamental to developing data-intensive applications. This knowledge impacts our design choices, and the basics of these features demand an understanding of reliability, scalability, and maintainability.

Reliability

Reliability means the application should continue to work correctly in a way that is expected even when things go wrong.

Reliable application functions as expected and can tolerate mistakes user makes or mistakes that happen when users use the software unexpectedly. It can prevent unauthorized access and abuse. Its performance is good enough under the expected load and data volume.

Fault ≠ failure; a fault is a functional or component problem. Failure is a whole system stopping providing the required service to the user. We design fault-tolerant systems to prevent failure.

Systems became unreliable because of

Hardware Faults
Software Faults
Human Errors

In software systems, we can't cover every fault or error; we only take precautious steps. We tolerate certain faults. Finding out which faults we should tolerate is the main challenge of developing a reliable system.

What are the costs of failures?

Due to the errors above, systems quickly become unreliable. The cost may vary from system to system. If we’re talking about nuclear systems, the fault might cause a failure that impacts many lives. If we’re talking about business applications, it might cause millions of dollars and eventually shut down the business.

Our goal is to reduce these costs. If we can decouple places where people make the most mistakes from the areas where they can cause an error, we can reduce the cost of failure. For example, sandboxing environments are a way to reduce costs. In iPhones, Apple uses application sandboxes for each application. When any application fails or crashes, it doesn't crash the whole phone. Apple increases the system's reliability by putting every application developed by third-party developers into sandboxes.

Scalability

What is System Load?

When we think about Twitter, the load parameter is not how many tweets are posted per second alone because it's not a high number that requires scaling the whole system. If there are 12000 tweets (write operation) per second, it's easy to handle. The load parameter for Twitter is the *fan-out_ effect of posting tweets. Each Twitter user follows many people, and each user is followed by many. How to build this system with 12000+ incoming tweets every second is the scalability problem of Twitter.

What is System Performance?

💡When we talk about average performance, we usually talk about the arithmetic mean. The average is rarely useful because it doesn't say anything about how many users are experiencing delays. That's why we use percentiles.

Approaches for Coping with Load

Some services are elastic; they can add or remove resources depending on the need. Some of them need manual scaling, which leads to a simpler system and fewer operational surprises.

What kind of scaling to use will always depend on the system. The system that scales well will be built around assumptions of defined load parameters (predicted common and rare operations).

:::note 💫 In start-ups and non-proven products, it's more important to iterate on the product instead of building the system for a hypothetical future load. :::

Maintainability

There are mainly three design principles for maintaining software systems: Operability, Simplicity, and Evolvability.

Operability

"Good operations can often work around the limitations of bad for incomplete software, but good software cannot run reliably with bad operations."

Good operability means making routine tasks easy, allowing the operations team to focus their efforts on high-value activities.

Simplicity

Systems that are not made simple quickly become "a big ball of mud." To simplify systems, we need to reduce the accidental complexity, not the systems' functionality. One of the best ways to reduce accidental complexity is an abstraction. However, finding good abstractions is not easy.

Evolvability

Making changes easy is crucial because system requirements, business priorities, technical infrastructure, and user requests never stay the same. Making a system evolvable depends on its simplicity and abstractions. Simple and easy-to-understand systems are easier to modify than complex ones. That's the idea behind agility. Agile working patterns such as test-driven development are helpful, but agility is often used on a local scale (a few source code files in an application); therefore, we use evolvability on the data system level.

Reply via email | Reply via Mastodon | Comment

Mektup #38: Can you get a promotion by changing jobs?

Tue, 23 Aug 2022 00:00:00 GMT

Hey friend,

You might be in a strange position in your career where you hope to get a promotion soon, but the company seems like have no option for you. They have no new positions for your dream role. This new role can be any kind of leadership. Probably, you may know by now that giving someone the title "senior" is not bound to open positions but rather the experience, impact, and skills. Yet, staff engineering or engineering management, tech lead, and team lead roles—additionally—bound to open positions, headcount, and company's needs. Each software engineering team has various senior, mid-level, and junior engineers, but they have one leader (or two when the tech lead and team lead co-exist). Getting that position is not that easy.

If you and your manager feel ready for your promotion, but the company is unwilling to promote you or has no open space, what should you do?

First, I've been there too, and you're not alone. I felt so alone and hopeless at that time. These situations are not easy to handle and cause a lot of stress. When we're stressed, our judgment and decision-making also get impacted. Hence, we make wrong calls. Overall, just know that you aren't alone; you're part of a big crowd.

So, if you're considering leaving the company because they have no options for you, can you find a leading role in another company without being a leader or have no official leader title?

The short answer: Yes, but it isn't easy.

Why is it difficult?

The answer is simple: companies don't want to take risks for leadership roles because the result can be catastrophic for the team and business.

Hiring someone always has a certain amount of risk. When the new hire is not experienced in the role, this risk is more significant. The person might be knowledgeable about leadership (technical and/or people). Still, knowledge does not represent reality, and the application of knowledge—what we call experience—is the real trait in leadership. And that's also what they ask you in interviews as well.

In leadership interviews, you get behavioral questions besides technical questions. Companies test your technical skills and leadership skills separately. You may be familiar with technical interviews and can succeed well because of your knowledge and experience. But when it comes to leadership interviews, companies ask you to talk about your concrete experiences in specific topics.

You might be knowledgeable or have an idea about what to do in certain situations, but they are interested in what you have done before. If you have relative experience in which you can relate to the question, you can give them some good answers. That's what I've done as well. When I was interviewing for an Engineering Manager role before becoming a manager, I already had relative experience mentoring and coaching people and driving projects from start to finish. I used these experiences in the STAR method, which helped me get an offer.

Recommendation: To answer their behavioral questions, always use the STAR method. Define the Situation you have been in, explain your Task in the situation, which Actions you took and what was the Result of them. If you lean on the "if this happens, I will do that" style, that shows a lack of experience. If you don't have the experience, try to build that experience or talk about something related but be honest that you don't have direct experience.

Whether you can get promotion via changing jobs or not depends on what kind of person the company you're applying to is looking for. If they have an experienced VP or Head of Engineering, or Engineering Manager who can coach and guide you, the company might be okay with hiring a junior leader. However, they will still look for relevant experience. Hence, you have to gain that experience.

If you're in between looking for a new job in another company and waiting for your current company to promote you, I would suggest you approach it pragmatically.

What is the realistic timeline you see for getting promoted in your current job? If the company believes that you're ready for a job promotion, but they have no budget or position open, for how long you most likely will wait? Is there anyone else looking for the same role? Do you have any competition? Write these down along with your possible compensation changes. Validate them with your manager. They might not disclose compensation details, but you can still ask if the numbers you have in mind are in the ballpark or not.

Meanwhile, start applying to open positions in other companies. Don't hesitate. These processes often take time. The earlier you start, the better situation you will find yourself in. Each interview will teach you where you lack experience. Also, interviewing is a skill that improves with practice. More interviews ➡ better interviewing skills.

If the promotion process takes at least another year, don't hold onto that and look for something else. You might still be in the same company for a year more during the transition, but once you start looking, you might find a good opportunity. While looking for another job, seek opportunities that help you build leadership experience. Soak all the knowledge you can get from your current employer and convert this knowledge into wisdom that will guide you in your future.

As I mentioned, I got an engineering manager offer from another company when I was a software engineer. I didn't accept that job offer for various reasons. But I'm a living example that it can be done. In the next Mektup, I will talk about what I have done to get an offer without being a manager before and how I built the experience and skills to get a good offer.

Until next time,

Candost

P.S. I self-studied leadership—a sneak peek into the next Mektup.

Reply via email | Reply via Mastodon | Comment

Mektup #37: Mentoring vs. Coaching vs. Teaching

Tue, 09 Aug 2022 00:00:00 GMT

Hey friend,

In the last Mektup, I talked about proactive mentorship and what makes a mentor great. Let's continue with coaching and teaching and the differences between all three.

Mentorship is the first step any engineer takes. Almost all senior engineers are somehow expected to mentor others. And rarely expected to be a mentee at the same time. There is a misperception that senior engineers do not need to be a mentee, but I disagree with that. Everyone—including principal engineers and CTOs—needs mentoring in one area or another. There is always room for improvement, and finding a mentor is one of the best growth strategies.

The mentoring relationship often starts with a need; you need a mentor, or someone else needs you. Although the beginning is a bit awkward, it can become a great relationship. As I said in the last Mektup, mentoring helps both sides grow because the focus is on long-term career development. It's a knowledge exchange and learning collaboration. Let's demonstrate this to understand better.

A mentor has a piece of knowledge on a topic. The mentee is interested in acquiring this knowledge and experience. They have some knowledge, but they want to learn more.

When their relationship starts, their common knowledge is often small.

After some time, their common knowledge grows. As the mentee consumes and learns more about the topic, the mentor also grows their knowledge.

When a mentor starts sharing wisdom, their understanding of the topic deepens. Mentee's questions challenge the status quo in the mentor's mind and nudge them to rethink, research more and learn more. Over time, the mentor's knowledge grows together with the mentee's. That's the beauty of mentorship. It's bidirectional. Mentor ↔ Mentee.

Now, let's look at coaching and teaching—unidirectional relationships. A coach guides you, and a teacher teaches you. Well, it's not that simple, but in short, it's what happens. Contrary to mentorship, where you figure things out together, in coaching, the coach asks questions to help other people find their own way. The coach gives small nudges to guide or course-correct. The focus is on a specific skill. Of course, a coach also learns during guiding. Yet, their learning is different from learnings as a mentor. A coach learns from the coachee's experiences without being involved in them. The main work is on the coachee; they follow the suggestions and recommendations of a coach. If the coachee doesn't put in the effort and work on improvements, the relationship fails. The same applies to teaching.

In teaching, the teacher is informative. They directly share knowledge; they are the ones who took the same journey as a student before and currently sharing what they have learned over time. Think about yourself in a classroom. There is a teacher who explains a topic to you. The student is in listening and consuming mode while the teacher is in informing and narrating mode.

What separates all three—mentoring, coaching, and teaching—is who the active side is.

In teaching, the teacher is active; they do the main work (Teacher ➡ Student). They prepare for the class and pass their knowledge to students.

In coaching, the coachee is the active one. The coach asks questions and gives suggestions or small nudges, but the work is on the coachee; they have to do the work and follow their own path (Coachee↩Coach). In mentoring, both sides are active. Although the mentor has some knowledge that the mentee doesn't, they both actively contribute to the topic. It is why engineers are expected to mentor but not expected to teach or coach.

On the other hand, leaders are often expected to coach people together with mentoring. The point of leadership is helping people figure out problems by themselves, and that's the definition of coaching. I will write about coaching in detail later, but the difficulty with coaching is learning to stay silent and not give guidance all the time. The best coaches (and leaders) I worked with rarely gave advice but always asked questions.

Depending on your needs and plans, you have to decide what you're looking for. My recommendation for all engineers—regardless of their growth path—is to start with mentoring. Help someone grow by being a mentor, and find yourself a mentor who has been in your place before. Never stop your mentorship relationships in your career. As both mentee and mentor are active, you'll always learn something from both sides.

If you're planning to move into more management roles, find a junior or graduate engineer you can try coaching. Read "The Coaching Habit" by Michael Bungay Stainer and learn how to stay silent and ask better questions.

If you're into teaching others, that's a role you can always do anytime in your career. There are always people who are less knowledgeable than you. The best way to start is to give talks in your company about topics you know.

Be aware of the key differences between mentoring, coaching, and teaching and which one you want. Pick one and follow your own path. Doesn't matter which side you're on (the active or passive side); you'll grow immensely.

One important note; never start either of them if you don't have energy or time. It's crucial that mentoring and coaching sessions are frequent and consistent. Don't leave someone halfway because they will be frustrated, and it is never easy to find a new person halfway. Be reliable and trustworthy, and share what you learn on your journey.

Until next time,

Candost

P.S. I wrote this 2,5 years ago. All of them are still valuable lessons.

Reply via email | Reply via Mastodon | Comment

Form enabling teams to share expert knowledge in the organization

Sat, 30 Jul 2022 00:00:00 GMT

Enabling teams consist of experts in a subtopic where deep expertise is required. These teams take pressure from stream-aligned teams by doing research and guiding them in certain areas. Enabling teams join stream-aligned teams, share their knowledge, and leave. I've never come across any team like that. I believe these teams are more common in big companies where mid-size companies don't have enough people to fill this team. The business also cannot be in favor of these teams with a limited budget. If enabling team's mission is to help stream-aligned teams move faster, it might actually work with a limited budget by having short-living enabling teams.

Related Note(s):
Source(s): Team Topologies by Matthew Skelton and Manuel Pais;

Reply via email | Reply via Mastodon | Comment

Mektup #36: How to Become A Great Mentor

Tue, 26 Jul 2022 00:00:00 GMT

Hey friend,

I've been mentoring people all around the world for a while. As I stepped into the management role, I also started coaching people in my team who were already mentors. When I started mentoring, I thought it would be less work for me as a mentor and a lot of work for the mentee.

It seemed logical to expect mentees to come up with topics and tell me skills they want to improve because they should know which ones they lack. At least, as a starting point, I expected mentees to bring up what they wanted to improve. Soon I realized that it was not the reality. Mentees often have no idea where to improve. If they knew, they could have already worked on it by themselves.

On the other side, as a mentee, I often struggled with figuring out which skills I should improve. There is a ton of information available, yet which ones to help in a career is always a question.

After a while, I looked for what a mentor should do, how to approach the mentee, how to build a relationship and trust and give the mentee the right direction.

Every mentor-mentee relationship should start with a clear goal. Depending on the need, the mentoring will either require a long time for a broad focus on skills or a short time with a focus on a specific one. Either way, I learned that the mentor should be as proactive as possible.

Whenever the mentor is passive and expects the mentee to come up with either a topic or questions, the relationship fails. Every time I tried to be proactive, asked questions, and brought up new topics, our relationship with a mentee was stronger, and they were on a great learning path.

When a mentee asked a question I didn’t know the answer to, I went back to researching and learning. Then I brought the answer to the mentee without waiting for the next meeting. That made me trustworthy and reliable, and mentees became more relaxed and could ask whatever came to their minds.

Studying and researching helped me deepen my knowledge. I became more proficient in supporting the mentee in their learning path.

The beauty of the mentor-mentee relationship is that both sides learn.

Let’s list down the role of a mentor. A mentor

makes the learning experience effective.
asks guiding questions.
keeps the focus on a topic.
always listens.
doesn’t leave the mentee alone.

On top of all, a proactive mentor

asks the mentee if they need any help without waiting for them to ask for help.
gives feedback on actions they observe from the outside without waiting for the meeting.
builds the relationship without waiting for the mentee.
researches and learns a topic they didn’t know and returns to the mentee with some answers.

It sounds like a lot of work for the mentor. However, all of these take a little time (except research). Building the relationship in this proactive approach will help both parties grow exponentially. Also, proactive mentorship is one of the milestones of any leadership position—whether manager or staff engineer.

Why proactive?

Being a mentee means being out of your comfort zone. If the mentor waits for the mentee to ask a question, the mentee’s stress level increases even more. The reason for this relationship is the mentee’s struggle with a topic. Being in an incognizant position already creates tension. When we top that with even more responsibility, being a mentee becomes challenging.

Also, the mentee might not know they are on the wrong path. If the mentor is not proactive, the mentee can get far on the irrelevant track. Being proactive saves time for both mentor and mentee. The mentor can course-correct easily when they see the mentee going off-track in the beginning.

Lastly, proactive mentorship eases frustration. Mentees often struggle and can be hesitant to disturb mentors every hour. When there is no response for some time from the mentee, asking how they are doing helps mentees solve smaller problems easier and decompress their tension.

As you grow into leadership, proactive mentorship will be one of the milestones in your career. Being a great mentor always elevates you because people will back you up when you’re up for promotion, regardless of your company’s promotion approach. Having these relationships will teach you tons of things you haven’t considered before and make you a great leader.

One last note, keep in mind that you’re not a teacher. I will talk about the differences between teaching, coaching, and mentoring in the next Mektups, but in short, teaching and coaching are one-way activities while mentoring is bidirectional. As a mentor, you must do the work as much as your mentee does.

Until next time,

Candost

P.S. In case your mentee (or you) needs some strategies for problem-solving.

Reply via email | Reply via Mastodon | Comment

Organizations should reduce cognitive load on stream-aligned teams

Sun, 24 Jul 2022 00:00:00 GMT

Stream-aligned teams are the most common but most mistaken teams. They are the bones of any organization, yet I have seen they often have many problems because other team topologies don't exist, and organizations work only with these teams. This strategy becomes the major bottleneck for faster delivery. It results in teams not having that much autonomy, a lot of dependencies on each other, and accumulated tech debt with little-to-none experimentation.

When other teams exist (e.g., platform), stream-aligned teams thrive and become more successful. The organization's goal should be to reduce the cognitive load of these teams. Then, these teams can deliver end-to-end customer and business value.

Related Note(s):
- 24: Strong teams are motivated by goals;
- 33: Elevating Others Around You;
Source(s): Team Topologies by Matthew Skelton and Manuel Pais;

Reply via email | Reply via Mastodon | Comment

Forming teams and defining topology depends on the context

Thu, 21 Jul 2022 00:00:00 GMT

The pre-maturely decided team structures often fail sooner than expected. Teams have to be formed around a vision of a domain. While forming any team, we must consider which dependencies the team will have, the cultural and technical maturity of team members, and the organization's size. We must make conscious decisions about the silos we create or break down. We have to form the team for long-term solutions, not short-term ones.

Related Note(s):
Source(s): Team Topologies by Matthew Skelton and Manuel Pais;

Reply via email | Reply via Mastodon | Comment

Team Anti-Patterns and their effects

Wed, 20 Jul 2022 00:00:00 GMT

Ad-hoc team design sounds excellent for solving a problem or delivering a specific project part. However, in this situation, many things appear as an afterthought. Because each team builds tech debt and tries to solve it after some time. When people leave the team, and a few people are destined to maintain all systems somehow, the team's delivery gets a huge hit, and morale swiftly decreases. The remaining team cannot handle the workload, and it becomes more and more challenging to maintain the whole system.

Shuffling team members is often called team fluidity—teams change once in a while—while expecting people to learn different parts of the project and tech stack quickly. This is often an anti-pattern because it demands individual and system fundamentals to be strong. When someone moves from Team A to Team B, the onboarding has to be smooth and easy, the tech stack, frameworks, and infrastructure must be built in the same way, documentation has to be strong, and domain knowledge shouldn't be a significant problem to learn. Also, once a person leaves a team, they leave behind a system to maintain, often taking their knowledge. Getting all this stuff right is difficult.

Related Note(s):
Source(s): Team Topologies by Matthew Skelton and Manuel Pais;

Reply via email | Reply via Mastodon | Comment

Define team APIs to design the team's outside communication

Mon, 18 Jul 2022 00:00:00 GMT

In theory, having team APIs is great and can work in relaxed times. Defining and enforcing them is tricky in a dynamic company that changes every few months. Team APIs need a constant team with a consistent push to follow the APIs. In practice, it is difficult. Another part is who will be responsible for keeping them up-to-date. Writing down all these documents should be everyone's work in the team. Only a dedicated person should be accountable. If the team is mature enough, they can keep updating their APIs. If the team is not mature enough, the manager has to follow up on APIs to ensure they are updated regularly. That's extra work for the team. Yet, it's highly possible to achieve.

Related Note(s):
Source(s): Team Topologies by Matthew Skelton and Manuel Pais;

Reply via email | Reply via Mastodon | Comment

Mektup #35: Don't call people resources

Wed, 13 Jul 2022 00:00:00 GMT

Hey friend,

Today, I wanted to write you about mentoring, but this seemed more suitable for the current tech scene. As many companies take a look at how to use their workforce more effectively to increase profits and cut costs, I wanted to write about something that disturbs me a lot.

It’s not difficult to guess that in each company, people are called resources in one way or another. I’ve never heard of a company that forbids using the “resources” word.

My problem with the word is that how we use it doesn’t fit its definition, and it removes the human sentiment from any situation.

**According to Merriam-Webster Dictionary**, the most suitable definition for the tech industry’s usage is “a source of information or expertise.” If we call people a source of information or expertise, that would be okay-ish. Still wrong, but okay-ish. People can be experts and can be a source of information. But people are never just a source of information.

The word “resources” dehumanizes the people in the company. People are individuals and have unique characteristics that can’t be replaceable. If people were resources, we could hire and replace everyone quickly without having any behavioral interviews and would never look for a “cultural fit” in the hiring process.

Historically, people’s characteristics were not considered during industrialization. That’s why the term “Human Resources” came up. People’s jobs were repetitive and didn’t require any specific skills or personality. Humans were used as resources like materials that can be replaceable quickly when it’s not working.

In the tech industry, people are, well, people. We have to consider every aspect of human life. We can’t even get the same productivity from a person every single day. People have good and bad days. Their motivation and performance will vary each day in different projects and situations.

That’s the part you’ll learn when you become a leader. As a leader, your job is not to see people as resources. Always think about them as human beings. Think about people’s lives, and if you know that they will be in a stressful month, support them by trying to reduce their stress and workload on the company. Even if you’re doing so-called “resource planning,” use the right term and do “staff time allocation and project planning.”

While it doesn’t fit into its definition, my other problem is about culture. Using certain phrases and words changes company culture. Every leader should care about cultural changes in a company. When wrong words make their way into the company vocabulary, the culture shifts.

As using the “resources” dehumanizes people, the company starts optimizing the wrong things. Resource planning becomes like a number game where “resources” are shifted left and right without considering any personal impact. The burden on the teams and departments grows and attrition increases. If you become a manager, you’ll see that planning projects and staff are difficult jobs where nothing can be like a number game.

I want to keep this letter short today. So, don’t use the word resources to refer to the people in the company. Never. Ever. Find alternatives for the situation you have. Use the terms “project planning,” “staff,” or “people.” Also, read Uwe’s post. Uwe explains well the ethical, performance, team, and hiring problems when using the word “resources.” I couldn’t explain it better, so that’s why I’m sending you Uwe’s post.

Until next time,

Candost

Reply via email | Reply via Mastodon | Comment

Mektup #34: Process Thinking

Tue, 28 Jun 2022 00:00:00 GMT

Too Few Processes is Chaos; Too Many Won't Move Anything

Hey friend,

Two Mektups ago, I mentioned a mindset that engineers should develop: process thinking.

This one is a bit tricky because it’s one of the areas where software engineers can easily get lost. They either get into creating too many processes or resist creating any processes and lose possible increases in productivity and focus.

I remember my time going into the senior level; I focused on increasing the team's productivity by automating things or taking care of the tasks that nobody wanted to do, such as researching a topic and writing a results report. These efforts ended up helping me grow into management roles. I also saw similar work from my colleagues who ended up in staff+ engineer positions.

Let’s dive in!

What is Process Thinking?

Focusing on processes to increase productivity helped me to see how people get distracted from their work. Coding and designing applications/systems demand focus; these are not jobs you can do while watching a video on the side (Don’t tell me you can. You cannot.). Although many engineers try to keep their focus on their own strategies, they might have a tremendous amount of distraction from the company. If projects need too much conversation and consensus every time, creating a standardized process can help.

Some of these processes are technical, and some of them are not. Whether you want to grow in the Individual Contributor or management track, your focus will shift.

Growing into manager roles demands improving the productivity of the team, usually without writing a single line of code. For example, when I was a senior engineer, I focused on how we communicate with each other, our team and company-wide routines, and the collaboration we do between teams. I led the creation of the RFC process in our company. I created the customer support days for engineers because engineers were unaware of the customer complaints. These were the results of the problems I had seen.

Although requirements of staff+ engineers change from company to company, the role often demands a holistic view of the systems and how people interact with these systems. For example, if the engineers spend a lot of time rewriting the same components from scratch or copy-pasting them from previous projects in each new project, creating a reusable component or library of components makes sense. Finding out how the company will maintain this library is process thinking. Creating a library is often easier than integrating it into existing systems and keeping it maintained for a long time. If you only develop the library and leave it there, it will come back and bite you. People will often refer to your work as unfinished or not thought well. Thinking about this library’s lifecycle and finding the best strategies will move you forward in your career.

We can summarize the process thinking as “Making the place better than you found.”

How to Find the Needed Process

When we wanted to have an RFC process, we didn’t start from the RFC. We had a feedback and documentation problem. Individuals couldn’t get enough feedback on their ideas and needed a way to make their ideas more visible. Their solutions were not reaching their potential. Also, we often couldn’t find any background information about a strategic decision that’s been made in the past. Not knowing the background of a decision makes it difficult to change it later. By introducing a process, we opened up a way for new ideas, and we made sure they were written down.

Long before the RFC process, I tried implementing Scrum with two weekly sprints in my previous team when I was an engineer. Because I’ve read a few books about it and wanted to apply my learnings. Although everybody was happy to try Scrum, it did not solve any problems we had. Scrum slowly phased out, and we went back to our previous position. The mistake was that I liked the solution, yet, it didn’t address any problem in our previous collaboration system. Now, when I look back, I see my mistake: I didn’t look at the root problem. And that’s how you develop process thinking.

Look at the root of the problem and start thinking about how you can solve it once and for the long term. Process thinking is taking a step back and having a holistic look. Seeing the bigger picture shows the overarching problems and interconnections between them. It requires a lot of research. Although your company’s problem might be unique, a lot of problems are solved by other people in the industry. When you find a solution, don’t jump into the first one. Find multiple strategies and bring sustainable solutions.

Don’t have a process for the sake of having it. Process thinking somehow tricks you into loving processes—the solution you bring. Keep your focus on the problem. You might learn a process from others and want to implement it in your team or department. However, look at the problem in the beginning. Which problem does a new process solve? Mindfully and diligently approach your problem and go into its root before introducing any process. Ask for help and feedback before implementing the process.

Process thinking is not an alone activity. You have to involve your team and others and work together. Without their support, your attempts will always fail. You have to get the buy-in from people and earn their trust so that they will follow you.

How to Make Progress

I don’t know how many times I’ve seen a process kicks off well with huge support and slowly phase out. Implementing a sustainable process is more difficult than creating it. There are tons of things that can—and will—go wrong. Similar to the second law of thermodynamics, without deliberate action in any process, the degree of the disorder increases. Here are a few things I learned about creating department- or company-wide processes:

Be reliable. Reliability builds trust. When you promise to do something, don’t neglect it.
You can’t do it alone, and more importantly, you can’t make people do something. What you can do is to make the entry barrier low. Then ask them to give it a try.
You need to remind, ping, and push people deliberately. Saying something once won’t move the needle. Changing habits and processes is not easy. Even if the existing processes are broken, humans are hesitant to change and often fall back on whatever they have.
If it doesn’t work, it doesn’t work. Adapt or abandon. If you find a better solution on the way, evolve your solution. There is no perfect solution; all solutions are trade-offs. Learn your trade-offs by asking why people don’t follow the process. Adjust your solution when you hit a roadblock.
Find the balance. Too much process will never move anything; too little process is pure chaos.

I want to close this letter with a differentiation between managing and leading that you need to be mindful of while growing into leadership roles. Paulo André mentions a principle that must be part of any leadership and management role: “Manage process, lead people (and be led by them). Processes are inanimate, to be controlled, tweaked, optimized, and manipulated. People are animated with thoughts, feelings, hopes, dreams, fears, and anxieties. Treat each accordingly, and never confuse the two.”

When any leader tries to manage people, it ends with disaster. While working on processes, lead people but also allow yourself to be led by others.

— Candost

P.S. Maybe you can try process thinking by creating a Definition of Done within your team and extending it to the organization.

Reply via email | Reply via Mastodon | Comment

On Drugs and Great People

Mon, 27 Jun 2022 00:00:00 GMT

I’ve been thinking about drug usage for a while and never had a chance to have an open conversation with anyone for a long time until recently.

I wondered for a long time if drug users think about the background of the drug they use or not. If people thought about the others who are killed/injured and families destroyed behind the scenes. I question if they thought about what happens to people who risk their lives for so little gain while the cartels take the most significant cut.

The wondering is not a judgment. Not an accusation. It is curiosity. I have many friends who occasionally use drugs, and I love each one of them. They are always thoughtful and will offer others help when it is needed the most. And that puzzles my mind.

Why don’t great people think about the background of drugs?

It’s not that they don’t know what’s going on. There are hundreds of documentaries, daily news on TV and in newspapers, and even various TV series (e.g., Narcos—its first season was the most popular TV show on Netflix when it was released). Everybody knows Pablo Escobar's name and what he has done over the years.

The problem is not the knowledge; it is awareness and mindfulness, I believe. I asked, “Have you thought about the background of the drug, about people dying and suffering?” one of my friends. They answered, “I’ve never thought about it until you said it.” It was the answer I expected. It looks like they are buying drugs, like they are buying meat from the supermarket. It’s not the same as adults who are ignorant of where the food comes from. I know that my friends are not ignorant. They know what’s going on behind the scenes. They just don’t think about it. Never. Because they don’t immediately see the result of their actions. What they see is not the reality.

Additionally, using drugs—I believe—is being cool and rebellious, feeling relaxed and high, and trying to suppress daily stress*,* nothing more. I had a few discussions long ago with a few rebellious friends who were smoking marijuana. Their arguments gathered around smoking marijuana being less harmful than smoking cigarettes. They want to legalize marijuana because of that as well. This situation doesn’t show that marijuana should be legal; it shows that cigarettes should be illegal. I’m saying that as a past smoker. I smoked cigarettes for seven years. And as much as I hate any kind of restriction, that should be the way.

I don’t support any restrictions that are being done to impact personal choice. Everyone is free to do whatever they want to do to their bodies. However, the line starts when actions harm others. When you smoke cigarettes, you harm others. When you use cocaine, you harm others. It’s no different than the other. If your action hurts someone else on the way, then it has to be stopped.

If I stop any drug user in Berlin or Hamburg, ask them, “Would you kill someone?” I’m 100% sure all of them will be shocked by the question and answer with “Absolutely not! Are you crazy?” Yet, with every line they do and every joint they roll, many people die behind the scenes.

Disclaimer: I also smoked marijuana a couple of times before. Not only was I not mindful, but also I was ignorant of what was happening behind the scenes at that time.

Reply via email | Reply via Mastodon | Comment

Mektup #33: One milestone and five articles

Tue, 14 Jun 2022 00:00:00 GMT

Hey friend,

In the last Mektup, I talked about product thinking. That struck a chord on HackerNews, and thousands of people read and commented on it. I haven’t read the comments yet. I always have mixed feelings about comments (stress/curiosity/doubt) on HN; that’s why I’m waiting a bit.

With that, this month my blog has passed a big milestone of 100,000 page views from whopping 94,000 visitors like you! I started this blog in December 2020. Although I was mainly writing on my previous blogs, starting fresh and building up was a big challenge; it still is. However, I enjoy writing down my thoughts and learnings and will keep doing it for the foreseeable future.

Anyway, in honor of achieving the milestone, I will keep it short and recommend five articles I have written before. These articles will help you gain a new perspective, open doors in your growth path, and challenge you. Although I wrote them a while back, they are timeless and still popular.

Give them a read if you haven't yet!

Effective One-on-One Meetings for Engineers

Article

There are many one-one-one guides for managers but near to nothing for engineers. The meeting is for engineers; it’s their meeting. Therefore, engineers should own the meeting and make it effective. If your manager doesn’t care about one-on-ones, you can nudge them. This is what I did. When I changed my perspective and worked on improving my one-one-one meetings, the results were terrific. I increased my communication with my manager, and I felt I was learning and growing faster than usual. This led me to become an engineering manager.

How to Stop Endless Discussions

Article

When we find ourselves in endless debates where everyone defends their idea (tabs vs. spaces, React vs. Angular, iOS vs. Android, Reactive vs. Object-Oriented programming), we don't know how to handle the situation. We often create conflicts between ourselves and other team members. We eventually find a way out, but what we need is an excellent system. In this article, I explain that system.

Bias for Action

Article

I always thought that we needed to learn all of the fundamentals of a topic before taking any action. It was the approach I took as a software engineer. I spent my whole life going down rabbit holes, researching, learning, and coming up with solutions that substantially solved the problem. Think twice (or more); code once. I was wrong with my approach. All I needed was action. Having a bias to action is more helpful than discussing and researching everything prior. Quantity beats quality in learning. Action beats perfection.

Don’t Assume Consensus in The Absence of an Objection

Article

Consensus decision-making means everyone explicitly agreeing to the proposed idea. The leader needs explicit agreement from everyone and shouldn't assume consensus in the absence of objection. Many people assume there is a consensus when they don't and are faced with silence. This pattern became more common in virtual meetings. In this post, I shared why we have these silences and how it impacts the decision.

The Decision-Making Pendulum

Article

The most critical problem I've seen is having struggles in the decision-making process. The inflexibility in decision-making is at the root of various issues. Many leaders either use a lot of authority or seek consensus. I wrote this post about The Decision-Making Pendulum. The leaders must learn the skills to move in the pendulum from side to side.

Until next time, take care!

Reply via email | Reply via Mastodon | Comment

Mektup #32: Product Shouldn't Be Left to Product Managers

Tue, 31 May 2022 00:00:00 GMT

Hey friend,

Up until my mid-level engineering, I didn’t think about the product. My focus was on writing good code, designing software well, and delivering it on time. Clean and readable code, decoupling dependencies and sub-systems, adapting to changes that Apple announced (I was an iOS engineer), and learning about collaboration strategies (Scrum, Kanban, etc.) were my focus. Although that focus made me a better mid-level engineer, I needed something else to go beyond mid-and senior-level when the time came. That’s when I realized that I needed product and process thinking. I’m gonna talk about process thinking in upcoming letters, but let me open product thinking and how it is essential to level up.

There was a point in mid-level engineering where I started talking with stakeholders directly, looking at the data to understand the important user problems instead of waiting for my product manager or team lead to tell me what I needed to do. The behavior change broadened my horizon and extended my influence on the product and company as well.

Once I realized that I was hired to solve problems and had to understand the product to solve them, my career started to go up fast. I became knowledgeable about the product and was able to influence its direction. Thanks to product thinking, my focus moved from solution to problem.

What is Product Thinking?

Product thinking means thoroughly understanding the domain you’re working at, knowing the market your domain is part of, and how your product contributes to the overall business model and strategy. You need to actively keep the customer needs in mind and leverage input from product stakeholders and engineering leaders to determine the right technical solutions to deliver customer value quickly.

For example, I’m currently working in payment and billing systems. Therefore, I have to know billing, payment, invoicing, dunning, discounts, etc., so that I can understand the problems we’re facing. I also have to follow how the payment engineering market evolves and learn the changes and new technologies in the domain. Additionally, I have to know how our solutions fit into the business strategy, such as our subscription model, discounting strategy, and more. Although these topics are not related to coding at all, they make me a better engineer and engineering leader.

However, there is also an engineering side to product thinking: you have to understand your organization’s engineering strategy and its implications for your team. For instance, if you start a new project, you have to know which technologies you should use (programming languages, frameworks, tools, etc.) and which ones you should avoid. I’ve seen (many, many times) that a few engineers favor one programming language that no one else knows in the company and develop a product and leave the company after a year. What they leave behind is a burden, pain, and a codebase that no one wants to work on (Side note: please, never do that).

Why do you need product thinking?

Because if you want to develop better software, you have to understand the factors that contribute to the problem you’re solving. Without understanding your product’s strategy, how it will evolve, and the roadmap ahead, you will start accumulating technical debt at light speed. The system design and code structure will be flawed and inflexible.

If you don’t know the engineering strategy of your company, you’ll have unnecessary debates and create future problems such as knowledge gaps, ineffective onboarding, and not leveraging engineering tools available to you. I’ve seen many engineers get lost in creating the best architectural design because they focused on their engineering solution instead of the user’s or product’s problem. (I also made these mistakes, and that’s why I’m sharing these learnings with you.) When you focus on the problem and dive deep to understand the real issue before writing a single line of code, you get to meet with your stakeholders, collaborate with your teammates, and create a better solution that actually solves the problem.

That’s why you have to increase your product expertise and keep your users in mind. This way, you will deliver customer value quickly to get the fastest feedback. You will step up within your peers and start leading. If you leave product thinking to product managers, your chances of showing your excellent engineering skills will be low, and you will hit the ceiling whenever you want to get to the next level.

Simply put, instead of expecting someone (e.g., product managers) to tell you which product features to develop, you should be able to tell what are the most critical problems your users or product are facing and find the best solutions that fit into your product and engineering strategy.

— Candost

P.S. Maybe you need to learn how to approach software architecture design.

Reply via email | Reply via Mastodon | Comment

Learning Cone and Blame Spiral—The Case of Blame Absorbers

Thu, 19 May 2022 00:00:00 GMT

People’s learning paths differ from person to person. Some throw themselves into challenges and learn by doing it; some research the fundamentals before applying knowledge. A subgroup within this range learns the best when they take responsibility regardless of their learning method. Whenever they get a task or topic in their hand, they take it seriously and try their best till the end. Other folks around these people appreciate their responsible behavior.

When this group of people is not mindful or misguided, this behavior goes out of its way. Their specialty turns into absorbing all the responsibility around them while leaving none for others. The situation results in self-blaming in case of failures. While they are on the learning path, they abandon this path and enter the blame spiral—another path full of self-blame.

In this article, I will talk about this journey and a few ways to prevent the learning cone from switching to a blame spiral.

Learning Cone

Learning starts when we move out of our comfort zone and discover new things. Regardless of the topic, we begin with close-to-none knowledge and look for ways to enhance our wisdom. In engineering teams, people are often more open-minded in the beginning because they are clueless about the topic and have various options to improve. Being open-minded helps these people look at others and approach them with curiosity.

After some time, they start applying new knowledge in their work and making mistakes once they gain confidence. If the manager encourages them to learn more and discover more paths instead of judging for mistakes, the learning exponentially increases. The more encouragement and appreciation they get, the more responsibility they begin to take. Making many mistakes on the way helps them to learn even more and gain enough experience. This responsibility, experience, and expanding knowledge create new opportunities and a steep growth trajectory.

Although navigating this trajectory becomes difficult after a while because of the endless learning possibilities, good engineers get guidance and help from others and set their trajectory right.

But not everyone advances in that direction. Some people tend to leave the growth trajectory and, without the right support, easily absorb all the responsibility and blame. They tumble themselves into the blame spiral.

Becoming a Blame Absorber — What is a blame absorber?

In a blame spiral, blame absorbers begin to lose learning opportunities. The beneficial responsibility turns into a detrimental self-blame. Suddenly, they leave out the infinite learning cone and find themselves in the blame spiral. Although they were making mistakes all the way long, how they approached these mistakes shapes what they gained from them.

They start taking on more tasks and, with that, more responsibilities. As they feel responsible for mistakes, they try to cover them by taking even more responsibility. The spiral of responsibility turns into guilt, which pushes them more and more. After a while, they become frustrated and start to think that only they take responsibility; other people don’t care about anything as much as they do. They are the one who takes the job seriously to work extra hours and solve as many issues as possible. They keep blaming themselves, starting to resent others, and becoming frustrated with all the burdens they have.

Blame absorbers, as Sheila Heen calls them, are the people who take all responsibilities to themselves in a problem or a mistake while leaving none for others. They blame themselves for the failure and discard the other factors in the situation. A few common phrases blame absorbers use are

I should have known that it would fail.
I could have seen this might happen.
I would have tried fixing the bug on time.

We see blame absorbers both in work and personal relationships. Imagine a couple getting separated. A blame absorber, in this situation, would say, “If I wasn’t behaving like that, my partner wouldn’t leave me. It’s all on me; my partner was perfect, and I screwed up.” What the person misjudges here is that both have a role in the breakup because a healthy relationship requires a minimum of two people to keep it healthy, and a failed relationship requires two people to fail. Even if one side makes a mistake, the problem can’t be solely loaded onto them. There are always underlying problems that both sides couldn’t recognize at the time of the breakup.

At work, blame absorbers play a different role. Let’s use a delayed project as an example. One of the engineers who took on many responsibilities feels responsible for the delay. When the responsibility feeling turns into self-blame, the blame absorbers load mistakes of various factors on themselves. “I should have foreseen the increasing risks,” they say. “Why haven’t I tried to mitigate the problem when it was minor?” they ask. And in all that, they often say, “I could have worked more or harder”—and sometimes they do work harder. This past-wishful thinking increases their stress level, and they get into a blame spiral where even a tiny mistake becomes detrimental.

At the beginning of that spiral, their behaviors look good from the outside, and they get positive feedback for their responsible and accountable behavior. The feedback becomes a positive reinforcer for the blame spiral to grow.

However, as their blame spiral grows and stays unmanaged, they start to impact others. The blame absorber’s spiral touches other people’s learning cones and blocks them.

Others begin avoiding accountability because someone takes care of the problems every time, so they don’t have to. In the end, a single point of failure emerges, and the team becomes dysfunctional.

As a result, blame absorber increases their chance of getting frustrated and hinders learning opportunities. What was once a learning cone is now a blame spiral that impacts everyone around it. That thin line marks the switch to unlearning mode.

The only good side of the blame spiral is nobody gets stuck in it forever. People constantly switch between the learning cone and the spiral.

Moving Between Learning Cone and Blame Spiral

Moving from the learning cone into the blame spiral looks like an instant action. Yet, it’s not a one-way road. In some cases, the blame absorber gets into the spiral for a moment and comes back. If the person knows themselves and is aware of their actions, they can pull themselves back to the learning cone. Yet, the outside factors affect how frequently the blame absorber abandons the learning cone. If the manager often imputes the failures to their lack of competency or knowledge, it becomes easy for the blame absorber to get into the blame spiral.

From the blame absorber’s perspective, once they cross the line, the blame spiral looks like a one-way road. However, like in every journey in our lives, it’s a two-way street; there is always a road back. And the best side is that whenever they turn back, their learning cone grows a bit.

The best action for a blame absorber who often gets into a blame spiral is to be aware of the behavior. Once they name the situation with “Ah, I’m going into a blame spiral again,” they automatically pull themselves back to the learning cone. Awareness and mindfulness are keys to staying in the learning cone.

However, developing mindfulness is a difficult journey; that’s why I like Marshall B. Rosenberg’s approach to taking responsibility for our feelings, not for every task.

Taking Responsibility for Our Feelings

In Non-Violent Communication, Marshall B. Rosenberg states that what others do may be the stimulus of our feelings but not the cause. Other factors in any failure might boost certain feelings, but they are rarely the main reason for how we feel. Rosenberg explains how we choose one of the four options when receiving a negative message:

We can blame ourselves. (a.k.a. blame absorbing)
We can blame others.
We can sense our own feelings and needs.
We can sense others’ feelings and needs.

The first option is where the blame absorber redirects the negativity to themselves. When their manager says, “You are unorganized!” it will reflect as “I should have been more organized.” They embrace the judgment of other people and reflect on themselves.

In reality, judgments of others are alienated expressions of our own unmet needs. The more we are able to connect our feelings to our own needs, the easier it is for others to respond compassionately. When we embrace our own feelings and needs and express them, we distinguish between giving from the heart and being motivated by guilt. In other words, everybody needs certain things, and when they are not met, they feel something. If we express our needs, we have a better chance of getting them met. If we don’t value our needs, others may not either.

The framework Rosenberg uses is connecting the feeling with the need by using a sentence: “I feel ... because I need ...” When the manager says, “You’re unorganized!” the reflection changes and becomes powerful “I feel overwhelmed because I need to have some space and time to process all the incoming work and organize them.” Now the self-blame can turn into an action item and fulfill the need for a blame absorber without getting them into the blame spiral.

How do you stop blaming yourself?

If you’re a blame absorber, it’s easy to blame yourself for many things. Once you get into the blame spiral, it’s difficult to jump back to healthy responsibility. The first thing is to look at the bigger picture. It’s not always easy to do it by yourself. You might get help from a trusted person (or your manager at work) who can show you how the various factors work together.

If you want to do it yourself, create a map of the situation. Answer a few questions: Who are the people in the situation? What are the processes? The goal is not to find something else to blame; it’s to look for how everything plays together. For example, the project got delayed, and you’re blaming yourself for it. Look for who else is working on the project and your stakeholders, and define their knowledge and experience on the project and work. Stay impartial and only state the facts you know.

Once you put each element on a map, the next step is figuring out how these elements play together. The task distribution might not be right; someone else might have been assigned a task they can’t handle, and you might have helped them figure out how. It can, in turn, delay your task. Maybe, you had to wait for a week to get a confirmation on a task you delivered. Look for connections like these. Still, you’re not looking for anything to blame. Don’t judge or evaluate; only define the situation.

Now you know the people and processes, it’s time to find out the external factors, such as how the company operates, how the business is going, and how much workload everyone has. Maybe priorities shifted along the way, and your stakeholders prioritized another project while delaying yours. Look for how external factors contribute to the problem.

Once you have everything, you will see some of your feelings change. The holistic view turns negative blaming into an understanding of the big picture. When you see all the factors together, your part in the problem becomes less significant.

Now, it’s time to use Rosenberg’s formula to express your feelings and needs (“I feel ... because I need ....”) that I mentioned above. It will help you to figure out your unmet needs.

When you bring all factors together, look at the learning opportunities lying in front of you. If you keep blaming yourself and reducing all elements to a single point (you), you miss the opportunities for further growth. When there is a problem, there is rarely a one-and-only-one cause. There are always multiple factors that contribute to the problem. (It always takes two people to have a conflict. A poorly managed workload leads teams to delay projects.) Figure them out early on to avoid getting into a blame spiral.

If you’re not a blame absorber but working with blame absorbers, how can you guide them?

How to Guide and Lead Blame Absorbers

The path is very similar to how blame absorber stops blaming themselves. While explaining, don’t load all responsibility into anyone or the system. Let the blame absorber understand how all the factors play a role by showing all factors together. Then help them understand their part and enable them to take full responsibility for that part, not for the others. If you let this slip, it builds resentment over time. The absorber starts to think they’re always to blame, and others don’t take responsibility at all. If you’re building an ownership culture, be careful and show people the bigger picture and how you, they, and others are responsible together.

Blame absorbers are everywhere. It’s not a personality; it’s a behavior that everyone develops from time to time. For some people, it happens often; for some, it’s rare. However, there is usually a person who blames themselves for things happening around them. Look around yourself; I’m sure you will find someone who behaves like that. If nobody came to your mind, let me make it easier: I’m one of them. I often blame myself for the failures around me.

P.S. If you’re looking for a systematic way to give feedback to blame absorbers, you can read this post.

Reply via email | Reply via Mastodon | Comment

Mektup #31: Non-Engineers Leading Engineering Teams

Tue, 17 May 2022 00:00:00 GMT

Hey friend,

We started reading Team Topologies in a book club at work. I'm still in the first 100 pages of the book, but one chapter changed my perspective, and I want to share that with you.

Before, I thought that not all engineering managers (or team leaders) needed to be great engineers. To be more specific, I thought about leadership as a separate profession. When we think about how these people managers work, they have no time to write code; they focus on people, roadmap, and organizational work. On top of that, not all positions require technical knowledge. Of course, there are companies where these leaders code, but there is an implicit agreement that leaders can't lead the team and simultaneously code in a project.

So, in my perspective, I believed that even non-engineers could successfully lead the team(s) because no coding is involved. And I have seen it work. The validation enforced my controversial thoughts, and I sought to become a leader of a team whose area of expertise is different than my engineering background—I have an iOS engineering background, and I'm leading a backend-heavy, non-mobile team. Now, I think a bit differently.

Well, what changed my mind? Why do I think leaders should have good technical knowledge of the topic their team is working on?

In Team Topologies, the authors talk about team-first design. When we think about Conway's Law ("Any organization that designs a system will produce a design whose structure is a copy of the organization's communication structure."), we design systems starting from the team structure. Instead of beginning with the software architecture design, team-first design applies Conway's law first. For example, if we want to create a mobile application, the system design will look different when we embed a backend engineer in the team rather than separating teams into the backend and mobile engineers. When the team is cross-functional (has an embedded backend engineer), the system will be designed in a way that maximizes the communication between mobile and backend systems (and engineers). The backend application and mobile client will be coupled. When no backend engineers are embedded in the team, mobile and backend applications will be much more independent. You might be thinking, "Why not let the engineers design the system that fulfills the business need and solves the problems instead of creating premature structures?"

It's where the problems begin. When there are separate backend and mobile teams, the system will continuously evolve to support this structure. Even if the engineers design a coupled system, Conway's law states that teams will continue separating their work on the way. Creating an initial software architecture design that demands close communication will fail in the long run. The same applies the other way around; if we have a cross-functional team, the systems will evolve to support this structure, even if it's built decoupled.

When we think about this picture, a non-technical leader probably cannot foresee it. Although they may know by experiencing these problems, it's essential to understand the system's technical fundamentals when designing teams.

As leaders have long-term visions, they have to know the technical side well enough to anticipate these problems before they appear.

There is still one scenario non-technical leaders can still be successful: they lead with great sidekicks. If a non-technical leader has a person or two next to them with whom they partner up, then it may work. If you watched Ted Lasso, Ted is an American football coach who goes to the United Kingdom to coach a football (soccer) team. Ted has no experience leading a football team. However, he creates a solid group that knows football by heart. Then he uses this group to support him in leading the team to success.

Okay, my friend, you might think about what this situation means to you. If you have a non-technical leader (first, be nice to them), try to be the one who supports them; be their partner. That way, you'll be involved in various leading activities and gain experience before becoming a leader. And in case you have an opportunity to lead a team where you have no deep expertise, find a partner or create a group that can help you on the technical side. Work very closely with them to become successful together.

Until next time, take care!

Candost

P.S. Understand how distributed systems work if you're working with one.

Reply via email | Reply via Mastodon | Comment

Structuring Teams in Organizations

Sat, 14 May 2022 00:00:00 GMT

I've been in various reorgs. Sometimes, it made sense to do a re-organization to align the organization with the evolving business better. However, one of the realizations for me is that org charts are difficult to get. They serve to identify who reports to whom but other than that, they are inefficient. When companies focus on org-charts instead of work streams and communication lines, they face major problems because they fail to identify teams' accountability. Organization charts don't reflect teams' accountability. People learn team responsibilities in time. Having reorgs prevents people from getting to know each other; thus, making the organization inefficient for a while. Especially, if the reorgs are frequent and depend on the org chart, then catastrophe awaits. People won't have time to learn the new organization before getting another reorg.

Related Note(s):
Source(s): Team Topologies by Matthew Skelton and Manuel Pais;

Reply via email | Reply via Mastodon | Comment

Conway's Law Still Holds True After Decades

Sat, 14 May 2022 00:00:00 GMT

I used to think designing systems and architectures started within the team. Engineers in the team usually don't have a holistic picture of the organization, and they design systems with their best intentions and using their understanding of constraints. After reading Team Topologies, I learned—or let's say, enlightened—that designing systems starts from designing teams; as Conway's Law states, "Organizations are destined to create software constrained by how teams communicate with each other." Before reading it, I thought that software engineering leaders didn't have to be technical because leadership is not a technical job. However, the same leaders create organizational structures and, therefore, decide how the architecture of systems will be shaped. Now I think they have to have a technical background to understand how their decision will reflect on the system design. Or they have a technical person on the table while designing the organization.

Related Note(s):
Source(s): Team Topologies by Matthew Skelton and Manuel Pais;

Reply via email | Reply via Mastodon | Comment

Limiting the communication lines to create better system design

Sat, 14 May 2022 00:00:00 GMT

There is an understanding that the more communication between teams and people, the better the work. Within the teams, this holds. However, leaders must be mindful of the communication overhead and its impact. When we unnecessarily create communication lines between teams, we are prone to develop systems that support these communication lines (a.k.a. Conway's Law). When we limit the communication between teams, we force the teams to create specific API boundaries and documentation to remove the need for communication. When the communication line is open, people will use it instead of relying on APIs and documentation. The team that offers API will also use these communication lines instead of working on a better API design or documentation.

Related Note(s):
Source(s): Team Topologies by Matthew Skelton and Manuel Pais;

Reply via email | Reply via Mastodon | Comment

Database Partitioning (Sharding)

Sun, 08 May 2022 00:00:00 GMT

Database partitioning is used to divide data into different partitions to access it faster and eliminate a single point of failure. Partitioning is usually used for performance, availability, manageability, or load balancing (scalability).

There are different methods for partitioning a database.

Related Note(s):

Reply via email | Reply via Mastodon | Comment

Vertical Partitioning

Sun, 08 May 2022 00:00:00 GMT

Vertical Partitioning is splitting database tables into multiple tables and storing data in fewer columns in each table. Normalization is also one part of vertical partitioning. However, vertical partitioning is much more than normalization. Vertical partitioning is often used when there is a need to split the static and dynamic data. Vertical partitioning is, for example, in a user database, keeping the user’s fundamental—and rarely changing—data in one database and splitting the user’s action into a different database. However, it’s possible to keep both data in the same table and use different rows for storing them; splitting increases the performance of accessing static data. Of course, when we want to reach both static and dynamic data, it will be slower. However, accessing static data is much faster.

Related Note(s):
- 60: Database Normalization;

Reply via email | Reply via Mastodon | Comment

Horizontal Partitioning (Range-Based Partitioning)

Sun, 08 May 2022 00:00:00 GMT

In this mechanism, we use range-based partitioning. We split the data to multiple databases by range while keeping the database scheme constant (i.e., using the same columns in every database table). For example, if we have a dictionary database, we can divide one extensive database into multiple ones by their first letter. So, words starting with A get into one database, and B gets into another. Our range key is the word’s first letter. The partitions can have different volumes of data. For example, the number of words starting with E is much higher than those starting with X. To balance these conditions, we either merge multiple letters into one database or split E into multiple databases by using the second letter as a secondary index. The advantage of using a range is querying more entries in ranges is much easier. The disadvantage is accessing words in the E database will be much more frequent, and it can have a high load while other databases stand idly. To solve this problem, we can use something else other than the first letter of the word as a key. Deciding which keys to use is the difficult part of this partitioning. Either the database administrator can choose partition boundaries manually, or the database can choose them automatically.

Related Note(s):
- How to Partition a Database;

Reply via email | Reply via Mastodon | Comment

Directory-Based Partitioning

Sun, 08 May 2022 00:00:00 GMT

We put a lookup service in front of the database partitions. The lookup service knows the current partitioning scheme and can tell us which shard to read or update the data. Clients first communicate with the lookup service to learn which partition they must go to, then query/update the data. Using directory-based partitioning, we can add additional database servers or change the partitioning schema without impacting the application. The disadvantage of this method is that the lookup table is a single point of failure.

Reply via email | Reply via Mastodon | Comment

Mektup #30: The Exceptional Books, Articles, Videos, and Communities That Made Me a Better Engineering Leader

Tue, 03 May 2022 00:00:00 GMT

Hey friend,

I rarely share links in this newsletter because these letters are not for link curation; I aim to plant ideas, and the rest is for you to learn because everybody’s learning method varies. However, it doesn’t mean that I won’t share any resources. Today, I will share what changed my perspective, helped me grow into engineering management, and still helped me grow as a software engineering leader.

On another note, this is one of the ways for me to appreciate folks who produced these resources. Creating something is extremely difficult; creating something that helps people in their lives is unique. I hope at least one of these resources will benefit you as well.

The list seems long, but bear in mind that studying them took me years. Also, I only recommend the best resources that I’ve devoured and helped me.

On this journey, I recognized that when you grow as a person, you—naturally—grow as an engineer. How you consume the information and interpret it defines your wisdom. For leaders’ growth, not everything should be related to software engineering.

Let’s start with my boosts in life—the fundamentals.

Learning How to Learn

Course Link

While I was studying Deep Learning Specialization on Coursera, I realized that my learning method was not that great. I often forgot things and had to study from scratch. This course taught me the fundamentals of learning methods. Although I still don’t follow the exact same method all the time, I changed my learning strategy to a more effective one.

How to Read a Book

Book Link

Many people learn how to read in school. I learned it from my uncle—who was a teacher—before school. But nobody taught me how to read a book. Teachers and the education system force us to read books, and every single time, they want us to read cover to cover. When I realized that not every book is worth spending extensive energy on, I looked for what I could do to get the most out of a book if it doesn’t worth reading its 800 pages. And I found How to Read a Book by Mortimer Adler. A book about reading a book. How meta. And how amazing it is. (I hopefully will share my notes from the book later) The book is not an easy read (it was first published in 1940!, and updated in 1972), and in case you want to grasp the main idea, FS.Blog’s guide is great.

How to Speak

Video Link

When I wrote about speaking, writing, and ideas, I was studying to improve my speaking skills. As a leader—and a podcast host—speaking is a fundamental skill that I want to enhance. In this MIT lecture on speaking, Patrick Winston said, “Your success in life will be determined largely by your ability to speak, your ability to write, and the quality of your ideas. In that order.” 💯 I won’t say more. Watch the 1-hour long lecture.

Non-Violent Communication by Dr. Rosenberg

Book Link

As a leader (people manager or staff+ engineer), empathy is one of the central skills. It’s the force within you. Unlike the Star Wars universe, it’s a skill you can learn. If you want to lead people, you have to understand their needs. You have to ask the right questions to persuade them. This book teaches to see a person thoroughly. Even Microsoft CEO Satya Nadella gifted this book to every member of his senior leadership team when he became the CEO. Well, I agree with Satya that every leader has to read this book.

FS.Blog Membership

Website Link

When I discovered The Knowledge Project Podcast’s interviews with outlandish guests, I was hooked. I dove into the whole archive (over 100+ episodes) and took many notes, and pondered on many quotes. Then I took a look at their website. I found a fantastic community and even more high-quality resources. Their content helps me make better decisions and improve my life and personality. You don’t need to become a member; their free newsletter and podcast are already gems.

Now onto some engineering-specific resources.

The Engineer/Manager Pendulum

Article Link

This article changed my perspective on management AND engineering. Before I decided to become a manager, I ALWAYS believed that if I switched to management, I could not return to engineering. That’s why the decision was tough for me because I enjoy both sides. Now, I know that I want to stay in the pendulum. A few years of people management and a few years of engineering will—probably—be the way I will work. At last, that’s what I think now.

Rands Leadership Slack

Website Link

Over 20000 people get together in hundreds of channels and help each other out. This leadership Slack—which is focused on engineering leadership—is a fantastic resource for me to learn from others. I also ask my questions, get help, and help others. It’s free, and the community is impressive. I love their safe environment and excellent level of moderation.

Gergely Orosz’s Blog

Blog Link

I’ve read many articles Gergely wrote on his blog, and I’m also a subscriber to his newsletter. His writing gives great insights into the industry and leadership. Especially these ones were beneficial to me: 1, 2, 3, 4, 5, 6, 7. Also, his book was a great read.

Fundamentals of Software Architecture Book

Book Link

I started reading this book with a book club at work. Although I couldn’t join every session in the book club, this book made its place in my library, and I often reopened and (re)read some chapters frequently. It also helped me record the two most popular episodes (1, 2) in my podcast. It’s an excellent must-have book that supports me in understanding how to approach architecture and the differences between various software architecture styles.

That’s all for resources. But I think there are a few more things worth mentioning, things that made me a better engineer and leader: reading documentation when I have problems, taking long walks during the day to think about certain things, meditation, and countless other books (to name a few more: Deep Work, Atomic Habits, Designing Data-Intensive Applications, Radical Candor, Thanks for the Feedback, Writing to Learn) and blog articles I’ve read.

Last but not least, whatever I wrote, talked about, and the people whom I had a conversation with made me better at my job and in my life. I appreciate every single guest on my podcast and every person I had a conversation with, and I’m grateful that they made me a better person, engineer, and leader.

What's the best resource you have ever read/watched/listened to? Let me know your suggestions.

— Candost

P.S. Managing up is difficult, but it sets you apart from the crowd in your growth.

A Quote I'm Pondering

*"Childhood is when you keep gaining, old age is when you keep losing."* — Ursula K. Le Guin

Reply via email | Reply via Mastodon | Comment

Think Again Book Review, Summary, and Notes

Thu, 28 Apr 2022 00:00:00 GMT

How Strongly I Recommend It: 7/10

How Likely I Will Gift It: 5/10

What is Think Again Book by Adam Grant about?

The book is about recognizing how much time we spend thinking and forming our thoughts and how less time we spend on not even going back and evaluating them, although we live in a rapidly changing world. Adam Grant conveys the importance of rethinking our easily-formed opinions and explains how to reconsider them and spread the same strategy to the people around us. Grant explains them in three steps: individual rethinking, interpersonal rethinking, and collective rethinking.

🚀 The Book in 3 Sentences

We often form our opinions easily but rarely reconsider them.
We don't always need to think more and more about many topics; rethinking can solve many of our problems once we open our minds to change.
Creating a learning environment and surrounding ourselves with open-minded people demands changing how we approach people around us.

🎨 Impressions

The book is easy to read. It sparked moments when I closed the book and needed to think about what I had read. Although the reading was enjoyable, I deem the text long. I understand that the narrative is important, and it makes reading fun; I came to the point of skimming one or two stories instead of reading them fully. This is not necessarily a bad thing. Every book and each chapter demands a different reading style. With all that, I liked the idea the book brings: rethinking. Adam Grand didn't just say to rethink what you think but went on a journey and explained the psychology around rethinking. So, the book is more prosperous than I expected. It could've been shorter, but it's not too long, either.

Who Should Read It?

People who want to create a learning environment, especially leaders.

☘️ How the Book Changed Me

How my life/behavior/thoughts/ideas have changed as a result of reading the book.

After reading the first chapter, I began recognizing my behavior in different parts of my life (work, personal). At work, I realized I play all the four mindsets mentioned in the chapter (preacher, prosecutor, politician, scientist). However, I'm more of a preacher and prosecutor than a politician at home.
After reading, I feel like I can be a better leader if I apply a few things from the book to my work: using motivational interviewing when I debate ideas, coaching people better by asking more questions, etc.
I also understood, once more, the importance of keeping debates on talking about how to do a certain thing instead of why we do it. As a leader, I have a stronger self-argument to think about the why more clearly.

✍️ My Top 3 Quotes from Think Again

"If knowledge is power, knowing what we don't know is wisdom."

"Who you are should be a question of what you value, not what you believe."

"We won't have much luck changing other people's minds if we refuse to change ours."

📒 Think Again Chapter Summary + Notes

A Preacher, a Prosecutor, a Politician, and a Scientist Walk into Your Mind

We see other people's behavior while seeing our intention. When someone misses the point or needs to rethink their approach, we swiftly recognize that. When it comes to our own ideas, we favor feeling right over being right. We often don't form second opinions while expecting them from others.
Adapting to a changing environment is not something companies do. It is something people do. Many people become experts in their fields and stay there without changing their stance or knowledge stack. The comfort zone makes them vulnerable to change. However, the bests adapt to changing environments with their everyday decisions.
Preacher-Prosecutor-Politician Mindsets:
- Preacher: When our beliefs are in jeopardy, we begin preaching to protect and promote our ideas.
- Prosecutor: When we recognize other people's flaws in their arguments, we prosecute them and try to prove them wrong.
- Politician: When we seek to win the audience, we lobby and campaign our beliefs and ideas for approval.
Scientific Thinking:
- Thinking as a scientist (experimentation, skepticism, and reconsidering the approach) forces us to reconsider our stand all the time. Although scientists don't always apply scientific thinking in their lives, the method works. When we think we're smart, we change our minds less (confirmation and desirability bias). Scientific thinking is not only reconsidering; it is also being skeptical, searching for what might be wrong when everything is normal.

"If knowledge is power, knowing what we don't know is wisdom."

"Our convictions can lock us in prisons of our own making. The solution is not to decelerate our thinking—it's to accelerate our rethinking."

The Armchair Quarterback and the Imposter: Finding the Sweet Spot for Confidence

The most successful leaders have both humility and confidence. They believe in their strengths; they are also aware of their weaknesses. They can change their minds when they are proven wrong.
Feeling like an imposter (imposter syndrome) has also its advantages:
1. Motivates us to work harder. (naturally)
2. Motivates us to work smarter. If we don't believe we're going to win, we have nothing to lose to rethink our approach.
3. It makes us better learners—the doubt of not knowing opens us to learning from others.

The Joy of Being Wrong: The Thrill of Not Believing Everything You Think

Our previous knowledge and beliefs make us less open to new things. That's why we often hear "That's not how we do things here." phrases. When we haven't formed any beliefs, we are more open to being wrong. We're open to change because we're learning. When we have expertise in one topic, it's difficult to walk away from our beliefs, even if they are foolish.

"Who you are should be a question of what you value, not what you believe."

When we define ourselves, it's crucial to think about what we are tying up our identity to. Materials and monetary stuff are not always a good idea. When a person explains themselves with things they own, they will have difficulties changing their identities. On top of that, when people define themselves with opinions rather than values, they also lose flexibility. As they will tie their identity to a certain idea (such as supporting one party's ideas in politics), they will defend these ideas more and more and become inflexible. Wherever we put our identity defines our adaptability to changes around us.
We often don't change our beliefs or ideas quickly. We usually defend them, although we form them very quickly. When we form opinions, we don't even think about why we might be wrong. Even thinking once about a possible reason we might be wrong will improve our ideas, show us our weaknesses, and break our overconfidence.
Thinking in the long term has a prolonged impact. When we focus on being right at the moment and sticking to our thoughts all the time, we increase the risk of being wrong in the long run. When we're flexible with our opinions, we feel comfortable changing them to being right in the long term.
Admitting we were wrong is considered a weakness by many people. However, that's what makes us strong. When we admit we were wrong, we eliminate other people mocking or publicly shaming us. We become untouchable. Admitting our mistakes makes us powerful.
When something is wrong, there is no need to blame whose fault it is or whose responsibility that mistake is. What matters is it's our responsibility to fix that. When that mistake is in our mind, there is no other person than us to correct or change that mistaken opinion.

The Good Fight Club: The Psychology of Constructive Criticism

Relationship conflicts are worse than task conflicts. When people have relationship conflicts, they focus on topics unrelated to work. Their criticism of each other is based on how they behave toward each other. In task conflicts, people focus on the work, and their goal is to find out the best way to do the work. Task conflicts are necessary. Without conflicts, there is no harmony; there is only apathy.
When in task conflicts, we learn from the other side. We learn from people who challenge our thought processes. When we avoid arguments, it doesn't mean that we have good manners; it means we ignore the other side's views and don't value their perspectives.
People like others who agree with their perspective more. However, when we say "agree to disagree," we actually avoid these thoughts and put up walls around our ideas. If someone is challenging our thoughts, it means they value our opinion. We need to create cooperative groups that can disagree with each other while showing respect for each other.
When people argue about why they should do something in one way or another, they cannot bring out the best solutions, and the discussions end up in relationship conflicts. They should have one common why and argue over how to do it. When discussions happen over how to part, the conflicts tend to stay as task conflicts and be productive. That's why it's crucial to have leaders who clarify the why so that people can focus on the how part.

Dances with Foes: How to Win Debates and Influence People

Debates are not wars that we have to fight constantly; they are more like a dance in that we have to move back and forth and create harmony. We have to listen carefully and find common arguments and agree with some of the other side's arguments. We need to step back and acknowledge their valid points instead of constantly supporting our argument with more reasons. We shouldn't go into either defense or offense mode; we have to see the debate as dance and use stronger and fewer reasons.

"We won't have much luck changing other people's minds if we refuse to change ours."

"We don't have to convince them that we're right. We just need them to open their minds to the possibility that they might be wrong. Their natural curiosity will do the rest."

To change other people's minds, we have to present humility, acknowledge their valid points (so we are reasonable), and ask questions to open their minds. The best negotiators ask many questions—more than average negotiators.
In any heated argument, we can stop and ask, "What evidence would change your mind?"
People are interested in hiring people who acknowledge their weaknesses rather than bragging about their strengths.
When we ask questions, we invite people to join our dance. When we assume things and think on their behalf, we never get them on the dance.

Bad Blood on the Diamond: Diminishing Prejudice by Destabilizing Stereotypes

Convincing others to destroy their stereotypes demands counterfactual thinking. Like asking questions in debates, we should ask questions and put the other side in situations where they understand how they formed these stereotypes. We should ask questions that will let them put themselves in someone else's shoes. When people realize how easy it is to develop stereotypes, they change their perspectives. We need to ask questions that nudge them to explore the origins of their thoughts and beliefs, and we need to provoke them to reconsider their stance.

"Many of our beliefs are cultural truisms: widely shared, but rarely questioned."

When people interact with others with whom they formed beliefs against them, they often destroy their beliefs.
In general, the people who hold power should question their beliefs more because they will likely form stereotypes and prejudices that will not be questioned.

Vaccine Whisperers and Mild-Mannered Interrogators: How the Right Kind of Listening Motivates People to Change

Motivational interviewing consists of
- Asking open-ended questions
- Engaging in reflective listening
- Affirming the person's desire and ability to change
- Summarizing
Listening well is not only listening. It's asking questions, being curious, and responding to other people. If someone just seems like they listen to you, you feel that they are not interested in what you're saying. Listening well requires listening with interest.
The Righting Reflex: the desire to fix problems and offer answers. An excellent motivational interviewer resists this reflex.
Empathetic and uncritical listeners make people less anxious and defensive. People feel less stress and encourage themselves to explore their thoughts more deeply, recognize more nuances, and openly share them.

"Communicators try to make themselves look smart; great listeners try to make their audience feel smart."

Listening is giving the best gift: our attention

Charged Conversations: Depolarizing Our Divided Discussions

To overcome binary bias, exposing ourselves to various perspectives is necessary.
Doubtful experts are more persuasive. When people hear unknowns and uncertainties from the experts they trust, they pay more attention to the argument.
Changing the focus from why to how reduces polarization and enables people to have more constructive conversations.
Seeing and appreciating complexities remind us that there is no best and most effective behavior, and all of them have consequences.
Binary bias is not only in our behavior but also in our emotions. When we face an adversary, it becomes easy to be stuck in one feeling, and it's difficult to rethink our position later on.

Rewriting the Textbook: Teaching Students to Question Knowledge

Thinking like a fact-checker requires three guidelines:
1. Interrogate the information instead of just consuming it.
2. Reject popularity as its reliability.
3. Recognize that the sender of the information may be different than its source.
People learn more when they look at their solutions and try different approaches. Rethinking helps to master their craft.

That's not the Way we've Always Done It: Building Cultures of Learning at Work

Psychological safety and accountability play a critical role together in learning teams.
Psychological safety is when people can express their concerns and suggestions while knowing they will be well received. These cultures foster trust, respect, and openness.
In performance cultures, where we praise performance more, people rely on experts more and trust their word instead of thinking—and rethinking—their approach.
To create psychological safety, leaders need to state their weaknesses out loud and make a public commitment to be open to feedback.
Psychological safety requires humility: "confident humility to state that we're working in progress."
When we explain some process behind a decision to someone else, we tend to see vulnerabilities more clearly, and we think more critically.
When best practices become the standard, they tend to get worst practices because people blindly follow them and stop improving them.

Escaping Tunnel Vision: Reconsidering Our Best-Laid Career and Life Plans

Asking kids about what they want to be when they grow up nudges them to place their identity in their work. They should actually think of the work as something they do rather than something they are. When they see it as something they do, they become more open to exploring their options and various responsibilities in their adult life.
Have regular career check-ups. Have the same for relationships. Overall goal: Expand repertoire of possible selves.
- For career: once or twice a year.
  1. Find out people who inspire you. Observe what they do day-to-day.
  2. Form a hypothesis about how their style/processes might align with your interests, skills, ways, and values.
  3. Test out by running experiments. Do job interviewing, shadowing, and internships; the goal is to get a taste of work.
- For relationships: once in a while when facing difficulty.

Reply via email | Reply via Mastodon | Comment

#28: How to Present Solutions as Software Engineers

Tue, 26 Apr 2022 00:00:00 GMT

28: How to Present Solutions as Software Engineers

In response to: https://candost.substack.com/p/28-how-to-present-solutions-as-software

Reply via email | Reply via Mastodon | Comment

Mektup #29: Building correct relationships will help you climb the Ladder

Tue, 19 Apr 2022 00:00:00 GMT

Hey friend,

Over the last three years, I've realized the importance of relationships. Today, I want to talk about how I failed, how this failure cost me an extra year to get a promotion, and what I've learned.

When I wanted to become an engineering manager, I thought I had enough skills to make the jump, and later I learned I partially had. Yet, I needed an extra year to make them visible to various people. Why has it happened?

I had great relationships with my peers and my manager. I was acting like a leader in the team. At that time, we had one manager acting in both Product Manager (PM) and Engineering Manager (EM) roles. The organization started to separate these responsibilities into two people. While our manager was more focused on the PM role, there was a possibility of me becoming an EM. Many things happened along the way, and once I started pushing more, I failed because I didn't have relationships with people who could vouch for me. I had relationships with my manager, and I thought that should be enough because the team was elevating me to the EM position. It cost me a year to build missing relationships.

Here is what I have learned.

Engineer’s Circle

When working in a team as an engineer, you have your peers, PM, and manager. Your circle is defined well, and you rarely go out of them. You may talk with project stakeholders and other engineers in the organization, but you rarely leave your circle. Your inner circle might know your career plan, what you want to learn, and which promotion you’re looking for. But that’s it.

Leader’s Circle

If you become a manager or staff engineer, your first and essential relationship will be with your team, stakeholders, and your manager. Then with your peers and your manager’s peers. And your success depends on all levels.

If you don’t have good relationships with your team, your team won’t be successful.

If you don’t have a solid relationship with your manager, your team will fail because you won’t find the support your team needs.

If you don’t have good relationships with your peers, it will be difficult for your team to collaborate with other groups. Once you have valuable relationships, they will enable you to run cross-team initiatives and jump to the next level.

Why do you need these relationships?

You need the first two layers of relationships to go to the next level. If you stay there, you’ll be missing some big pieces of the puzzle. You need to break out of these circles and slowly create your third inner layer. This is where I failed. I developed great relationships with the inner layers and thought they would elevate me to leadership. Once I learned that it was still not enough, I spent a long time working on expanding my circles.

If your organization doesn’t have separate promotion boards, you have to increase your visibility and build relationships with the next levels because these people will decide on your promotion. Although you will still need to develop your promotion case, these relationships will be required.

Having your manager on your side is not enough. Decision-makers might trust your manager’s judgment, but they want to see it themselves. Once they know your thoughts, experiences, and knowledge, they can vouch for you for the next level. You need these people to talk about you when you’re not in the room. Your name should come up often.

How to Make the Jump?

Understanding different circles and creating these relationships take time and effort. You might think that you don’t have the time and energy for all these people. However, you can do a few simple things.

Write people on Slack or so and ask them questions. It doesn’t have to be a meeting all the time.
Even if you know some of your peers, involve others in discussions. Ask them questions to build relationships.
If you have a topic you are passionate about, let everyone know. Your name should be attached to the topic. But don’t get stuck on one topic; regularly add new ones to your repertoire.
Increase your visibility by joining cross-team initiatives.
Become a host or moderator in a few meetings outside of your team.
Have random one-on-ones with people in the next level.
Have regular but less frequent one-on-ones with your skip-level managers.
Have sync one-on-ones with your peers.

The more touchpoints you have with the outer circle, the easier it will be for you to grow. When you’re a leader, your goal is not to learn everything in the organization; it is to know who to go to when you have a question. These people will eventually elevate you in the long run because you will solve problems faster and learn better. It will be a win for everyone.

Don’t confuse these relationships with friendships. It’s sometimes okay to look for a friendship, but not all the time.

Build trustful and solid relationships with people who will advocate for you and your work when you’re not in the room.

— Candost

P.S. Career frameworks are never enough.

A Quote I'm Pondering

"Can we listen with an attention in which there is no interpretation, no opposition or acceptance, so that we understand totally what is being said?" — Jiddu Krishnamurti

Reply via email | Reply via Mastodon | Comment

Mental Health for Professionals

Sat, 16 Apr 2022 00:00:00 GMT

How we grow up shapes us—all of our thoughts, lifestyle, values, and more. Growing up in a culture where work is the only thing people care about profoundly impacted how I value myself. In Turkish culture, our lives are less valuable than our professions. Societal structures are created according to work. The more money you had, the more people respected you. Before the 2010s, people had more respect for specific professions such as lawyers, doctors, or engineers. These days, it's only money. But we still keep asking kids what they want to become when they grow up. These kinds of questions falsify children's thinking about their values. They conceive work as a personal value. They place their values in the wrong place. Instead, we should show work as something they do instead of something they are. Later on, this perspective makes them more open to various options.

Related Note(s):
Source(s): Think Again by Adam Grant;

Reply via email | Reply via Mastodon | Comment

Instead of giving advice directly, use an empathetic approach

Sat, 16 Apr 2022 00:00:00 GMT

"Here are a few things that helped me. Do you think any of them might work for you?" is often implicit. (Use the question instead of giving recommendations or commands.) When it's implicit, people don't understand and become resistant to changing their behavior. Also, even when implicit, there are people easy to change when the motivation comes from their manager, whom they trust.

Related Note(s):
Source(s): Think Again by Adam Grant;

Reply via email | Reply via Mastodon | Comment

Overcoming Binary Bias and Polarization

Sat, 16 Apr 2022 00:00:00 GMT

Polarization is one of the biggest problems in the information age. Creating echo chambers is easy. When we face charged conversations or opposing perspectives, we often discard them and stay in our comfort zone. One of the fundamental reasons for polarization is discussing the why.

When we find common ground and realize that we can actually focus on the how part of the problem, we expose ourselves to different perspectives—we overcome binary bias. Coming to this position is not easy. When we face unknowns and uncertainties, we raise our defensive walls.

To unstuck ourselves from binary bias, we must be exposed to different perspectives and become more doubtful.

Related Note(s):
Source(s): Think Again by Adam Grant;

Reply via email | Reply via Mastodon | Comment

Have regular career and relationships check-ups

Sat, 16 Apr 2022 00:00:00 GMT

Regular career check-ups and running experiments in various domains are great strategies. It's difficult to see things from the outside. We often have wrong perceptions about a job until we start doing it. For example, until I became an engineering manager, I didn't know the importance of prioritization and the stress level that it produces. If I could have had more chances to try the profession, I might have chosen a different one.

We should have some checkpoints in our careers to evaluate how it's going.

Related Note(s):
Source(s): Think Again by Adam Grant;

Reply via email | Reply via Mastodon | Comment

Summarize when you want to clarify the other side's change request

Sat, 16 Apr 2022 00:00:00 GMT

When a person wants to change something and consult us as a coach or manager, summarizing their request helps clarify what we understand from their desire to change and catch any misunderstandings. As guides (or coaches), we're not done until the other person reaches their goals. It tends to stop after the person changes their idea, but without them being done, we cannot be done. Our goals have to align in the end. Otherwise, nobody will change their mind.

Reply via email | Reply via Mastodon | Comment

Listen with attention and ask questions with curiosity to encourage others to be open

Sat, 16 Apr 2022 00:00:00 GMT

When we listen, we give the best gift: our attention. If we take time and listen to someone, why shouldn't we do it well? We have already given our time. We could also share our attention too. When people don't give their attention while listening to someone, the other side feels it. Listening well is not looking like you're listening but also consists of asking questions with curiosity and responding to the other side. Empathetic listeners make others relaxed and put down their defensive walls. People feel less stress when talking to these listeners. That's why when these listeners ask questions, the talkers encourage themselves to explore their thoughts more deeply and share what they have found.

Related Note(s):
Source(s): Think Again by Adam Grant;

Reply via email | Reply via Mastodon | Comment

Relationship vs. Task Conflicts

Fri, 15 Apr 2022 00:00:00 GMT

When we think about conflicts at work, we see different behaviors and approaches.

It's difficult to keep relationships out of work for some people. Whenever someone criticizes their work, they take it personally and become defensive. We see this behavior in relationship-based cultures. For example, a stereotypical Turkish person falls slightly into this category. Whenever you give negative feedback on their work, they take it personally because relationships are essential at work, as many people make friends. However, we see stereotypical Dutch people giving harsh feedback about the work in front of others without hesitation because they are focused on bringing out better work. They think it will improve their relationship with others because they show that they care about someone else's work. There is no right or wrong here; both have pros and cons.

However, when we focus on the conflict and discard cultural impact, task conflicts are more favorable in the business world. Relationship conflicts focus on how people behave toward each other. "She never listens to me, always becomes defensive," "He said that he would join the meeting, but he is always late to meetings where I'm the moderator." On the other hand, task conflicts focus on the work; the goal is finding out the best way to finish the task. "The process changes you made impacted us badly, and I think we should have done it the other way around," "We shouldn't merge the Pull Request who breaks the pipeline." Although these sentences might be directed to one person, their focus is on making things better, not making someone else better.

When we focus on showing people's weaknesses, they quickly get defensive. When we expose the broken processes and offer better ways, we unbind the feedback from the person.

Additionally, avoiding conflicts doesn't solve anything. Conflicts are necessary for improvement and growth and are a healthy part of relationships. Adam Grant said, "Without conflicts, there is no harmony; there is only apathy." If we always agree with each other, there will always be one side sacrificing something. They either hide their true thoughts or get disturbed after a while. When we always agree on it, it feels fake. The relationship doesn't look and sound natural. Each individual is different, but society forces us to be the same. Always confirming each other and avoiding conflict doesn't help us find the truth. When there is no truth in the relationship, we cannot be honest and, therefore, cannot form trust.

We learn from people who challenge our thought processes. Avoiding arguments doesn't showcase that we have good manners; it means we ignore the other side and don't value their perspectives. Embracing and encouraging task conflicts are better for improving our collaboration.

These are my thoughts on a topic from Think Again by Adam Grant.

Reply via email | Reply via Mastodon | Comment

Persuading others requires accepting their arguments and building empathy

Fri, 15 Apr 2022 00:00:00 GMT

I've been on the side of pushing my arguments more and more. I always chose the most logical side (at least the one that looked most logical to me) and always looked for extra ideas to support my reasoning. I thought I could win debates if I stuck to the facts and counted one point after another. Yet, some things come with experience and age. My way was the wrong one to persuade people. I didn't learn it from this book, but this book strengthened my learning; it enhanced my perspective. When I accepted some of the arguments in discussions, I recognized that people become open to change. As I showed my openness to accept counterarguments, they also became less defensive.

We should change our perspective, see the other side's strongest argument, and acknowledge and give credit to build empathy. If we insist on our arguments and count reasons one after the other, we don't create a conversation; we enter prosecutor or preacher mode. When we acknowledge the other side's valid points, we present humility.

Related Note(s):
Source(s): Think Again by Adam Grant;

Reply via email | Reply via Mastodon | Comment

Present humility and ask questions to persuade others

Fri, 15 Apr 2022 00:00:00 GMT

Irrationally repeating the same arguments, staying the same line repeatedly, and not budging frustrates people, and they raise shields. If we don't present humility and never accept valid arguments, we become irrational. We can ask, "What evidence would change your mind?" in any heated discussion to break this habit. Asking questions with curiosity shows them that we're open to changing our minds instead of being stubborn over our arguments. When we show humility and weaknesses in our arguments, the other side joins the debate dance, and we begin forming trust with the other side.

Related Note(s):
- 4a: On Being Curious;
- 8d: Ask Questions;
Source(s): Think Again by Adam Grant;

Reply via email | Reply via Mastodon | Comment

Ask questions that nudge the other side to explore the roots of their stereotypes

Fri, 15 Apr 2022 00:00:00 GMT

The fish is never aware of its surroundings. Everywhere is water for it; thus, it will never learn from its environment. Humans form stereotypical thoughts according to the environment they are in. Due to the biological nature of stereotypical beliefs, breaking them requires going out of the route and getting into someone else's shoes. Like asking questions to convince people, we have to ask questions that can challenge these stereotypical thoughts. If we want people to reconsider their stance on specific arguments, we need to ask questions that nudge them to explore the origins of their ideas and beliefs. Once they start exploring how they formed these stereotypes, they realize how easy it was to build them.

Source(s): Think Again by Adam Grant;

Reply via email | Reply via Mastodon | Comment

Unclear WHYs create more relationship conflicts

Thu, 14 Apr 2022 00:00:00 GMT

When Simon Sinek recommended starting with why, there was a reason behind it. One of the arguments he had was, "With a clear WHY, everyone inside the company will be able to make decisions as clearly and as accurately as the leader." When the why is unclear, people tend to focus on why they should do something in that way or another way. Unclear direction creates adversaries. An unclear mission creates relationship conflicts. The reason should always be clear when we want to do something. Then, the discussions can focus on how to do that thing. Focusing discussions on HOW improves the outcome because it promotes task conflicts instead of relationship conflicts. Leaders should always clarify the WHY part so that the team can focus on HOW to do things.

Related Note(s):
Source(s): Think Again by Adam Grant;

Reply via email | Reply via Mastodon | Comment

#27: Problem-Solving Skills & A Strategy for Software Engineers

Tue, 12 Apr 2022 00:00:00 GMT

27: Problem-Solving Skills & A Strategy for Software Engineers

In response to: https://candost.substack.com/p/27-problem-solving-skills-and-a-strategy-065

Reply via email | Reply via Mastodon | Comment

Relationship vs. Task Conflict

Fri, 08 Apr 2022 00:00:00 GMT

When we think about conflicts at work, we see different behaviors and approaches.

It's difficult to keep relationships out of work for some people. Whenever someone criticizes their work, they take it personally and become defensive. We see this behavior in relationship-reliant cultures. For example, a stereotypical Turkish person falls slightly into this category. Whenever you give negative feedback on their work, they take it personally because relationships are essential at work, as many people make friends. However, we see stereotypical Dutch people giving harsh feedback about the work in front of others without hesitation because they are focused on bringing out better work. They think it will also improve their relationship with others because they show that they care about someone else's work. There is no right or wrong here; both have pros and cons.

However, when we focus on the conflict and discard cultural impact, task conflicts are more favorable in the business world. Relationship conflicts focus on how people behave toward each other. "She never listens to me, always becomes defensive," "he said that he would join the meeting, but he is always late to meetings where I'm the moderator." On the other hand, task conflicts focus on the work; the goal is finding out the best way to finish the task. "The process changes you made impacted us badly, and I think we should have done it the other way around," "We shouldn't merge the Pull Request who breaks the pipeline." Although these sentences might be directed to one person, their focus is on making things better, not making someone else better.

When we focus on showing people's weaknesses, they quickly get defensive. When we expose the broken processes and offer better ways, we unbind the feedback from the person.

Additionally, Conflicts are necessary for improvement and growth and are a healthy part of relationships. Adam Grant said, "Without conflicts, there is no harmony; there is only apathy." If we always agree with each other, there will always be one side sacrificing something. They either hide their true thoughts or get disturbed after a while. When we always agree on it, it feels fake. The relationship doesn't look and sound natural. Each individual is different, but society forces us to be the same. Always confirming each other and avoiding conflict doesn't help us find the truth. When there is no truth in the relationship, we cannot be honest and, therefore, cannot form trust.

Related Note(s):
Source(s): Think Again by Adam Grant;

Reply via email | Reply via Mastodon | Comment

Productivity Scam and Perception of Time

Thu, 07 Apr 2022 00:00:00 GMT

I have been trying to optimize my life for a while. I looked for what I could do to organize my life. If I search about productivity and life organization, Google shows me almost four billion pages for “productivity.” I have read many of them while hoping they will help me. After a while, I realized my problem was not being unproductive. My problem was my understanding of time. The word productivity became so polluted that we forgot how time works. We think that time is limited, which is accurate, and we try to bring out the best. This limitation comes from comparing it with eternity. We believe our time in life is so tiny that we have to rush everything. Yet, we have more than 70 years on average; it feels like an eternity. Thinking about that long time, I asked myself, “Why do we rush everything? Why can’t we take the long road and slowly move while consuming everything around us in the best way possible?”

While keeping this wondering in my head, I’ve met with Oliver Burkeman’s thoughts about productivity and time after reading a wonderful piece from Maria Popova in Marginalian.

This strange moment in history, when the time feels so unmoored, might, in fact, provide the ideal opportunity to reconsider our relationship with it. Older thinkers have faced these challenges before us, and when their wisdom is applied to the present day, certain truths grow more clearly apparent. Productivity is a trap. Becoming more efficient just makes you more rushed, and trying to clear the decks simply makes them fill up again faster. Nobody in the history of humanity has ever achieved “work-life balance,” whatever that might be, and you certainly won’t get there by copying the “six things successful people do before 7:00 a.m.”

Rushing every task, job and finishing everything quickly fastens the process of refilling. Productivity is a never-ending scam. The more we try to be productive, the more we are sucked into extra shallow work. We forget that we still have long years and act as if we are about to end our time.

We will never control everything that’s going on. There is no way other than accepting the reality that life is messy and we will never have work-life balance by just copying other people who got up early at 5 a.m. and did X number of things.

Constantly increasing productivity is a capitalist scam that increases the output while promoting more happiness and satisfaction by giving rewards, especially in the knowledge worker community. I’ve fallen into this trap and confused productivity with happiness. When I produce more, I tend to think I’m happy. A small dopamine rush after completing a to-do item gives me pleasure and, as a result, demands more from my life because I take that load and think that I can do more all the time. Yet, I can’t because life puts various difficulties.

Whenever life amplifies the difficulties, we choose the easiest way out. That’s what Rainer Maria Rilke observed as well.

“People are drawn to the easy and to the easiest side of the easy, but it is clear that we must hold ourselves to the difficult.”

Although Rilke was talking about the difficulty of solitude, there are other things around us that are difficult but serve us the best. For example, the best non-fiction books are often the most difficult ones to read. Some of the best movies are the longest ones you have to watch with focus. The best games are the most challenging ones that take you into a story and teach you something else than just a game. And the best writer is the one who spends more than 10 years changing with words with every piece. The best Japanese swordsmith spends around 18 months on a single Katana and does not care about productivity. The process has to be slow. Whenever the expert rushes, the result will show itself.

It takes years to become an expert, and there is no to-do list for a swordsmith during the training; it’s the leisurely pace that brings the best. It breaks our hasty relationship with time. We have to slow down and accept that reality sucks, and there is nothing we can do about it. Life will always show its difficulties and will throw us off track. Improving our productivity and processes won’t help at all unless we change our perception of time and take some things slowly.

Reply via email | Reply via Mastodon | Comment

Mektup #28: Changing jobs to seek happiness won't bring you what you want

Tue, 05 Apr 2022 00:00:00 GMT

Hey friend,

For the last two years, we have faced different challenges worldwide. Many surroundings have made us feel overwhelmed, whether it was a pandemic, being stuck at home, or wars.

On top of that, we have daily work stress, which often significantly impacts our happiness. These situations resulted in A Great Resignation wave in many countries. While we’re in this era, I wrote an article about my suggestion to some people: do not change your job. The article got a lot of comments and criticism. One thing I realized at that time was not making it clear that I was coming up with my suggestion backed by research. Now that you’re here. Let me explain why I think you shouldn’t change your job if you’re not open to changing yourself.

In the Great Resignation, software engineering salaries skyrocketed, and they are still increasing. Many companies hired conservatively during the pandemic. However, with the virus getting weaker in every variant and vaccination spreading worldwide, people looked for a change in their lives with the hope of getting more money (who can resist not doubling the salary?) and getting happier.

In the article, I said that if you really need more money, I won’t argue that you change your job. However, if you’re after happiness and you think more money will make you happy, that’s where you might be wrong.

❗Before you read the rest, I want to make one point prominent: As software engineers, we’re in a privileged situation where we can get a ton of money to perform our profession while sitting at a desk. When we compare it with many professions, we’re in a privileged position that we should all be aware of.

There are many research projects around money and happiness relationships. There is a single chart that explains this relationship (a.k.a. fulfillment) well.

Source of the Image: Investment Moats

In this chart, the “Enough” spot depends on you. Everyone has different levels of fulfillment. But many software engineers are already above their comfort level.

Let me quickly tell the story of Buddha, a well-known spiritual leader. Buddha was born into a wealthy family. Being able to reach out for anything he wanted didn’t make him happy, and he looked outside and saw that people were happy outside of his palace. So, he sought poverty, thinking it would be a satisfying life as he saw poor people happy. That didn’t work either (as we can all expect). He started thinking about the reasons and eventually found happiness in the middle ground. That point is the comfort point of the fulfillment curve you see above. For Buddha, comfort was enough.

Finding where that top point in your life is the tricky part of happiness. And that’s the part I want to talk about. According to scientific research, our happiness is 50% genetic; we have nothing to change there; our personality has a huge impact. Of the remaining, 10% is the environmental impact; what’s happening around us, the company, and the world. This is the part Buddha tried to change at first by leaving the palace and living on the streets. It’s only 10%, yet we expect more happiness from the environment than we attribute to our inherited genetics. The remaining 40% is intentional activity; this massive chunk of happiness literally depends on us. How we approach events around us, think about what we do, and understand and interpret our life and work experiences form 40% of our happiness. This portion was what Buddha found out when he sat down and thought about life.

When you change jobs to be happier, you are—hopefully—improving less than 10% of your happiness by changing the work environment. If money is not the problem and you’re living comfortably, changing your work won’t make any difference. You will be the same unhappy person, just working in a different company.

If you have a toxic company culture, improving that by <10% may help you improve your overall life. But if you’re working in good company culture, that change might not affect you. In the research studies, scientists found that moving to a new place with a view after retirement or making lots of new friends, or even getting married showed some positive outcomes only in the short term. In the long term, people returned to their original happiness baseline. So, what can you do?

The 40% happiness, the intentional activity, is what you can change. The bad part of this 40% is that it doesn’t happen by itself. As it is intentional, it demands effort. The 10% environmental part happens to you, but the 40% is the activities you act in your circumstances. For example, if your company changes your project, it depends on you to be happy or not. You might blame your organization for moving you from a great project to a bad one, but you may as well see it as an opportunity to handle a bad project and make it a success. How you interpret the situation defines your happiness.

When you change jobs, you might be hired for a specific project. However, you may be assigned to another one after six months because your initial project will be shut down. If you value stability and want to keep working on that project, you won’t be happy. That’s the part you can change your attitude. These events will happen everywhere, and your happiness will depend on how you interpret them. Think twice—or even three times—before sending your resignation letter. Evaluate the situations and your perspective together. How you think about any problem can impact your happiness more than you imagine.

I will close this week’s letter with the same paragraph from the article I wrote:

If you’re leaving for more money or safety, I will never argue. If you’re leaving for a different type of experience (e.g., remote work vs. in-office, big co vs. start-up) or different company cultures, I won’t argue. …… If you’re leaving your company because the market is hot right now and your company can’t give you a raise that might not even change your life, then maybe you should question again. Don’t get caught in the great resignation wave.

— Candost

*P.S. Deep Walks to increase life and work satisfaction.*

A Quote I’m Pondering

*"Many of our beliefs are cultural truisms: widely shared, but rarely questioned."* — Adam Grant

Reply via email | Reply via Mastodon | Comment

How do I behave when I receive feedback?

Sun, 03 Apr 2022 00:00:00 GMT

Reactions to feedback define how the feedback giver perceives the other person's feedback-receiving skills. When people react with anger or cry when they receive harsh feedback, it creates a picture of how they cannot handle the feedback. These various behaviors are the feedback footprints that are unique to the individual. Many people are not aware of their feedback footprint and are not ready to face harsh feedback. Asking, "How do I typically behave when I receive feedback?" is a good strategy to help anyone learn their unintentional behaviors. After learning the reactions, it will be easier to prepare for any kind of feedback and easily handle difficult situations.

Related Note(s):
Source(s): Thanks for The Feedback by Douglas Stone & Sheila Heen

Reply via email | Reply via Mastodon | Comment

Best Practices and Consistent Improvement

Thu, 31 Mar 2022 00:00:00 GMT

Engineers often struggle to explain their train of thought. They create processes and systems in their minds but fail to explain them using simple sentences. Good engineers often become terrible communicators and collaborators not because of their limitations in thinking but because of limitations in explaining their decisions. They make good judgment calls and decisions but fail to adapt these decisions to changing situations. Especially when teams form best practices, these practices become the worst after a while because nobody has the guts to rethink them and improve them. They accept them as best practices and use them without reviewing them.

Related Note(s):
Source(s): Think Again by Adam Grant;

Reply via email | Reply via Mastodon | Comment

Confident Humility is Required to Build Trust

Thu, 31 Mar 2022 00:00:00 GMT

It's horrifying to open our weaknesses in front of others. Especially if we're raised in a culture that promotes being the best and the strongest in society, it's challenging to admit mistakes publicly and tell everyone where our weaknesses are. However, there is no better way to build trust. If we can show humility while knowing our strengths and displaying them with our weaknesses, people build trust because they get to know us better. If they don't know or can't rely on us or guess how we will react to certain situations, they can't trust us. It's that simple.

When I think about managers I've worked with, the best ones were the ones who say, "I don't know" or "I was wrong." They knew their weaknesses in the team or, in general, the company. Instead of hiding them, they embraced them and allowed others to fill the gap in their knowledge. They also knew their strengths. They were confident in some areas; they knew what they were good at. Meanwhile, they also accepted that they were wrong, even in their confidence area. They were always open to learning. Adam Grant defines this behavior as confident humility. And that's what they had.

Source(s): Think Again by Adam Grant;

Reply via email | Reply via Mastodon | Comment

Comparing Psychological Safety with Performance Culture

Thu, 31 Mar 2022 00:00:00 GMT

Creating psychological safety is challenging and demands empathy and consistent action from leaders. Keeping the environment safe is a complex dynamic, and empathy is not enough. People should trust each other first. Creating trust requires showing vulnerabilities, admitting mistakes, and taking action on constructive feedback. When a leader's words and actions do not align, trust is broken. Trust is the first step, but it's not the last one. I've experienced that even when people trust each other, some folks are more hesitant than others to raise their voices because of their backgrounds and how they learned from previous situations in their lives (be it a cultural background or from their previous company's culture). It is crucial to guide and show them their possible positive impact on the team.

On the other hand, the culture decays when performance and delivery become the first thing people look for instead of creating the best possible work. In the long term, delivery and performance decay. It's impossible to keep high performance for an extended period when it's the most important thing. A performance culture works in the short term (such as in task forces). However, psychological safety creates better results if the team has a longer-term vision and work.

Reply via email | Reply via Mastodon | Comment

Scientific Thinking and Fact-Checking for A Better Life

Wed, 30 Mar 2022 00:00:00 GMT

Interrogating the information instead of only consuming it helps us comprehend it as a whole and makes us more skeptical.
Popularity ≠ Reliability. Being the first is not the same as being correct. Understanding the information's reliability is crucial. Otherwise, the data leads us to wrong judgments. The same applies to hype technologies. Popular doesn't mean the best.
Some folks broaden the information's reach, but the source can differ. Whoever is giving the message might have a different source. Be aware of it.

Related Note(s):
- 3: Being a Team Manager and Manager's Job;
- 4b: Monitoring & Inspection to Learn;
- 27b: How to Learn New Things via Habit Stacking;
- 17i: How to Understand The Public Talk Feedback You Get;
- Scope insensitivity is what prevents us from understanding the whole picture, especially when what we are focusing on is growing exponentially or becoming increasingly longer.
Source(s): Think Again by Adam Grant;

Reply via email | Reply via Mastodon | Comment

Trailer: Season #3

Tue, 29 Mar 2022 00:00:00 GMT

Trailer: Season #3

In response to: https://candost.substack.com/p/trailer-season-3

Reply via email | Reply via Mastodon | Comment

Impact of knowledge and beliefs on learning

Mon, 28 Mar 2022 00:00:00 GMT

When we grow experts in one area, it becomes more difficult to change our thoughts. It's easy to leave the learning zone. Once we form beliefs, it impacts how we learn from others. When we get feedback/input, we defend ourselves as they attack our beliefs. While people we lead try to express their thoughts, we—without realizing it—close ourselves to their suggestions and stop rethinking. It's easy to fall into this trap. Staying in the learning zone and being humble and open moves us forward. Instead of thinking like we're experts, we need to think about how to silence our inner dictator and open ourselves to others' thoughts to learn from them.

The knowledge we have impacts how we approach things. When we form beliefs, we are more likely to destroy these beliefs. We build walls around them.

Related Note(s):
Source(s): Think Again by Adam Grant;

Reply via email | Reply via Mastodon | Comment

Impact of Imposter Syndrome

Mon, 28 Mar 2022 00:00:00 GMT

Imposter syndrome has many drawbacks. It can prevent us from being seen as strong people. But it also has advantages that can help us become better people and leaders.

Being an imposter motivates us to work harder. When we feel like we are cheating or our knowledge is insufficient, we work more to catch up.

It motivates us to work smarter. We're more inclined to change our opinions. If we believe we're not going to win, we have nothing to lose; therefore, we rethink our approach.

It makes us better learners. When we doubt our knowledge, we're more open to learning from others.

Related Note(s):
Source(s): Think Again by Adam Grant;

Reply via email | Reply via Mastodon | Comment

Mektup #27: Unstuck yourself from the ideas that go nowhere

Tue, 22 Mar 2022 00:00:00 GMT

Hey friend,

I often see some engineers stick to one idea. They see the advantages of one side but don’t review their approaches if it solves the problem or not. Many engineers learn to perform a job in one way. They start to think they can approach other tasks in the same way. I made the exact mistake countless times. I learned one architectural pattern in iOS development, which I thought was the best way. At that time, all senior engineers and I were in the same place, and the project we developed was in great technical shape, which allowed us to develop features faster with high code quality. But it didn’t last long.

Another project needed an engineer, and I was the lucky one to move there. The new project was vastly different. Even though we were working with a similar business as my first project, the second one was a technical and organizational challenge. I did what I knew best and started applying the strategies I learned in the previous and outstanding project. One day, while trying to develop a feature quickly, I insisted on a technical approach and made it a big deal because I knew that was the best way to do it. And I was right.

What I didn’t know were the other business cases, deals between project stakeholders, and the urgency. We had to sacrifice technical excellence and deliver a feature, and it was a conscious decision that I couldn’t see. I failed to let the technical excellency go, and conflicts appeared. In the following weeks, I became frustrated, and the team's mood slightly changed. Eventually, I had a chance to move to another project, but I learned a lot. And here is what I learned.

When people insist on doing a job in a certain way, try to understand why. If you’re both pushing in different ways, there is a high chance either one or both of you miss some context. Instead of pressing more and more, take a moment and notice that you’re trying to solve the same problem. When you push the idea, the other side will immediately raise their defense walls because they feel threatened. In turn, you also put your shields up, and the situation leads to conflicts. When you notice the differences, declare that both of you are solving the same problem. This strategy is one of the essential strategies for persuading others. It also helps you to reconsider your thoughts.

Then, ask questions to broaden your perspective on the topic. A few straightforward questions are:

“What do you see that I miss? I believe we have different knowledge and context about the problem. Help me understand yours.”
“Why do we see the situation differently? Help me understand your perspective.”

These phrases set the ground for differences and show humility. They don’t judge the other person or their thoughts. They help you comprehend the motives behind other people’s thoughts and find similarities between your approach and theirs. Once you grasp their perspective, acknowledge the part of their solution you also agree with. This acknowledgment will destroy the defense walls because they recognize that you’re taking a step.

Let’s take a look at another example in which an engineer recommends something for a long time but can’t convince others. One of the senior engineers suggested that everyone in the team share status updates in written form and announce everyone on a single document. For months, I heard the same request over and over again. It started to feel like we were having the same conversations repeatedly. But, the case is, the engineer never took a step to ask either themselves or me or others, “What do you see that I can’t do so my suggestion seems ineffective?” I’m not blaming anyone, of course. From the manager’s standpoint, we also couldn’t succeed in showing them the broader perspective and why the team and we think their approach won’t work.

When people grow in their careers into senior roles, implicit expectations begin to appear, and this is one of them. To ask questions to figure out why a suggestion doesn’t—or won’t—work is a skill that experienced engineers have to acquire. They have to develop elasticity in their recommendations and be flexible with their approaches.

Getting out of a stuck mindset allows us to learn. It helps us reconsider our approaches and find the best for the situation. Any action we take shows us the trade-offs and guides us to an optimal decision. I know it’s already challenging to notice that we’re going into a conflict. Yet, once we experience a conflict and retrospect the situation later, we realize many signals we missed. That is a skill to learn and develop. Much like any skill, it needs time and repetition. You will make many mistakes on this road but think of every mistake as new learning.

— Candost

A Quote I’m Pondering

"Who you are should be a question of what you value, not what you believe." — Adam Grant

Reply via email | Reply via Mastodon | Comment

A Systematic Approach to Give Feedback to Blame Absorbers

Fri, 18 Mar 2022 00:00:00 GMT

Have you ever worked with a person who always says either one or more of these sentences:

I should have done that.
I could have done XYZ.
I should have known this might happen. It won’t happen again.
I made a mistake, not others. It’s all on me.
…

At first glance, all of these phrases look good because it shows that the person owns their work and has a sense of responsibility. These good intentions are usually welcomed and appreciated by their leaders and colleagues. However, people who use these phrases often don’t notice that they harm the team more than bring an advantage.

While working with blame absorbers—as Sheela Heen calls them—leaders have to take precautious steps. Otherwise, it leads to a toxic and unlearning environment. When a blame absorber takes all responsibility for a failure, none is left to others. When people own one mistake that many other factors contributed to, they overlook the reasons. They lose sight of the big picture.

At the same time, this behavior is detrimental to the blame absorber. Letting this behavior slip causes the person to absorb all the blame and build resentment over time. The absorber will start to think they’re always to blame, and others don’t take responsibility at all. They also begin thinking they are not good at their job, and therefore, the situation might result in high-level stress and burnout.

How to work with and guide a blame absorber?

Working with a blame absorber requires listening well and approaching with empathy. We need to unload some responsibility while keeping it at a healthy level. Understanding where they stand starts with explaining why we are having a conversation about it. Many leaders miss this point and confuse the people reporting to them.

It starts with walking them through the big picture and broadening their perspective. At this stage, it’s crucial not to blame any person but instead focus on all the factors contributing to the problem.

Once they comprehend the whole picture, we need to help them see how they contribute, their behavior, and their impact. Using a concrete situation as an example is always a good strategy. There are various methods to uncover behavior, but I found the Situation, Behavior, Impact (SBI) Feedback Model helpful for this case. The goal of the SBI model is not to give any suggestions but show them one scene overall.

In the SBI Model, we explain the Situation as straightforwardly as possible, without any personal comment or remark. For example, the situation can be “Yesterday in the Post-Mortem Analysis meeting when you explained the root cause.” The situation doesn’t indicate anything besides defining the exact moment.

When we define Behavior in the next step, it’s crucial to avoid stating opinions and judgments. The behavior should explain the person's behavior without guessing any reason behind it in that specific situation. For example, the behavior can be “When you said the root cause was all your fault and you should have thought it before.” The behavior doesn’t state any personal opinion or judgment.

The last step is explaining the Impact of the person on us, the team, and the organization. This is the part we objectively approach the overall picture. In the SBI model, the Impact usually defines the person’s behavior in a few sentences. However, when working with blame absorbers, we have to add more information to show them how their behaviors create problems.

As they absorb the blame, they suck themselves in a black hole and often can’t see the overall picture. Therefore, we need to show them how they create responsibility conflicts. We need to explain when they take extra responsibility—which doesn’t belong to them—it confuses people and makes them adversaries. Then, we need to show them how the overall system is and why taking unnecessary responsibility nudges others to act in an adversarial way.

The explanation should be done with empathy and humility, not in a preacher or prosecutor mode. Instead of blaming them, we have to explicitly show we want to help these people. Before giving feedback using the SBI model, it’s also helpful to explain the SBI model and how it works. It opens their mind if they haven’t heard the model before.

While explaining, we also have to be careful not to load all responsibility into ourselves or the system. We should let the blame absorber understand how all the factors play a role by showing them together. We need to help them understand their part and take full responsibility for that part, not others.

Blame absorbing is a habit, and changing habits is a difficult process. This approach won’t work like magic when we only do it once. Changing behaviors need constant iteration and willingness to change. If the person puts on the defence walls, we have to re-iterate our approach. Probably, we’ve done something wrong on the way, and they brought up the walls. We have to build trust first and listen to them with empathy. The change won’t happen quickly; it will need time and effort. We have to be patient and not give up.

Reply via email | Reply via Mastodon | Comment

Coaching for Responsibility

Fri, 18 Mar 2022 00:00:00 GMT

Let people be responsible while doing the work and when they have the results. If you let them work only and take responsibility when something fails, you're not a good leader. It's not different from taking all the credit when a project succeeds. You're taking away all the learning opportunities. Let people own their mistakes. I'm not saying fire them because they made mistakes. Instead, encourage them to learn from their mistakes and even ensure they learn. Coach them to fail early so they won't get into trouble if they fail too late because late failures usually bring big problems. Early failures enable us to learn iteratively. Iterative learning sticks, and they are effective.

Don't fire people when they fail. If you fire a person just because they failed, you're not learning. You're putting all the responsibility on that person and missing many learning opportunities.

Encourage people to fail fast. The responsibilities have to be balanced. Nobody should have full responsibility, even if they are working alone. Ensure they share the responsibility with the people surrounding them. Look at it holistically and understand how multiple factors and people contribute to the problem. Take ownership of your side and responsibilities, not everyone else's.

Related Note(s):

Reply via email | Reply via Mastodon | Comment

Mektup #26: How to Create a Definition of Done in Your Team

Tue, 08 Mar 2022 00:00:00 GMT

Hey friend,

In the last Mektup, I talked about why you need to develop a Definition of Done (DoD) and what it is. Today, I will talk about creating one in the team. The Definition of Done is unique to the team, and it's an agreement with stakeholders.

First, you need to define who your stakeholders are. In product companies, these people are often the Product Managers, Team Leads, Engineering Managers, or any other manager leading the team. If engineers don't have this level of management in the team, then stakeholders are the people who are responsible for the team's deliverables and accountable for the overall work. Don't confuse these people with project stakeholders who usually don't care about developing a feature or a project. Project stakeholders only care about if you deliver it on time or not.

The first step to developing a DoD is getting together with all engineers, designers, quality assurance folks, project/product managers, engineering managers, team leads, or any other manager who is accountable and responsible for the team's work. During this time together, everybody will write down their expectations from a finished work from their perspective. You can use Post-its—virtual or physical—and write down one item in each Post-it. Give everybody fifteen minutes to write their expectations down without too much thinking or pondering on them.

The next step is identifying the shared expectations. Group post-its that mention similar expectations. Then, as a group, start from the largest group and discuss why people think that expectation should be in DoD. The goal is to identify common ground, find people who disagree with the expectations, and have a healthy debate. One by one, from the biggest group to the smallest group of post-its, discuss with your team. To keep the discussions on time, set a maximum of five minutes for each group and have a decision in the end whether the expectation should be in DoD or not. If you need more time in discussions, extend it by one minute each time.

Once you have listed all your· expectations, go over them and identify if all expectations are applicable to your projects. If any expectation is not suitable for all of your work, mark them either "optional" or "if applicable."

While going over the list again, think about if you can meet all the expectations all the time. Don't try to come up with an exhaustive list. The DoD should have only the bare minimum. It shouldn't contain wishful thinking; it should include essential items in your work.

Once you're done with the DoD, set a timeframe to try it. I found six to eight weeks a reasonable time frame that people can adapt to a new process and realize the invalid or missing points in DoD. During this testing period, try to enforce the DoD as much as possible. For example, add it to your pull request templates if you use GitHub or integrate it in your flow as a checklist in Jira.

Once your testing period is over, iterate and refine the DoD. Prune unnecessary or inapplicable items and add missing ones. When you're done, announce it to everyone around your team, especially to all your stakeholders and other teams you often collaborate with.

After you have it defined, I recommend keeping it as a living document and reviewing it every six months. Our projects evolve, and we change our workflows in time. It's crucial to keep DoD up-to-date with our evolving processes.

Before we end this letter, I have one last tip. Look out for the items in DoD that you can automate. If you can somehow automate any item in any way, it is definitely worth the effort.

— Candost

P.S. If anyone objects to your Definition of Done, you know how to overcome them.

A Quote I'm Pondering

This quote is from The Wise Man's Fear by Patrick Rothfuss. During the conversation, two people talk about a game they are playing. I found Bredon's point as a valuable lesson to the many things in life.

He gestured at the brief and brutal lay of stones between us. "Look at that. Why would I ever want to win a game such as this?" I looked down at the board. "The point isn't to win?" I asked."The point," Bredon said grandly, "is to play a beautiful game." He lifted his hands and shrugged, his face breaking into a beatific smile. "Why would l want to win anything other than a beautiful game?"

Today I Learned

Yesterday was Equal Pay Day in Germany, marking the date that women are working up to yesterday for free due to the gender pay gap. It's coincidental that today is International Women's Day.

Reply via email | Reply via Mastodon | Comment

Why Should Leaders Have Good Storytelling Skills in Reorganizations or Restructurings?

Mon, 07 Mar 2022 00:00:00 GMT

Giving any information to the team as a manager is like acting in a theater. As leaders, our tone, facial expressions, and mimics set the audience’s feelings. We build stories to navigate people through the mist and bring them into the sunshine. In stories, people don’t follow words; they follow emotions. Using the proper tone in the statements becomes a way to influence people. Good storytelling skills help us give the message clearly and expose the correct feeling at the right time.

Especially making significant changes in the organization demands a clear understanding of the reasons and requires good storytelling skills to convince people. We must clarify that these changes are for the greater good, although they might not be the best for specific individuals. Stories empower these situations and enable the leaders to convey the reasons while setting the emotions right.

Stories’ strength doesn’t come from only the language we use but also the emotion that the information brings to the listeners—excitement, sadness, relief, frustration, and more. Like many stories, we want to arrive at a happy ending, but how we get there is often ambiguous.

Why The Story?

How we tell the story becomes as important as what the story is about. Even though the news may sound bad for certain people, we can positively impact them by choosing a sympathetic tone.

Organizational restructuring can be frustrating or exciting for different people. We can encourage people in a steep growth trajectory to leverage these organizational restructurings. Also, if we have folks who wish stability in the team, we can inspire them to see the advantages of restructurings.

On the other hand, when we choose a frustrated tone because people have to move to another team, everyone will be frustrated. Whatever style we choose will reflect on the other side.

If there is transparency and the team knows the background of the decision, it’s okay to rush to the story’s ending. However, if there is a lack of transparency, having the emotional roller coaster becomes the connection we have with our teams. We have to ride this rollercoaster with them to eliminate their fears. They have to feel the correct emotions at the right time. When we hurry and unnecessarily push people, we block their feelings—which can come out later on where we least expect.

The Tone of The Message

Leaders’ approach and tone in the team discussions impact the discussions’ fate. If we have bad news and announce it to the team in a frustrated mood, the team will get stressed and frustrated. However, whatever the announcement is, if we set the tone inspiring and optimistic, people will approach it more favorably. The essential part is choosing the tone and narrative.

Organizational changes are frightening but often necessary for growth. Wherever we announce changes, we should choose a positive tone. Sometimes we can be frustrated and sad because changes might come as top-down decisions, and maybe we will depart our ways with some people. However, it’s beneficial to choose our strategy of showing our frustration to the team. Finding the balance is complicated, and showing vulnerability is necessary to be authentic.

Reorganizations or restructurings are done for a good reason, either for the organization or the people—at best, for both. It’s better to show an optimistic view when announcing changes to the team, project, or organization. Hiding the frustration can motivate people to get on board.

Many leaders hide emotions under the “being professional” label. Being professional means doing your job and getting paid for it. Being professional doesn’t mean being emotionless; it means showing the right emotion at the right time and place.

Being mindful is the key here. Understanding the psychology of the team and people and preparing the message in the correct tone and words are crucial skills that any leader should master. A strategy for hiding or showing emotions should be developed by thinking like a storyteller. Depending on which story we’re telling people, our approach should always differ.

Narrative and Storytelling

Storytelling skill is often taught as presentation skill. However, it’s a bit different. Giving presentations improve storytelling, it’s true, but when we give information in the daily standup or weekly team meeting, our words and body language become our presentations in a limited time. We have to use them wisely.

Many software engineering leaders are analytical. They cut the chase and give the information without any stories. When we do this, we leave the emotions to the people. If the message doesn’t have any narrative, doesn’t guide people’s feelings, and it’s just on point, people will hear it with whatever emotion they have at that time. They will go into various unknown places and will be lost.

To eliminate chaos even before it occurs, we have to present the reorganization’s background, reasons, the execution plan, and the expected outcome in the correct order. Many leaders don’t even think about these different parts of a story, and their narratives create confusion. In which order we build the narrative depends on the situation and the people involved in the reorganization.

Whenever the narrative, the structure, and the tone are apparent, it gets easier to onboard in the restructurings. When we think about it, even non-fiction books and articles make us feel something. These articles and books keep our curiosity alive while feeding us with information. We’re neither writing a book nor an essay, but whatever we announce has to have the story elements to be impactful. Otherwise, it will be only an analytical statement that creates chaos and leaves everyone with mixed feelings.

Complement with listening to Managing Organizational Changes Podcast Episode, and reading Communicating Decisions In The Organizations, Bias for Action, The Decision-Making Pendulum.

Reply via email | Reply via Mastodon | Comment

Yet I Cried; One More Time

Thu, 03 Mar 2022 00:00:00 GMT

I cried five days ago.

I cried for the Ukrainians. The people who are dealing with the Putin regime. The people whose country is invaded.

I cried four days ago.

I happily cried for the Ukrainian refugees and how Western countries offer endless help to them. I cried proudly and heartwarmingly. I cried with pridefulness for Polish folk who opened all the borders to Ukrainians. I happily cried for all the support Ukraine received from Westerners.

I cried three days ago.

I cried for losing the peace in Europe. I cried because I moved to Europe for safety. I cried for not feeling safe again.

While crying, a teardrop fell down, a different one. The teardrop was screaming at me for the hypocrisy of Westerners.

I cried more on that day. This time for Syrians and how they were, and still are, treated in Europe.

I cried for Turkey, my home country, which hosts the most refugees globally.

I cried for Germany, who did many things to take as many refugees as possible in both cases. That teardrop was happier.

Another drop fell for the rest of the EU, which didn't lift an arm to accept Syrian refugees. I cried for their two faces: one face for welcoming Ukrainian people because they look familiar and another for throwing tear gas bombs at various refugee groups on the EU border because they look different.

Two days ago, I cried my eyes out.

I saw that racism plays its role in wartime as well. I cried after hearing, "Ukrainians are just like us; they are white Christians with blue eyes." I cried more after seeing how people of color are treated by the Ukrainian police forces on the Ukrainian border.

I cried even more after hearing, "These are Ukrainian people, not Syrians or Iraqis coming from the Middle East."

I cried once more for those who think Ukrainians are better than Middle Easterners. What a horrible life they must have to live with this perspective. What a sad moment for all of us listening to this.

Yesterday, I cried again for everyone who had to deal with the war in the middle of the pandemic, not only Ukrainians but also Syrian, Taiwanese, Venezuelan, and African people.

Yesterday, I cried for past myself, for young me, for not seeing things clearly. I cried for my previous thoughts like, "I'm better than others because I'm living in a safe country." What a horrible perspective I had before.

Today, I proudly cried for the Russian academics for bravely announcing their opposition to the invasion of Ukraine.

I know I cry a lot.

But most of these are crying inside because I've seen a lot in this world only in 30 years.

I lived in insecure places. The places I walked a lot were bombed, and there was a high possibility of me dying in one of the bombings.

I moved and lived in multiple countries, and I have seen how a lot of people are the same and selfish. And many of them have no idea about these kinds of lives.

I cried inside because I also lived a privileged life in comparison.

I was able to cry and not deal with the war itself. I was privileged not to see a dead body with my own eyes. I am still privileged to live in a safe country while writing my thoughts.

I am saving my real teardrops for my future because I know I need them. I will probably cry more tomorrow for all the people who will lose their lives in someone else's greedy war.

I will remember seeing a Russian helicopter getting hit and exploding. I will cry for that Russian soldier in the same way I cried for the Ukrainian soldier who lost a life because of a Russian tank.

I won't forget seeing the parents of the Turkish soldier who lost his life in Syria.

I won't forget watching the Syrian refugee's journey to Europe to safety. I won't forget watching that movie in the cinema while the person who recorded it was sitting next to me and had to leave the cinema because she couldn't watch herself going through the horrible journey again.

I know I will cry with sadness tomorrow, but it's okay. I got used to it.

Crying opened my eyes. I know this hypocrisy and racism do not live only among Westerner folks; it's everywhere. I see things more clearly now, unlike some Westerners and all the other folks around the world who need another lens in life.

I know I will cry with contentment tomorrow for all the fantastic Westerners and others who don't think people are different and treat everyone's race and nation the same.

I know that there are still people who think above the nations and offer help to everyone.

And tomorrow, I hope to drop my happy tears for them.

Reply via email | Reply via Mastodon | Comment

Confident Humility

Mon, 28 Feb 2022 00:00:00 GMT

When I think about managers I've worked with, the best ones were the ones who say, "I don't know" or "I was wrong." They knew their weaknesses in the team or, in general, in the company. Instead of hiding them, they embraced them and allowed others to fill the gap in their knowledge. They also knew their strengths. They were confident in some areas they knew they were good at. However, they also accepted that they were wrong more, even in their confidence area. They were always open to learning. Now, there is a term for their behavior: confident humility. That's what they had.

Reply via email | Reply via Mastodon | Comment

Mektup #25: You Need A Definition of Done in Your Team

Tue, 22 Feb 2022 00:00:00 GMT

Hey friend,

In the last Mektup, I mentioned the Definition of Done when discussing reliability. Now, I want to dig deeper into it and explore why you and your team need one.

If you hear someone says, "The work is done," but they need to do some minor things or add tests to ensure everything works, the work is actually not "done"! These situations appear more when there is no agreement about what Done means. Without the explicit Definition of Done (DoD), I always see that people use various definitions they imagined. Especially when tasks depend on each other, a different understanding of Done can cause misaligned expectations, conflicts, and double work.

Instead of implicit misunderstandings, we need to make our processes as explicit and transparent as possible and create a common language for the phrases we use. Working agreements and using the same language enable us to focus on crucial and complex issues and free our brainpower.

What is the Definition of Done?

The Definition of Done is a written agreement between team members and stakeholders that people can point to when the other side is breaking it. We can think of it as a contract. Wherever we deliver work, we can ensure what is included and what's not.

DoD is not only for better communication but also for quality and best practices. Ensuring we deliver high-quality work is often a debate between engineer and product teams. While product teams (e.g., product managers) want to push the feature to market quickly, engineers want to produce high-quality software. Once the quality is part of DoD, it becomes easier to negotiate and agree with product managers/owners.

For example, suppose having unit and integration tests are part of DoD. Whenever our stakeholders push us to release the feature early and communicate that we're done with the feature, the engineering side can quickly raise a flag and say, "Sorry, we're not done yet. As we agreed on DoD, tests are missing, and we have to do that before the release." This way, we prevent a possible tech debt, raise our confidence in our work and achieve consistent product quality.

What should you include in the Definition of Done?

The beauty of DoD is its uniqueness for the team. Every team has different operational routines. DoD can be generalized to the company at a higher level, but teams always differ according to their projects and stakeholders. For example, creating one DoD that covers both DevOps and product teams won't be easy. Having separate DoD is better for every team.

I won't go into the process of creating a DoD today; that will be the next Mektup. But let me leave one example of the Definition of Done that we used in our backend team to give you an idea of what it can include.

Example Definition of Done

Implementation Complete

Acceptance criteria are met.
Appropriate alerting and monitoring are configured.
Appropriate error handling and logging are implemented.

Quality Assurance

Code Review

Pull request is created, reviewed, and approved by another engineer.
Pull requests have;
- A link to the relevant ticket, which is meant to resolve.
- Have a short description of why that specific approach is taken during the implementation.

Testing

Appropriate testing is implemented (unit, smoke, integration, end-to-end).
Tests are passed in the continuous integration (CI) before merging the pull request.

Release

Deployed to the relevant environment(s).
The Jira board and relevant tickets are updated.
Stakeholders are informed.

A Definition of Done is a living agreement, which means whenever we recognize that our operation is changed, the DoD needs an update. Teams, companies, and products evolve and change often, and we have to acknowledge these changes and apply them to our agreements.

In the next Mektup, I will talk about developing a Definition of Done for your team and how you can agree on it with your stakeholders.

Do you already have a definition of done? If yes, how does it work for you?

Looking forward to your answer. Thanks in advance!

— Candost

A Quote I'm Pondering

"Your success in life will be determined largely by your ability to speak, your ability to write, and the quality of your ideas. In that order." — Patrick Winston

Today I Learned

Grammarly has a desktop app (in addition to its desktop editor) that works almost in every app. 😍

Reply via email | Reply via Mastodon | Comment

Do Not Change Jobs

Fri, 18 Feb 2022 00:00:00 GMT

If you ask me what my advice would be to mid-level software engineers these days, it would be to stay where you are if you don’t have a stressful problem and if you’re learning. Changing the company feels exciting (new adventures, new type of learning), and often it pays more. Especially with the ~~great resignation~~ job-changing wave, it is even more urging to hop to another company. However, the challenges and advantages of staying are often overlooked.

I’ve seen some engineers change jobs every 1-3 years, and some stayed in the same company for 5- 10 years. Every single time, I realized something different in engineers with long tenure. It was not easy to define. Every time, I thought they were wiser, but it was untrue. I thought the accumulated knowledge made them special. Although the knowledge made them valuable to the company, it didn’t make them special. Knowledge made their job—and ours—easier. After struggling to define it, I decided to uncover it by looking at myself.

I’ve been working in Jimdo since July 2016, almost six years now. During my time here, I’ve witnessed a lot of stuff: sunsetting projects, monoliths, microservices, native mobile apps, cross-platform mobile apps, in-office teams, hybrid teams, remote teams, unsuccessful and successful initiatives, jaw-dropping-amazing projects, and stuff that didn’t make sense at all; you name it. I’ve seen many projects completed, abandoned, over-achieved, half-completed, put into the trash. We can argue that these things happen in every company, and even I changed jobs often, I can, and will, come across them. Then, what’s the difference in longer tenure?

It’s gaining a new perspective and long-term thinking.

I think most engineers work on projects that other engineers developed. We all see how the judgment of the previous developer is “wrong” every day. We also assume that we won’t be the same and will have better judgment. Yet the next developer after us always feels the same. The story doesn’t change until we see our older self’s mistakes and failures, become the previous developer to ourselves and see how the company’s decisions had long-term consequences.

Seeing not only our past self’s wishful thinking but observing the company’s previous decisions and how they played out is an eye-opening experience. For example, Jimdo moved from monolith to microservices a few years back. Although I was not involved in that decision, I observed from the consumer side as an iOS engineer. Did we guess what would be drawbacks at that time? I’m sure we did. However, after years, we started to realize the real drawbacks and the work we had to put into it. If I have left after a year or two, how could I see any long-term impact of this decision? Now, I know how much effort this move requires and its challenges.

Let’s take a non-technical example, an extreme one. In my fourth month, Jimdo had lay-offs and reduced the workforce. Some of my amazing colleagues were out of jobs. It was a painful moment. If I had left after that event, there was no chance to see how this decision impacted the company as a whole. Now, we couldn’t be in the same position if we didn’t have this decision. Was it the best decision? Probably, no. I’m sure there were better options, but I’m also sure that the people who made the decision evaluated the other options. All I know is that the decision was for both the short-term and longer-term. Leaving in the middle would make me blindfolded to long-term consequences.

It doesn’t matter when we leave; there will always be a consequence of a decision we will miss when we do. The questions are “have we seen enough?” and “Does the leave compensate for the experience we will get in long-term thinking?”

If you’re leaving for more money or safety, I will never argue. If you’re leaving for a different type of experience (e.g., remote work vs. in-office, big co vs. start-up) or for different company culture, I won’t argue at all. If the environment is not toxic or not draining your energy and you’re still learning, then why leave the company? If you’re leaving your company because the market is hot right now and your company can’t give you a raise that might not even change your life, then maybe you should question again. Don’t get caught in the ~~great resignation~~ current job-changing wave.

Even if you do leave in the end, be aware of the trade-off you’re making. If you haven’t stayed in a fast-moving company for more than four years, there is a great experience you’re missing.

Reply via email | Reply via Mastodon | Comment

Mektup #24: One of the best superpowers you can get as an engineering leader

Tue, 08 Feb 2022 00:00:00 GMT

Hey friend,

Today, I want to talk to you about one thing that made a big difference in my career and life. People gave me positive feedback many times, and it became one of my superpowers: I'm a reliable person. I'm not here to brag or so but to give you a perspective on how one word can—reliability—can impact your career and, frankly, your whole life.

It all starts and ends with trust. If you're reliable, people trust you. They trust you that you will do the work, they know that you will be there when they need you, and they become confident that you will show up and do whatever it takes to finish the work you took over.

I've seen many unreliable engineers deteriorating their career growth because they left things behind and didn't keep their promises. What's surprising is that what they had to do was usually minor and straightforward, but they didn't bat an eyelash. I know some things might be straightforward to me but not to others. However, when I asked about what they should have done, they all knew the next steps. They just didn't do it for a variety of reasons. In these cases, having a good manager or mentor can boost reliability as they help you find what's essential and what you should do next.

What I've seen more is that many experienced engineers and leaders leave things behind and just move their focus to something else (often new or hype things). Many folks don't complete the thing they started and leave things in an unfinished state. I get it; all of these experienced folks are busy. But I can't accept that there are tons of incomplete initiatives and projects waiting for someone else to pick up.

When you're growing into leadership roles, you will have multiple initiatives and projects run in parallel. Following up on the work and being reliable will become complicated by the minute. Between many initiatives, various dependencies, and different stakeholders, there will be a few things you can be aware of and improve.

How to Become More Reliable

Being reliable is not a checkpoint that you have to pass. It will happen in time, and all you need to do is keep your promises (sounds simple, right?). If you say that you will take care of something, take care of it. Don't let it slide. Although reliability doesn't have a handbook, I want to share some concrete tips to help you organize your work to become reliable.

Commit a realistic amount of work. This alone is not easy, and it requires prioritization skills. If someone asks you to do a task, ask about a timeline and the scope. If you think you need to do overtime, either say no or delegate the job or delegate another job of yours to someone else to open up a space.
Split the work into chunks and deliver them one by one. One of the things I've come across in engineering is tackling tasks as big blocks. Whatever job you get, split it into a few pieces and work on them separately. If you're not hands-on working on the task and leading it instead, nudge people to divide the task into smaller pieces and deliver them one by one. When you keep delivering the work, people start trusting you.
Create a definition of done (DoD) in your team(s). Often what done means differs for every team and every person. Aligning everyone in one definition helps a lot in discussions between team members and different stakeholders. With one definition, whenever you say the task is done, others will understand what it means, and the terms such as "done done," or "done done done" will fade out. I've initiated the implementation of DoD before at the organizational level. I will talk about it in the next Mektup about how you can start the discussions and develop a Definition of Done.
Use a task-tracking system for yourself. In addition to what you use in your team (Scrum, Kanban, or any other board), create a system only for you. Keep it simple. Write down every task you have in that system. It doesn't matter if it's a 10-minutes thing or not; put it there. I have my own Personal Kanban, and I love it because it helps me see all my work. I create a new card (or post-it) for every task and freely move it between columns suited to my work. While the team project tracking boards reflect your team's workflow, your personal tracking system reflects YOUR workflow, and you will see it's not the same.
Communicate, communicate, and communicate once more. You would be surprised to see how many tasks I stopped working on mid-way, but my reliability didn't get a hit at all. I always told people about it and explained the reasons instead of leaving the task unfinished and hoping that people would forget. If there is a chance that you will delay the delivery of a task, communicate with the stakeholder and explain the reasons. The key is communicating all way through.
If you have to drop a task because of other priorities, find a person to whom you can delegate the task. As you become a leader, you should start matching tasks with people's skills and career plans and delegate them accordingly. Communicate this handover with your team and stakeholders and explain that you'll help the person when needed, but the new person will run the job.
Officially stop the project or task if you see that it doesn't provide value anymore or you simply have no time and can't delegate to another person. Instead of leaving the projects in an unfinished state, officially close them. If you do, write down why you made that decision as it will help future you when someone asks about abandoned projects.

I hope these tips will help you. I know there is a lot there, and it might overwhelm you, but overall, they are easy to apply once you pay a bit of attention to them. Becoming reliable won't happen overnight; it's a long-term investment. This investment is not a risky bet and has a great return. Put some time and energy into it, and you won't regret it.

Reply via email | Reply via Mastodon | Comment

Being Morally Good in The War of Life

Fri, 04 Feb 2022 00:00:00 GMT

Life is a war—a long war between happiness and others. In every battle of this war, we expect fairness—be happy as much as others and be treated as equals. From childhood, I was taught that people who are morally good and lawful will always win this war. That's who I wanted to be. All the movies, books, and religions taught me sticking the goodness will always result in happy endings. My parents, grandparents, friends, and relatives believed in this idea; we all believed in it together.

All my life, I've been waiting for this war to end. It's been thirty years, and with this expectation, I cannot survive; we cannot survive. There is no end to this war. Being morally good doesn't help happiness to grow. It helps to become a better person in society, that's all. Being a better person doesn't guarantee winning the war; it doesn't make me the best person in my war.

Ursula K. Le Guin was right when she separated a morally good man from the best man in a fight.

'Let the best man win' doesn't mean the good man will win. 'This will be a fair fight, no prejudice, no interference—so the best fighter will win it.' If the treacherous bully fairly defeats the nice guy, the treacherous bully is declared champion.

Learning the best man is not the good man takes a long time for us—as it took thirty years for me. We have to forget all movies we have watched, all the superheroes we've seen—all the misperceptions. The problem is not being morally good but expecting a good outcome solely from being good. The problem is the expectancy. Ursula saw our deficient comprehension and continued,

This is justice. But it's the kind of justice that children can't bear. They rage against it. It's not fair! But if children never learn to bear it, they can't go on to learn that a victory or a defeat in battle, or in any competition other than a purely moral one (whatever that might be), has nothing to do with who is morally better.

Might does not make right—right?

Therefore right does not make might. Right?

But we want it to. "My strength is as the strength of ten because my heart is pure."

If we insist that in the real world the ultimate victor must be the good guy, we've sacrificed right to might. (That's what History does after most wars, when it applauds the victors for their superior virtue as well as their superior firepower.) If we falsify the terms of the competition, handicapping it, so that the good guys may lose the battle but always win the war, we've left the real world, we're in fantasy land—wishful thinking country.

This justice is the counterpoint to our beliefs, all the things we learned, and our envisions for happiness. Society taught us that a good soul would eventually win, but our beliefs are shaken from the core.

When we abandon the rules in real life, we lose and become weak. Our goodness doesn't make us frail; believing we, the morally good ones, will be victorious does.

In the fantasy land created around us, we don't realize that the good guys are learning how to fight. They lose battles, but they win the war by choosing to fight. They practice, focus, and don't give up. However, folks behind movies and TV series still move our focus to only being morally good instead of the superheroes' mentality change. They still display how these heroes learn to fight, but that part never sticks with us.

With all the influence on us, with knowing that real justice is different, how do we become both right and might?

If life is full of problems, as Mark Manson said, how can we choose the good problems instead of the bad ones? How can we remember the big war we're in?

Not learning how to fight doesn't prepare us for most of the fights in our adulthood. The protectiveness of our families, constant support, and religion make us believe that we don't need to prepare for the fight well.

As unprepared fighters, we lose battles by hoping that we will win the war because we are morally good. However, we won't. If there is no preparation, no one can win a war by being nice.

People often tell me, "Pick your battles wisely." But I think choosing the battles is what makes good people lose. Accepting the reality that good people lose wars, we have to choose which wars we would like to have, not the battles. Similar to deciding on which problems we will focus on, we need to choose good wars to fight. Choosing the battles is an amateur mistake while choosing the wars is a professional approach, and we need to live professionally.

This phrase may sound awkward, but professionally living requires learning how to live in happiness, not in a way we're forced to do. We don't have to stick to our weaknesses and accept them. I know that some of us are privileged, and not many people have a choice to decide what they should do. However, there is always a way out to happiness. History is filled with stories of people who didn't accept their fate. They learned how to fight after a long struggle. That's what we should do as well: know our privileges, embrace our advantages, learn how to fight and pursue happiness. Is there any other way? Will someone else (maybe our parents again) teach us? No, nobody knows our fight better than us, and we will never win anything just because we're good.

We're alone in our fight, and we have to figure it out alone.

Now, it's time to accept this and start practicing. Not tomorrow.

Reply via email | Reply via Mastodon | Comment

Mektup #23: The closest you can get to a leading role: hosting a workshop

Tue, 25 Jan 2022 00:00:00 GMT

Hey friend,

When I looked around me, I realized that many growing engineers have a few things in common, but we rarely talk about them. Engineers who want to grow still focus on many technical skills, which is correct. As you get these letters, you probably know that you need other skills to grow into Staff+ Engineer or manager roles.

Although people are more aware that they need to improve their human skills to level up after senior engineering, they still focus on themselves more than they need. This focus can become problematic and frustrating because one of the responsibilities of staff+ software engineers or managers is growing people around them. While looking at the bigger picture and solving problems that require multi-team effort, they have to mentor and level up others (usually more than one) around them. Otherwise, they won’t get anything done.

Now the question is, how did staff+ engineers move their focus from themselves and begin to grow other people’s skills? One of the things many senior software engineers do is host events and workshops—one of the best ways of growing people around you.

I’ve done many workshops before I became a manager, and these workshops helped me show my skills to the people I don’t work closely with. Also, I’ve seen many software engineers who host amazing workshops, and it often became one of the things people remember about them. Most of them are already at their next level, and some are on the way.

What is the power of workshops?

Workshops are not presentations. Although some of them include small presentations, they are never monologues. Workshops—in their nature—are interactive. That’s where it has the biggest power. When you host a workshop, this nature forces you to wear different jackets in a short time. As a moderator, you have to facilitate it, create a story, coach others in the journey, clarify questions, lead people from the beginning till the end and engage everyone—even the most silent ones.

A workshop is like a project: it has a goal, and as a host, you have to plan it, explain the value proposition, estimate the expected time, set a schedule, explain to people why you’re hosting it, what’s the benefit and why do we need it. During the workshop, when someone is not engaging, you have to engage them without being too assertive and coach/mentor right at that moment for the things they struggle with.

If you look closely, you can see that many responsibilities match the expectations of staff engineers, team leads, and managers.

Facilitating a workshop is the closest you can get to being a manager or staff engineer in a short period.

Workshops bring you unique sets of skills AND additional visibility. If you’re not working in a big company with all the policies defined to get a promotion, you will need some visibility to level up. Decision-makers often want to be sure that you can manage the next level’s challenges. You can hear phrases like “You have to be doing the job before getting the title.” That is how it usually works in many small to mid-size organizations. These organizations typically have a lot of things on their plates. That’s why they only recognize repeated action. Once you host workshops on your team and extend it to others, you will become visible, and people will remember you for your workshop’s topic.

About what you can host a workshop?

I must admit one thing: technical workshops rarely work. If you’re thinking of hosting one, be mindful, and don’t put yourself under a lot of pressure if you don’t get the expected outcome. What works is team building, problem-solving, brainstorming, strategic thinking, or any other workshop engaging all joiners.

You can use books, white papers, mental models, or anything else you’ve come across as a workshop topic. You can convert many things into a workshop. For example, I’ve read a fascinating book, and I thought about doing an exercise about the book’s content. After some preparations, I started hosting a workshop at work. Later, it became one of the topics people knew my name in the company. I’ve been hosting these workshops for more than a year, and I can comfortably say that these sessions helped me a ton in my promotion.

You can also host a short workshop to solve a problem. One of my managers hosted a workshop for 45 minutes to resolve conflicts in our team. They used Tuckman’s Stages of Group Development as workshop material, and we worked on it and talked about it. It required minimum preparation. The topic is really up to you. Choose something that interests you and can become an exercise and learning material for everyone.

If you have no topic in mind, try running a retrospective meeting for another team and be a moderator. The key to retrospective moderation is being a facilitator, communicating at different levels, and keeping everybody engaged while you’re staying outside of discussions.

A few tips on successfully running a workshop

Run it with a passion: don’t do it for the sake of doing it. It’s not a checklist item for promotion. When you’re not doing it with passion, participants get bored quickly, and the workshop becomes useless. If there are six people in an hour-long workshop, it means six hours will be lost, not one.
Choose a topic you enjoy first, then think about others. To run it with passion, you have to choose a topic that interests you.
Rehearse. Rehearse. Rehearse. Rehearse. Rehearse—a minimum of five times.
Prepare for the worst case. Think about possible failure scenarios and get ready for them. Prepare backups. Prepare backups for backups.
Your first few workshops will not be great. Accept it, and don’t worry about it. Keep going.
Ask for feedback in the end. Ask people to leave a note on a (virtual) post-it. If no one says anything, send a message to a few individuals you value their opinion and ask for feedback.
Regularly ask participants during the workshop to see if anyone has any questions or if anything is unclear.
Balance the speakers. It is an art and difficult. There is one magical way to do this, and I will discuss it more in my next letters. Until then, give silent ones a nudge to talk and loud people a sign to shut up without saying “shut up.”

I’ve run many workshops over the years, and I absolutely love them. Taking people on a journey and engaging them with the material is challenging, but these workshops honed my various skills. Thanks to them, I know how to give better presentations, lead people on a journey, and easily talk to people I haven’t met before. My friend, please don’t underestimate the power of facilitating a workshop. I know preparation looks difficult, and speaking in front of others is stressful, but it’s actually easy once you give it a try, and I hope you will.

Until next time, take care!

— Candost

Reply via email | Reply via Mastodon | Comment

Why Listening with Empathy is an Important Skill for Every Leader?

Thu, 13 Jan 2022 00:00:00 GMT

Many leaders have problems with empathy, especially managers with software engineering backgrounds. Before transitioning into people management, they were usually senior engineers: the knowledgeable ones who got used to providing opinions. But now, they hold a different position—one that requires them to understand people.

The fundamental change during the transition happens in perspective. People encourage software engineers to give input, which trains them to talk more and share more thoughts. In leadership, instead of being encouraged to input, you start encouraging others to share opinions. You have to listen and understand more; you have to silence your inner software engineer, keep it on hold and understand what people are saying.

The leaders who cannot silence their inner engineers lead the team members into difficult situations and conversations. They forget that they were once in the same position, annoyed by the hands-on micromanager who always talked and gave directions. Now, they are in the same place and unintentionally repeating the same mistakes.

The leader has holistic knowledge; others don't

Leaders often see things others can't. They have a more holistic view and knowledge of projects, people, and goals. Although they can use this perspective to bring clarity to the problem, many leaders unintentionally force people to follow their solutions. They fail to become great leaders; instead, they succeed as mediocre micromanagers.

As the leader holds authority, their view has more weight and impacts the discussion. That's why leaders are discouraged from sharing opinions all the time. The leader has to let other people learn. Instead of assuming the engineers have similar knowledge and perspective, the managers have to listen, stay silent and develop understanding through people's growth and problems.

Genuinely understanding an engineer, or anyone, results from listening with empathy and requires a lot of work. Sometimes, it becomes difficult because the person is unaware of what they really need. They want something, but they actually need something else. The need often differs from the want. This mismatch is the difficulty of developing empathy.

For example, imagine an engineer who wants to work on a specific project. If the skill set matches with requirements, the non-empathetic leader assigns the person to the project. After a while, the engineer begins to have significant problems with the project. The manager starts to think that the engineer is the problem. As a manager, they did what the engineer asked for: assigned them to the project. However, the problem is not on the engineer but the manager. Yes, the engineer said they wanted to work on a project and the manager assumed this is what they needed, but, instead, they either needed recognition, or a new challenge, or less stress, or to prove themselves. It's rare that what a person asks for is the same as what they really need.

Assuming rarely works; assuming without empathy never works

The first thing the leader has to do is active listening: silencing the noise both in the mind and in the mouth and focusing on the other person, seeing through and beyond them.

Humans naturally form assumptions to find a common understanding between each other. However, many leaders unintentionally stick to these premature thoughts. Leaders have to constantly abandon assumptions until they find the correct route to the truth. Many discussions lose track because one side sticks to a premature idea and drives the conversation with it while the other side is talking about something else. These switch-track conversations are easy to fall into and lead to many conflicts.

Assumption and empathy are mutually inclusive: without one, we can't have the other. Building empathy requires forming a lot of assumptions and premature thoughts and constantly abandoning them. If the wrong assumptions drive the conversations instead of a sudden dispersion, empathy will be hindered. For empathy to surface, assumptions have to repeatedly disappear until they are replaced by genuine understanding.

Approaching with empathy

Leaders confuse empathy with being nice. Empathy indeed provides the source of power for kindness and care. It's also true that empathetic leaders are nice. But empathy is more than that.

Empathy is listening and seeing another person; preventing all personal judgment, fitting another lens on life, wearing another jacket, and putting on someone else's shoes. Empathy is becoming a different person each and every time.

While these definitions are nice, empathy is easier said than done. Approaching another soul with empathy is difficult. There are only a handful of known techniques which also don't guarantee great success. Actively listening encompasses these few techniques including increasing transparency, asking clarifying questions, and repeating the other side's message.

While many leaders try to do one or two of these, they still fail to understand the person in front of them. The real value emerges when these three techniques are done in the correct order. Many leaders begin with asking clarifying questions after listening to another person. This technique is the first recommendation attached to empathy in leadership literature, but it actually should come after bringing transparency to why you're asking clarifying questions.

It should be a universally accepted understanding that when someone asks a question, they also give the reason why they are asking. Giving the reasoning behind a question brings transparency and, therefore, builds trust. Yet many leaders fail to form a simple sentence before asking a question: "I would like to ask a few questions because I want to understand the core of your message, feelings, and thoughts." One sentence is often more than enough.

Without transparency and clarification, there won't be trust. Without trust, all questions are meaningless, and all answers fall short. That's why before asking any question, the leader has to be transparent. Once the engineer understands the person behind the questions, getting the proper answers for clarifying questions becomes easier.

Asking the right question at the right time is an art that many leaders work hard to become experts at. However, many of them also stop right after they get answers to their questions. There is one last thing to do, one of the most overlooked actions to understand another soul: simply repeating the message as heard.

The power of the technique is in its simplicity, and that's why many people underestimate its value, yet, it solves almost all implicit misunderstandings. Both clarifying questions and repeating the message give the engineer a chance to, and the confidence to, elaborate on their message and correct any misunderstandings without the fear of judgment.

If we put all the actions in order, the correct guide for becoming a leader who listens with empathy emerges as follows:

Explain your intention about why you'll ask questions to bring transparency and build trust.
Ask clarifying questions with curiosity. Let the engineer feel your curiosity.
Repeat the other person's message as you understand it to seek alignment.

Truly listening and seeing another person is a long journey. Learning these simple techniques takes time.

To see takes time, like to have a friend takes time.

— Georgia O'Keeffe on the art of seeing.

Aside from taking the time to learn and practice empathy with this technique, there is another element of empathetic listening that has to spread through the whole conversation—staying silent.

Making peace with silence

Saying nothing always scares people. A moment of silence is one of the most vulnerable moments of our social lives. It creates heavy stress and an urge to speak up. Silence causes stress because it actually starts the busiest conversations; conversations between feelings. Instead of a mouth, it uses the heart. This vulnerability scares leaders because the tough business leader image that society drew for decades cannot handle being open with another person.

However, when the leader effectively uses silence, the message, "I hear you, let's think and digest the words together" shouts to the engineer. It becomes clear that the leader takes time to comprehend the message. In conversations, there is usually no place to think things through. That's why during the small pause, the leader publicly and silently announces that they heard and are currently thinking. Practicing this kind of silence is difficult because the software engineering leaders got used to giving opinions so much that staying silent always feels intense and miserable.

It's the urge of not only every software engineer but also every human to fill a silence after four seconds. During this time, many leaders fall into the flow because they want to take action on projects, while deadlines are putting pressure on them, and they interpret the silence of others as uncertainty on what action to take.

Leaders don't have time as they rush through from a one-one-onemeeting to a weekly update meeting, from discussions to a decision, from action to feedback. Within this busy life, taking a ten-second silence is terrifying. The always-on, urgent life tricks leaders into destroying the beauty of silence and breaks the first opportunity to build true empathy. In empathetic listening, there is no place for urgency. Taking the time is mandatory to understand the other person (and ourselves), to let the feelings have a great conversation.

If we were not so single-minded

about keeping our lives moving,

and for once could do nothing,

perhaps a huge silence

might interrupt this sadness

of never understanding ourselves.

— Pablo Neruda

Getting comfortable with silence is difficult. But it gets easier with practice. Without practice, trial and error, it's impossible to build empathy.

While assumptions hurt relationships, silence, and active listening strengthen it. With every empathetic action, the leader makes a deposit into the trust bank and opens another line of connection with the engineer. Once the leader begins understanding the engineer and their actions, the sky becomes clear, and coaching and guiding the engineer becomes easier.

Before offering advice or reassurance, leaders have to offer empathy. Many leaders fall into the trap of giving advice because they believe they have to "fix" the situation. By approaching analytically and intellectually and sticking to wrong assumptions, empathy is blocked. The only way for the leader to hear what the engineer is saying is by starting with active listening and empathy. When the leader sees that the engineer releases their tension and their flow of words come to a natural halt, the leader becomes successful with their empathetic approach.

Reply via email | Reply via Mastodon | Comment

Mektup #22: What should you expect from your manager?

Tue, 11 Jan 2022 00:00:00 GMT

Hey friend,

In the last Mektup, I talked about which skills you should learn in the new year. Improving your skills and learning new ones help you take a step forward. However, you can't do these things alone. Your manager has to support you. Today, I will talk about what you can expect from your manager in your growth journey.

Managers talk about their and the company's expectations of you most of the time. It's also essential to define the other way around. When people join the teams I'm leading, one of the first questions I ask is, "What do you expect from me?" Surprisingly, the answers are often vague, like "I expect clarity," "I expect support," or "I expect freedom." When we turn the tables, your manager usually expects certain things from you—sometimes delivering a significant feature in a project, taking the lead in a particular area, mentoring others, completing a course, etc.

While it's the manager's job to define certain expectations from you, it's also your job to set particular expectations from your manager. If you two are not closely working together, you won't be growing in your role, and they won't be a successful manager (because the manager's work is measured not only by projects they deliver but also by how they grow their team members).

Set regular time with your manager—one-on-ones

Everything starts with one-on-ones. I wrote about my thoughts about one-one-one meeting strategies before, but I still talk with many people who don't have alone time with their managers. If you don't have one-on-ones, ask your manager to have them at least once every two weeks. If you already have it but feel you need to talk more often, ask your manager and increase the frequency. One-on-ones will be the time to talk about your growth, career, and opportunities in the company. They will help you establish your relationship with your manager and build trust. Don't skip it even if you have no particular topic to discuss. Also, expect your manager not to postpone or skip one-on-ones. If they do, verbalize this expectation and tell them. If you have no discussion topic, bring one general question or use it as a coffee chat to get to know your manager. One-on-nes will be your relationship's foundation; you'll need to form other expectations.

Feedback

The second expectation is not new: feedback. Each individual in my team asks me to give them feedback. Many people answer my question ("What do you expect from me?") with feedback. However, telling me, "I expect feedback," or asking, "Do you have any feedback?" rarely works. The crucial part is knowing which area or topic you want to get feedback on. Your manager won't shower feedback on you because it will overwhelm you. They will be selective with the feedback because there are only a few things you can improve simultaneously. That's why you should specify your expectation.

If you want to get feedback on your communication style, instead of asking, "Do you have feedback on my communication style?" ask, "How did you like my communication in our last weekly team meeting? I'm trying to improve a few things, and I would love to hear your feedback." This way, it will be easier for them to give feedback. They will tie their feedback to your behavior, and you will get concrete feedback that you can turn into action. In the end, being specific will help you and your manager.

If you don't know where you should improve, talk about it. Start the conversation with "In which areas should I improve to grow my career in a way that I want to?" Then probably, your manager will come up with specific areas they see as essential and fits into company and team goals. From there, you can start discussions and ask for detailed feedback.

Sponsoring

Last but definitely not least is sponsoring—one of the powers of being a manager. Managers often coach and mentor the engineers, but they rarely sponsor. Sponsoring is different than mentoring or coaching. In mentoring, your manager tells you, "Did you try doing X?" but in sponsoring, they tell you, "I recommended you for doing X. Can you do it?" They take the extra step and actively recommend you to others. Sponsoring makes you visible to others in the company. If your manager has never done something like this, send them this article and ask them what they think about sponsoring you for one significant thing in an area you want to grow. It's literally your manager's job to sponsor you. But let's be clear; they might not quickly find the right opportunity that matches your skills, or they may think you are not ready yet. That's why you should also open your eyes around and look for projects that you want to contribute and bring the project to your one-on-ones and talk it over.

These three expectations are the baseline. If you don't have one-on-ones or think you get less feedback, or don't have any sponsorship, it won't be easy to grow your career. Of course, you might have other expectations, such as better compensation, promotion, getting quick (and no-questions-asked) approval for your vacation request, and more. If you have the baseline set correctly and build your relationship with your manager, talking about other expectations will be way easier. Set the base correctly; the rest will follow smoothly.

I hope this letter helps you and gives you at least one idea. Let me know what you think by replying to this email.

Thanks for your answer in advance.

— Candost

P.S. A technique in case you can't decide which project you should focus on next.

Reply via email | Reply via Mastodon | Comment

Is Software Engineering an Art?

Thu, 06 Jan 2022 00:00:00 GMT

The Software Engineering profession is one of the most misunderstood disciplines. Many folks consider it as engineering; some tell it's like painting—an art, a few think it as a creative journey full of flaws. While engineering and painting may look different, they are similar in software engineering. Both start with empty hands, requires discipline, repetition, and knowing the fundamentals.

However, they differ in their approach to the problem. While painting can point out a problem, it rarely solves it. The engineering looks at an existing issue to find a solution. On the one hand, software engineering tries to achieve both with a single shot. On the other hand, it rarely succeeds because it's neither an established engineering discipline nor an accepted art trend.

If we look at other engineering disciplines such as civil engineering and mechanical engineering, software engineering falls short as a discipline. It doesn't have the defined quality standards and the legislation to enforce any standard. That's why there are a lot of crappy software systems all around us.

When we compare software engineering with painting, both often create new trends. In painting, new trends need time to establish and accepted by people. In software, we reinvent one trend after another without taking the time to establish the existing one. Being in the hype mode prevents bringing out creativity and blocks innovation.

If the software is not engineering and not art, what is it?

What is Software Engineering?

Software engineering is thinking that we can build Sagrada Família, combining the art and the engineering but failing miserably. Sagrada Família is unique because numerous architects worked on it after the initial architect (Gaudi). Each architect faced the challenge of keeping the original design but applying new trends, technologies, and own ideas. These days, each software engineer faces a similar challenge but takes a different path.

Unlike Sagrada Família, every software engineer who adds a piece of code tries to put their ideas and style by ignoring or destroying what the previous engineer has built. We think we are so good that we can quickly build Sagrada Família. But we don't have discipline, we don't know the fundamentals, and we often forget a foundation we should consider first.

A while ago, we talked with a friend, and he said the good software is boring, reminding me of Dan McKinley's post. Software engineering is actually to have a big enough tool belt, knowing each tool well, solving the problem, and using high-quality standards to measure the impact. And, this whole system is boring.

It's boring because the focus is on solving the problem with the boring tools that are established and producing a high-quality result. If we're trying to reinvent the wheel every time, the chances are that we are moving away from the actual problem and/or sacrificing quality. Boring technology keeps our focus on the problem.

Take Spring Framework, for example, it has many features, and it's established. And I think it's boring. Many things come out of the box and have guidelines to do certain things. Whenever we're stuck in any technicality, we can find an answer on Google.

Using Spring in a project is more close to engineering. We don't think about how we should implement dependency injection or caching. It's there and ready to use. We just need to decide how to apply it in our use case.

With using boring technology, the mindset shifts; we move the focus from technology to the domain—the goal changes from using new technology to solving the problem in the best way. The shift accentuates creativity and innovation.

Creativity and Innovation in Software Engineering

There is often confusion between being creative and being innovative. Being innovative encapsulates creativity, but not every creative activity is innovative.

Almost all engineering process is creative. The goal is to bring out what's in our heads. When we're planning, we plan how we work on small pieces to bring out the masterpiece. When we're coding, we start with an empty text editor, a small section of the bigger piece. Every time we code, we become creators, not innovators.

The innovation comes from combining both engineering and art. Building Siri, World Wide Web, multi-use rockets, blockchain, etc., are all innovations. These technologies advance our race. The problem is that we often praise innovation more than boring engineering.

We often ignore the reality of innovation: The innovation rises from knowing the ground rules well enough that we know which ones we can bend or demolish.

Take Tim Berners-Lee, for example. Before implementing the first HTTP, he worked in telecommunication companies, did many projects in computer networking for years. He learned the fundamentals well enough that later he was able to connect TCP and DNS to set the foundation of the World Wide Web (WWW).

On a lower scale than WWW, let's take Uber (or any other big tech company) as an example. They have built their own mobile architecture (RIBs) after they learned the ground rules and used the boring ones. Until it didn't fulfill their need, they used what was there. They learned the technology, needs, and business so well that they knew what they had to do to invent a new framework.

The major problem of becoming an innovator, artist, and engineer, we have to do the boring work first. Without having the fundamentals in place and knowing the ground rules, innovation cannot emerge.

I'm not saying that we have to learn how to use punch cards or write code in FORTRAN. We should choose our own boring technology that is established and won't require us to reinvent a new way to solve the same problems.

Many people always pick the latest technology, and many companies promote them. If we keep focusing on learning the latest technology before the boring ones, we can be neither an engineer nor an artist; I'm not even counting on being an innovator.

To get better at software engineering, we should pick a part in it and do it over and over again. Once we learned and mastered one side, we can look for new ones around it. If we don't learn one thing well enough, our foundation will be weak, it will crack, or we will spend enormous time solving the problems that were solved years ago.

Reply via email | Reply via Mastodon | Comment

Mektup #21: Which skills should you learn in 2022? and How?

Tue, 28 Dec 2021 00:00:00 GMT

Hey friend,

Here comes the 21st letter—the last letter of 2021. (The matching numbers are pure coincidence, I didn't plan this at all 😄.) The new year is upon us, and it's time to think about the next year.

Before deciding on New Year's resolutions, it's always helpful to reflect on the last year and see how far we went in a year. When we look back, the frustrating moments usually look smaller than we experienced before. After learning this perspective, I decided to do these retrospectives more often, more than once a year. When possible, daily.

Having regular retrospectives is a great way to recognize if we're progressing or not. Because many skills require a long time to build, we often forget about our goals and new year's resolutions after we set them. We start to live day-by-day.

When I realized that I had stopped creating goals, I focused on forming habits instead of New Year's resolutions.

Goals vs. Habits

I don't have goals in my life for almost two years. This strategy scares some goal-oriented people. However, I am focused on gaining new habits and playing a long-term game while living in the moment. This strategy helped me more than any goal that I had tried before. But I know that this style is not for everyone, especially not for many software engineers.

When I think about software engineering, the goals are the profession's nature. K.P.I.s, O.K.R.s, bug metrics, deadlines, and sprint goals are all pushing us to define more timely, measurable, and specific goals, a.k.a. S.M.A.R.T. goals. However, there is one thing many engineers forget: developing skills takes time and demands a lot of practice, courage, and resilience to take an unknown journey.

Think about the last time you wanted to learn a new skill, let's say coding. How was your journey? Did you know what you will learn? Most probably, you didn't. Even if you had a university or a bootcamp curriculum, you didn't know. Yet, here you are. You know how to code, and you probably already forgot how much time and energy you put into it. Now, you are focused on learning a more specific skill aligned with your career's progress.

As you grow your career, you get more specific with each skill. It was coding first, then software architecture and testing began. As you progress, there is always a more precise skill to learn. But learning any skill takes time, and creating goals for each of them puts us into a stressful race that achieving any goal will bring only a tiny moment of happiness because we have to think about the next one. There is always a next goal, next objective, next destination, next, next, next.

While you're onto new year's resolutions, think about how you work and live every day. If you want to learn how to design systems or how to build more secure systems, don't just say, "I will learn cybersecurity practices in a year." Think about what you should change in your day to learn a new tool, skill, or approach. Instead, your statement can be a mix of goal and habit, "Learn one thing in the security field every two-to-three weeks and practice it every day until you can comfortably explain it to another person." This statement still focuses on security but changes your daily habits.

If you are not going to change how you work or live, whatever goal you decide will fade away quickly. Focus on changing a tiny bit of your day. The effect will compound, and the impact will be massive by the end of 2022.

Which skills should you improve in 2022?

Many software engineers think about improving their technical skills and solely focus on them while they progress in their careers. The poor side of this approach is that they overlook other skills such as handling feedback and disagreement, managing projects, driving collaboration, facilitating meetings, mentoring, and many others. The worse part is that the other skills are more significant when combined.

The chart gives an overview of all skills distribution for senior software engineers. To provide a better perspective for different roles, Gergely Orosz shared a great notion that'll take a lot of words to explain.

Source: Gergely Orosz

Looking at the picture closely, you see that hands-on building software loses its portion once the software engineer starts growing into other roles. Don't get me wrong; technical skills are still mandatory for almost all leading roles. But they are not the only skill to become a great software engineer. In junior roles, improving technical skills has the highest priority. After that, other skills are more crucial.

When we think about technical skills, the leading roles demand more technical breadth than technical depth. It's still essential to keep technical skills alive because they are beneficial in all leading roles. But you don't need to know every single detail in the code. If you're leading, you will have to let others do the job so that they can grow while you're working more strategically.

If you are planning New Year's resolutions, consider the perspectives above. Don't bog yourself down on never-ending goals. It's difficult to say, "Yes, I have this skill now." Developing new skills requires constant improvements, and it takes time. Focus on changing your day a tiny bit to open up a space for learning new skills. Whatever you choose to learn, do it every day. Every. Single. Day. Even if it's reading an article for five minutes or trying one technique quickly, it doesn't matter: don't skip.

I hope to see you develop your skills, become a great leader, and have the best year of your life in 2022.

Thanks for reading; see you next year! 😉

— Candost

P.S. Maybe you're curious about which specific skills senior engineers need beyond coding.

Reply via email | Reply via Mastodon | Comment

Make Time Book Review, Summary, and Notes

Mon, 20 Dec 2021 00:00:00 GMT

How Strongly I Recommend It: 5/10

How Likely I Will Gift It: 1/10

Make Time is written by the bestselling authors Jake Knapp and John Zeratsky. We know the authors from another book, Sprint: Solve Big Problems and Test New Ideas in Just Five Days.

📣 What is Make Time Book by Jack Knapp and John Zeratsky about?

The book is about improving your life by focusing on what matters to you. It's not about managing your time block by block. It's not about creating a complicated system to increase productivity. It's about trying simple and effective strategies and adjusting them to your life.

The book gives only a straightforward strategy: choose a daily highlight. The rest of the book is focused on how you can do it, how you can improve your life to achieve your Highlight, and what you can focus on to have a better life.

Inside the book, there are 87 techniques that you can test in your life.

🌟 My Review

If I was new to the time management and focus concept, I would have liked it more. This is a great book for beginners on the topic.

The book's physical quality is low. The paper and cover are of good quality, but there are full black pages, and some of these pages left their mark on the adjacent pages.

I didn't learn as much as and in a way I expected. That's not because the book doesn't contain information; it has many techniques (87, to be more specific). It's because I expected something else. As I bought it online, I couldn't look inside before buying it.

But reading the book was smooth and easy. I also liked the drawings and page design; they made the reading a pleasure.

Also, the authors reminded me of the daily Highlight and Reflection methods. They also presented some tactics that I want to learn about the scientific background.

With all these, you might think that I'm not recommending the book. On the contrary, I recommend this book to the people I wrote in the "Who should read it?" title.

🚀 The Book in Three Sentences

Highlight, Laser, Energize and Reflect is the primary strategy that includes taking notes and writing, which I like to do.
There are 87 techniques in the book that covers all four topics to help you take control of your life and get rid of constant busyness.
The book is not just about time management tricks, but it's more about how to better focus on what matters to you and how to support this with your all life while getting rid of the busy bandwagon mindset.

🎨 Impressions

The book is an easy read, and there is no need to read it cover to cover. However, reading the Introduction and How to Make The Works Chapters is necessary to grasp the idea.

The book's language and style are aligned with its message. The language is succinct and straightforward; reading it doesn't take much time.

If you're already aware of many health, time, and energy boost strategies, it might not give you much. But it will teach you something you didn't know.

Who Should Read It?

If you're struggling with managing your time and have issues setting time aside for your passion, you should read this book.

If you're already working on your passion all the time, you can read this book to understand what aspects of your life you can improve. I'm sure you will get at least one new idea.

📒 Summary + Notes

The methodology is simple but powerful if you can apply it to your life. The beauty is that there is no need to follow step-by-step like a recipe.

Making Time methodology consists of four elements: Highlight, Laser Mode, Energize, and Reflect.

Highlight: You choose one activity that requires your attention. The activity shouldn't take more than 90 minutes to accomplish. The Highlight can be any activity such as reading and answering many emails, preparing a marketing campaign, writing an article, developing a new feature in your app, cleaning the apartment, or fixing your car.

A highlight is a single activity that you will prioritize during your day. It doesn't matter if your focus time is in the morning or evening. Your daily goal is to do whatever your Highlight is.

When there is a highlight, your mind is more in a happy state. After you finish your Highlight, you're done. Whatever else you're doing will be much more straightforward.

Laser: During your day, your laser focus will be on your Highlight. To increase your laser focus, you have to eliminate distractions.

Email, social media, TV series, and news are everywhere, and we are usually not aware of them taking our time. These days, we can neither block all of them and live in a cave nor spend our life around them. There is a balance, which requires being mindful and adjusting how we use these technologies.

If Instagram takes four hours every day, and you're complaining that you don't have time for anything you want to do, there are tricks to reduce your time on Instagram. Nobody is telling you to stop using it. The key is finding these techniques to focus on your Highlight of the day.

Energize: Cutting out time from distractions is alone not enough. Your body needs the energy to focus. That's why you have to take care of your physical and mental health with exercise, food, sleep, quiet time, and face-to-face social interaction.

There are many ways you can energize yourself while keeping your focus on your Highlight. There are tiny habits you can form or small changes that help you turn your bad habits into good ones.

For example, when you consume caffeine is crucial for balancing your energy during the day. Your body has its own clock and hormones that are adjusted during evolution. The extra chemicals you take have an impact, and not only how much you take these chemicals but also when you take them has a significant impact on your overall energy during the day.

Reflect: Reflection is writing notes before going to bed. It's not long-form writing or keeping a diary. You're free to make it as short as you want and as long as you need. The important thing is that you write daily. If you're not into writing, just try it for a few days. You'll already see the change.

What do you write? You write about the techniques you tried during the day and whether they worked or not. If they didn't work, why? Can you adjust it a little and try again tomorrow?

If you couldn't accomplish your Highlight, it's okay. You don't have to drop everything.

It's okay to have the same Highlight for the next day. You don't have to come up with something new every day.

It's okay to take a break from the system and come back later. It's not a complex system, and you don't need to follow it for the rest of your life.

The book has many techniques that are designed to fit each section (Highlight, Laser, Energize, Reflect). The goal is to choose any of these techniques that fit your life (or adjust it to your lifestyle) and try them. If it works, try again. If it doesn't work, change it or drop it and try something else.

There are 87 techniques in the book. I'm not going to write each one because almost all of them are written very well, and I can't write again without copy-pasting from the book. However, I will include the categories' list as it appears in the Table of Contents and how many techniques there are inside the category. So, you know what you will get from the book.

Highlight Tactics
- Choose Your Highlight (7 techniques)
- Make Time For Your Highlight (9 techniques)
Laser Tactics
- Be The Boss Of Your Phone (6 techniques)
- Stay Out of Infinity Pools (11 techniques)
- Slow Your Inbox (9 techniques)
- Make TV "Sometimes Treat" (5 techniques)
- Find Flow (7 techniques)
- Stay In The Zone (6 techniques)
Energize Tactics
- Keep It Moving (4 techniques)
- Eat Real Food (5 techniques)
- Optimize caffeine (7 techniques)
- Go Off The Grid (4 techniques)
- Make It Personal (2 techniques)
- Sleep In A Cave (5 techniques)
Reflect (No special techniques, but it has three titles inside)

☘️ How the Book Changed Me

How my life / behavior / thoughts / ideas have changed as a result of reading the book.

I can't tell that the book changed me or my life a lot. At least, not yet.
As the authors suggest that we shouldn't try everything written there, I'm only trying to adopt one thing in my life; daily notes, including Highlights and Reflections.
Also, I realized that I already know a lot about productivity, time management, and how to focus on essential things. I picked up this book because I was having trouble with correctly spending time at work. I assumed that I needed a new approach or a framework. Yet, I didn't. Maybe one thing that will help me is consistently using Highlights and Reflection. I already tried writing daily Reflection before but failed miserably. Perhaps this time, it will stick, as I'm more inclined to write than before.

I expect books to enlighten me. As I don't have unlimited time and capacity, I will probably read 25 books a year. If I live 40 more years, that's only 1000 books. It sounds like a lot, but not. 2,2 Million NEW BOOKS were published just in 2013. TWO MILLION and TWO HUNDRED THOUSAND. Therefore, my expectations are high from any book that I read.

How I Discovered It

I discovered the book with Amazon's recommendation algorithm when I looked for books related to Time Management.

Reply via email | Reply via Mastodon | Comment

Recognize but don't promote all of your employees

Thu, 16 Dec 2021 00:00:00 GMT

Recognizing the rock stars (excellent performance/gradual growth trajectory) is tricky because leaders often misunderstand these people and want to reward their performance. These leaders err in reward and give promotions while the person is not looking for a promotion. Promotion kills these people's motivation. They are looking for different challenges. One of the best ways to recognize these people's success is by asking them to teach what they know to inexperienced people. But also never forcing them to teach. If they don't want to, they should never be forced. Leaders should respect.

Finding opportunities for these people is the delicate and difficult part of being a manager for these people. Identifying what can work and what cannot is challenging and requires a lot of conversations with these people and others.

Related Note(s):
Source(s): Radical Candor by Kim Scott

Reply via email | Reply via Mastodon | Comment

Why people who are growing too fast can have low performance

Thu, 16 Dec 2021 00:00:00 GMT

People who grew quickly but have struggled in their position perform badly because of a couple of reasons: they might be in the wrong role. An engineer getting a promotion to manager because they were excellent is an example. Find the right role for these people. The second reason can be that they are new to the role, and therefore, too much happens too fast that they can't handle it. Clear out expectations in these cases. Setting the ground right will help them to learn and prioritize. Another reason can be personal problems. They might have difficult situations in life; just wait in this case. And the other reason can be that they are a poor fit for the company or the team. Either fire them or change their team. Keeping these people will be detrimental to everyone, including the person.

Source(s): Radical Candor by Kim Scott

Reply via email | Reply via Mastodon | Comment

Mektup #20: The Rule of Three to Avoid Bias

Tue, 14 Dec 2021 00:00:00 GMT

Hey friend,

I've been thinking about the goal of software engineering and what we do to achieve that goal. It's easy to generalize the goal by saying, "it's all about solving problems." However, it's not easy to generalize how we solve these problems at all. The most general answer to all our problems is "it depends."

There is no single way to define our next step when facing any issue. We might immediately find a solution by instinct, or we research a lot and then come up with a solution, or even mix both and then do a little research, try an answer, do more research, and adjust the solution.

The problem with going with instinct is that we have biases and prejudice. We intuitively form these with experience. If we didn't have any biases, we probably couldn't decide whether to use a for loop or a while loop. Although biases are helpful for minor problems, when we face more significant issues, biases and prejudices are detrimental.

Biases prevent us from finding the optimal solution. In a problem, we recognize some cues that are familiar to us because of our previous knowledge. If we solved a similar issue in an earlier project, we're inclined to use the same solution, although the conditions are different and the solution is suboptimal.

This flaw puts us at risk of miscalculating the solution or making ourselves blind to alternative and better solutions. Pair programming, Request for Comments (RFC), Post-Mortem Analysis (PMA), feedback sessions, and other processes were born to eliminate these flaws.

These processes bring different minds together to eliminate bias. Another pair of eyes evaluate our solution and help us to find the flaws we missed in the first place. Albeit these processes are helpful, people often criticize them for the communication and collaboration overhead. That's why many people are hesitant to do pair programming or write an RFC for their solution. Instead of dealing with all the complexities of these processes, we sometimes need another way to eliminate the bias.

The Rule of Three

There is one simple yet powerful method—The Rule of Three!

Wherever we face a problem, we have to find a minimum of three solutions. Not one, not two, but three. Before you think that is a lot of work, which will slow us down, look at it this way: Add it to your tool belt and use it wherever you need. I've been using this methodology for years. Just even thinking about three solutions itself is a fantastic mental practice. Even if you choose your initial solution, the other two solutions give you enough perspective to open your eyes and understand the core of the problem.

Because once you think of three different scenarios, you are already acting like you got feedback from your peers. If you write an RFC and include the alternatives to your solution, whoever comments on your proposal already notices that you considered their way but eliminated them for specific reasons. Hence, you prevent discussion overhead.

By the way, I hear your inner voice keep asking: why three?

Because one choice is literally a trap, it's full of bias, and if your only solution doesn't work, you're out of options—you're screwed.

Two solutions are not enough because it creates a dilemma. Your mind starts to think it like either this or that. Instead of concentrating on the problem, you shift your focus to the solution.

Three solutions give you an actual choice. The more solutions you have, the better.

If you want to give this method a try, here are some guidelines that Rothman and Derby recommend in their book "Behind Closed Doors!"

Don't worry about who will implement the solutions. First, find them. Choosing who will take care of the solution comes after.
Consider solutions even if you don't know how to implement them—how part comes later.
Find good solutions. Don't come up with lousy ones just for the sake of finding an alternative. Also, it doesn't matter if you like the solution or not. All of them have to be worthy of serious consideration.

I'm not saying that you should apply The Rule of Three everywhere. But be aware that the application is not limited to software engineering. You can use it for any problem you have in your life.

Use the rule as a tool, and let me know if you give it a shot in one of your problems. It's always good to hear back from a friend who tries your advice.

— Candost

Reply via email | Reply via Mastodon | Comment

Have The First Win to Build Team Spirit

Wed, 08 Dec 2021 00:00:00 GMT

When I became a manager, I asked my managers for advice about how to build the team spirit in a new team to have a great start. There were many answers, but one advice was common: give the team a goal and deliver something as soon as possible. Deliver something.

While it sounds like a vague idea that doesn't specify what to deliver, we found a goal and committed to it, and it worked. With small nudges to keep the team focus on the goal, the team of five people delivered three achievements in the first six weeks.

And this article is about why the first wins are important.

Before we dive into, it's better to grasp the context of the team. The team was a spin-off from an existing team. Three of us were working together already, one person came from a team that we were closely collaborating. The last person joined us from another team that we had no prior collaboration. We don't have a scrum master or a dedicated product manager, however, we have two great product managers and a staff engineer who help us whenever we need.

Many teams just work on a project without having a clear vision and goals. Sometimes motivation comes from creating a new product or using a new technology. However, if the work doesn't provide any meaning, all the team building activities fall short. If we were in a boat with the team, it doesn't matter if we have the best boat or not. When we have to no destination to go, it's not fun to stay in the middle of the sea and consume all the supply in parties while floating. Especially, new teams quickly consume their low motivation supply in this floating state.

New teams have different dynamics from existing teams because there are no processes yet and people don't know each other; they are in the forming state, as Tuckmann says. When we partially spun off a new team, we inherited some processes, such as daily stand-ups, planning cycles, and more. It was tempting to focus on creating processes around the new team. However, what I realized that giving the new team a goal helps to form these processes on the way. When the goal is clear, the processes evolve in alignment with the goal.

Every team has unique sets of problems. Not everyone has a chance to form a new team. Sometimes we took over a team that is struggling to deliver. Most struggling teams usually forget their goals. When they focus on something else than the goal and have many discussions without a common objective, everyone follows their own track. When I was working in such a team as a software engineer, the first thing our new manager did (after listening to everyone) was gathering everyone around a goal and constantly reminding it to everyone. One common goal helped to solve other related issues as well. When people learned that they share a goal, they become more collaborative.

Team spirit forms around a common goal

Be it a new team or on existing one, when people have common understanding of the aim, they have a “reason to move the ship.” Instead of being in a floating ship, they focus on doing their part to move the ship in the right direction. They also figure out better ways to collaborate while doing it. Collaboration creates team spirit, team spirit creates success. Once everyone believes in that they can work together and succeed, there is nothing can stand in front of them.

Creating a team spirit passes from having the common and achievable goal. I don't like S.M.A.R.T. goals for teams. When I talk about goals for new teams, I mean release X in Y weeks, I don't mean increase conversion rate by 3% in a month. First, let the team accomplish something together, anything. Give them a meaningful, and achievable goal which is so small that they cannot not achieve it.

When we set a big goal for the team right in the beginning, it becomes difficult to achieve and people fall on to sidetracks and create their own smaller goals. In the beginning, pick the goals smaller. Small goals will bring more moments of success and celebration. However, giving a sole goal doesn't work alone.

Setting the goal and leaving the team alone with it is apt to fail. The leader has to constantly repeat the goal and coach and nudge people in the correct direction. In the boat, if the captain doesn't remind the course all the time, neither helmsperson nor the navigator can fix the course by themselves.

Don't start with processes

While setting goals, many managers fall into a trap of defining processes, a.k.a. how we are going to work. When leaders start defining methods, they take responsibility from the team. The new groups who discuss how they will work tend to forget the goals. Even though the methods aim to achieve the goal, the team's focus stays on the processes and methods. When the whole team, including the manager, focus on the goals, they usually find superior processes and approaches on the side.

Celebrate

When everyone focuses on the same small goals, the achievement easily follows. There is one thing I briefly mentioned that is as important as the goal itself: celebration. Without celebrating an achievement, we cannot expect it to be repeated. We want repeated success, and celebration is a type of reward we can give the team because we want to reinforce the desired behavior and recognize the work that has been done.

When managers immediately focus on the next goal and skip or forget the celebration, they fail to create the team spirit. Without taking a moment to recognize the achievement, we cannot create a sense of ownership.

Pushing for shorter iterations, starting with small goals, and celebrating in the end helps to create an autonomous, self-healing team. Then as a leader, you can start having better one-to-one relations with team members and move your focus to stakeholder alignments, organizational problems and cross-team projects.

If you're a manager of a new team and don't know where to start, gather people around a small goal and deliver it, deliver something to create team ego. What you deliver is not as important as you think in the beginning. Of course, it has to be related to your team's focus but deliver quickly and celebrate. I've tried this, and it works great. Don't skip celebrations, and never stop listening to your team members. If you're a new team, you have to prove your value to the organization and stakeholders. The best way to do that is to deliver work consistently.

When you deliver, your team becomes happy, you become happy, your stakeholders become happy: WIN-WIN-WIN.

Reply via email | Reply via Mastodon | Comment

I'm Sorry. The Project is Delayed and It's All My Fault

Thu, 02 Dec 2021 00:00:00 GMT

In one of my previous delayed projects, I told my manager, "It's all my fault. I made many mistakes, and I take full responsibility for it." Although my manager walked me through the reasons for the delay and tried to show me how everyone had their own portion, I still blamed myself, which contributed to a burnout that I had a year later.

I learned that I was not acting responsibly. Instead, I absorbed all responsibilities without leaving anything to others. At that time, it seemed like good behavior. I was the lead developer in the project, and I thought that the leaders should be responsible for the failures. However, absorbing all of it was destructive, and it was detrimental to me and everyone around me.

I was soaking up all the responsibilities, or as Douglas Stone and Sheila Heen call it, I was a blame absorber: "When things go wrong, you point the finger at yourself, now and forever." Now I know why I always had an imaginary finger pointed at me.

All my life, everyone prompted the idea of learning from mistakes. We fail, we learn; we don't make the same mistake again. "Make a lot of mistakes, own them. That's how you will learn," they said. However, I found out that some of us learn more than others, while few of us do not learn at all. When I put a magnifier on how to take lessons from failures, I found the connection to the amount of responsibility taken.

When there is no responsibility taken, there is no learning. Stone & Heen call these no-responsibility-takers blame shifters. When things go south, blame shifters, opposite the blame absorbers, shift all the blame to others and take no responsibility. Therefore, they don't learn at all. Both blame shifter and absorber are states we all have been in our lives. Who didn't blame the previous developer on the project for all the mistakes?

In my delayed project, there was no previous developer to blame. When I soaked up all responsibility, I was focused on only my side and failed to see how other elements contributed to the delay.

There was no apparent contributor besides me in hindsight. When I dig now, I see that there were other small and significant contributions. When I soaked every failure, there was none left for these contributors to learn. They also made mistakes, and all of them went unnoticed, and they didn't learn as much as they could. There was one more consequence that nobody could have seen.

I built up resentment. At that time, I looked around and thought that nobody took responsibility as much as I took. I started to have a grudge when I was the only one who took things seriously. My obliviousness caused me to blackout the holistic view of everyone's contributions. These thoughts had built up, and until my burnout, I didn't recognize them at all.

I learned now that the blame absorber behavior is not healthy for anyone. At first, it looks like a good habit that showcases responsible behavior. However, it's easy to recognize how detrimental it is to the group and the person when looked closely. The project was delayed, and I was responsible, true. However, I didn't delay the project alone. When I told my manager, "It's all my fault. I made many mistakes, and I take full responsibility for it," she responded with, "It's not a big problem, Candost. I appreciate you taking responsibility, but it's not all on you; we're in this together." Now, I understand how we are in this together.

Reply via email | Reply via Mastodon | Comment

Mektup #19: How to Prepare for Your Annual Review

Tue, 30 Nov 2021 00:00:00 GMT

Hey, friend,

It's that time of the year. Managers started the preparations and scheduled events on calendars. Today, I will share some tips for better and strong preparation for your annual review. I had many reviews, some good and some bad, as a software engineer. Now that I'm a manager, I have experienced both sides and clearly see how things work behind closed doors.

You may think that you don't need any preparation because your manager will do their job perfectly. Once, I had a manager who took care of everything and just told me about the raise I got in the end. He missed so many points, and the whole situation was inhumane. We didn't have a conversation; he had a monologue. Even if you have a similar manager like mine, and you know that preparation won't impact the result, you still have to prepare. You deserve this for yourself. Think of it as a reflection of the entire year.

It is easier to prepare if you're taking notes during the year about what you've done and achieved. If not, set an hour aside and scroll back to Jira tickets, Slack messages, calendar invitations, or any other tool that you use. While doing that, open a new document and start writing them down. Before starting this whole preparation, get Julia Evans' Brag Document. This document is what I use myself and recommend to my team members.

Julia structured the document in a way that forces you to think at different levels about your work. You group your work under Projects, Collaboration & Mentorship, Design & Documentation, What you learned, and Outside of Work. I won't go into details that Julia already covered. But I will share a few tweaks and highlights. Even if you don't use the Brag Document, these tips will be highly beneficial in your own style.

Measure Business Impact

If you can identify the business impact of your specific work, add it to your document. Many people say they improved Continues Integration(Cl)/Continuous Deployment(CD) pipelines and reduced the deployment time from 40 minutes to 20. While it's a good measurement, you can showcase it even better. If you want to impress, measure business impact.

Let's imagine your project/company makes $10 per minute, and you had a system failure that took the whole system down. Once you found the problem, you pushed the code. If Cl had run in 40 minutes, your company could have lost $400 in revenue. Thanks to your improvement, it was $200. On top of the saved hours from developers and release times, $200 is an additional and literal business impact.

Why is this important? Because the result of your compensation discussion may need approval from higher-level managers and Human Resources, and they always ask one question: Why? Adding a $ presentation to your document makes your case strong to get better compensation and easier approval (more about the compensation below).

Add the user impact

Besides business impact, think about how you impacted your users. Did the work you have done change users' lives? Not all of our work is on projects that reach millions of users. However, whatever we do, we impact some people's lives.

The user definitions are different depending on the team (e.g., product teams vs. platform teams) you work on. Find out how and how much you impacted your users. Did you improve performance by X%, and that improvement sole saved Y seconds every day in each user's life? If you have 10k users, Y second becomes Yx10kY seconds (probably some hours per day).

Attach the feedback

If your manager doesn't ask your peers for feedback, talk with your manager and ask them to collect feedback. If they won't, collect peer feedback yourself. Try asking three simple questions to your peers:

What should I continue doing?
What should I start doing?
What should I stop doing?

Add "Why?" to each of these questions if you'd like to.

Additionally, add screenshots of the praise you got in public or private channels. If you think these praises are obvious, still add them. Your manager can neither see nor capture all of them.

Share the document with your manager in advance

Send the document to your manager at least a week or two before the meeting and ask for feedback. Your manager needs time to read and digest it. Let them know that you're open to any questions about the document.

Compensation

The next thing you should do is prepare for the expected compensation change. I know that many people don't negotiate it at all, especially people from underrepresented groups. But you're giving service, and it hopefully has a lot of return to the company. On top of that, the market for software engineers is so high right now; companies and managers are doing whatever they can to keep people in.

Money might not be your primary motivator. However, money is what you get in return for labor, and if your value is higher than before, you should get more.

Be mindful of negotiation. It doesn't always have to be about salary increase; approach holistically. If you can't get the salary you wish for, what would you prefer instead? More vacation days (paid time off)? Less working hours? One-time bonus? Extra training allowance? Stock options? Equity? Make a plan with possible scenarios, and make another backup plan if some scenarios don't work. Whatever you do, don't go to the review meeting without thinking about it.

Don't let your manager decide anything alone. The annual review is not a monologue. It's about you, your impact, the company's options, and the market. The meeting should be a bidirectional communication. Better communication requires both parties to know what you have done, what both sides want, and what everyone needs.

Thanks a lot!

— Candost

P.S. Know your career system.

Two Topics From Me

I've recently finished the book Worth Doing Wrong by Arnie S. Malham. I found out about this book when I was searching for books related to changing the culture at work. After keeping it on my wish list on Amazon, my manager bought it as a job anniversary gift.

🔖 Worth Doing Wrong Book Summary, Review, and Notes

In our conversation on the season finale episode, Jesper talks about the differences between Machine Learning and Data Science, how to enter the field, and how and why life scientists shift their focus to Data Science. We talk about how businesses should approach data as the processes and methodologies are completely different from software engineering.

🎙 PODCAST: #26: Machine Learning and Data Science with Jesper Dramsch

One Topic from Others

Gergely is one of the people I have been following for a long time. Based on his experience in Uber, Skype, Skyscanner, and more, he wrote pieces of advice for software engineers to get the most out of the current heated market. Read it to learn more about how you can turn this opportunity to your advantage, whether you stay in your job or leave.

The Most Heated Tech Job Market in History: Advice for Software Engineers

One Question for You

Think about this question to reflect and learn more about your skills.

Why is the team stronger because you’re part of it? (Credit)

Reply via email | Reply via Mastodon | Comment

Clarify the expected outcome and the action it requires in written form to get it out of your mind

Mon, 29 Nov 2021 00:00:00 GMT

When we have tasks or other things that keep our minds busy, we usually think about them without taking action. This creates anxiety because we don't do these things; they just constantly occupy our minds.

When we write them down, we stop thinking about them. Because we trust ourselves that we will take care of it, we don't need to contemplate it anymore.

That's what typically happens when we procrastinate or forget to write down. The important thing is that we need to keep them out of our minds to relax and get things done at the same time.

We need to clarify to get it done. When we manage projects, we split everything into small chunks, especially in scrum. However, we fail to follow a similar strategy when we are at upper levels in our careers or managing projects vertically and horizontally. Especially managing time becomes difficult if we don't clarify tasks. We start excusing ourselves by saying, “I'm busy.” while the reality lacks clarity: we don't define what “done” means (outcome) and what it looks like (action).

When both are written down in tasks, it is usually easy to take care of them. Once we know what we will do and the expected outcome, we can take the task on time and finish it properly.

Related Note(s):
Source(s): Getting Things Done by David Allen

Reply via email | Reply via Mastodon | Comment

Have a single highlight of the day

Mon, 29 Nov 2021 00:00:00 GMT

A daily highlight is a method for focusing on your day. A flexible highlight that is achievable within 60-90 minutes of focused time keeps your attention on one thing. If you achieve your highlight during the day, you're done with the day.

Having a highlight helps you adjust other tasks to create space for it. If your calendar is full of meetings, you will look for ways to create a space to work on your highlight.

If you realize you can't achieve your highlight of the day, you can still change it in the middle of the day. You can also use the same highlight on multiple days if you haven't finished yet. Flexibility is the power of the highlight. But keep your highlights within the 60-90-minute achievable range.

Related Note(s):
- 25: Consistent writing brings success;
- 27: Developing Habits;
Source(s): Make Time by Jack Knapp and John Zeratsky;

Reply via email | Reply via Mastodon | Comment

Difference between an amateur and a professional

Mon, 29 Nov 2021 00:00:00 GMT

When we start a hobby as an amateur, we are okay with dropping it or not doing it for a while. But we're not okay with failure. Wherever we have a setback or failure, we demoralize ourselves and have a really hard time standing up again.

At the same time, in our professional endeavors, we never drop. Even when we're not in the mood to go to work, unmotivated, frustrated, or have other feelings, we still get up and do the job. This difference in mindset makes everything different. What about if we choose some of our hobbies and approach them professionally? Instead of falling down in every negative feedback or getting demoralized when people don't care about us, we take them as feedback and still keep going.

Reply via email | Reply via Mastodon | Comment

Not everyone has to have a passion for work

Mon, 29 Nov 2021 00:00:00 GMT

I've worked with people who want to bring money home and keep their passion for something else. This is entirely normal. Many people don't look to find meaning in their jobs. For them, it's just a job that enables them to live the way they want.

As leaders, our job is not to give them meaning in life at work. Our job is to understand each person's desire and motivation and create an environment where they can find their own meanings in their own ways.

Not everyone has to have a passion for work, and it's okay. If they still try their best and do that job well, there is no need for passion in these people.

Related Note(s):
Source(s): Radical Candor by Kim Scott

Reply via email | Reply via Mastodon | Comment

Why do we bother to write?

Sun, 28 Nov 2021 00:00:00 GMT

There are many reasons why we must write:

Writing is thinking. It shapes thoughts. We learn fresh ideas when we write them. Whatever we read, watch, and listen to is not ours. We internalise them by writing them in complete sentences.
Writing is remembering. The thoughts that only stay in our minds abandon us quickly. There is a Turkish saying, “Expression flies; writing stays.” When something is written, it's permanent.
Writing frees the mind from clutter and opens new places for fresh ideas. Whatever we write, we don't have to think about it anymore. It's written, shaped, and out of our minds. We now have more room for new thoughts.
Writing is creating. We make connections between ideas when we start writing more and more. Creating a network of thoughts not only helps us reflect on our thoughts but also improves our thought processes. We generate new ideas when we connect written ideas.
Writing is sharing. A written idea is not always individual. We share it with others, get feedback, and open more discussions about the topics we write about. We create communities, enhance the knowledge of the community and move forward.

Reply via email | Reply via Mastodon | Comment

Individual Contributor or Manager

Sun, 28 Nov 2021 00:00:00 GMT

How to make a career decision?

Ask yourself and answer truly: Do you imagine yourself in five years still coding the same thing or coding at least?

Related Note(s):
- 8a: Making the decision between management or IC Leadership;

Reply via email | Reply via Mastodon | Comment

Growing in IC track in Engineering

Sun, 28 Nov 2021 00:00:00 GMT

Growing in seniority requires more autonomous work. One needs to be able to work independently from others and in ambiguity. Helping others improve what they are doing becomes the kind of motto. Clear, concise, and transparent communication in written form is absolutely necessary. If the writing is abysmal, explaining the stuff in mind to others will not be easy. Last but not least, asking the right questions is one of the underrated skills, along with being kind.

Reply via email | Reply via Mastodon | Comment

Doing side projects helps you test your ideas

Sun, 28 Nov 2021 00:00:00 GMT

If you have the energy, do side projects where you can test what you've learned in a sandbox environment. While growing, you need to be able to identify the gaps in your knowledge, and you need a place to test your ideas first before applying them to work in production.

Source(s): Software World Podcast #9: Engineering Career Path - Tobias Bales;

Reply via email | Reply via Mastodon | Comment

How to move to the next level

Sun, 28 Nov 2021 00:00:00 GMT

Look at the defined career path in your company. If you don't have one, ask your manager about the expectations. List them down and learn what moving to the next level requires. Then focus on achieving them one by one. While doing this, write down all the things you're doing on the way.

Reply via email | Reply via Mastodon | Comment

Engineer Autonomy

Sun, 28 Nov 2021 00:00:00 GMT

The senior and above levels are more autonomous than juniors or lower levels. Prove your autonomy. But don't create a silo of your own. You should be able to work by yourself while still sharing what you've learned and done on the way, and bring people to the solution.

Reply via email | Reply via Mastodon | Comment

Be Kind at Work

Sun, 28 Nov 2021 00:00:00 GMT

Be kind. If you're working with juniors, they can make mistakes, but they are still people. Be a decent human being. Nothing comes out of being a dickhead. You cannot have a bigger impact if you are a dickhead.

Source(s): Software World with Candost 9;

Reply via email | Reply via Mastodon | Comment

Experiences are like compound interest on money

Sun, 28 Nov 2021 00:00:00 GMT

The effects of our habits multiply over time. Same as habits, in our career, whatever we focus on, our knowledge and experience multiply over time as well. In each area, we start small but each added knowledge creates an exponential growth. All our experiences add to our career development, like money multiplying through compound interest.

Related Note(s):
- 10a: Growing in IC track in Engineering;
- 30b1: Immunity to suffering requires healthy doses of pain;
Source(s): Atomic Habits by James Clear

Reply via email | Reply via Mastodon | Comment

What should you do when your manager delegates a task to you

Sun, 28 Nov 2021 00:00:00 GMT

When you get a delegated task, get as much information as possible. Ask what the manager has in mind to complete this task. How would your manager approach the task? There are multiple ways they delegate the task to you. Clarify their expectations.

Do they want completed work returned for confirmation?
Do they delegate everything and trust you to do the job and they don’t mind seeing the result?
Do they want you to come up with a plan before the execution and get a confirmation?
Do they want you to come up with a plan only for optional feedback but you’re free to go to the execution?

There are many ways to delegate and it also depends on the relationship and the task at hand. So if you’re a manager, be clear about what you delegate to a person. Make everything clear in the beginning so that you won’t have any problems later on. Make sure that you won’t block your direct report.

People sometimes don't complain even if the delegation is not clear. It doesn't mean that that is a problem. When something is not right, it will come back to you. Don't stress over it.

Related Note(s):

Reply via email | Reply via Mastodon | Comment

Managing Time as a Manager

Sun, 28 Nov 2021 00:00:00 GMT

When you are waiting for work to be completed, think about what the future will look like. If you have time, plan for it.

When you have time, make sure that others have what they need to do the work. Catch up with them and ask them if they need something from you.

Related Note(s):
- 19d: Why can't this be done sooner?;

Reply via email | Reply via Mastodon | Comment

The Meetings of a manager

Sun, 28 Nov 2021 00:00:00 GMT

The meetings are where the actual work happens. Don’t think you don’t have time to complete the work. In the meetings, thoughts are discussed, ideas are reviewed, and decisions are made.

There is no escape from the meetings in management. Even if the team is remote, you’ll have one-on-ones, planning meetings, etc. It’s not avoidable.

Related Note(s):
- 19d: Why can't this be done sooner?;

Reply via email | Reply via Mastodon | Comment

Public Speaking and Improving Skills

Sun, 28 Nov 2021 00:00:00 GMT

Give people a couple of questions before the talk and let them prepare to increase engagement.

If the talk is online, they should write to the chat so that there is an engagement going on.

Related Note(s):
Source(s): A colleague at my previous workplace

Reply via email | Reply via Mastodon | Comment

Choosing a talk topic is art

Sun, 28 Nov 2021 00:00:00 GMT

Choosing a talk topic is art. You need to take a look at the roots of a challenge or a problem you solved. You must define what you are talking about—is it people-related or deliverables-related? Share your progress. Reassess your solution. Could you have chosen a better approach? What are the mistakes or failures?

Source(s): Demystifying Public Speaking by Lara Hogan

Reply via email | Reply via Mastodon | Comment

Increasing Public Speaking Skills

Sun, 28 Nov 2021 00:00:00 GMT

Flip your fear and anxiety about public speaking to "deeply caring about the topic or subject" you are gonna talk about. There is no shame in caring about stuff.

Related Note(s):
Source(s): Demystifying Public Speaking by Lara Hogan

Reply via email | Reply via Mastodon | Comment

Do whatever works for you in your public speaking

Sun, 28 Nov 2021 00:00:00 GMT

"Do what works for you." When you want to present a topic, don't listen to the cliches such as "Never say umm." Doing what works for you brings authenticity, invites vulnerability, and forces you to be open to new things.

Source(s): Demystifying Public Speaking by Lara Hogan

Reply via email | Reply via Mastodon | Comment

Focus on only one improvement in every rehearsal for public speaking

Sun, 28 Nov 2021 00:00:00 GMT

In every practice run, focus on one improvement area and try developing it. When focusing on multiple areas, it is difficult to catch nuances.

If you make a mistake, don't start over. Finish the whole talk first.

Learn how to cover screw-ups one by one.

Source(s): Demystifying Public Speaking by Lara Hogan

Reply via email | Reply via Mastodon | Comment

Transform your nervousness into mindfulness in public speaking

Sun, 28 Nov 2021 00:00:00 GMT

Transform nervous thinking to mindful thinking in public speaking. Instead of saying, "I'm nervous," say, "I'm getting an adrenaline rush because I'm excited, and adrenaline helps me to concentrate."

Related Note(s):
Source(s): Atomic Habits by James Clear

Reply via email | Reply via Mastodon | Comment

Make key takeaways clear on your talk

Sun, 28 Nov 2021 00:00:00 GMT

Choose the key takeaways so that an attendee of your talk can directly apply them when they are back at work. Also, don't forget to give context so they understand the key points well.

Source(s): Demystifying Public Speaking by Lara Hogan

Reply via email | Reply via Mastodon | Comment

Prepare and ask questions to create engagement

Sun, 28 Nov 2021 00:00:00 GMT

Ask questions to the audience to create engagement. Put yourself into the audience's shoes. They are strangers to you. Will they still get the joy? Will they understand why you think this topic is important? Will they learn something new?

Source(s): Demystifying Public Speaking by Lara Hogan

Reply via email | Reply via Mastodon | Comment

How to Understand The Public Talk Feedback You Get

Sun, 28 Nov 2021 00:00:00 GMT

LifeLabs Learning developed a rubric to define four kinds of feedback on a public talk.

Hearts ♥️: Positive, but not specific. (I liked your talk)
Diamonds ♦️: Positive, specific, and actionable. (Your talk is good. If you do this, it can be great)
Spades ♠️: Negative, actionable suggestions.
Clubs ♣️: Negative, not specific or constructive.

Always look for Diamonds♦️ and Spades ♠️.

Related Note(s):
Source(s): How to give effective feedback on a talk

Reply via email | Reply via Mastodon | Comment

Inform viewers about questions

Sun, 28 Nov 2021 00:00:00 GMT

Tell in the beginning that you expect your audience to write something in the chat, or you’ll have the options to invite them to talk directly. When they know that they will be asked to engage, they can shake the “shyness.”

Source(s): A colleague at my previous workplace

Reply via email | Reply via Mastodon | Comment

Knowns and Unknowns

Sun, 28 Nov 2021 00:00:00 GMT

Choosing the technology, creating a new product, or even a company has its stages. In each stage, we figure out how to approach a problem. There are two different unknowns. We have known unknowns. We know that there is a thing we have to do, but we don't know how to do it or what happens if things go wrong. There are also unknown unknowns that we have no idea exist. New technologies often come with many unknown unknowns. We don't know what can go wrong.

We should not only be careful but also consider many different perspectives and take a look at the maturity of our new choice.

Related Note(s):
- We can find out some unknowns with collaboration.
- 20: Influencing Others;
- 22: Cross-Cultural Communication;
- 4b: Monitoring & Inspection to Learn;
- 24d: Strong product teams solve customer problems, instead of output;
- 39: Increasing Quality of Systems;
- 19c: How to move faster in organizations;
- 19d: Why can't this be done sooner?;
- 19e: How to make faster decisions by validating objections?;
Source(s): Choose Boring Technology;

Reply via email | Reply via Mastodon | Comment

Choosing the old technology

Sun, 28 Nov 2021 00:00:00 GMT

When technology is boring, it has its standards set. We not only know how to use it but also know the failures if we use it wrong. New technologies have more unknown unknowns than older ones. Older ones have that too, but the set is a lot smaller.

Source: Choose Boring Technology;

Reply via email | Reply via Mastodon | Comment

The process of choosing a new technology

Sun, 28 Nov 2021 00:00:00 GMT

Choosing a new technology is a process and a conversation, and we need to facilitate that.

We need to consider how we can solve our current problems without adding a new thing.

We need to write down why solving the problem with the current stack is difficult and expensive.

We need to set clear expectations when you want to migrate old technology to the new one.

Related Note(s):
- How to Stop Endless Discussions;
Source(s): Choose Boring Technology;

Reply via email | Reply via Mastodon | Comment

Consent-Based Decision Making

Sun, 28 Nov 2021 00:00:00 GMT

Deciding and Trusting scales from The Culture Map form Consent-based decision-making. You have to trust in task-based, low-level communication about why and egalitarian leading, top-down decisions.

Reply via email | Reply via Mastodon | Comment

How to move faster in organizations

Sun, 28 Nov 2021 00:00:00 GMT

Businesses work with making decisions and executing the decisions. To move faster, first, decide when the decision will be made in the beginning. When the decision is made is more important than which decision is made.

Related Note(s):
- 29: Uncertainty is needed to stay open-minded;
Source(s): Speed As a Habit by David Girouard on FirstRound Magazine;

Reply via email | Reply via Mastodon | Comment

Why can't this be done sooner?

Sun, 28 Nov 2021 00:00:00 GMT

Good decisions consist of gathering input and pushing toward it. Ask, "Why can't this be done sooner?" to achieve both. When moving fast, people should have a low level of discomfort. This indicates that they are out of their comfort zone. If we're going too fast, we can see this in the faces of team members.

Related Note(s):
Source(s): Speed As a Habit by David Girouard on FirstRound Magazine;

Reply via email | Reply via Mastodon | Comment

How to make faster decisions by validating objections?

Sun, 28 Nov 2021 00:00:00 GMT

How can we validate objections to make faster decisions that are "safe to try?"

Give everyone a chance to object to the decision by asking

"Does anyone have evidence why trying this proposal would cause immediate harm? If so, please suggest an edit that would make it safe to try."

Whenever you hear an objection, ask three questions in order.

Are you objecting because you have a better idea? Yes → Invalid objection.
Is the problem you foresee a future problem or now problem? Future → Invalid objection
Will that "now problem" be easy to recover from? Yes → Invalid objection.

Related Note(s):
Source(s): From The Decision-Making workshop (by aug.co) that I attended from a previous workplace.
Resourced: How to Handle and Overcome Objections to Your Proposal;

Reply via email | Reply via Mastodon | Comment

Writing by Hand

Sun, 28 Nov 2021 00:00:00 GMT

Writing by hand is more effective than writing on a computer or other electronic device. Handwriting forces us to understand the fundamental idea, concept, and structure of the thought better. The main reason is that handwriting is slow. We cannot be faster to write everything we hear. We have to be selective and write what we understand in the clear and the shortest way possible.

Related Note(s):
- Handwriting also happens together with editing and rewriting;
Source(s): How to Take Smart Notes Book

Reply via email | Reply via Mastodon | Comment

How to Take Literature Notes

Sun, 28 Nov 2021 00:00:00 GMT

Write briefly what you understood and your thoughts in your own sentences.

Keep all notes in one place.

Sort them alphabetically with surname_year format.

Match them with bibliographic details in your system.

The goal is understanding the text and preparing to transfer ideas into the context of our own thought lines in the slip-box.

Source(s): How to Take Smart Notes Book

Reply via email | Reply via Mastodon | Comment

Adding a New Note To Slip-Box

Sun, 28 Nov 2021 00:00:00 GMT

When we try to place a new note, the slip-box's chain-of-notes strategy forces us to think about the connections with other notes, including unrelated ones.

Instead of directly relating the note to something, we are nudged not to fit the idea into the existing line of thought and create a new line of thought. That's the beauty of Zettelkasten.

Source(s): How to Take Smart Notes Book

Reply via email | Reply via Mastodon | Comment

Contradictions in ideas within a thought line

Sun, 28 Nov 2021 00:00:00 GMT

Contradictions within the slip-box can be discussed further in the thought line. We find (and discover) opposite thoughts when we try to place the note in the slip-box. The most important part is connecting the note with as many thoughts as possible (while keeping a close relationship). However, it doesn't mean that opposing thoughts can't stay together. We can still discuss the contradiction within a line of thought.

Source(s): How to Take Smart Notes Book

Reply via email | Reply via Mastodon | Comment

Elaboration on an idea

Sun, 28 Nov 2021 00:00:00 GMT

The most successful learning method is the elaboration of what we've learned. When we elaborate, we first think about what we read. Then when we think about and write it, we start considering how it informs different questions and topics. And when we try to relate the note with our previous notes, we think about how it could combine with them.

Source(s): How to Take Smart Notes Book

Reply via email | Reply via Mastodon | Comment

Winners and losers share the same goals

Sun, 28 Nov 2021 00:00:00 GMT

Achieving goals are only for the moment. Winners focus on the systems and how to improve them. Losers only focus on the goal. Once they reach the goal, they are done. Winners are never done. Because the goals create "Either-or" conflict, it doesn't bring endless happiness. Setting goals means winning the game. When we focus on building systems and our mechanisms, we stay in the game.

Source(s): Atomic Habits
Resourced: Growth with Systematic Bliss;

Reply via email | Reply via Mastodon | Comment

Continuous Improvement Means Changing The System

Sun, 28 Nov 2021 00:00:00 GMT

One of the most common systems in the software industry is continuous improvements. When we don't make the improvement, systems start to rot. However, we don't change our goal while making an improvement. Continuous improvement means changing the systems, not the goal.

Source(s): Atomic Habits

Reply via email | Reply via Mastodon | Comment

Embrace & Love Boredom

Sun, 28 Nov 2021 00:00:00 GMT

"You have to fall in love with boredom."

This sentence has many aspects. Producing something valuable and being a creator requires dealing with boredom. Having a deep life with meaning requires knowing and facing boredom. For example, if you want to improve your writing, there are many days that you will look at the empty page for a long time. If you distract yourself and check social media, you will not write anything. Embrace boredom so that you can do some exercises over and over and over again, even if you are not in the mood to do them. "The only way to become excellent is to be endlessly fascinated by doing the same thing over and over. You have to fall in love with boredom."

Source(s): Atomic Habits

Reply via email | Reply via Mastodon | Comment

How to Improve Writing

Sun, 28 Nov 2021 00:00:00 GMT

Rewrite to learn what you didn't write

When we rewrite the text we have written, we learn about the parts we didn't know before. The first writing puts the raw idea out. Editing and rewriting shape the idea and perfect it. Putting the raw idea on paper is a sculptor's drawing on the paper; rewriting it is making the sculpture. We see the small details and nuances when we start rewriting. We connect dots that we missed at first. We learn what we haven't thought about yet.

Source(s): Bird by Bird by Anne Lamott

Reply via email | Reply via Mastodon | Comment

Influencing Others

Sun, 28 Nov 2021 00:00:00 GMT

When we share our thinking with someone early enough, we can generate more ideas, and people can get on board way easier, especially if we incorporate some of their suggestions into the plan.

Related Note(s):
Source(s): Think Less Learn More by Srini Pillay

Reply via email | Reply via Mastodon | Comment

Thinking out loud

Sun, 28 Nov 2021 00:00:00 GMT

In discussions at work, encourage people to "think out loud." Do the same. Then, people will stop thinking about authority and explain their opinions as well.

The same might work with saying, "Let me play devil's advocate" from The Culture Map by Erin Meyer.

Source(s): Turn The Ship Around;

Reply via email | Reply via Mastodon | Comment

Sharing knowledge is not a noise

Sun, 28 Nov 2021 00:00:00 GMT

Knowledge sharing might seem like a lot of noise. However, when the knowledge is/might affect someone else, then it is worth it.

Source(s): Turn The Ship Around;

Reply via email | Reply via Mastodon | Comment

Efficient Code Review Process (The changes I wanted to do in one of my teams)

Sun, 28 Nov 2021 00:00:00 GMT

3 people assigned and two reviews are required. The more the merrier.

Why do I want to do?

We have a lot of (unintentionally) hidden knowledge about our services.

Domain knowledge is not spread across the team.

Learning domain knowledge is hard if you are trying to discover it by yourself. There are many legal or non-legal aspects of the features.

Onboarding people is hard, and our onboarding process still needs to get better.

What I want to do - and what's the value of that?

I want to

Increase the number of code reviewers to three
Set merge requirements to two approvals
Automatically assign people using the Load Balance algorithm instead of Round Robin as the routing algorithm within the whole team, not task-forces.

Value & Goals:

Prevent creating new unintentionally hidden knowledge
Increase domain knowledge
Increase tech stack knowledge
Give and receive more valuable and effective feedback from different members
Have a better onboarding process
Increase communication between task-forces
Improve code quality.
Lower the efforts in new feature/project planning phases.

How do I want to do?

I will go to GitHub team management and change everything as I propose above.

I will remove squad GitHub groups. I will keep task-force groups. If someone has a question related to the task force, they will be able to mention others.

What you will have to (do/learn/change) after I finish it

You will use only the team group on Github (and remove other subgroups) while assigning code reviewers.

This process will require everyone to review the code of others and other projects actively. It will add a little bit of overhead. But an important and valuable one.

You will have to learn each task force’s mission and their work. You will have to spend some time reading Jira tickets and ask questions proactively to challenge others.

The code reviews will probably take >0.5 days per person per week, but I don’t expect it to take more than one day per week.

Risks

If we change the code review mentality from “yet another task to do” to “it’s another chance to make this team better than I found,” we can lower the following risks.

PR review waiting times might get longer.

People will not actively review the code but will let the third person do it.

Communication overhead. If people don’t check the code at a certain time, it will require pinging people in person to take a look at the code. To lower this risk, everyone can review once a day the PRs that they have been assigned.

Measurement

Faster software designing for new projects, features. (We can measure how much time it will take us to plan the next feature/project implementation and compare with the last one)

Fewer bug reports. It’s hard to directly measure since we’re using different projects, boards, etc. But I know that it’s possible in Jira.

Faster and better onboarding. We will get feedback from the people who are currently in the onboarding stage.

Related Note(s):

Reply via email | Reply via Mastodon | Comment

Why should we do a code review?

Sun, 28 Nov 2021 00:00:00 GMT

When we're onboarding, we often don't know the domain and the system. On a personal level, we have many known unknowns. If we're a junior developer, then we have many unknown unknowns. That's why mentoring and code review helps a lot in figuring out what we didn't know. Especially for junior people, it's a great strategy to learn because they don't know if something exists. When a person starts getting experienced in the job, their unknown unknowns in their domain or tech stack start dissolving. However, when they pick something new, the same thing starts again. The code review process helps to share knowledge. If we share our knowledge, we might solve someone else's unknown unknown.

Related Note(s):
- 19a: Knowns and Unknowns;

Reply via email | Reply via Mastodon | Comment

Four stages of the best code review process

Sun, 28 Nov 2021 00:00:00 GMT

The most convincing code review happens in four steps. First, make it obvious: explain in a very detailed form. Don't just say, please change X to Y. Explain the why so the change should be very obvious. Second, make it attractive: explain the benefits of the change. Make the change request very attractive that they want to do it. Third, make it easy. Don't request a full rewrite. Your changes shouldn't create hesitancy or devastation, on the other side. Last, make it satisfying. They should "get" a reward after that. You can praise their effort, or do other things to make the code review satisfying. These cannot be done all at the same time. These are in an endless loop and in order. Once there is satisfaction, it should feed into the loop again.

Source(s): Atomic Habits by James Clear

Reply via email | Reply via Mastodon | Comment

Cross-Cultural Communication

Sun, 28 Nov 2021 00:00:00 GMT

In the cross-cultural communication scale (low- and high-context), which two communication styles have more conflicts and problems in communication?

Two high-context cultures: Both high-context cultures try to read the air from their own cultural point of view. But the other side's cultural difference makes it difficult to grasp the thought behind the scene.

Related Note(s):
Source(s): The Culture Map by Erin Meyer;

Reply via email | Reply via Mastodon | Comment

Don't assume while working with people from various cultures

Sun, 28 Nov 2021 00:00:00 GMT

You shouldn't assume things. For example, when you are not sure about someone's religion, you shouldn't even try celebrating the religious days of their religion. Assuming is one of the worst strategies in cross-cultural communication. It creates awkward moments. Unless you explicitly ask, hypothetical approaches will always be based on stereotypes. But people are not stereotypical.

Having a diverse workforce is a crucial step for many companies. Leaders in these companies need to build trust with many different cultures. That's why leaders have to learn when to ask explicitly and how to read between lines. As a practice, ask yourself "is this knowledge come from my assumptions, or did I ask explicitly about it, or did I hear them talking about it before?"

Reply via email | Reply via Mastodon | Comment

The First Question of Feedback Discussions

Sun, 28 Nov 2021 00:00:00 GMT

Would you be open to hearing some feedback? How do you want to receive feedback? Written? Verbal? In private? In public?

The above phrase is one of the first questions I ask my direct reports. It's also one of the questions I ask anyone before giving them feedback.

Use it. You won't regret it.

Before giving any feedback, ask the person how they would like to receive the feedback and in which format—for both negative and positive feedback. Each person is different and wants a different style.

Many people want to receive negative feedback in private and praise in public. However, don't put everyone in the same basket. Many cultural influences impact people's styles.

Some people are okay with receiving negative feedback in front of others. But they might not be okay with sharing praise in public. Some folks want to receive feedback in written form upfront to digest it and think about it before talking with you about your feedback.

Always ask in which form (written or verbal) they would like to receive any feedback—positive or negative.

Source(s): The Culture Map by Erin Meyer;

Reply via email | Reply via Mastodon | Comment

Give positive feedback at the moment of action

Sun, 28 Nov 2021 00:00:00 GMT

The feedback has its meaning when it's timely. Positive feedback usually feels like a pat on the shoulder, and we usually think that we can do it at any time. However, positive reinforcement works better when it's delivered right after the desired behavior. When we reward people at the moment they do something good, they directly connect it to the behavior, and that behavior solidifies. When the reward is late, it loses its meaning, and we begin to have a hard time justifying achievements.

Source(s): Turn The Ship Around by David Marquet;

Reply via email | Reply via Mastodon | Comment

Authority has no impact when action on feedback

Sun, 28 Nov 2021 00:00:00 GMT

When an authoritative figure (like a CEO or manager at work) gives feedback, the feedback usually has more weight. People often carefully listen. This situation creates a fallacy for leaders: when they give feedback, they expect that everybody will act on it. However, it's not true. Regardless of authority, if the receiver side doesn't take the feedback, nobody can force it, including the CEO. They can take action and give notice or even fire the person; however, there is literally nothing they can do besides threatening and forcing other people to take the feedback.

Source(s): Thanks For The Feedback by Douglas Stone & Sheila Heen

Reply via email | Reply via Mastodon | Comment

Be careful with obnoxious aggression

Sun, 28 Nov 2021 00:00:00 GMT

Obnoxious Aggression occurs when you give feedback without personally caring about the person. Feedback goes out as pure, non-constructive criticism. It becomes a slap in the face, and you become an asshole boss who stabs people while looking in the eye.

Obnoxious Aggression also occurs in praise. If you give praise without personally caring about the other side, the praise becomes empty and even detrimental. It begins to be seen as insincere and disgusts people.

Source(s): Radical Candor by Kim Scott

Reply via email | Reply via Mastodon | Comment

What is Manipulative Insincerity?

Sun, 28 Nov 2021 00:00:00 GMT

In manipulative insincerity, you give feedback to others without personally caring and without challenging them directly. So, you give feedback for the sake of giving feedback. You tell another person what they want to hear instead of your real thoughts. This type of feedback shows that you don't care about the other person enough.

Source(s): Radical Candor by Kim Scott

Reply via email | Reply via Mastodon | Comment

Don't give feedback for the sake of giving feedback

Sun, 28 Nov 2021 00:00:00 GMT

When we give feedback to each other, we sometimes get stuck in the feedback. I once had a direct report asking me to give feedback in their first month on the team. I focused on giving something as feedback. When we focus on delivering feedback about what they are doing wrong while we have nothing to say, we get stuck. We need to take a step back and look at what each of us is contributing to the work and collaboration. This strategy helps us to find what's going well and what's not. When we do this, we see common patterns. Instead of giving empty and wrong feedback, we can deliver meaningful feedback.

Source(s): Thanks for The Feedback by Douglas Stone & Sheila Heen

Reply via email | Reply via Mastodon | Comment

How to show a blame absorber other factors' impact on the problem

Sun, 28 Nov 2021 00:00:00 GMT

A blame absorber is a person who takes all responsibility and leaves no responsibility to others. They absorb all responsibilities even if they have nothing to do with it. They don't count the external factors. We know these people who usually say, "I should/could have done X. It's all my fault."

To show them the effect of other elements, walk them through the big picture, and broaden their perspective without blaming them. First, help them see how they contribute and how their behavior and impact are (you can use situation, behavior, impact modal). Take the second step and explain how their and others' roles and responsibilities clash and create a responsibility conflict and adversaries. Third, show them how the overall system causes or affects these players to act in that way.

While explaining, don't load all responsibility into yourself or the system. Let the blame absorber understand how all the factors play a role by showing all factors together. Then, help them understand their part and enable them to take full responsibility for that part, not for the others.

Related Note(s):
Source(s): Thanks For The Feedback by Douglas Stone & Sheila Heen
Resourced: I'm Sorry. The Project is Delayed and It's All My Fault;

Reply via email | Reply via Mastodon | Comment

Just say what you are going to say while giving a damn

Sun, 28 Nov 2021 00:00:00 GMT

When I started thinking about my feedback and how can I give it in the Radical Candor framework, my feedback already improved because I had to think about challenging people and caring about them. I realized that I already care about people; my only missing part was challenging them directly. Now, I'm looking for ways to challenge people.

Caring about people is often seen as a weakness because professionalism doesn't include personal feelings a lot. But we're born with caring for others; we currently hide under the professionalism tag and use it as an excuse to be inhuman. If we have a hard time giving feedback, we can think of a similar but simpler situation and apply techniques from the simpler situation to the complicated one.

In the end, "If you are holding an authoritative position, just say what you are going to say while giving a damn."

Related Note(s):
Source(s): Radical Candor by Kim Scott

Reply via email | Reply via Mastodon | Comment

Strong teams are motivated by goals

Sun, 28 Nov 2021 00:00:00 GMT

People have different motivation drivers. However, when we form teams, they are motivated by team goals. Individual goals follow behind the team goals. Without an aim for the team to go, they cannot feel successful. No one wants to be in a ship that is just floating in the middle of the sea. If people don't know where they are headed, they won't follow at all.

Related Note(s):
Source(s): Introduction to OKRs by Christina Wodtke

Reply via email | Reply via Mastodon | Comment

Creating goals when you join a new team

Sun, 28 Nov 2021 00:00:00 GMT

If you are joining a new team, one of the first things you should do is learn the goals of the team. If there is nothing, start by figuring out how you can create goals that are ambitious and can gather people around them as much as possible. OKRs are a nice method, but it's hard to use them in the beginning.

Related Note(s):
- 3b: Joining A Team As A New Manager;
Source(s): Introduction to OKRs by Christina Wodtke

Reply via email | Reply via Mastodon | Comment

Specify goals instead of methods or processes

Sun, 28 Nov 2021 00:00:00 GMT

Specifying goals instead of methods creates confidence. When people try to focus on implementing methods to achieve a goal, they get stuck and forget the goal. Their focus only stays on the method implementation. When they focus on goals, they apply the methods better and can even figure out a superior approach as well.

Source(s): Turn The Ship Around;

Reply via email | Reply via Mastodon | Comment

Begin with The End in Mind

Sun, 28 Nov 2021 00:00:00 GMT

Writing up evaluations of 1, 3, and 5 years later and thinking ahead clears the mind and creates achievable goals. At the same time, these goals need to be measurable. We can't say "improve test results" as a goal. We need to define how much we want to improve. Is it 30% or 50%? And these goals have to be aligned with the bigger goals of the organization.

Related Note(s):
Source(s): Turn The Ship Around by David Marquet;

Reply via email | Reply via Mastodon | Comment

People need clarity, not motivation

Sun, 28 Nov 2021 00:00:00 GMT

Does this work with tasks at work, too? When people say that they don't have motivation, do they actually mean they need more clarity? Having a clear picture and unambiguous situations are more desirable at work. We look for more structure and clarity at work.

Related Note(s):
- A strategy to find clarity yourself, instead of waiting for motivation.
- Bringing people clarity needs writing them down.
Source(s): Atomic Habits by James Clear

Reply via email | Reply via Mastodon | Comment

Strong product teams solve customer problems, instead of output

Sun, 28 Nov 2021 00:00:00 GMT

Strong product teams solve problems instead of focusing on delivering a product or a feature (a.k.a. output). Strong product leaders define the strategy and identify the problems for these teams.

The strategy serves customers (not businesses) but works for the company.

Source(s): Empowered by Marty Cagan & Chris Jones

Reply via email | Reply via Mastodon | Comment

Consistent writing brings success

Sun, 28 Nov 2021 00:00:00 GMT

Being a consistent writer is one of the underrated and underestimated skills. If the writing and publishing are not in a rhythm, the success is very low. Most blog authors fail, not because they are bad at writing but because they are not constantly writing and publishing.

"Most blogs fail because blogging is an ultra-marathon, and the author gave up after a lap around the kiddie pool." — Monica Lent

Related Note(s):
Source(s): By Monica Lent in Blogging for Devs;

Reply via email | Reply via Mastodon | Comment

You get what you repeat

Sun, 28 Nov 2021 00:00:00 GMT

“You get what you repeat.” — Atomic Habits by James Clear

Big-win moments are the results of previous actions. These previous actions can build up for a long time.

Related Note(s):
- 24c: People need clarity, not motivation;
Source(s): Atomic Habits by James Clear

Reply via email | Reply via Mastodon | Comment

Making the habit obvious helps not to wait for motivation

Sun, 28 Nov 2021 00:00:00 GMT

When we fail to form a new habit or get rid of a bad one, we focus on having motivation. But, what we need is clarity on the time and location of the habit. When we have vague dreams, it is easy to rationalize small excuses not to follow the change. Making the actions more obvious helps to take conscious actions in a certain way, even without motivation. The Atomic Habits book suggests using the formula "I will [BEHAVIOR] at [TIME] in [LOCATION]."

Related Note(s):
- 24c: People need clarity, not motivation;
Source(s): Atomic Habits by James Clear

Reply via email | Reply via Mastodon | Comment

Don't slip twice

Sun, 28 Nov 2021 00:00:00 GMT

Don't slip away from your writing habit twice.
It's better to do it every time, even if you can't make it perfect or as much as you want. Just writing a small piece is better than not writing at all.
Don't fall into an all-or-nothing cycle. Do something small rather than fully neglecting it.

Source(s): Atomic Habits by James Clear

Reply via email | Reply via Mastodon | Comment

Commitment gives you freedom

Sun, 28 Nov 2021 00:00:00 GMT

Committing to something is perceived as limiting your options, limiting your freedom of choice. But committing brings freedom. Freedom from things that don't matter.

When there are many options for the same thing, we get stressed and cannot decide. Especially in the digital age, we are bombarded with different things that ask for our attention.

Committing to one thing means freedom from distraction. It enables us to work on one thing to excel at it. It keeps our attention on that and discards others.

Committing is saying no to many other things. It frees us, reduces our stress, and enables us to get better at the things we commit.

Source(s): The Subtle Art of Not Giving A Fuck by Mark Manson;

Reply via email | Reply via Mastodon | Comment

The Cost of Software Deployment and Continuous Delivery

Sun, 28 Nov 2021 00:00:00 GMT

Whenever we delay deploying minor fixes of software (changes in small batches), the repair cost also escalates. The minor work becomes major and requires more work every moment we delay. The increase in effort and expense is non-linear.

When the batch size becomes larger, people start multitasking in deployments because they have many different things to take a look at. Deployment often takes a long time and requires big parallel tasks like running migrations, checking if the data aggregation is correct, etc. They lose focus on individual tasks. Stress becomes high.

Reply via email | Reply via Mastodon | Comment

The Bigger Batch-Size Deployment's Impact on People

Sun, 28 Nov 2021 00:00:00 GMT

In large batch-size deployments, people become disconnected from the changes they made. Because there is a time gap between changes and deployments, they forget what they have fixed. And this might create new problems because if something goes wrong, they will not be able to fix that.

Psychological safety gets lower. Since the changes are significant and the risk of failure is high, people can’t have a safety net anymore. The no-returning back (or problematic returning back) hurts psychology.

Source(s): Small batches for the win-Continuous Delivery;

Reply via email | Reply via Mastodon | Comment

Bigger Batch Size Deployments lower product feedback cycle

Sun, 28 Nov 2021 00:00:00 GMT

Big batch-size deployments lower the feedback cycle. With small batch deployments, we can get feedback early on in the product. With big batches, we wait for the deployment date. And if everything goes well, we start getting feedback. Adjusting the product according to the feedback takes even more time because we wait for the next deployment. It causes to have bad product decisions.

Source(s): Small batches for the win-Continuous Delivery;

Reply via email | Reply via Mastodon | Comment

Lack of ownership

Sun, 28 Nov 2021 00:00:00 GMT

When we have bigger-size deployments, the deployment team might seem like they own the changes. The teams who made the change can lack ownership. If the batch has a problem, who will send a hotfix?

Source(s): Small batches for the win-Continuous Delivery;

Reply via email | Reply via Mastodon | Comment

Software Delivery Batch Size vs. Transaction Cost

Sun, 28 Nov 2021 00:00:00 GMT

Deploy smaller batches until the transaction cost (cost of deployment, cost of people and time, infrastructure cost, etc.) makes smaller batches inefficient.

Big batches have other costs, such as the number of people needed to align increases with code freezes, communication, and testing. And also, the possibility of having a change that is difficult to revert (data migrations) is costly. The mean time to recover increases a lot.

Related Note(s):
- 39: Increasing Quality of Systems;
Source(s): Small batches for the win-Continuous Delivery;

Reply via email | Reply via Mastodon | Comment

Developing Habits

Sun, 28 Nov 2021 00:00:00 GMT

Don't act, do it. When you are doing something, don't act like you are doing it. If your procrastination comes from being in motion (preparing or acting like you are doing), you need to change something. Instead of simply satisfying yourself and feeling better from vaguely doing something, focus on what you do and try to produce results often.

Related Note(s):
- 1: Why do we bother to write?;
Source(s): Atomic Habits by James Clear

Reply via email | Reply via Mastodon | Comment

Increasing awareness of the actions and behaviors

Sun, 28 Nov 2021 00:00:00 GMT

Naming the actions, especially the ones we do without thinking, increases the consciousness of the action. When we repeatedly do the same actions, we start to form habits. In Kahneman's words, our actions move to system one (conscious) from system two (automatic) (Thinking, Fast and Slow by Kahneman) when we get used to them. However, when we point to the action and call it (Pointing & Calling strategy), we become aware of our actions (move back from system two to one) and reduce the chance of making mistakes. Japanese underground train drivers, pilots, and many more professionals are using this technique to increase awareness on the job.

Related Note(s):
Source(s): Atomic Habits by James Clear

Reply via email | Reply via Mastodon | Comment

How to Learn New Things via Habit Stacking

Sun, 28 Nov 2021 00:00:00 GMT

Habit stacking is a technique to tie a new habit into an existing one. Old habits already have cues everywhere. They have certain times and places embedded in them. Our habits work with cues coming from time and place. To form a new habit, instead of defining a specific time and location, we can simply attach the new habit to an existing one. To make it obvious, we can use the formula "After [old habit], I will [new habit]." The time and location are already embedded inside. For example, after I stop working, I will play bass guitar.

Related Note(s):
Source(s): Atomic Habits by James Clear

Reply via email | Reply via Mastodon | Comment

Why Environment Matters More Than You Think When Building Habits

Sun, 28 Nov 2021 00:00:00 GMT

"If you want to make a habit a big part of your life, make the cue a big part of your environment."

Smokers have many cues around them. They always have a reason to light up a cigarette. People cannot form new habits or stop the bad ones because most people live in an environment someone else designed for them, either their parents, partner or family. To make the habits more consistent, design your own environment. If you can't, try a new environment. Building new habit is easier in a new environment. That is why we behave differently on holidays or elsewhere than at home.

Source(s): Atomic Habits by James Clear

Reply via email | Reply via Mastodon | Comment

Self-control and motivation are short-term strategies of habits

Sun, 28 Nov 2021 00:00:00 GMT

Reduce cues of bad habits. Increase exposure to good habits and related things by putting them on sight and making them obvious. Self-control is a short-term strategy while changing the environment is a long-term strategy to form habits.

Source(s): Atomic Habits by James Clear

Reply via email | Reply via Mastodon | Comment

Learn when you reflect: 20/40 Rule

Sun, 28 Nov 2021 00:00:00 GMT

Always spend a minimum of 20 minutes before asking for any help. Never spend 40 minutes before asking for any help.

Reply via email | Reply via Mastodon | Comment

Try to keep your learning in 'Just Manageable Difficulty'

Sun, 28 Nov 2021 00:00:00 GMT

If you want to learn something and grow yourself on that topic constantly, you need to keep your learning level in the "just manageable difficulty." If the challenge is too hard, it demotivates you. If it's too easy, you get bored. This is called The Goldilocks Rule. If you are learning how to write code, don't try to do it all at once. Take a very small step and learn it until it starts to be boring.

Source(s): Atomic Habits by James Clear

Reply via email | Reply via Mastodon | Comment

Build your skills gradually to climb Mount Everest

Sun, 28 Nov 2021 00:00:00 GMT

If you want to climb Mount Everest, you don't start by going there and walking up. You first start in small mountains and build up your skills gradually. After you master the necessary skills and build up your body for the challenge, you plan to climb Everest. Even when you start climbing to the highest mountain in the world, you spend nights in camps to get used to the climate and have a rest. You don't always go up every single day. This is the same thing as being an engineer. Start building basics and master. Choose higher mountains every time. Have rest in between to allow your body and brain to have a rest.

Related Note(s):

Reply via email | Reply via Mastodon | Comment

Uncertainty is needed to stay open-minded

Sun, 28 Nov 2021 00:00:00 GMT

Similar to knowledge acquiring, being confident and pursuing to be certain makes you more uncertain. The more you read and learn, the less you know. The more uncertain you are, the more you are open to learning and changing.

The more you are open to uncertainty, the more comfortable you will feel when you encounter something you don't know.

When you are certain, you limit yourself and put borders around your thoughts. Certainty is the enemy of open thinking.

When we put everything in a certain way, there is no joy in it. The joy, learning, and growth come from enough uncertainty and being open to new things.

Related Note(s):
- 52: Personal Values;
Source(s): The Subtle Art of Not Giving A Fuck by Mark Manson;

Reply via email | Reply via Mastodon | Comment

How to get rid of distractions in your head while you write

Sun, 28 Nov 2021 00:00:00 GMT

Writing is boring. Sometimes, when you start writing, there are many voices and thoughts that pop up in your head. They distract you by saying check social media, did you turn off the oven, or what should you eat at dinner. Think as if these thoughts are coming from small mice. Pick one of them from the tail. Put them in a jar and close the lid. Do it for all. Then imagine a volume knob in all these jars. Turn them all at once. Listen for a minute and turn them off. Go back to writing the first draft.

Related Note(s):
- 1j: No happiness without suffering;
- Turn off social media as it’s worthless.
Source(s): Bird by Bird by Anne Lamott

Reply via email | Reply via Mastodon | Comment

How to create a story?

Sun, 28 Nov 2021 00:00:00 GMT

Identify and Understand the audience (the most difficult one)
Create and determine the goal
Discover the challenges
Find the right character
Bring the challenges to resolution

Source(s): Unleash the Power of Storytelling by Rob Biesenbach
Resourced: Mektup #49: The Craft of Writing Effectively;

Reply via email | Reply via Mastodon | Comment

Being a Team Manager and Manager's Job

Sun, 28 Nov 2021 00:00:00 GMT

We can summarize the manager's job as helping people execute in the best way by clearing out the blockers and ensuring they grow while bringing success to the business.

Managing a team comes with challenges. The team might face blockers, can steer away from the goal, or can get stuck. There are many unknowns, and it's the beauty of it.

There are known knowns, such as things to do in the projects, and known unknowns, such as how to give feedback and personal growth. The manager knows their existence and, sometimes, how to approach these, but the possible result is often unknown.

There are also unknown unknowns. For instance, introducing new technology to an organization. New technologies come with many unknown unknowns; there are many things we don't even know they exist. Engineers and managers can not know every single detail, especially if the technology is new in the industry. If you're a manager, steer away from unknown unknowns or take small steps to convert them to known unknowns.

If you're joining a team, know your unknowns or try to figure them out.

Reply via email | Reply via Mastodon | Comment

Change is Inevitable

Sun, 28 Nov 2021 00:00:00 GMT

By using E. coli bacteria, the scientists observe the evolution through an experiment. E. coli bacteria can multiply multiple times a day. In the experiment, they populated E. coli bacteria every day for 36 years while keeping their environment exactly the same (using the same solution). After 20+ years or so, E. coli bacteria surprisingly started to consume Citrus (it was in the environment from the beginning, but bacteria never consumed it as a food source; they always used Glucose) as a food source. Over the years, tiny mutations in their DNA have led to a big difference in the bacteria.

What we learn from this experiment is also in another direction. We say that the earth and the universe are always changing, and therefore, we, humans, change as well. But the change happens even when our environment is exactly the same. Change is inevitable.

Related Note(s):
- 29: Uncertainty is needed to stay open-minded;
- 52: Personal Values;
Source(s): The Longest Running Experiment;

Reply via email | Reply via Mastodon | Comment

Immunity to suffering requires healthy doses of pain

Sun, 28 Nov 2021 00:00:00 GMT

In our everyday life, social media bombards us with happy moments. The protection of safe zones that we created for ourselves caused us to see reality less. Not experiencing the pain, we're losing the benefits of learning how to deal with it. Like babies not being exposed to germs early on and growing up being more vulnerable with a weak immune system, we're growing to suffer more and more from less important things. Social media, especially Instagram and TikTok, cause misconceptions about the real world. Yet, the reality is full of pain.

The important part is learning how to deal with this pain. If we avoid healthy doses of pain early on, we become extremely sensitive to any trivial pain. Our suffering bar gets lower day by day. We need to get the benefit of learning and experiencing healthy doses of pain early on to choose what to suffer from later on.

Related Note(s):
Source(s): The Subtle Art of Not Giving A Fuck by Mark Manson;

Reply via email | Reply via Mastodon | Comment

The Case of Happiness

Sun, 28 Nov 2021 00:00:00 GMT

The media likes to show extraordinary people who have achieved great things. Because these people create attention. Humans are interested in things other than themselves, and the press uses the exceptional to keep interest high.

The misperception created by the media causes many mental problems. The extraordinary people we see in the media do unusual things because they usually accept themselves as average or worse at what they do. They live the reality: most things in life are either average or suck. The media blurs this reality. It also creates a fake one by saying that everyone can achieve everything. The mental burden of seeing these people and being pumped with 'you are special' speeches leads us to think that we also must be extraordinary while we're not. Once we accept that we are such (or average), we can leverage the appreciation of the essential things in life. This mindset lets us accomplish what we want to achieve without having self-criticism or judgment. It helps us focus on the moment more instead of blaming our past or creating dreams that will never happen.

“When you focus on the past, that’s your ego.” Giannis Antetokounmpo Life Lessons

Related Note(s):
Source(s): The Subtle Art of Not Giving A Fuck by Mark Manson;

Reply via email | Reply via Mastodon | Comment

Choose good values and good metrics in life

Sun, 28 Nov 2021 00:00:00 GMT

Everyone has values and metrics that define their perspective and perception of life. They also describe the problems they face. In each situation, they interpret the events and either accept them as a problem or not. When they don't take the "bad" event as a problem, they just don't give a fuck about it. It's also possible that they see these things as good. It's really a half-glass full or half-glass empty situation. Their personal values and the measures they use to evaluate these things define how they see the glass. Some good metrics yield good results; some bad ones yield poor results.

The crucial part is that when they want happiness in life, they need to be cautious about which metrics they use to measure happiness and which values they are looking for. For example, if their value is honesty and they count the number of lies, telling the truth makes them feel satisfied. However, if they value success by measuring how they are doing compared to others (comparing with people who are doing extraordinary things), they will always feel unsatisfied and unhappy.

Related Note(s):
Source(s): The Subtle Art of Not Giving A Fuck by Mark Manson;

Reply via email | Reply via Mastodon | Comment

Our lives are full of choices

Sun, 28 Nov 2021 00:00:00 GMT

We always have to choose if we care about something or not. We decide to have a particular perspective on different things. Even when we don't choose anything, it's still a choice by its nature. The reality is that choice is unavoidable. It is why we should move our focus to how and what we choose. If why we choose something is clear and aligned with good values, we can become happier. If we decide on something with our shitty values, then there is a high chance that we won't feel that much satisfied. That's why figuring out the values and making mindful decisions are crucial for happiness.

Related Note(s):
Source(s): The Subtle Art of Not Giving A Fuck by Mark Manson;

Reply via email | Reply via Mastodon | Comment

Choose how you want to play with your existing hand

Sun, 28 Nov 2021 00:00:00 GMT

As you are born, the cards are already dealt in your life. You may be lucky and get a good hand, or you're out of luck and have a bad hand. The reality is, these are not our choices. However, having a bad hand doesn't mean that you will lose the game of poker. Your strategy is your choice. Ultimately, you're responsible for choosing how you will approach playing with that hand.

The same applies to life as well. If you are not in a good position from the beginning, you will have a good or bad life, depending on how you want to live. If you choose shitty values, it's your responsibility. When you decide to move on after a bad thing that's not in your control, you can have a better life. If you choose to blame yourself for what happened, although you didn't pick it and didn't have an impact on it, you are responsible for having a miserable life. The choice is yours, and you're responsible for it. Choose good values and measurements over bad ones to stop yourself from complaining all the time.

Source(s): The Subtle Art of Not Giving A Fuck by Mark Manson;

Reply via email | Reply via Mastodon | Comment

Avoiding Accountability Dysfunction in The Team

Sun, 28 Nov 2021 00:00:00 GMT

Accountability, in a teamwork context, means holding each other accountable and calling each other on our actions, behaviors, and performance that might hurt the team.

When people avoid this type of call-on, they actually avoid their internal discomfort, they avoid confrontation.

On the peer level, I rarely did this—calling people on. But giving feedback is a big part of it. When we give feedback, we're holding other people accountable. Regardless of their intention to be accountable or not, that's what we do. If they don't feel accountable still, it impacts the team more. Because not having this skill creates dysfunction in the team and prevents the team from succeeding.

Related Note(s):

Reply via email | Reply via Mastodon | Comment

Effectively Learn from mistakes

Sun, 28 Nov 2021 00:00:00 GMT

How effectively do we learn from mistakes? Having different mechanisms, such as retrospectives, helps increase learning. But how effectively do we use these mechanisms? Clear intention for improvement and having follow-ups are crucial. We shouldn't have these mechanisms just to say, "yes, we are doing it." We need to use them effectively.

Source(s): Turn The Ship Around

Reply via email | Reply via Mastodon | Comment

Communicating Decisions in Organizations

Sun, 28 Nov 2021 00:00:00 GMT

Be authentic. Personalization in the language is essential. If we always talk formally, we remove the sophistication and the touch of personality from the conversation. This also applies to the decisions. Decisions can be formal. But communication of decisions might be better in an informal way.

Reply via email | Reply via Mastodon | Comment

Continually and consistently repeat the message

Sun, 28 Nov 2021 00:00:00 GMT

People forget. If we want people to change their minds or apply a new method, there is no other way than continually and consistently repeating the message. They will eventually learn by hearing when the message is resistant. The problem is not their competence. When we want to give a message that they should follow, what alternative do we have? Changing the message will only create confusion and a lack of direction.

Related Note(s):
- 3a: Team Decision Deployment Strategies;
Source(s): Turn The Ship Around;

Reply via email | Reply via Mastodon | Comment

Invest in growing your employees

Sun, 28 Nov 2021 00:00:00 GMT

You need to put your money where your mouth is. If you want to grow your people, don't just send them to conferences; tell them to read books. Lead by example. Otherwise, no one will follow. Put awards for people who grow. Promotion is not the only way to reward people. Give swags and awards; invest in these because your company will grow only when people grow. If you want people to read books, pay them to read books. Either tell them to spend an hour every week or pay extra rewards for reading.

If you're not putting your money into the things you ask people to do, no one will follow.

Source(s): Worth Doing Wrong by Arnie S. Malham;

Reply via email | Reply via Mastodon | Comment

Clarity in Organizations

Sun, 28 Nov 2021 00:00:00 GMT

Clarity is needed in the organization. Everyone needs to fully understand what we're trying to achieve. Since everyone is a decision-maker in leader-leader organizations, they have to make decisions in line with what the organization is trying to accomplish. If not, we end up with a suboptimal decision.

Reply via email | Reply via Mastodon | Comment

Transparency and respect build trust

Sun, 28 Nov 2021 00:00:00 GMT

Trust is built by respect and transparency. Employees feel respected when the leader gives them what they need; equipment, devices, coffee machines, and information. People should feel empowered when their needs are fulfilled.

When the leader hides information, people can't do their jobs because they need the information to make decisions and execute tasks. If the leader wants people to bring solutions, own projects, and become loyal employees, the leader should give the information. Secrecy only leads to low morale and people feeling like pawns, not players (an Engineering Manager at previous job).

When there is no transparency, people will hear different things—often the wrong ones—and it will impact many decisions and morale. As the secrecy goes on, it will also be difficult to detect and notice these problems.

Related Note(s):
Source(s): Worth Doing Wrong by Arnie S. Malham;

Reply via email | Reply via Mastodon | Comment

Protective Leadership

Sun, 28 Nov 2021 00:00:00 GMT

Taking care of people in the organization doesn't mean keeping them safe from the results of their behavior and work. It means giving them tools, education, and advantage to achieve their personal and professional goals in the best way.

Related Note(s):
Source(s): Turn The Ship Around;

Reply via email | Reply via Mastodon | Comment

Open Feedback Culture

Sun, 28 Nov 2021 00:00:00 GMT

Resilient organizations don't allow mistakes or errors. Even when the captain or CEO makes mistakes, people who are competent in the area can inform the leader and say, "No, you're wrong." This open feedback culture creates resilient organizations that eliminate mistakes.

Related Note(s):
Source(s): Turn The Ship Around;

Reply via email | Reply via Mastodon | Comment

Setting Organizational Goals and Processes

Sun, 28 Nov 2021 00:00:00 GMT

"While goals give direction, systems make progress."

Focusing on systems bring result and help us to reach goals. Goals only set the course. If we leave the port and set our course only half a degree wrong, we end up in a totally different place.

Use goals to set a direction and systems to find clues that distract you from the goal. Keep your main focus on having good systems that tell you you're off.

Related Note(s):
Source(s): Atomic Habits by James Clear

Reply via email | Reply via Mastodon | Comment

Including side work into technical initiatives

Sun, 28 Nov 2021 00:00:00 GMT

When you sell a technical initiative as a business case successfully, you can use that initiative as an umbrella for others. If other initiatives will contribute to the business case you sold (it doesn’t have to be a strong contributor), you can include them as well after you sell it. This looks sneaky at first, but it’s actually your job to make things happen on the engineering side. If you are able to explain how the things you include are related to the case you sold, it’s fine. The stage test is a good model for thinking: if you can answer the question in front of the whole company in public, then it’s alright. For example, if you sold Continuous Delivery as a business need, you can include some migration efforts and focus on tech debt in it.

Related Note(s):
Source(s): CTO Craft Con Berlin 2024, Grygoriy Gonchar - CTO Eurowings Digital, Elevate Engineering Goals to your Company’s Genuine Priorities

Reply via email | Reply via Mastodon | Comment

Changing Habits Happen in Three Different Ways

Sun, 28 Nov 2021 00:00:00 GMT

Three levels (outcome, process, identity) of change define our success in changing habits. These are like onion layers. Changing outcomes is the outer layer, such as losing weight. Changing processes is the middle layer, such as the eating system. Changing identity is the inner layer, such as our self-image or the world view. So, outcomes are what you get, processes are what you do, and identity is what you believe.

Related Note(s):
Source(s): Atomic Habits by James Clear

Reply via email | Reply via Mastodon | Comment

Focus on who you want to become, not what you want to achieve

Sun, 28 Nov 2021 00:00:00 GMT

Most of the time, we try to change our habits, starting with outcomes. We focus on what we want to achieve. However, if we reverse our view and focus on who we want to become, we see real change. For example, when we want to quit smoking, and someone offers us a cigarette, instead of saying, "No, I'm trying to quit", we say, "No, I'm not a smoker." Instead of saying, "I'm a person who wants this behavior," we say, "I'm a person who is this." Once we do this, we start doing things related to this personality. We start taking pride that is our driving power to maintain the habit. We start following habits that fit our identity.

Related Note(s):
Source(s): Atomic Habits by James Clear

Reply via email | Reply via Mastodon | Comment

Increasing Quality of Systems

Sun, 28 Nov 2021 00:00:00 GMT

There is a sweet spot in optimizing for quality. The further you try to maximize something, the less benefit you get. At some point, the quality becomes useless and only serves as an art piece. This applies to many things, such as writing, architecting software systems, coding, etc. We need to carefully analyze the relation between the cost and the quality and try to keep it balanced.

Reply via email | Reply via Mastodon | Comment

Team Decision Deployment Strategies

Sun, 28 Nov 2021 00:00:00 GMT

We make decisions to make the team work efficiently and in harmony. Sometimes these decisions come from the top of the hierarchy, and sometimes not. The team lead or manager takes responsibility for the implementation. However, most of the time, this process is not that easy. There are many factors involved in the implementation of the decision. And also, what kind of decision we’re gonna deploy is the major question.

The decision implementation strategies are similar to the software deployment strategies. It’s also the last step of every planning, design, and implementation, as the decision implementation. There are different strategies for software deployment.

In Canary Deployment, we deploy the new service in one instance and test it with production data. If the instance and the new version of the system are working as expected, we deploy to other instances. For deploying decisions, we implement the decision with only one person. If it works, we apply it to the whole team. These decisions can test one idea in the team. We assign one task to one person and see how the person handles the task. Or we tell the decision to only one person to test it and get feedback.

In Blue-Green Deployment, we deploy the new service as a separate environment, test it and move all traffic to the new one once everything is working as expected. While applying team decisions, we announce the decision and the change but do not directly implement it. Once the decision is accepted by the team, we make the change. This strategy is effective in restructuring the team or department. We test the idea in production by getting feedback from people and understanding if they want to work on a new strategy or not.

In Rolling Deployment, we deploy the new service in the same environment but in one instance. And if everything works as expected, we slowly update the instances one by one. In team decision deployment, it can be personal growth decisions. It’s easy to try out a new personal growth or development strategy with one person and see if it’s working or not. Once we understand that our approach is suitable and we get a better result, we can start applying it to other team members one by one.

In “Big-Bang Deployment,” we terminate one version and deploy the new version. This strategy is suitable for team or company restructurings. We change it by destroying everything and building all things from the ground up.

The team decision and software deployment strategies are very similar in nature. They both come from hard planning and design. Only the implementation differs. While implementing software, you work hands-on in writing the code. In decision implementation, you talk with people and explain why a decision is made and how it affects them. And the application of the decision is the last step, where we stop talking and start working with the new change.

Reply via email | Reply via Mastodon | Comment

Joining A Team As A New Manager

Sun, 28 Nov 2021 00:00:00 GMT

The first thing is people.

Build trust and understand how to communicate and clear out expectations.

Be organized. If you promised something, you need to deliver it. Take responsibility for your actions.

Source(s): My Previous Manager

Reply via email | Reply via Mastodon | Comment

Building Trust as a New Engineering Manager

Sun, 28 Nov 2021 00:00:00 GMT

What to do, especially when you don't know the domain and the tech stack?

Building trust is tricky, but you might have an advantage. If you don't know the tech stack and the domain very well, you should not give suggestions immediately. You should ask questions as an outsider. This can make them realize things they didn't consider before. It will help you to understand the domain without being biased and build trust. When you ask questions, they will see that you care. While asking, admit that you don't know and are trying to learn. This behavior can lower their shield.

Reply via email | Reply via Mastodon | Comment

Building Trust as a Leader

Sun, 28 Nov 2021 00:00:00 GMT

The very first rule of building trust as a leader; do what you say, say what you do. Build authenticity. When you act differently than what you talk about, the people you are leading get confused. Confusion leads to frustration and conflicts between you and your employee.

Trust is something like insurance; you have to pay regular contributions to use it when you need it. When you act differently than what you talk about, you don't pay your regular contribution. Similar to insurance companies, employees will ask you to pay your debt in a meaningful time. Otherwise, you will lose the trust fully.

Related Note(s):
- 3: Being a Team Manager and Manager's Job;

Reply via email | Reply via Mastodon | Comment

Be Honest and Open to Building Trust

Sun, 28 Nov 2021 00:00:00 GMT

Be honest and admit when you don't know. Accept that the team consists of experts who know the work better than you. As long as they see that you are trying to get better at what you do and you're being empathetic towards the team you're managing, they will trust you. Be honest and open with the team.

Reply via email | Reply via Mastodon | Comment

Make Your Intention Clear

Sun, 28 Nov 2021 00:00:00 GMT

Understand what kind of trust the person wants to build. If the person needs more "personal relationship," ask them how their kids or cats are doing. If they are more inclined to task-based trust, care about their goals, what is important to them and how they define a successful relationship (e.g., if someone says they don't want public praise, don't give them public praise. If they don't wish to public feedback, don't give them feedback in public).

Reply via email | Reply via Mastodon | Comment

Giving Ownership to People

Sun, 28 Nov 2021 00:00:00 GMT

If you want to give ownership, don't just preach and hope for the best. Implement mechanisms that will support ownership. People should be able to use these mechanisms to own their domain.

Source(s): Turn the Ship Around;

Reply via email | Reply via Mastodon | Comment

Autonomy and Ownership Requires Technical Capability

Sun, 28 Nov 2021 00:00:00 GMT

To be able to give someone autonomy and ownership, the person has to have the necessary technical capability. If they lack the skills, they will make wrong calls/judgments.

Seeing training as increasing decision-making authority is a good way. It makes people first better at their job, and second, they start owning the decisions with more trust in themselves. Their fear dissolves in time. Increased competency means increased decision-making authority.

Source(s): Think Again by Adam Grant;

Reply via email | Reply via Mastodon | Comment

Creating an Agenda for One-one-Ones with Your Manager

Sun, 28 Nov 2021 00:00:00 GMT

Meetings with managers are crucial for career development. We keep one shared document to prepare one-on-ones better. We fill this document during the week. Everyone writes down what they have in mind so we don't forget anything. We list achievements, things we ask for feedback and action items. The document is not perfect in itself. However, whenever we have something in our mind to talk about during the one-one-one, we open the document and write it there.

This document opened many topics for us to discuss. We don't forget things anymore. We don't confuse the topics. Having the structure forces us to use time efficiently and prevents wasting time.

Each person writes to their column. There is no requirement to fill every line. Because sometimes you don't have any blockers. My goal is to have at least one item in the learnings and "things that went well." Because these are celebration points.

Before, we had 30-minute one-one-one sessions. Now, we're in the process of increasing the time. Because if you just randomly talk about a topic, thirty minutes is a lot. When you put structure, it's nothing. The meetings have an agenda; they are very effective and full of constructive discussions. That's why we decided to increase the time. We don't see this as a waste of time.

So here are the exact titles in our document:

What’s on top of my mind?
Things that went well
Learnings
Priorities (since we last met)
Priorities until we meet again
Challenges & Blockers
Feedback
Action Items

Resourced: Effective one-one-one Meetings—1-on-1 Meeting Template;

Reply via email | Reply via Mastodon | Comment

Giving ownership to people by delegation

Sun, 28 Nov 2021 00:00:00 GMT

Giving ownership to people and delegating the work is one of the greatest ways to empower people.

I've grown in my career because my managers gave me the job and empowered me by making me the owner of the initiative, project, or piece of work. Once I owned it, I tried my best to do it well and finish it. After a while, I became reliable. So, delegating tasks to your employees enables them to grow, learn, and showcase their skills, and become reliable.

If you want projects moving and initiatives running, assign a responsible person to each. You cannot run every single piece by yourself as a leader. You don't have that capacity and expertise. Only involve yourself when they need you or when they are blocked. Let them make decisions, not you.

Source(s): Worth Doing Wrong by Arnie S. Malham;

Reply via email | Reply via Mastodon | Comment

Working with and leading blame absorbers

Sun, 28 Nov 2021 00:00:00 GMT

There are people who always say I should've/could've/would've done this and didn't; it is all on me. If you are leading a person like this, as Sheela Heen calls them, blame absorbers, you have to take precautions. Otherwise, it leads to a toxic and unlearning environment. It's easy to fall into the trap of owning a responsibility. When a blame absorber takes full responsibility, there is none left for others. Also, it is detrimental to the absorber. Usually, there is not only one responsible person. Usually, there is a system, and other people and situations impact the problem.

If you let this slip, it builds resentment over time. The absorber starts to think they're always to blame, and others don't take responsibility at all. If you're building an ownership culture, be careful and show people the bigger picture and how you, they, and others are responsible together.

Source(s): Thanks for The Feedback by Douglas Stone & Sheila Heen
Resourced:
- A Systematic Approach to Give Feedback to Blame Absorbers;
- Learning Cone and Blame Spiral—The Case of Blame Absorbers;

Reply via email | Reply via Mastodon | Comment

Teams need emancipation, not empowerment

Sun, 28 Nov 2021 00:00:00 GMT

Empowerment doesn't work without clarity and competence—empowerment results from a top-down structure. We need emancipation instead of empowerment. An emancipated team doesn't need empowerment. Because they don't need the power from the leader, when they have emancipation, they can act freely. Since they are competent and there is a clear goal, they have the power on themselves to make better decisions.

Source(s): Turn the Ship Around;

Reply via email | Reply via Mastodon | Comment

Setting Clear Expectations About Communication and Collaboration

Sun, 28 Nov 2021 00:00:00 GMT

Sharing status updates doesn't mean the team is collaborating. We need to organize our meetings to both communicate and collaborate. There can be certain meetings where we only communicate (such as daily stand-ups), but there must be someplace we collaborate (it doesn't have to be a meeting). Understanding what's collaboration and what's not is part of a manager's job, and they have to clearly define their expectations from the team and communication mediums.

Source(s): Bottleneck #03: Product v Engineering;

Reply via email | Reply via Mastodon | Comment

Monitoring Work of Direct Reports

Sun, 28 Nov 2021 00:00:00 GMT

Top-down monitoring systems like tracking everything people do at work are not efficient. They don't work. However, we still need to collect data to monitor systems. But they should be used to make the invisible things visible and identify problems to solve them. They should not be used to determine what direct reports do or track people's work.

Source(s): Turn the Ship Around;

Reply via email | Reply via Mastodon | Comment

Understanding the Feedback You Receive

Sun, 28 Nov 2021 00:00:00 GMT

The feedback in relationships is about you AND the other person

The feedback in relationships is never about you or me. It's about you AND me. It's a two-way street. When we hear feedback from someone else, and if they are close to us, such as a spouse or a boss, we receive it according to our relationship lens. It's never independent of the relationship and never in one direction. When your spouse says, "you could've been more friendly at the party last night." they don't only tell you about your behavior. They include your relationship, how they feel about your behavior, and how it impacts them. The same applies at work. When your boss gives feedback about a meeting performance from yesterday, they also have concerns about their presence and how you impact it. This also affects how they want to work with you.

Related Note(s):
Source(s): Thanks for The Feedback by Douglas Stone & Sheila Heen

Reply via email | Reply via Mastodon | Comment

Switchtrack conversations

Sun, 28 Nov 2021 00:00:00 GMT

In the feedback discussion, there are relationship triggers. The feedback comes from our relationship with another person. In this kind of feedback, one person starts giving feedback. The other person responds with a totally unrelated thing to the feedback; they switch track of the conversation. It's similar to the railroad switch tracks. One example would be a couple. One person buys a bouquet for the other, but the other person told before that they don't like bouquets and starts complaining that no one listens to them. The person who gives the flowers says that they do not appreciate it. Here, the person who gives the bouquet switches the track. The feedback becomes you vs. me while focusing on different subjects.

Related Note(s):
Source(s): Thanks for The Feedback by Douglas Stone & Sheila Heen

Reply via email | Reply via Mastodon | Comment

Creating accidental adversaries

Sun, 28 Nov 2021 00:00:00 GMT

We create accidental adversaries because of a lack of clarity or confusion in roles. When roles are not clear, we confuse the other side. That's why the feedback we get may feel off-point; when responsibilities and roles are unclear, who is responsible for answering support requests? When these kinds of things are unclear, the expected things from us will also be unclear. In these situations, it's better to take a step back and ask, “How are our roles contributing to how we see each other? How do we give feedback to each other?"

Related Note(s):
- 34: Clarity in Organizations;
- 36: Open Feedback Culture;
Source(s): Thanks for The Feedback by Douglas Stone & Sheila Heen

Reply via email | Reply via Mastodon | Comment

Learning How to Receive Feedback

Sun, 28 Nov 2021 00:00:00 GMT

Focus on how to pull feedback instead of giving feedback.

Master the pulling feedback skills that drive our learning and curiosity. We always focus on giving effective feedback, yet whoever receives it is more important to hand over the feedback right. The teacher gives the same lesson to all students. It's how you learn to pull the information that makes you learn and be successful in class. The same applies to my whole life. We learn by pulling the feedback even in the toughest situations, such as when we're not in the mood or it's delivered poorly. Then you will learn and feed your curiosity.

Related Note(s):
Source(s): Thanks for The Feedback by Douglas Stone & Sheila Heen

Reply via email | Reply via Mastodon | Comment

Characteristics of Creative Work

Sun, 28 Nov 2021 00:00:00 GMT

Every idea in each creative process has inconsistencies and missing parts. They reveal themselves in the execution step. When an author has an idea, they don't realize the inconsistencies in the idea and don't see the missing points until writing it down. A software engineer cannot oversee every missing part of the design or inconsistent structure until the implementation part or experimentation starts. That's why ideas will always be raw and not great until they see an execution.

Related Note(s):
Source(s): Mythical Man-Month by Frederik P. Brooks Jr.

Reply via email | Reply via Mastodon | Comment

How to discover creativity?

Sun, 28 Nov 2021 00:00:00 GMT

We can discover our hidden creativity instead of focusing on negativity and how incompetent we feel.

Set aside some time and go over the following to find out your creative sides:

Success: Think back and find out your talents and abilities. What are you good at? Think about your skills. Consider your previous accomplishments and achievements. What were they?
Intrinsic qualities: Who are you inside? What are your human qualities? Which qualities do you associate with yourself? Some ideas: driven, efficient, practical, respectful, analytical, ambitious, etc.
Your esteemed self: Think about another new person with the qualities you defined above. How would you talk with this person? Would you be impressed and have a lot of respect for this person? And think about how different you talk to yourself when you compare your talk with this person.
Where is your creativity? Take a look at 1 & 2 again and ask yourself: In where did you exercise creativity? How exactly were you creative at those times? What qualities inform and enhance your creativity? Think about a moment when you were in the flow.

Related Note(s):
- 52a: Accepting one thing requires saying no to other things;
- Software World #17: Banish Your Inner Critic with Denise Jacobs;
Source(s): Banish Your Inner Critic by Denise Jacobs;

Reply via email | Reply via Mastodon | Comment

Systems and Design Thinking

Sun, 28 Nov 2021 00:00:00 GMT

We can define traditional systems thinking as separating the system into parts, looking at the relationships between them, and designing the overall system while thinking about these relations. In systems thinking, the problem is considered holistically. It is a logical exercise where we solve the problem in parts. We separate the problem into smaller parts, try to understand the interconnections between these parts and solve these smaller ones. Design thinking is missing in traditional systems thinking. In design thinking, we first understand the full context and then prototype solutions. In architectural thinking, we look at how the parts need to connect to the needs defined in design thinking.

Related Note(s):
- 43: The Role and Responsibility of Software Architect;
- 51: Consistency Models in Distributed Systems Index;

Reply via email | Reply via Mastodon | Comment

Actors/actions model

Sun, 28 Nov 2021 00:00:00 GMT

While preparing and planning software architectures, the architect can get help from the actors/actions model to discover how the system will be used by whom. The architect defines actors and how they act in the system. The actors map each incoming communication to either a message sent to other actors or a new behavior that will govern the response to the next message processed or create new actors.

Thinking and finding out how the actors will handle the incoming communication and going beyond and finding out what they need to do helps architects understand the domain and create a better architecture for it.

Related Note(s):
Source(s): Fundamentals of Software Architecture by Mark Richards & Neal Ford;

Reply via email | Reply via Mastodon | Comment

Component discovery with Event Storming

Sun, 28 Nov 2021 00:00:00 GMT

Event Storming is a component discovery technique from Domain-Driven Design. An architect assumes that the system will use events and messages. Together with the team, they identify which events will occur and how these events will be handled. They design the components around these events and message handlers. This technique can be pretty helpful for distributed architectures (e.g., microservices).

Related Note(s):
Source(s): Fundamentals of Software Architecture by Mark Richards & Neal Ford;

Reply via email | Reply via Mastodon | Comment

The Role and Responsibility of Software Architect

Sun, 28 Nov 2021 00:00:00 GMT

The level of the architect's involvement in the project should be certain and not very deep. When architects create extremely detailed software designs, they begin micromanaging the work. This is one of the reasons why architects are often misunderstood and people don't like getting directions from them. The role of the architect is defining top-level partitioning of the system, not designing individual components or classes. These tasks are part of developers' and tech leads' jobs. Unclear responsibilities of architects cause unnecessary harm and conflict between roles. Taking the creative work from engineers and tech leads steers to having no architects in the future because the next generation of architects will grow within that group. When they get no design challenge, they cannot grow properly. Keeping a good amount of system design and managing it should be in the direction of leading and coaching. Architects define top-level partitioning and top-level design. They can suggest a way for implementation. But they shouldn't dictate and be open to accepting other ways to implement and even sometimes forego the credit for suggested improvements.

Reply via email | Reply via Mastodon | Comment

Explicit disagreement is better than implicit misunderstanding

Sun, 28 Nov 2021 00:00:00 GMT

When giving or receiving feedback, the statement is true. But I couldn't stop myself from thinking and challenging it by thinking about different cultures. Does it apply to every culture, especially where people highly avoid confrontation? In Asian cultures, such as Japan, harmony is preferred, and disagreements are extremely discouraged. We might argue that disagreement and misunderstandings are different things as well. Maybe we can change the statement to an explicit misunderstanding better than an implicit misunderstanding. I think, from my cultural perspective, explicit disagreement is not always better than implicit misunderstandings, but mostly better. Sometimes you need to have it implicit but have to make it explicit misunderstanding in one way. It doesn't have to be a disagreement. Also, I think the author's point is that when we make the disagreement explicit, it's out there. We're not in our heads while understanding things in the wrong way anymore.

Related Note(s):
Source(s): Thanks for The Feedback by Douglas Stone & Sheila Heen

Reply via email | Reply via Mastodon | Comment

We attribute failure differently

Sun, 28 Nov 2021 00:00:00 GMT

Our perception differs from others about situations, ourselves, and our behaviors. For example, when someone fails, we think they are not capable of the job or don't have what it takes. But when we fail, we say and believe that the situation was not great and that other problems caused the failure. We don't say that we're not capable. The difference in perspectives is the point that requires more empathy. While preparing or receiving feedback, we need to think from both perspectives and correctly analyze the root cause to act accurately.

Related Note(s):
Source(s): Thanks for The Feedback by Douglas Stone & Sheila Heen

Reply via email | Reply via Mastodon | Comment

Confrontation brings honesty

Sun, 28 Nov 2021 00:00:00 GMT

Confrontational cultures such as Russia and the Netherlands drive the confrontation with honesty. They are openly honest about things, and the situation derives from their culture.

Only you can be honest with yourself if you are honest with others. That's where other cultures lack. When a person tries to be in harmony with the group and avoid conflicts, they think the drive to succeed with the group. It's sometimes true, as we also see in Japan. However, understanding ourselves requires being honest with ourselves. Being honest with ourselves demands being honest with others, even if we have to confront them.

Related Note(s):
Source(s): The Subtle Art of Not Giving A Fuck by Mark Manson;

Reply via email | Reply via Mastodon | Comment

Without conflict, there can be no trust

Sun, 28 Nov 2021 00:00:00 GMT

Conflicts are healthy in relationships. Always agreeing with each other will demand sacrifice from one side. One side hides their true thoughts or accumulates resentment that bursts out after a while. The relationship feels fake, not natural.

Society forces us to be the same, although individuals differ. Always confirming with each other and avoiding conflicts prevent us from finding the truth. When there is no truth in the relationship, we cannot be honest and, therefore, cannot form trust.

Related Note(s):
Source(s): The Subtle Art of Not Giving A Fuck by Mark Manson;

Reply via email | Reply via Mastodon | Comment

Software Architecture Patterns and Models

Sun, 28 Nov 2021 00:00:00 GMT

Entity-Trap Anti-Pattern

Creating entity managers to perform CRUD operations is not architectural thinking, and the result is not architecture. These operations can be easily handled by frameworks such as Ruby on Rails, NakedObjects, or Isis. Mapping from a database to a server doesn't need a full-blown architecture. Incorrectly identifying database relationships as workflows is called an entity trap, and it's an anti-pattern.

Source(s): Fundamentals of Software Architecture by Mark Richards & Neal Ford

Reply via email | Reply via Mastodon | Comment

Architecture Sinkhole Anti-Pattern

Sun, 28 Nov 2021 00:00:00 GMT

When a request is made to a layered architected service, if the request has to go through all the layers without applying any business logic, the situation indicates an architecture sinkhole anti-pattern. This pattern happens often. The healthy ratio is 80%-20%; a maximum of 20% of the requests having sinkhole anti-pattern is considered healthy.

Although it looks like it is happening more in layered architectures, I also saw it often happening in technically distributed architectures such as VIPER architecture in iOS. VIPER is especially criticized for this anti-pattern.

Related Note(s):
Source(s): Fundamentals of Software Architecture by Mark Richards & Neal Ford

Reply via email | Reply via Mastodon | Comment

Intentions, Behaviors, and Their Impact

Sun, 28 Nov 2021 00:00:00 GMT

We might not intend to do something, but the situation can develop so that our behavior impacts others differently than our intention. That's why we often say or hear that "I know their intentions are good, but they shouldn't behave in that way."

Our behaviors affect others, not our intention. How do we align our intention, behavior, and impact on others? Looking from a different perspective is the first step to aligning intentions and their impact. Our brains evolved in a way that we don't hear our sounds or see our body language. To bypass this, we can record ourselves and watch later to realize how we behave, respond to someone, and react to events.

Related Note(s):
Source(s): Thanks for The Feedback by Douglas Stone & Sheila Heen

Reply via email | Reply via Mastodon | Comment

Doubts are rarely formed on experience

Sun, 28 Nov 2021 00:00:00 GMT

"Doubts are formed around concepts, ideas, beliefs, and rejections. They are very rarely formed on experience." — Andy, Headspace.

Most self-doubts are rooted in beliefs. We believe we won't be able to do anything. Even though we get signals that say we are good at what we'll do, convincing ourselves is difficult. Understanding doubts and their root causes helps us realize that they are not 100% real.

Our experiences are the real part of us. They are our past. But we don't retrospect enough and usually think about the future. Retrospecting and reflecting on our experiences are not difficult; with journaling and writing, they become easy.

Journaling helps to figure out what worked and what didn't. The experience log is the real reflection, and doing it daily makes this reflection more valuable. Because, in the end, we present ourselves as proof of our experience.

Related Note(s):
Source(s): Headspace Meditation App

Reply via email | Reply via Mastodon | Comment

Measuring self-worth comes from negative experiences

Sun, 28 Nov 2021 00:00:00 GMT

When we evaluate ourselves, we put some measurements. Depending on the measure, we feel satisfied, happy, and fulfilled. The measurements directed to self-worth--how much we feel valued by ourselves—usually come from negative experiences. It doesn't arise from how we feel happy or entitled to be happy, but rather what we hide beneath. How we feel about our negative experiences shows us our true self-worth. The person who has high self-worth can look at themself and say; yes, this is where I'm weak or vulnerable.

Related Note(s):
- 30c: Choose good values and good metrics in life;
Source(s): The Subtle Art of Not Giving A Fuck by Mark Manson;

Reply via email | Reply via Mastodon | Comment

Choose good problems to deal with

Sun, 28 Nov 2021 00:00:00 GMT

Happiness without any problems is improbable. Instead of focusing on removing all the problems, we should focus on which problems to tackle. Because if we try to solve every single issue, we won't have any energy left. Additionally, achieving big goals often involves many struggles along the way. By focusing on only certain struggles, we can achieve our goals.

Good goals are more important than others, and they vary from person to person. Upon choosing good problems, we can experience happiness consistently.

Related Note(s):
Source(s): The Subtle Art of Not Giving A Fuck by Mark Manson;

Reply via email | Reply via Mastodon | Comment

Software Architecture Styles

Sun, 28 Nov 2021 00:00:00 GMT

Entries:
- Layered Software Architecture;
- Pipeline Architecture Style;

Related Note(s):
- 42b: Systems and Design Thinking;

Reply via email | Reply via Mastodon | Comment

Layered Software Architecture

Sun, 28 Nov 2021 00:00:00 GMT

Open/Closed Layers in Layered Architecture

In a layered architecture, there are two kinds of layers: open and closed. In closed layers, the request comes from the above layers and has to go through all closed layers one by one to reach simple data in the bottom layer. For example, if the presentation layer only needs a simple string from a database, the request has to pass through all closed layers.

In open layers, the request can bypass layers (until it hits a closed layer) and get data from the bottom layer. If we think a presentation layer needs a string again, the presentation can directly request this string from the database without going through all layers (called the fast-lane reader pattern).

Related Note(s):
Source(s): Fundamentals of Software Architecture by Mark Richards & Neal Ford;

Reply via email | Reply via Mastodon | Comment

Layers of Isolation

Sun, 28 Nov 2021 00:00:00 GMT

In layered architectures, we can set up isolation between layers. It means the changes in one layer won't impact or affect any other layers, providing the contracts between layers remain unchanged. This isolation helps the software architect replace any layer with comfort when necessary. For example, a presentation layer developed with Angular can be replaced with React easily without having any impact on the layers below.

Wrappers partially do this job but on the lower levels. Isolating a presentation layer enables us to even use very different languages and frameworks. We should be able to replace Angular with Spring MVC, for example.

Source(s): Fundamentals of Software Architecture by Mark Richards & Neal Ford;

Reply via email | Reply via Mastodon | Comment

Pipeline Architecture Style

Sun, 28 Nov 2021 00:00:00 GMT

In this architectural style, the system is unidirectional. One module follows the other. Pipes connect these modules, which can be a producer (feeds the pipeline with data), filter (manipulates the data that it receives), or consumer (which is the end of the pipeline and can persist the data in a database).

The pipeline architecture is a common strategy in Unix development using pipes |.

The pipeline architecture is simple and cheap since it's monolithic by nature and doesn't have distributed system complexity.

It's fairly testable because of its partial modularity.

The worst part is it's not fault-tolerant. One of the failures in any part causes a complete system failure. Also, it's not scalable and elastic. Although it's possible to make certain functions scale more than others in the monolithic architecture, this operation is very complex.

Source(s): Fundamentals of Software Architecture by Mark Richards & Neal Ford;

Reply via email | Reply via Mastodon | Comment

Putting servers close to clients

Sun, 28 Nov 2021 00:00:00 GMT

The handshake between server and client doesn't cost bandwidth, although it makes a full round trip. Until the connection is open, the bandwidth is zero.

Lowering the handshake fastens the connection. The earlier the handshake ends, the faster the connection starts. To beat this penalty for every connection, we put the servers close to the clients. When the distance is short, the connection starts earlier.

Source(s): Designing Data-Intensive Applications by Martin Kleppmann

Reply via email | Reply via Mastodon | Comment

Accidental Complexity

Sun, 28 Nov 2021 00:00:00 GMT

Accidental complexity happens when teams don't care about their codebase, applications, and systems enough and when they break down tasks in the wrong way. The name accidental also explains that it usually happens unwittingly. The teams unintentionally build up accidental complexity, and it makes their job more difficult to evolve and change the systems. Onboarding becomes more challenging, and technical debt builds up. One way to reduce accidental complexity is through abstraction. Abstraction helps to make code simpler and limits access to in-depth implementation to prevent possible mistakes or wrong usages.

Source(s): Designing Data-Intensive Applications by Martin Kleppmann

Reply via email | Reply via Mastodon | Comment

Monitoring & Inspection to Learn

Sun, 28 Nov 2021 00:00:00 GMT

Embracing inspections/monitoring and third parties to check how you are doing is a good learning mechanism. While they are inspecting, we can ask for a better solution that they already know (and learned) from others. This also looks like a rubber duck programming and pairing as well.

Source(s): Turn the Ship Around;

Reply via email | Reply via Mastodon | Comment

Managing Promotions

Sun, 28 Nov 2021 00:00:00 GMT

As a leader, you're responsible for people and their promotions. If you are making the call for promotion for your team member, then it's easier. If you're not the one who decides on the promotion, you need to learn how to play the promotion game. Every company has different game rules. But regardless of the company, junior people often get promoted at least once in their first two years. As usual, you make the call for promotion with HR; if you don't stop these junior folks, it will be enough with some coaching.

For more senior roles, it's tricky. Find the stretch projects where they need to go beyond their skills and stretch to learn. Give these projects to the people close to the promotion. Together with them, you need to build their case. If you can't find opportunities in your team, then look for other teams and even other companies to help your report grow, even if it means you will lose them.

Source(s): The Manager's Path by Camille Fournier

Reply via email | Reply via Mastodon | Comment

Service Level Agreements/Indicators/Objectives - Percentiles

Sun, 28 Nov 2021 00:00:00 GMT

In software reliability and availability, there are usually vague descriptions. When we say we offer good performance, what does it mean? This is why we use percentiles. Let's think about response times, often used in SLOs, along with percentiles. In SLAs, we define X ms response time in the 95th percentile. To calculate this, put all response times and sort them from fastest to slowest. Pick the 95th one if you have 100 response times. (950th in 1000, and so on) The response time at that exact point defines your performance in the 95th percentile. For example, you can guarantee to serve in 200ms in the 95th percentile. The same applies to 99th and 99.9th percentiles. Pick accordingly from the sorted list. We also talk about the mean in response times. The mean response time is actually the 50th percentile. To find it, pick the middle one in the sorted list, and it shows the 50th percentile. For example, 200ms in the 95th percentile translates into 95% of all requests served faster than 200 milliseconds.

Related Note(s):

Reply via email | Reply via Mastodon | Comment

Consistency Models in Distributed Systems Index

Sun, 28 Nov 2021 00:00:00 GMT

The consistency model is defined as a contract between the software (process) and memory implementation (data store).

Related Note(s):

Reply via email | Reply via Mastodon | Comment

Strong Consistency

Sun, 28 Nov 2021 00:00:00 GMT

Usually, the leader of the multiple nodes serves the data; all read & write operations pass through the leader. This approach ensures that the served data acts like it is served from one node. There is a real-time guarantee for the data. The model is called strong consistency or linearizability.

The leader might not be a leader anymore when a request comes in. That's why the leader always has to check if it is still a leader. Only then can it return data. That's why this checking system adds time.

Related Note(s):
- Data Replication in Distributed Systems;
Source(s):
- Understanding Distributed Systems;
- Software World #24: Understanding Distributed Systems with Roberto Vitillo

Reply via email | Reply via Mastodon | Comment

Eventual Consistency

Sun, 28 Nov 2021 00:00:00 GMT

In the leader-follower data systems, if we don't pin clients to the followers, the clients are able to read data through different followers. The followers might be out-of-date. One follower might be behind the other due to asynchronous data replication. So when a client requests data first from one and then another, the result is different. But as soon as the write operation stops, all followers will eventually be consistent. If the system doesn't require high consistency, this model is good. However, building systems on top of eventually consistent systems is difficult.

Related Note(s):
- DDIA: What is Replication in Distributed Systems;
- Understanding How Database Transactions Work;
Source(s):
- Understanding Distributed Systems;
- Software World #24: Understanding Distributed Systems with Roberto Vitillo;

Reply via email | Reply via Mastodon | Comment

Personal Values

Sun, 28 Nov 2021 00:00:00 GMT

When we have values that define our personality, we always act accordingly. So, our values are actually limiting us. For example, if we value friendship, we will never yell at our friends, even if we really want to. If we value kindness, we will never tell a person that we hate them and never want to see them again, because these are against our values. Besides the good sides of having values, having them limits us. Having no value enables us to be curious and discover new things in life. When we set a new value, we set a new identity that we will try to fit into any chance.

Good values provide a solid direction in life, leading to a better structure and more productive time. However, knowing the side effects and being aware of the limiting behavior is eye-opening. It pushes us to be more careful and mindful of our identities and choices.

Source(s): The Subtle Art of Not Giving A Fuck by Mark Manson;

Reply via email | Reply via Mastodon | Comment

Accepting one thing requires saying no to other things

Sun, 28 Nov 2021 00:00:00 GMT

The focus is fundamental for achieving many things. Sticking to the values is one of them. Accepting a value requires saying no to the things that break the value. For example, if fidelity is one of our values, we will and need to, say no to any cheating in our relationships.

Saying yes and sticking to a thing requires saying no to many other things. Society—especially Western—nudges us to say yes to many things by embracing being part of it. People who say no or don't accept the yes-ism culture are considered outlanders. However, the true value comes from saying no. Always accepting and being in sync with everyone is not achievable, and even trying it is extremely tiring.

"We need to learn to say no to good things to be able to say yes to the great things."

Source(s): The Subtle Art of Not Giving A Fuck by Mark Manson;
Resourced: One Decision That Removes Hundreds of Decisions;

Reply via email | Reply via Mastodon | Comment