Week 9, 2025 - Trust Issues

Week 9, 2025 - Trust Issues
source: Fortepan (1980)

I had an overdue catch-up call with a friend this week. He shared experiences of frustration and shock from a job he recently left. Decades-old codebase, people who built or even understand it long gone, incompetent leadership. When I asked him what did he learn from this experience, after some thinking he summarized it like this: “Companies can survive long if their business numbers are OK, despite shitty tech or bad leadership.” This was similar to what I experienced at a job a long time ago. I saw the entire leadership change, destroying the culture we’d built for years, canceling necessary tech investment initiatives, driving away key people from the organization. The business was not thriving, but we survived - for a long time, actually. I think the bigger the company, the more it behaves like a supertanker crossing the ocean. It’s slow to change directions or speed because the built-up momentum dictates where they go.

This quote from Bill Gates resonates with that image: “We always overestimate the change that will occur in the next two years and underestimate the change that will occur in the next ten.” I was sure back then that the company would tank in a year max. I was very wrong, and not because things were going in a right direction that I failed to recognise. No, things were indeed going in a bad direction. But it takes time to get there.

📋 What I learned this week

I made some improvements to my Calendar Colorizing script, the main one being the automatic creation of travel blocks for events that have a valid Location address. I realized I needed this after someone booked a call with me 30 minutes before another meeting – which was at the other side of the city. Won't happen again now that I have appropriate time for travel blocked off automatically.

I feel like there’s a whole industry I’m not familiar with, developing custom Google Workspace solutions for business clients, quite like the VBA contractors back in the day. The tools and APIs are pretty powerful, the language is essentially javascript with a few changes, and you get hosting, authentication, data storage, everything ready to start customizing the office suite used by millions of companies. Extending Google Sheets, for example, automating a previously manual calculation, can mean thousands of dollars in savings for a company – yet I don’t hear much about this industry. I guess it’s less sexy than AI.

Related learning: when working with Google Apps Scripts, one has two choices: write the script right in their web interface or use a local editor and copy-paste. I use Cursor and version control with git, so it’s the latter for me. Still, the Cmd+A, Cmd+Tab, Cmd+A, Cmd+V felt like a lame process every time I changed something.

Enter Clasp!

This open source Google tool allows you to publish files to Google Apps Script, even while watching for file changes and automatically triggering an upload.

If you want to go the extra mile, you can set up Github Actions to publish when there’s a new commit to your main repo, building a true CI/CD environment for Google Apps Script. Nice.

🤔 Articles that made me think

Building Trust Across Cultures

I stumbled upon this older material this week. A year or so ago, someone asked me on an interview how I work with international teams. My answer was based on instincts and experiences, explaining building trust, approaching things with curiosity, setting clear expectations, etc. - but I felt this misses something and I could learn about specific approaches. This is a nice short article explaining the difference between cognitive and affective trust, a useful distinction in multicultural cases.

I also figured this could be a good area where LLMs can shine, so I worked a bit on a prompt to help next time I'm faced with this situation:

You are playing the role of a business consultant who specializes in training leaders for cultural differences in the business context. I'm an Engineering Manager from Hungary, working remotely with a distributed team. My company is international, with an open and straightforward startup culture. One of my new reports is a US developer. I want to build trust with them quickly, being mindful of cultural differences.

As a business consultant, give me 5 things to avoid during making my initial contact, things that would naturally be rooted in my culture and I might do subconsciously, but would be inefficient to build trust, or could even be considered offensive for this person. Then, give 5 things to do instead, actions or gestures that, based on my culture, would be minor, unimportant, or even counterintuitive for me, but could be a great help to speed up the trust-building process with this person.

Replace the bolded text and see the differences - or run it like it is and learn something about Hungarian culture. It’s a fun experiment — but don’t forget that these are generalizations. Always aim to know the person, not stereotypes about their country of origin. For example, my professional behavior is much closer to the US stereotypes because I spent the majority of my career at these kinds of companies.

How the Biggest Crypto Theft Ever Exactly Happened

In case you missed it, the biggest ever crypto robbery happened last week when hackers stole $1.5 billion(!) worth of ETH from Bybit, a crypto exchange. Now that details are emerging, it seems like another sophisticated attack from the Lazarus Group, funding the North Korean missile program.

In short, they used a compromised developer’s machine to deploy a slightly modified frontend code for Safe.eth, the platform used by Bybit to protect their Ethers. The code change specifically targeted Bybit’s cold wallet and was activated by a legitimate transaction, masquing the details from the web interface, which would’ve shown the change that allowed the hackers to drain all the holdings of the cold wallet.

