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.

Reply via email

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).

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.

Reply via Email

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.

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.

P.S. I’m thinking about forming a book club (mostly without any meetings and only over email). If you’re interested in or want to learn more, reply to this email.

Good to Great

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

Good: This is for men. I know that men are privileged and often whiny about so many things that other genders are rolling their eyes about. And I agree with many of them. But this one is something else. It’s about closeness. It’s about feelings (which many men think they don’t have any). Even if you’re not a man, I recommend reading it: Too many men lack close friendships. What’s holding them back?

Better: I’m a big supporter of Trunk-Based Development. Mattia summarizes well why I support it. I think trunk-based development is a great enabler of AI-agentic development. When you have multiple agents running in parallel, you want them to be merged to the main branch as quickly as possible instead of creating feature branches. I know it’s difficult to maintain discipline with engineers; AI agents will be yet another level. I think we all need to up our game.

Great: There is one thing I aim for with my blog: Slow down. That’s a methodology I believe we should all employ. Om says, “You don’t need to be right; you need to be first in the feed.” That’s the reason why I want to slow down. That’s why I read paper magazines or weekly news (not daily). Find the right. Find a thing that’s less wrong. But I know I’m swimming against a current. The masses follow the latest news; only a few chase after quality, the right thing. Read Om’s piece.

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

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:

1. I add it to Readwise Reader and never open it right away.

2. When I have time later for content (e.g., on the subway), I open the app.

3. I pick a content and skim over it and check if I still find it interesting.

4. If yes, I ask the three questions I shared above.

5. If I answer at least one “yes,” I engage with the content (while ideally taking notes if it’s non-fiction).

6. I move on to the next content.

7. 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.

1. I open the content from the Feed.

2. 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)

3. If I think I want to spend time with it, I move it to Readwise Reader’s Inbox.

4. Clean up the whole Feed by repeating steps 1-3.

5. I open Readwise Reader’s Inbox and find a piece of content.

6. I ask the three questions I shared above.

7. If I have at least one answer with “yes,” I engage with the content (while ideally taking notes if it’s non-fiction).

8. Move on to the next content.

9. 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.

Good to Great

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

Good: I’ve been using reMarkable Paper Pro Move for almost two months now. I also have reMarkable2. I can say that the device is good. I carry it with me everywhere. The only problem is when the outside temperature is near zero degrees Celcius, the device freezes.

Better: The post, “Why I love Trunk Based Development (or pushing straight to master)” is good. Debunks a lot of myths. We’ve been falling into feature branching a lot recently in my team and I would love to practice Trunk-Based Development more.

Great: No great things this time. They are rare. If you have seen one recently, let me know.

Recently, I wrote about

• I shared my notes and review of the book The Obstacle Is The Way by Ryan Holiday.

• Ava wrote this post about offline gaining its value back. I wrote my answer to it.

• Somehow, this post I wrote got quite popular in HackerNews. Thanks for reading!

Until next time,

Candost

Leave a comment

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 is 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 on 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

Leave a comment

Good to Great

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

Good: As you might know that 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 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 I was trying to slow down the time 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 bunch of new ideas as notes to my Zettelkasten. All notes are atomic.

  • Uncertainty and fear can be eliminated by training

  • Perception Shapes Our Reality

  • Three Simple Questions to Collect Feedback

  • Not Learning from Software Failures

  • Don’t trust people’s judgments in conflicts

  • Engineering Managers with a Debugging Mindset

  • Tools for managing managers

  • How to debug a dysfunctional team?

  • Software Engineering Handbook Index

  • Personal Growth Index

  • Engineers have more power than they think

  • Capitalism creates wealth through innovation and productivity

  • Minimizing costs and trading frequency increases market returns

  • Investor returns decrease as market motion increases

  • Management Handbook Index

• 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!

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.

Leave a comment

Until next time,

Candost

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 max three things I found interesting, sorted by 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 tries 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 this week. She uses Wardley Map, Team Topologies, Domain-Driven Design approaches to structure an organization and their systems. Highly recommended!

Leave a comment

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!

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). 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.

Leave a comment

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.

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!

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!

I’ve moved my newsletter to Substack due to Kit increasing its pricing to $390/year, which I’m not willing to pay. Nothing changes for you. All my writing is still on my blog; Substack is only for Mediations.

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.

Leave a comment

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 wrote

I didn’t publish anything. I’m working on a few pieces, but couldn’t polish them enough to share here. Next time!

Until next time,

Candost

P.S. I don’t know how many times I mentioned this blog post in real life.

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.

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.

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.

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

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.

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.​

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.

1. 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?

2. 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.

3. 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.

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.

​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.

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.

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?