Hacking a third party to deploy malicious code attacking a single specific target with an altered frontend shows an amount of sophistication, planning, and determination that’s scary to see. (Learn more about the Lazarus Group from this amazing BBC podcast; it’s not their first heist that could be in a movie.)

Let’s Ditch Performance Reviews

I love it when my opinion gets challenged because it’s an opportunity to improve or solidify my beliefs. Here, Laura Tacho, CTO of DevDX, proposes getting rid of the bureaucratic time-suck called regular performance feedback cycles and proposes to switch to continuous feedback instead.

I agree with a lot of her points, but I feel like she’s extrapolating the bad parts of the process to make a case. In an ideal culture, based on mutual trust and frequent immediate feedback aimed at improving performance, I still think regular formal feedback (definitely not quarterly though) has more benefits than drawbacks. I wrote about this in my Guide to Effective Annual Feedback article: the process of yearly feedback has values like formal recognition at a big milestone, long-term planning and vision building, and alignment re-enforcement, all with proper documentation, helping the career of the employee within and beyond the organization. Also, seasonal promotion cycles that naturally follow official reviews make it easier for companies to budget costs.

That being said, I agree with all of her points about immediate feedback, avoiding unnecessary bureaucracy, etc. I guess for me, it’s a case of “a little bit of both”.

🤖 Something cool: Claude Code

I played two hours with the recently released Claude Code research preview. It’s a sleek interactive command-line tool to implement chat-based development, an increasingly popular use case, where the AI agent is writing code and executing commands based on discussions with the user. I came up with the following initial prompt:

Let's create a new node.js app that has a simple purpose: display the 10 "hottest" Engineering Management-related articles from various sources. As the MVP, we should start with getting the front page of Hacker News only, though later, we'll have different sources like Reddit, Twitter, etc. We should get articles that are related to Engineering Management, especially focusing on first-time managers, coming from a developer background; or engineers thinking about management. The exact prompt to target what kinds of articles we need should be easily adjustably via some configuration. Once we have a list of articles, let's list them on a web interface. The list should only display the Title (linking to the article) and an LLM-generated summary, again, underlining how and why this is relevant to our target EM audience. Future improvements can be sorting by different criteria, etc; for now let's stay simple. Feel free to ask clarifying questions before jumping on it.

As you can see, I didn’t spend much time on prompt engineering. After this, I got simple questions about hosting (I was fine running things locally but wanted a Docker setup to help a potential release one day), LLM preference (I chose ChatGPT, why not), etc. After these, Claude jumped on the task, creating the directory structure necessary, installing npm packages, creating services, views, routes, all that’s required for this to work. 6 minutes passed without any interaction from me except for OKing all the proposals. Finally, after the sole manual action being creating an .env file with my OpenAI API key, I had a nice-looking web app working on http://localhost:3000.

This was the mind blown moment. 🤯

Sure, it didn’t work as intended yet, for example, it misunderstood requirements, and only created summaries based on the title of the article, but after a simple prompt (“Modify the logic to download the text contents of every linked article, then make summaries and relevance calculations based on that content instead of just the title and the URL.”) Claude Code fixed the problem by adding a html-to-text library and prompts to summarize via OpenAI. I checked, and until this point, I ramped up $2.5 in Claude and $0.9 in OpenAI API call costs. Not really comparable to a developer's salary, is it.

The next step was when everything fell apart.

I wanted to see how we can extend this app by including posts from another source, the Engineering Managers subreddit. After a lot of refactoring and rewriting, all kinds of errors appeared. First, nothing was shown from Reddit, then, when I turned off Hacker News to be able to better debug, at one point it was working fine — but re-adding it hid all the Reddit articles again. Irrelevant articles started to come up from Hacker News, and when I explained the problem, Claude started to soften the requirements and introduce a default 50% relevancy for no apparent reason. I didn’t want to look at the code on purpose; the goal of this experiment was to evaluate how Claude Code can work for a technical but non-coding user. After an hour, I stopped, I failed to fix the app with prompts only.

Final balance: $4.89 for Claude and $1.07 for OpenAI. (Yes, one of my first prompts was implementing caching to avoid repeated LLM queries.)

Feel free to look at the code here if you’re curious.

Lessons?

My experience was very much aligned with what I’m reading on various forums: initial amazement, some struggles when things get complicated, and an increasing risk of reaching a point of complexity when previously working things fail and everything seems to fall apart, from which it’s extremely hard to refactor your way out with prompts. That being said, these are new tools, and we still need to discover and learn how to use them efficiently. One thing seems certain though: who can develop software, and how are they doing it, has changed, irreversibly.

That’s it for today, have a mind-blowing experience this weekend,

Péter

Subscribe to my newsletter

I write about engineering leadership topics.
Sign up to receive new articles.
[email protected]
Subscribe